Desenvolvimento de aplicaes Orientadas a Objeto apoiado por tecnologias Java Parte I

O aumento da complexidade dos softwares, de sua aplicao em diversos setores da sociedade e tambm da grande concorrncia entre empresas de desenvolvimento criou uma preocupao crescente com aspectos do desenvolvimento de sistemas. Assim, questes relativas ao tempo e custo de desenvolvimento, tecnologias utilizadas e ferramentas de apoio so decisivas. A aplicao de boas prticas pregadas pela Engenharia de Software pode auxiliar a atingir esses objetivos, possibilitando a construo de sistemas com um menor custo, mais confiveis e com boa qualidade. Atualmente, a principal prtica adotada pelas empresas de desenvolvimento de software para obter melhorias em seus produtos o paradigma de orientao a objeto. O uso de objetos permite a utilizao de abstraes mais naturais e prximas dos problemas reais, facilitando o mapeamento das solues idealizadas pelos engenheiros de software em modelos e em implementaes computacionais. Entretanto, percebemos que em grande parte desses produtos somente a modelagem de alto nvel feita seguindo este paradigma e apenas em alguns casos esses conceitos so respeitados tambm durante a codificao. Devido escassez de ferramentas e solues que apoiem a orientao a objeto nas diversas etapas de desenvolvimento, observado que frequentes mapeamentos so necessrios para possibilitar o desenvolvimento completo de um sistema. Isto aumenta o risco de insero de defeitos no software. Como principal exemplo temos a questo do armazenamento de dados, onde comum se realizar um mapeamento dos diagramas de classe para o modelo de entidades e relacionamento. Essa abordagem utilizada pelo fato de banco de dados relacionais ser uma tecnologia j madura. Para este caso, seria interessante o uso de uma plataforma de desenvolvimento que evite essa abordagem de mapeamento, permitindo que o mesmo tipo de abstrao possa ser aplicado em todas as etapas do ciclo de vida de desenvolvimento de um software. Baseando-se neste cenrio, ser apresentada a partir desta edio uma srie de artigos descrevendo uma forma de desenvolvermos software utilizando o paradigma da Orientao a Objeto durante todo o seu ciclo de vida, desde a anlise de seus requisitos at a realizao de testes. Nesta primeira parte introduziremos conceitos e tecnologias que sero aplicadas durante a execuo das etapas que compem o ciclo de vida de desenvolvimento de um software. Nos prximos artigos sero apresentadas ferramentas de apoio s tecnologias discutidas nesta primeira parte e um exemplo de desenvolvimento de software, guiado por um modelo de ciclo de vida incremental composto pelas etapas de anlise, projeto, codificao e teste, onde sero aplicados na prtica os conceitos e tecnologias discutidos ao longo da srie.
Tecnologias utilizadas para o desenvolvimento orientado a objeto Para a apresentao de uma abordagem de desenvolvimento de software utilizando o paradigma de orientao a objeto durante todo o seu ciclo de vida, alguns conceitos e tecnologias devem ser selecionados.

Modelagem: para a modelagem de alto e baixo nvel do sistema ser utilizada a modelagem orientada a objeto atravs da linguagem UML (Unified Modeling Language) que consiste em um padro para elaborao da estrutura de projetos de software. Desenvolvimento: Devido s facilidades oferecidas, sua evoluo e amadurecimento, Java foi escolhido como plataforma de desenvolvimento. Essa plataforma fortemente fundamentada nos conceitos de Orientao a Objeto (OO), caracterstica que dificulta o seu aprendizado por desenvolvedores iniciantes que no conhecem a teoria da OO. No entanto, aps vencer a sua curva de aprendizado, as facilidades apresentadas por esta plataforma permitem o desenvolvimento de forma mais simplificada e rpida de diversos tipos de software. Armazenamento: Sero aplicados os conceitos de persistncia de objetos visando mostrar ao leitor uma soluo de armazenamento que evite a criao de complexas sentenas SQL e que permita atender as necessidades de acesso e armazenamento dos dados do sistema.

Iremos introduzir a seguir um modelo de ciclo de vida que pode ser utilizado para guiar o desenvolvimento do software. Para cada etapa do ciclo de vida ser abordada ento uma estratgia para execut-la atravs do paradigma de orientao a objeto e possveis ferramentas (de preferncia gratuitas) que apoiaro essas etapas. O uso de ferramentas ao longo do desenvolvimento resulta em uma maior produtividade da equipe e fornece tambm um conhecimento sobre as atividades a serem realizadas. No entanto, as licenas dessas ferramentas resultam em um custo significativo para as empresas de desenvolvimento. Desta forma, a utilizao de ferramentas gratuitas pode diminuir o custo e consequentemente o preo do produto final. O modelo de ciclo a ser seguido foi inspirado no modelo de ciclo de vida incremental (Figura 4). Esse modelo foi desenvolvido atravs da combinao entre os modelos cascata e prototipao. O desenvolvimento dividido em etapas, denominadas incrementos, que produziro gradativamente o sistema, at a sua verso final. Em cada incremento, todas as etapas bsicas do desenvolvimento de software so realizadas, do planejamento aos testes do sistema. Cada etapa produz um sistema totalmente funcional, apesar de ainda no cobrir todos os requisitos. O modelo incremental apresenta diversas vantagens para o desenvolvimento de um software, especialmente se os requisitos no esto claros inicialmente: O cliente esclarece seus requisitos e incrementos; O cliente pode contar com os servios da A construo de um sistema menor construo de um grande; Se um grande erro cometido, apenas o suas prioridades para os prximos verso j produzida sempre menos arriscada que a ltimo incremento descartado;

Figura 4 Modelo de ciclo de vida incremental Anlise de requisitos Os requisitos consistem em uma srie de sentenas que descrevem de maneira clara, concisa, consistente e no-ambgua todos os aspectos significativos do sistema (objetivos, funes e limitaes) a ser desenvolvido. Para a especificao dos requisitos, o desenvolvedor deve analisar a utilizao especfica do sistema a ser produzido. A especificao deve ser bem documentada, avaliada e deve conter requisitos funcionais e no-funcionais (requisitos de qualidade) do sistema, alm das restries funcionais e de projeto. Ao final dessa atividade o desenvolvedor deve produzir o documento (especificao) de requisitos que guiar o restante do processo de desenvolvimento. Essa especificao deve estabelecer o comportamento visvel do sistema, independente da implementao a ser desenvolvida. Nesta srie de artigos ser utilizada a tcnica de casos de uso para representar os atores e suas aes no sistema. O modelo de casos de uso a ser produzido nesta etapa deve ser acompanhado por um documento com a descrio detalhada das funcionalidades apresentadas neste modelo. Para a definio deste modelo ser utilizada a linguagem de modelagem orientada a objeto UML. Projeto de sistema Nessa etapa, os componentes individuais de software so refinados at o nvel de interfaces, classes e componentes. Detalhes so adicionados, em termos de estrutura de dados e algoritmos, de modo a permitir que os componentes individuais do software sejam futuramente implementados. Para tal, devem ser tomadas decises de projeto, como por exemplo, a definio da base de dados, da linguagem de programao, do padro de integrao e do estilo de interface. Ao final desta etapa, o desenvolvedor deve produzir o documento (especificao) do projeto do sistema. Para a definio das classes do sistema, que ser mostrado na continuao desse artigo, ser utilizado o diagrama de classes definido pela linguagem UML. Em seguida, ser realizado o mapeamento deste diagrama para estrutura da camada de persistncia de objetos para controlar o acesso aos dados no SGBD MySQL.

Codificao O desenvolvedor deve codificar e documentar cada unidade de software usando tcnica de implementao que produzam um cdigo eficiente e livre de erros. Se o projeto elaborado na fase anterior possuir um nvel de detalhe elevado, a etapa de codificao ter seu esforo minimizado, pois muita coisa poder ser gerada automaticamente. Teste O processo de teste centraliza-se em dois pontos principais: as lgicas internas do software e as funcionalidades externas. Esta fase concentra-se na descoberta de erros comportamentais do software e tem como objetivo assegurar que as entradas definidas produzam resultados reais que coincidam com os requisitos especificados. Consideraes Nesta primeira etapa foi descrita uma viso geral sobre os conceitos e tecnologias que apoiam o desenvolvimento de sistemas orientados a objeto. Nos prximos artigos da srie iremos apresentar como as tecnologias analisadas podem ser aplicadas na prtica, alm de mostrarmos possveis ferramentas de apoio atravs do desenvolvimento de um sistema real.

Desenvolvimento de aplicaes orientadas a objeto apoiado por tecnologias Java Parte II Anlise
Nesta segunda parte, iniciaremos o ciclo de desenvolvimento do software seguindo o processo incremental apresentado no artigo passado. Conforme descrito na primeira parte, iremos abordar no restante desta srie somente a execuo de um incremento do processo de desenvolvimento. Para cada incremento, teremos desenvolvido um ou mais mdulos para o usurio. Veremos detalhadamente a etapa de anlise de requisitos (ver Figura 1). Sero apresentados mecanismos para a realizao de suas atividades, ferramentas que a apoiam e sua aplicao em um estudo de caso. A etapa de anlise de requisitos preocupa-se com o entendimento e representao do problema atravs de suas funes e comportamentos. Iniciaremos agora apresentando o estudo de caso que ser utilizado nesta srie de artigos.

Figura 1. Etapa do processo abordada neste artigo. Estudo de Caso Nosso estudo de caso um sistema de automao de locadora de vdeo. Para isto, vamos supor que fazemos parte de uma fbrica de software e recebemos a seguinte solicitao da locadora LocaVD. Objetivos do sistema Melhorar o atendimento ao cliente; Melhorar o controle do acervo; Aumentar segurana das informaes de negcio. Lista de funes Deve permitir a incluso e a excluso de filmes no acervo e de clientes; Um cliente s poder ser excludo do sistema aps a quitao de todos os seus dbitos;

Os filmes do acervo podem ser pesquisados por ttulo, assunto, diretores e/ou principais atores; Os filmes includos no acervo podem ter mais de uma fita ou DVD disponvel para locao; O sistema deve permitir a locao e devoluo de fitas e DVDs; Filmes podem ser classificados em trs categorias: lanamento, catlogo e promoo. Sendo que o valor da locao depende da categoria; O nmero de dias teis que cada cliente poder ficar com os vdeos limitado a trs dias; A locao de vdeos s poder ser realizada caso o cliente tenha no esteja em dbito com a vdeo-locadora; O sistema dever fornecer uma estatstica de locaes de vdeos contendo o ttulo e o assunto dos filmes para um perodo selecionado. Alm disso, o sistema dever fornecer informaes sobre clientes que esto em dbito com a locadora.

Anlise de Requisitos Segundo Shari Pfleeger, requisito uma caracterstica do sistema ou a descrio de algo que o sistema capaz de realizar para atingir seus objetivos. Os requisitos podem servir a trs propsitos. Primeiro, eles permitem aos desenvolvedores explicar seu entendimento de como os clientes querem que o sistema funcione. Em segundo lugar, eles informam aos projetistas que funcionalidades e caractersticas o sistema resultante deve ter. E em terceiro, os requisitos informam equipe de testes o que demonstrar para convencer os clientes de que o sistema est sendo entregue de acordo com o que foi solicitado. Os requisitos podem ser classificados em funcionais e no-funcionais. Um requisito funcional descreve uma interao entre o sistema e seu ambiente informando como um sistema deve se comportar considerando um determinado estmulo. Um requisito no-funcional (ou requisitos de qualidade) descreve uma restrio no sistema que limita nossas opes para criar uma soluo para o problema. A identificao dos requisitos uma parte especialmente importante do processo de desenvolvimento de software. Mas por que to importante? Estudos realizados em mais de 350 empresas sobre seus mais de 8 mil projetos de software indicaram que 31% dos projetos foram cancelados antes de serem concludos. Alm disso, somente 9% dos projetos foram entregues dentro do prazo e no valor estimado para o oramento. Alguns dos fatores apontados como principais causas foram: 1. Requisitos incompletos (13.1%); 2. Falta de envolvimento por parte do usurio (12,4%); 3. Falta de recursos (10,6%); 4. Expectativas no realistas (9,9%); 5. Falta de apoio dos executivos (9,3%); 6. Modificaes nos requisitos e nas especificaes (8,7%);

7. Falta de planejamento (8,1%); 8. O sistema no era mais necessrio (7,5%). Observe que algumas partes do processo de identificao, definio e

gerenciamento dos requisitos esto envolvidos em quase todas as causas. A falta de cuidado com o entendimento, a documentao e o gerenciamento dos requisitos podem levar a uma grande quantidade de problemas: a construo de um sistema que resolve o problema errado, que no funciona como o esperado, ou que difcil para os usurios entenderem ou utilizarem. A etapa de anlise de requisitos composta por um conjunto de atividades que devem ser realizadas dependendo da complexidade do sistema ser desenvolvido. Um exemplo de processo de anlise de requisitos pode ser visto na Figura 2.

Figura 2. Processo de Anlise de Requisitos. Assim, temos: Levantamento de Requisitos: na qual feito um contato com o cliente para definir os requisitos do software a ser construdo e o escopo do projeto; Prototipao: na qual so elaborados prottipos para auxiliar a atividade de levantamento e fechamento do escopo do projeto. Geralmente esta fase necessria quando o cliente no consegue definir com facilidade suas necessidades. Especificao de Requisitos: na qual os requisitos capturados so detalhados de forma a possibilitar o prosseguimento da construo do software nas fases de projeto, implementao e teste; Validao: na qual os requisitos especificados so enviados para o cliente para que este aprove a especificao feita. Como foi dito, a complexidade do problema influencia nas atividades do processo de especificao de requisitos a serem realizadas. No nosso caso, h a necessidade de realizar as atividades de levantamento e especificao de requisitos uma vez que o domnio do problema conhecido e tambm no h a necessidade de criao de prottipos. Para a fase de levantamento, existe uma variedade de tcnicas que podem ser utilizadas. Entre elas podemos citar:

Entrevistas:

uma

das

mais

importantes

utilizadas

tcnicas

para

levantamento de requisitos. Consiste em dilogos entre analistas de requisitos e futuros usurios do sistema para captura de suas necessidades. Laboratrio: onde o analista de sistemas observa como as atividades so executadas no dia a dia da organizao para que ele identifique possveis pontos cuja utilizao de software traga ganho de produtividade. Para este estudo de caso podemos dizer que utilizamos entrevistas como tcnica para detalhamento das funcionalidades especificadas no estudo de caso. Na Tabela 1 apresentada a lista de requisitos funcionais para o estudo de caso apresentado. Percebam que a lista bastante parecida com a apresentada pelo cliente. normal que isto acontea. Mas importante deixar claro aqui que neste passo definimos claramente quais so os requisitos funcionais e o escopo do sistema. Tabela 1. Lista de requisitos funcionais para o estudo caso.

Tendo definido os requisitos funcionais, fazemos sua especificao dividindo o sistema em pequenas partes compreensveis. Para esta atividade, diversos modelos podem ser utilizados. Entre eles, destaca-se o modelo de casos de uso definido pela UML. Diagramas de Casos de Uso Podem ser aplicados para capturar o comportamento do sistema que est sendo desenvolvido e facilitar a comunicao entre desenvolvedores e usurios finais do sistema. Algumas vantagens na visualizao de um sistema em termos de casos de uso so:

Podemos examinar cada caso de uso separadamente e entend-lo sem precisar conhecer todos os detalhes do sistema; Podemos utilizar os casos de uso como base para estimar quanto tempo e esforo sero necessrios para o projeto e codificao do sistema; O desenvolvimento pode ser controlado em termos de casos de uso. Isto , os gerentes podem acompanhar o progresso de cada caso de uso, medida que o sistema projetado, codificado e testado.

O modelo de casos de uso composto principalmente por dois elementos: atores e casos de uso. Casos de uso indicam as funcionalidades do sistema e atores, os papis que executam os casos de usos. Com base nos requisitos apresentados na Tabela 1, foram identificados o ator funcionrio, e os seguintes casos de uso: Efetuar locao de vdeos; Efetuar devoluo de vdeos; Cadastrar clientes; Cadastrar vdeo; Pesquisar vdeos; Pesquisar clientes; Gerar estatstica de locao; Verificar clientes em dbito.

A Figura 3 apresenta o diagrama de casos de uso para o sistema de locadora de vdeos.

Figura 3. Diagrama de casos de uso.

Muitos pensam que feito o diagrama de casos de uso podemos passar para as atividades de projeto, mas isso um engano. O diagrama pouco nos fala sobre como as funcionalidades so processadas ou como o ator interage com o sistema para execut-la. Por isso, o diagrama de casos de uso deve ser acompanhado por

um documento com a descrio detalhada das funcionalidades que ele representa, a especificao dos casos de uso. Especificao dos Casos de Uso Utilizaremos um processo de desenvolvimento iterativo onde para cada iterao, feita a especificao de alguns casos de uso, ajustes na modelagem, implementao e teste. Para a seleo dos casos que iro compor a primeira etapa de iterao, foi realizada uma anlise sobre os casos de uso identificados de acordo com sua importncia e o seu risco de desenvolvimento, que consiste na gravidade do impacto causado por possveis falhas no desenvolvimento (ver Tabela 2). Tabela 2. Anlise dos casos de uso.

Considerando as variveis risco de desenvolvimento e importncia para o negcio e tambm por razes didticas, escolhemos os casos de uso Cadastrar Vdeo e Efetuar Locao. Por possurem nvel de importncia e risco de desenvolvimento definidos como alto, essas funcionalidades necessitam de uma maior preocupao por parte da equipe envolvida no desenvolvimento em fases iniciais do projeto. Antes de efetuarmos a especificao, necessrio definir quais os pontos importantes de serem descritos em uma especificao de casos de uso. Estes pontos esto relacionados com: a prpria necessidade de descrever as funcionalidades do sistema; a fase de projeto e implementao, e; a elaborao de casos de teste.

E so, para cada caso de uso: Descrio do objetivo do caso de uso; Descrio dos atores envolvidos no caso de uso; Domnio e propriedade de atributos utilizados pelo usurio; Excees; Interao entre ator e sistema; Regras de negcio existentes;

Requisitos no funcionais.

Com estas informaes, iremos descrever os casos de uso da primeira iterao (verTabelas 3 e 4). Tabela 3. Especificao do Caso de Uso Cadastrar Vdeo.

Tabela 4(A). Especificao do Caso de Uso Efetuar locao de vdeos.

Tabela 4(B). Especificao do Caso de Uso Efetuar locao de vdeos.

At aqui utilizamos duas ferramentas. Uma para a criao do diagrama de casos de uso e outra para a especificao. A especificao pode ser feita em qualquer editor

de texto, fica ento a cargo do leitor escolher um de sua preferncia. Quanto ferramenta de modelagem, existe uma gama de opes: Rational Rose, Argo UML, Visual Paradigm e Poseidon dentre outras.

Desenvolvimento de aplicaes orientadas a objeto apoiado por tecnologias Java Parte III Projeto
por Arilo Cludio Dias Neto e Rafael Ferreira Barcelos Nesta etapa abordaremos a fase de projeto de sistema (Figura 1). Veremos especificamente o que deve ser feito para se definir as modelagens comportamentais, estruturais e arquiteturais de um sistema. Durante a definio da arquitetura, ser mostrado tambm como os conceitos de camada de persistncia so integrados na arquitetura e no projeto de um sistema. Ao longo desse artigo, os conceitos discutidos sero aplicados no desenvolvimento do estudo de caso. Para apoiar as atividades apresentadas nesse artigo, mecanismos e ferramentas tambm sero apresentados.

Figura 1. Etapa do processo abordada neste artigo. Projeto de sistema O projeto consiste na transformao dos requisitos identificados para um sistema em uma soluo de software especfica. Nesse momento, descrito como as funcionalidades identificadas na especificao de casos de uso podem ser implementadas. Assim, um projeto descreve a configurao de hardware, as necessidades de software, as interfaces de comunicao, a entrada e sada do sistema, a forma como os diferentes mdulos que compem a arquitetura se comunicam, e outras coisas que permitam a traduo dos requisitos em uma soluo para o problema do cliente. Vale ressaltar aqui que para um conjunto de requisitos, no existe somente um tipo de projeto possvel. Diversos fatores contribuem para a escolha das caractersticas do projeto a ser desenvolvido, como: experincia da equipe de desenvolvimento, requisitos no-funcionais, prticas organizacionais, estratgia de negcio e o conhecimento do projetista. Existem vrias formas de se projetar um sistema. A escolha do projeto orientado a objetos ocorreu devido s facilidades em usar essa abstrao na definio da arquitetura e no desenvolvimento do sistema. A utilizao desta abstrao

simplifica o mapeamento entre elementos da arquitetura para os elementos que iro compor o sistema. Durante a definio do projeto orientado a objetos do estudo de caso, os seguintes passos sero seguidos: deciso de projeto, modelagem estrutural, modelagem conceitual e modelagem arquitetural. Porm, antes de abordamos esses passos, apresentaremos os principais conceitos referentes ao paradigma da orientao a objetos com o intuito de facilitar o entendimento desta etapa do processo. Conceitos Bsicos de Orientao a Objetos Quando utilizamos o paradigma OO no desenvolvimento de um sistema, as principais abstraes que devem ser utilizadas para a formao de um software so os objetos, que representam as principais entidades do domnio do problema e, as mensagens que representam a forma pela qual os objetos se comunicam. Veremos a partir de agora com um pouco mais de detalhes estes conceitos. Objeto Objeto a abstrao de um elemento do mundo real utilizado durante a modelagem e codificao de um sistema segundo a abordagem orientada a objetos. Um objeto modelado somente com os conceitos da entidade real que so necessrios para o sistema do qual ele faz parte. Diferente da abordagem estrutural, onde os programas so compostos por procedimentos que manipulam estruturas de dados (Figura 2a), em orientao a objetos o foco so os objetos. Essas entidades so compostas por atributos, que representam seus dados, e por mtodos, que indicam a forma como os atributos de um objeto podem ser manipulados e como esses objetos se comportam em relao ao ambiente em sua volta (Figura 2b).

Figura 2. Diferena entre abordagem de projeto. (a) estrutural (b) orientada a objetos Classes Durante a especificao do projeto, os objetos devem ser modelados a fim de determinarmos exatamente suas propriedades. Em muitos casos, podem existir

vrios objetos que se comportam de maneira semelhante e que se diferenciam somente pelo valor de seus atributos. Um exemplo retirado do estudo de caso apresentado nessa srie de artigos seria, por exemplo, os vdeos encontrados em uma locadora. Todos os vdeos podem ser caracterizados com as mesmas informaes (ttulo, elenco, direo, gnero, etc), o que possibilita a definio de um molde comum a todos eles. Esse molde representa a classe vdeo. Assim, uma classe consiste em uma abstrao utilizada para representar objetos com a mesma estrutura. Durante a sua criao, definimos quais os atributos e mtodos que a compe. A partir de uma classe, vrios objetos podem ser criados. Herana Herana um mecanismo presente na modelagem de relaes entre classes. Esse mecanismo permite a definio e a implementao de uma classe (subclasse) que se baseia na definio de outra classe, previamente definida (superclasse). Para entendermos melhor temos o seguinte exemplo, se B for uma classe que herda as operaes de A ento B considerada a subclasse ou a classe derivada e A considerada a superclasse ou classe base (Figura 3). Neste caso, a classe B possui a mesma definio de A, ou seja, os mesmos mtodos e atributos, alm das definies especficas a B. Com isso, podemos dizer que um objeto da classe B tambm uma instncia de A, e dessa forma, onde a classe A for usada B poder ser tambm usada.

A herana utilizada em casos onde diferentes classes possuem muitos mtodos e atributos em comum. Nestes casos, uma classe pai pode ser criada com as caractersticas comuns a essas classes, deixando explcitos os atributos e propriedades comuns s subclasses. Polimorfismo Com o uso de conceitos de herana, logo percebemos a necessidade de que uma mesma mensagem receba tratamento diferente dependendo do objeto receptor (o que fornece um servio). Em OO, esse conceito recebe o nome de polimorfismo. Por exemplo, em um sistema bancrio existem diferentes tipos de contas onde uma das possveis operaes a realizao de saques. Porm, a implementao da

operao de saque difere de acordo com o tipo de conta movimenta (corrente ou poupana). Encapsulamento Encapsulamento uma propriedade bsica de um objeto. O encapsulamento em objetos define a restrio de acesso aos dados e s informaes dos objetos. Com essa restrio, o acesso pode ser realizado somente atravs de servios especificados como pblicos em cada objeto. O conjunto desses servios forma a interface de um objeto. A principal vantagem em encapsular as propriedades est na limitao dos tipos de operaes que podem ser realizadas nos dados de um objeto, o que facilita a manuteno da integridade dos dados. O conceito de encapsulamento est ligado com os conceitos de mtodos pblicos e mtodos privados. Os mtodos pblicos so aqueles que fazem parte da interface do objeto, ou seja, so acessados por outros objetos. Os mtodos privados so aqueles procedimentos que s podem ser executados pelo prprio objeto e por mais ningum. Relacionamento entre objetos Um objeto sozinho possui capacidades limitadas. Qualquer sistema complexo deve ser composto por vrios objetos de diferentes classes que interagem entre eles. Em sistemas OO, essa interao ocorre quando um objeto envia mensagens a um objeto receptor para que ele realize um servio disponvel. Se um objeto utiliza algum servio de outro objeto, existe uma associao entre esses dois objetos. Um outro tipo de relacionamento comum entre objetos a agregao, que reflete o relacionamento todo/parte de. Aps abordarmos os principais conceitos relacionados orientao a objetos, daremos incio descrio dos passos que devem ser seguidos durante a definio de uma arquitetura atravs de um projeto de software orientado a objeto. Para exemplificar esses conceitos, o estudo de caso do sistema de Locao de vdeos ser utilizado. Deciso de Projeto Durante as tomadas de deciso de um projeto, conceitos e tecnologias comeam a ser definidos. Para listar as razes das escolhas realizadas durante esta etapa, justificativas devem ser apresentadas sobre cada deciso relativa s tecnologias e abordagens utilizadas para o desenvolvimento do sistema. Como exemplo de decises podemos citar a escolha do paradigma de desenvolvimento, estilo arquitetural, a forma de acesso aos dados, plataforma de desenvolvimento e banco

de dados. No contexto do estudo de caso do sistema de locao de vdeos, a Tabela 1 lista as principais decises tomadas e suas respectivas justificativas. Tabela 1. Decises e suas justificativas para o estudo de caso.

Deciso Escolha Justificativa Paradigma de desenvolvimento Orientao a Objetos Razes didticas o artigo busca descrever o desenvolvimento completo de um sistema seguindo este paradigma Plataforma de desenvolvimento Java Linguagem de programao orientada a objeto, gratuita e que permite explorar os conceitos de camada de persistncia Estilo Arquitetural Stand Alone Opo dos desenvolvedores para o estudo de caso. Poderia ser cliente-servidor, Web, etc. Banco de dados MySQL SGBD estvel e gratuito

Modelagem Estrutural A modelagem estrutural objetiva a representao dos aspectos estticos do sistema e os principais elementos que fazem parte do problema, assim como suas propriedades e seus relacionamentos. Esses elementos so conhecidos como classes. Na fase de projeto de sistema, a UML define dois possveis diagramas para a modelagem estrutural de um sistema: diagrama de objetos e diagrama de classes. Para maiores detalhes sobre como elaborar um diagrama de classes, recomendamos a leitura do artigo Projeto de software utilizando UML da edio 13 da SQL Magazine. Para o estudo de caso apresentado nesta srie, ser construdo o diagrama de classes de todo o sistema.

Diagrama de classes
O diagrama apresentado na Figura 4 apresenta o conjunto de classes definido para o nosso estudo de caso. A partir dos requisitos do sistema, foram identificadas quatro classes: Cliente: pessoa que realiza emprstimos na locadora. Cliente deve estar cadastrado no sistema antes da realizao de um emprstimo; Filme: obra cinematogrfica que disponibilizada para locao atravs do sistema; Vdeo: uma cpia de um filme em um meio fsico (DVD ou VHS). Um vdeo est sempre associado a um filme previamente cadastrado; Emprstimo: operao realizada por clientes para locao filmes, feita atravs disponibilizao de um vdeo do filme escolhido. As associaes e cardinalidade do diagrama representam as seguintes informaes: Um filme pode possuir vrios vdeos (cpias), porm um vdeo est obrigatoriamente associado a um nico cliente; Um cliente pode realizar vrios emprstimos, porm um emprstimo est associado a um nico cliente;

Um vdeo pode ser emprestado vrias vezes (contanto que em momentos diferentes), da mesma forma que um emprstimo pode conter vrios filmes.

Figura 4. Diagrama de Classes. Modelagem Comportamental A modelagem comportamental de um sistema especifica a viso dinmica do sistema. Na fase de projeto de sistema, a UML define quatro possveis diagramas para a modelagem comportamental de um sistema: diagrama de sequencia, diagrama de colaborao, diagrama de estado e diagrama de atividades. Para o estudo de caso apresentado nesta srie, sero construdos os diagramas de sequencia relativos aos casos de uso selecionados para a primeira iterao do processo, conforme apresentado no segundo artigo desta srie. A deciso em especificar somente um tipo de diagrama est relacionada com as dvidas e complexidade do problema. Se os casos de uso forem complexos, com mltiplas interaes de atores ou vrios estados que um objeto possa assumir, aconselhvel especificar principalmente os diagramas que permitam uma melhor visualizao dessas propriedades (no exemplo citado, diagrama de sequencia e diagrama de estado, respectivamente). Vale lembrar que a UML no impe a utilizao de seus 10 diagramas, ela recomenda a criao dos diagramas que o

projetista achar mais relevante de acordo com o sistema que estiver sendo desenvolvido. Diagrama de Sequencia um diagrama de interao que d nfase ordenao temporal das mensagens. Um diagrama de sequencia mostra o conjunto de objetos e as mensagens trocadas entre esses objetos. As Figuras 5 e 6 apresentam os diagramas de sequencia para os casos de uso Cadastrar Vdeo e Efetuar Locao de Vdeo do nosso estudo de caso. Para maiores detalhes sobre como construir esses diagramas, sugerimos a leitura do artigo Projeto de software utilizando UML publicado na edio 13 da SQL Magazine.

Figura 5. Diagrama de Sequencia para o caso de uso Cadastrar Vdeo O diagrama da Figura 5 representa a interao entre o sistema e o ator funcionrio atravs da representao temporal das atividades de acordo com a especificao do requisito apresentada no segundo artigo desta srie. Inicialmente, o ator funcionrio preenche as informaes sobre o novo vdeo e as envia classe Controle. Esta classe solicita ao sistema a verificao da existncia do filme, e caso no esteja cadastrado, solicita o seu cadastro no acervo do sistema atravs de uma nova instncia dos objetos Filme e Vdeo. A classe Controle responsvel principalmente pela comunicao entre as classes do sistema e o ator Funcionrio. Esta classe tambm responsvel pelo envio de mensagens relativas a eventos do sistema.

Figura 6. Diagrama de Sequencia para o caso de uso Efetuar Emprstimo O diagrama da Figura 6 representa a interao entre o ator funcionrio e o sistema para a realizao de um novo emprstimo. Inicialmente, o ator funcionrio preenche as informaes sobre o cliente que realizar o emprstimo e as submete classe Controle (responsvel pela comunicao entre o ator e o sistema). Esta classe solicita a verificao da situao do cliente, e caso no esteja em dbito com a locadora, disponibiliza os vdeos disponveis para emprstimo. A classe Controle solicita a criao de um novo emprstimo ao sistema. O funcionrio escolhe os vdeos a serem locados, e ao final a classe Controle calcula e exibe o valor total, a data de locao e devoluo do emprstimo e registra essas informaes no sistema. Modelagem Arquitetural A modelagem arquitetural de um sistema visa descrever a arquitetura fsica do sistema. Essa arquitetura exibe a decomposio detalhada do hardware e software que compem a implementao do sistema. Ao utiliz-lo, objetivamos mostrar o mapeamento da estrutura lgica de classes para uma arquitetura em termos de componentes, especficas, ou seja, atravs e de mdulos se que possuem atravs funcionalidades de interfaces. independentes que comunicam

A UML define dois possveis diagramas para a modelagem arquitetural de um sistema: diagrama de componentes e diagrama de implantao. Para o estudo de caso apresentado nesta srie ser construdo o diagrama de componentes de todo o sistema.

Diagrama de componentes Este diagrama empregado para a modelagem da viso esttica de implementao de um sistema. Isso envolve a modelagem de itens fsicos que residem em um n, como executveis, bibliotecas, tabelas, etc. Com esse tipo de representao, temos ideia do funcionamento do sistema computacional. Alm do diagrama (Figura 7) aconselhvel, tambm, uma descrio de cada componente da arquitetura (Listagem 1) para evitar interpretaes ambguas relacionadas arquitetura e seu funcionamento. Nesta descrio so destacadas explicitamente as funcionalidades dos componentes e sua interface de comunicao.

Figura 7. Diagrama de Componentes do Sistema Listagem 1. Descrio da arquitetura O Sistema de Vdeo Locadora formado pelos seguintes componentes:

o Software de Vdeo Locadora

Parte do sistema responsvel em oferecer interfaces para o usurio para o cadastro de vdeos, pesquisa de ttulos e locao de vdeos. Parte do sistema responsvel em fazer a comunicao com o banco de dados e o software de vdeo locadora. Esse componente disponibiliza a interface JDO para que o software utilize responsvel somente por a abstrao os dados de do objetos. sistema. o MySQL Componente armazenar

Camada de persistncia e JPA Durante a etapa de projeto, uma das atividades que normalmente realizada a criao do modelo relacional. Quando pensamos em acessar dados contidos em um banco relacional para a criao de objetos, a forma que nos vem em mente a execuo de comandos SQL que iro retornar os atributos de tabelas. Com esses dados, o programador pode ento instanciar o objeto desejado. No desenvolvimento de um programa orientado a objetos, o acesso a bancos relacionais faz com que o desenvolvedor deixe de utilizar a abstrao de objetos e necessite conhecer a estrutura do banco ou as interfaces das stored procedures. Alm de ser trabalhosa e consumir tempo de desenvolvimento, essa abordagem necessita que exaustivos testes sejam realizados para evitar que os dados do banco sejam corrompidos e que o mapeamento objeto relacional tenha sido feito de forma conveniente. Uma possvel forma de gerenciar a persistncia dos dados atravs da utilizao de camadas de persistncia de objetos. Com essa abordagem possvel desenvolver aplicaes de forma mais produtiva, sem a necessidade de realizar mapeamentos entre diferentes tipos de modelos (modelo de classes ? modelo relacional). A tarefa de persistir os dados fica transparente ao desenvolvedor, que passa a se preocupar principalmente com a modelagem dos objetos de negcio e sua codificao, enquanto que os dados so gerenciados atravs da camada de persistncia. Para que se utilize uma camada de persistncia, uma configurao prvia deve ser realizada. Essa configurao consiste principalmente em informar camada de persistncia informaes sobre: (1) as classes que sero persistidas e seus relacionamentos (obtidas atravs do diagrama de classe) e (2) como acessar o banco onde os dados sero persistidos. De posse dessas informaes, o gerenciador responsvel pela camada de persistncia cria as tabelas respectivas e disponibiliza mtodos atravs do qual os objetos e os seus respectivos dados podero ser acessados, deixando transparente para o desenvolvedor a forma como as converses entre dados e objetos ocorrem. Visando facilitar o uso de camadas de persistncia em programas Java, a Sun definiu um conjunto de APIs, intitulado JDO (Java Data Object). Essas APIs foram definidas com o objetivo de padronizar a forma de acesso a diferentes camadas de persistncia que adotam esse conjunto de API. Portanto o que diferencia as implementaes das camadas de persistncia que seguem o padro JDO a forma como cada implementao acessa o banco e realiza a converso entre dado e objeto, o que permite a troca dessas implementaes sem a necessidade de alterar o cdigo fonte. Concluso Apresentamos aqui a etapa de projeto do sistema referente primeira interao do processo de desenvolvimento especificado. Pelo estudo de caso escolhido ser um sistema pequeno, foi possvel realizarmos o projeto de toda a arquitetura do

sistema e no somente dos casos de uso escolhidos para a primeira interao do processo. Como pudemos perceber ao longo da especificao do projeto de sistema, esta fase fundamental para o sucesso do restante do seu desenvolvimento, visto que toda a codificao do sistema ser baseada nos modelos gerados nesta etapa. Um erro durante a etapa de projeto pode significar muitas horas de implementao perdidas. At o prximo artigo. Arilo Cludio Dias Neto (acdn@cos.ufrj.br) Bacharel em Cincia da Computao formado na Universidade Federal do Amazonas, atualmente estudante de mestrado na rea de Engenharia de Software da COPPE/UFRJ. Possui 3 anos de experincia em anlise e desenvolvimento de software. Rafael Ferreira Barcelos (barcelos@cos.ufrj.br) Bacharel em Cincia da

Computao formado na Universidade Federal do Amazonas, atualmente estudante de mestrado na rea de Engenharia de Software da COPPE/UFRJ. Possui 3 anos de experincia em desenvolvimento de sistemas para Desktop e para Web utilizando Java como plataforma.

Desenvolvimento de aplicaes orientadas a objeto apoiado por tecnologias Java Parte IV Codificao
por Arilo Cludio Dias Neto e Rafael Ferreira Barcelos No primeiro artigo desta srie, apresentamos uma viso geral sobre os conceitos e tecnologias que apoiam o desenvolvimento de sistemas orientados a objetos. Definimos tambm o processo de desenvolvimento que tem sido seguido durante essa srie.

No segundo artigo, descrevemos o estudo de caso que estamos utilizando para explicar ao leitor a aplicao dos conceitos de OO e das tecnologias baseadas na plataforma Java. Foi iniciado ento um ciclo de desenvolvimento de software para resolver o problema proposto e comeamos a lidar com ele realizando a etapa da anlise.

No terceiro artigo da srie, abordamos a fase de projeto de sistema, onde foi visto detalhadamente o que deve ser feito para se definir as modelagens comportamentais, estruturais e arquiteturais de um sistema. Durante a definio da arquitetura, mostramos como os conceitos de camada de persistncia so integrados na arquitetura e no projeto de um sistema.

Ao longo desse artigo ser apresentada a fase de codificao do software (Figura 1). Para esta fase, descrita a configurao da camada de persistncia de objetos utilizada pelo estudo de caso apresentado nos artigos anteriores (sistema para uma vdeo locadora) e tambm a transformao dos modelos de projeto, definidos previamente, em cdigo na linguagem Java.

Figura 1. Etapa do processo abordada neste artigo. Criao da Camada de Persistncia

Como visto no artigo anterior, a fase de projeto responsvel pela especificao dos modelos estruturais, comportamentais e arquiteturais de um software. Em relao ao modelo arquitetural, optamos pela utilizao de camada de persistncia de objetos como mecanismo para garantir a persistncia dos dados da aplicao. Uma vez escolhida esta opo, o primeiro passo a ser realizado na fase de

codificao consiste na configurao da camada de persistncia e instanciao da base de dados do sistema. Existem vrios produtos no mercado que implementam a especificao JPA para persistncia de objetos. Uma descrio mais abrangente sobre os conceitos e vantagens em utilizar essa API apresentada num Apndice desta apostila. Aps essa escolha, para que os conceitos de persistncia sejam utilizados na codificao, uma srie de configuraes e inicializaes devem ser feitas. Em um primeiro momento, as classes a serem persistidas devem ser selecionadas para que ento a estrutura do banco seja montada a partir dessas classes. Uma compilao desses arquivos se faz necessrio na qual as classes a serem persistidas sero transformadas em bytecode e onde instrues sobre o funcionamento da persistncia sero embutidas (Nota 1). XXXXXXXXXXXXXXXXXXXXXXXXXXXXX 3. Utilizando a ferramenta JDO Genie

Aps a compilao das classes previamente geradas atravs do Poseidon, podemos utilizar a ferramenta JDO Genie para criar e configurar a camada de persistncia para a aplicao. Para iniciar a ferramenta, o arquivo /workbench.bat deve ser executado. Para se dar incio configurao, um novo projeto deve ser selecionado. Essa seleo implica no surgimento de uma seqncia de telas que devem ser preenchidas. Durante o preenchimento dessas telas, as principais informaes solicitadas so referentes ao projeto (Figura 4), ao banco de dados que ser utilizado (Figura 5) e s classes que sero persistidas. Algumas dicas sobre estas etapas esto descritas na Nota 5. Nota 5 Dicas para configurao da ferramenta JDO Genie As dicas apresentadas so referentes ao preenchimento das informaes sobre projeto e banco de dados: ? Em relao ao Projeto, assumindo que as classes geradas pelo Poseidon esto no diretrio /src, aconselhvel que o ProjectBaseDir (Figura 4) aponte para o diretrio . ? Em relao ao banco de dados, os campos User Name e Password (Figura 5) devem ser preenchidos com as informaes do usurio e senha do MySQL.

Figura 4. Informaes sobre o projeto.

Figura 5. Informaes sobre o banco de dados. Aps o preenchimento dessas informaes, o JDO Genie exibe as classes existentes no diretrio /src, para que o desenvolvedor selecione aquelas que devero ter seus dados persistidos (Figura 6). Em seguida, a ferramenta faz uma anlise da estrutura dessas classes visando identificar possveis incompatibilidades na codificao. Caso algum problema seja identificado, a interveno do usurio solicitada.

Figura 6. Selecionando as classes que sero persistidas. Os principais problemas que podem surgir so referentes forma como os relacionamentos mltiplos entre as classes foram definidos. Em Java, utiliza-se principalmente collections (representao do conceito de um conjunto de elementos) para representar uma lista ou conjunto de elementos quando existe uma relao um-para-muitos ou muitos-para-muitos entre duas classes. Usando esse tipo de estrutura, a linguagem trata esses elementos com se fossem objetos genricos. Contudo, a ferramenta JDO Genie necessita saber exatamente quais os tipos de elemento que formam esse conjunto. Para isto ela disponibiliza a funcionalidade de indicar o tipo de relacionamento e o tipo das classes que participam desse relacionamento. A forma como JDO Genie informa os pontos em abertos consiste na apario de uma janela aps o final da configurao de um projeto. Um exemplo dessa tela pode ser vista na Figura 7, onde JDO Genie apresentou alguns pontos em aberto sendo que um deles consiste na definio do relacionamento entre as classes Cliente e Emprstimo. De acordo com o que foi especificado no diagrama de classe, um Cliente pode realizar vrios Emprstimos mas esse conceito codificado atravs de um atributo da classe Cliente do tipo Collection chamado de emprstimos. Porm, como foi dito anteriormente, ao processar essa informao, o

JDO Genie no consegue deduzir automaticamente o tipo de relacionamento e solicita ao desenvolvedor que alguns esclarecimentos sejam feitos. Por exemplo, qual tipo de objetos contm esse elemento Collection (nesse caso composto por vrias instncias de Emprstimo) (Figura 7A) e solicita tambm o tipo de cardinalidade entre essas duas classes, nesse caso um-para muitos (Figura 7B).

Figura 7. Especificando (A) o tipo e (B) a cardinalidade do relacionamento entre Cliente e Emprstimo. Aps isso, deve-se gerar a estrutura do banco de dados atravs da funcionalidade disponibilizada pela ferramenta JDO Genie atravs da opo create-db. Em seguida a opo compile deve ser selecionada para que as classes persistidas sejam compiladas junto com as informaes de persistncia configuradas (Figura 8). Essa compilao realizada pelo JDO Genie tambm conhecida como Enhancement cujo conceito foi descrito nas sees anteriores. A Nota 6 descreve a seqncia de passos a serem seguidos caso haja a necessidade de se realizar modificaes nas classes a serem persistidas aps a gerao do banco de dados.

Figura 8. Compilando e criando a estrutura do banco Nota 5 Atualizar as classes persistidas Caso seja necessrio realizar modificaes nos atributos ou mtodos das classes persistidas e deseja-se que essas modificaes sejam refletidas no banco de dados, os seguintes passos devem ser realizados: 1. Realize a modificao no arquivo .java; 2. Compile as classes modificadas; 3. Na ferramenta JDO Genie, faa File->Reload classes para atualizar as mudanas; 4. Execute o create-db e o compile para atualizar o banco de dados (Figura 8). Observao: Realizando esses passos, as informaes que j estiverem cadastradas no banco sero perdidas. Isso ocorre pelo seguinte motivo: com as mudanas estruturais nas classes, as tabelas que representam essas classes so tambm alteradas, e para evitar problemas de integridade relacional o JDO Genie adota a poltica de apagar esses dados. Particularmente, achamos que essa poltica adotada uma limitao da ferramenta. Aps essas etapas, a camada de persistncia est configurada e o passo seguinte consiste na codificao dos mdulos que utilizam essas classes. Codificando o Sistema A codificao foi considerada durante muito tempo como a principal etapa do desenvolvimento de um software, porm, aps vrias pesquisas, especialistas demonstraram que o tempo de codificao pode representar somente entre 8% e 16% do esforo total de desenvolvimento do sistema, considerando que as etapas de anlise e projeto tenham sido realizadas de forma completa. A diminuio desse esforo ocorre pelo fato de que as etapas anteriores codificao buscam adquirir uma maturidade sobre o problema, fazendo com que solues sejam especificadas antes que a codificao seja iniciada. Desta forma, evitamos retrabalho ocasionado por constantes alteraes na soluo proposta no momento de sua implementao. Com isso, a tarefa de pensar na soluo para o problema e de como essa soluo ser implementada no mais da responsabilidade do programador e sim do analista ou projetista. O papel do programador ser somente o de transformar os modelos em cdigo. Um outro motivo para diminuio do esforo envolvido na fase de codificao est relacionado com as facilidades que podem ser alcanadas por se trabalhar com modelos uma vez que isto torna possvel a gerao automtica de cdigo relativo s funcionalidades especificadas. Tambm deve ser levado em considerao quando estamos desenvolvendo um software, principalmente utilizando o paradigma de orientao a objetos em

conjunto com um ciclo de vida incremental, a ordem de implementao das classes do domnio, visto que no h a possibilidade de implementarmos todas as classes simultaneamente. Neste momento, surge a necessidade de criao de stubs. Um stub uma codificao parcial de uma classe que ser implementada em uma prxima iterao, ou seja, somente suas caractersticas bsicas e com esforo mnimo, visando simular o comportamento necessrio para apoiar o funcionamento das demais classes que estiverem sendo implementadas na iterao corrente. Para o nosso exemplo, a necessidade de stub para o sistema de Vdeo Locadora surgir no momento em que a classe Emprstimo for implementada. Como ela depende de duas outras classes (Vdeo e Cliente) e no estaremos implementando a classe Cliente na primeira iterao, haver a necessidade de criar um stub para simular seu funcionamento (Figura 9).

Figura 9. Stub a ser criado para a classe Cliente A Listagem 1 exemplifica a criao de um stub para um mtodo responsvel pelo retorno de um objeto Cliente, onde ser passado o CPF do cliente como parmetro de entrada. O mtodo real deve procurar pelo cliente com o CPF especificado dentro de uma lista, mas um stub simula esse processamento e retorna simplesmente um cliente qualquer, evitando o esforo da construo deste mtodo. Deste modo, este stub est simulando o comportamento do mtodo getCliente que ainda no foi implementado. public getCliente(String CPF) cli = new Cliente(); cli.setNome(Lindsen Dias); car.setEndereco(Manaus-AM); car.setTelefone((92)123-4567); ... return (cli); } Listagem 1. Stub para o mtodo getCliente { Facilidades na codificao Com a evoluo das ferramentas utilizadas nas etapas de anlise, projeto e codificao, muitas facilidades tm sido oferecidas ao desenvolvedor para agilizar, entre outras coisas, a tarefa de codificao de um sistema. Neste artigo utilizaremos a ferramenta NetBeans 4.0 (Nota 7) para a codificao do sistema de vdeo locadora. Esse ambiente foi escolhido por ser um ambiente completo de desenvolvimento voltado para a linguagem Java e por possuir uma licena de utilizao Community Edition que permite seu uso para fins de aprendizado. Veremos a seguir uma descrio desse ambiente. Nota 7 Instalando o Netbeans Para fazer o download do NetBeans acesse o site www.netbeans.org, onde podem ser baixados instaladores dessa ferramenta para diferentes sistemas operacionais. Cliente Cliente

 Descrio do NetBeans A tela principal da ferramenta NetBeans 4.0 composta, principalmente, por quatro reas conforme apresentado na Figura 10. (A) Menu Principal e Barra de Ferramentas: esta rea responsvel pelo acesso s funcionalidades disponveis atravs da ferramenta NetBeans, como a criao de um novo projeto, compilao e execuo do projeto corrente, configurao da ferramenta, entre outras. (B) rea de projeto: representa a estrutura lgica de um projeto. Apresenta os arquivos .java relativos a um projeto utilizando uma abstrao de pacotes e classes. (C) rea de codificao: rea destinada codificao de classes na linguagem Java. Esta rea apresenta as classes abertas para edio em um projeto (JCadastrarVideo e JEfetuarEmprestimo), permitindo que uma classe possa ser visualizada atravs de seu cdigo ou de sua interface (caso possua). (D) Janela de compilao: esta rea disponibiliza o resultado aps a compilao de um projeto atravs da ferramenta. Na Figura 10, esta rea est minimizada. Para maximiz-la basta clicar no boto Output.

Figura 10. Tela principal da ferramenta NetBeans 4.0 para um projeto aberto A ferramenta NetBeans permite a visualizao de um projeto atravs dos arquivos fsicos que o compe. A estrutura de arquivos apresentada a partir do diretrio raiz de um projeto (Figura 11) e contm todos os arquivos existentes a partir desse diretrio.

Figura 11. Sistema de arquivos apresentado pela ferramenta NetBeans 4.0 Uma outra facilidade disponibilizada pela ferramenta NetBeans 4.0 consiste na criao de elementos de interface para um projeto. Para a criao desses elementos, a ferramenta divide a rea de codificao (apresentada anteriormente) nos seguintes elementos (Figura 12): (A) Form de trabalho: consiste no formulrio selecionado para edio atravs da ferramenta. Apresenta a representao grfica do form e seus componentes grficos. (B) API / Componentes: contm os componentes (elementos de interface) que possam ser utilizados em um formulrio, como campos editveis, tabelas, botes. Os componentes so separados de acordo com suas APIs grficas (Swing, AWT, Layouts, Beans, etc). (C) Componentes do Projeto: contm os componentes grficos que esto sendo utilizados para formar a interface grfica da classe codificada no momento. Esses elementos so representados em forma de rvore visando mostrar a hierarquia entre os objetos grficos. (D) Propriedades: contm as informaes sobre um componente selecionado entre aqueles que j fazem parte do projeto. Contm as propriedades, eventos e informaes referentes gerao do cdigo para o componente selecionado.

Figura 12. Criao de elementos de interface atravs da ferramenta NetBeans 4.0 Alm dessas funcionalidades, o NetBeans permite acoplar outras funcionalidades atravs de plugins. Alguns desses plugins so disponibilizados junto com a verso bsica do ambiente, como, o JUnit que permite a realizao de testes de unidade (ser apresentado no prximo artigo dessa srie) e o Ant que realiza automatizao de algumas operaes (Nota 8). Nota 8 Ant nas ferramentas JDO Genie e NetBeans A ferramenta Ant est sendo considerada como um padro de mercado para a automao de atividades de desenvolvimento. Ela realiza tanto operaes simples como a compilao de cdigo, at tarefas mais complexas como a obteno de arquivos via CVS (Sistema de Controle de Verso). O Ant usado tanto por JDO Genie quanto por NetBeans para compilar os arquivos fontes. Porm, como essas duas ferramentas no so integradas, o desenvolvedor deve seguir alguns passos que permitem o funcionamento simultneo dessas ferramentas: NetBeans e JDO Genie usam o mesmo diretrio como diretrio de trabalho, portanto deve-se ter ateno para que os arquivos de configurao do Ant dessas duas ferramentas (build.xml) no sejam sobrescritos. Para isso aconselha-se a renomear o arquivo build.xml (Figura 13) gerado pela ferramenta JDO Genie localizado no diretrio para buildJDO.xml, por exemplo. Aps realizar essa tarefa, devemos atualizar essa modificao no JDO Genie: abra o projeto da locadora no JDO Genie e na opo File ? Project & DataStore properties ? Project ? Ant , no campo Build File atualize o nome do arquivo para buildJDO.xml (Figura 14). Esses dois arquivos realizam tarefas distintas. Usa-se o buildJDO.xml do JDO Genie para realizar principalmente a operao de Enhancement. O arquivo build.xml da ferramenta NetBeans deve ser utilizado para as outras operaes, como execuo e empacotamento. Criando o projeto do sistema de vdeo locadora no NetBeans Para utilizarmos o NetBeans como ferramenta de codificao, deve-se criar, em um primeiro momento, um projeto onde algumas configuraes so feitas referentes ao

sistema que est sendo desenvolvido. Iremos descrever a seguir o conjunto de passos que devem ser efetuados para criar esse projeto e realizar essas configuraes. 1. O NetBeans e JDO Genie utilizam a ferramenta Ant como base para realizar as operaes de compilao. Porm, por esses dois ambientes no serem integrados, algumas aes devem ser realizadas: aps usar JDO Genie para a gerao da estrutura do banco de dados e para realizar o enhancement das classes persistidas, o diretrio de trabalho fica com a composio observada na Figura 13. Para criarmos um projeto usando o NetBeans devemos apagar o diretrio build e renomear o arquivo build.xml (Nota 8);

Figura 13. Diretrio Inicial aps o uso do JDO Genie

Figura 14. Atualizando informaes no JDO Genie 2. No NetBeans, selecione o item de menu File ? New Project. Nesse momento, para uma aplicao Standard so apresentadas quatro opes. Escolhemos ento a opo de Java Project with Exiting sources, pois esta a nica que nos permite trabalhar com cdigo j gerado por outras ferramentas , no nosso caso estamos utilizando os cdigos gerados pelas ferramentas Poseidon e JDO Genie (Nota 9). Nota 9 Funcionalidades do NetBeans A ferramenta NetBeans utiliza o Ant como base para as operaes de compilao e demais operaes como a execuo de casos de testes, por exemplo. Porm, essas funcionalidades s so disponibilizadas ao desenvolvedor se o arquivo de configurao Ant do projeto corrente possuir essas tasks definidas. Como JDO Genie no integrado ao NetBeans, o arquivo build.xml (renomeado para buildJDO.xml) gerado pelo JDO Genie no possui essas tasks, e se um novo projeto

for criado com a opo Java Project with Existing Ant Script , o arquivo do Genie seria usado como arquivo de configurao e muitas funcionalidades que utilizaremos durante a implementao, como a criao de casos de testes, ficariam indisponveis. 3. Em seguida deve ser configurado o caminho do diretrio de trabalho. Uma sugesto est representada na Figura 15.

Figura 15. Configurao dos paths. 4. Aps a criao do projeto, devemos adicionar as bibliotecas (JAR) usadas pelo JDO. Selecione a opo de propriedades do projeto, clicando com o boto direito do mouse sobre o n da rvore que representa esse elemento (Figura 10). Ao abrir a janela, selecione o item Build ? Compiling Sources e adicione o diretrio license que se encontra no e tambm todos os arquivos JAR do diretrio /lib clicando no boto Add JAR/Folder... (Figura 16).

Figura 16. Configurao das bibliotecas 5. A partir desse momento o NetBeans est configurado. Contudo, tivemos que excluir a pasta build com os arquivos que foram criados pela operao de enhancement executada atravs da JDO Genie, para que no houvesse conflito durante a criao do projeto pelo NetBeans (Nota 8). Para gerar novamente esses arquivos, devemos compilar novamente essas classes utilizando o buildJDO.xml, uma vez que ele o responsvel por realizar a tarefa de enhancement. Para isso, selecione a aba Files do NetBeans (Figura 11), selecione o arquivo buildJDO.xml e com o boto direito do mouse selecione a opo Run Target ? compile. Como o leitor pode observar, pelas ferramentas terem sido integradas, mesmo que de forma manual (Nota 8), podemos realizar as operaes presentes no JDO Genie (Figura 8) dentro do NetBeans. No caso do Enhancement, por exemplo, os arquivos sero gerados dentro do diretrio build. Pronto! A partir desse momento o NetBeans permite o uso no projeto das funcionalidades referentes camada de persistncia. A seguir ser apresentado como essas funcionalidades podem ser utilizadas durante a codificao de um projeto. Codificao para o estudo de caso Para ter acesso s informaes contidas no banco de dados durante a execuo do sistema, classes auxiliares disponibilizadas pela API JDO devem ser usadas. Atravs dessas classes possvel realizar todas as operaes bsicas em um banco de dados (insero, alterao, remoo e consulta). Contudo, por ser uma camada de persistncia de objeto, a granularidade utilizada para essas operaes a de objetos, ou seja, essas operaes bsicas no sero realizadas sobre um registro de banco de dados, mas sim sobre um objeto de uma classe do domnio. A seguir ser descrito como essas operaes bsicas so realizadas atravs do uso das classes disponibilizadas pela API JDO. Essa descrio ser ilustrada por trechos de cdigo implementados para satisfazer as funcionalidades do estudo de caso que

est sendo utilizado como base para essa srie de artigos. Desejamos ressaltar que no est no contexto desse artigo descrever como se utilizam os objetos bsicos da linguagem Java, portanto s sero apresentados explicaes sobre a codificao das funcionalidades que envolvem o uso de classes da API JDO. Para demais dvidas, acesse os links interessantes ou faa o download do cdigo fonte disponvel no site da revista. o Estrutura dos pacotes Visando facilitar a organizao das classes do sistema, aconselhvel criar pacotes para agrupar as classes que possuem funcionalidades semelhantes. Para o sistema de vdeo locadora (Figura 17), quatro pacotes foram criados: (1) o core que contm as classes que so persistidas, (2) o factory que contm as classes que encapsulam as funcionalidades de acesso aos dados, (3) o main que possui o arquivo principal e os arquivos de stubs que simulam a existncia de um objeto da classe Cliente no momento da criao de um novo Emprstimo, conforme descrito na Listagem 1, e (4) o pacote ui composto pelas classes que representam a interface grfica do sistema. O arquivo Factory.java do pacote factory ser a principal classe descrita nos prximos tpicos, visto que nela esto codificados os mtodos de acesso camada de persistncia. Esse arquivo foi criado para aumentar o controle do programador sobre as operaes de persistncia, pois utilizando essa abordagem possvel isolar as chamadas s classes pertencentes camada JDO em um nico local. Essa abordagem adotada, onde criada uma classe Factory, consiste em uma sugesto dos autores para o encapsulamento dos conceitos de JDO e foi baseada em boas prticas de programao definidas na literatura.

Figura 17. Configurao das bibliotecas o Inicializando o acesso aos dados da camada de persistncia Para utilizar a camada de persistncia utilizando JDO, o desenvolvedor deve se atentar a algumas configuraes iniciais (veja a descrio da Listagem 1 para saber como isso se traduz no cdigo): ? As configuraes sobre a persistncia devem ser carregadas; ? Um objeto, conhecido como PersistenceManager, que possui o papel de gerenciar os dados deve ser inicializado; ? Antes de realizar alguma operao bsica, deve se ter certeza de que uma transao, representada pelo objeto de tipo Transaction, foi inicializada; ? Aps qualquer operao, para que as modificaes sejam persistidas no banco, o mtodo commit da transao deve ser executado.

Aplicando essa abordagem no sistema de vdeo locadora, uma instncia da classe Factory deve ser criada. Dentro do construtor dessa classe se encontram as configuraes iniciais descritas anteriormente e quando uma instancia dessa classe gerada essas inicializaes so executadas. O cdigo descrito na Listagem 2 mostra quais objetos e mtodos so invocados durante a inicializao de um objeto Factory. //Arquivo: locadora.factory.Factory.java 1: PersistenceManager pm ; 2: PersistenceManagerFactory pmf; 3: Transaction trans; 4: public Factory() { 5: Properties prop = new Properties(); 6: try { 7: prop.load(new FileInputStream("locadora.jdogenie")); 8: pmf = JDOHelper.getPersistenceManagerFactory(prop); 9: pm = pmf.getPersistenceManager(); 10: init(); 11: } 12: catch(Exception e) { 13: e.printStackTrace(); 14: } 15: } 16: public void init() 17: { 18: trans=pm.currentTransaction(); 19: trans.setOptimistic(true); 20: trans.begin(); 21: } Listagem 2. Cdigo de inicializao da camada de persistncia A especificao da JDO exige que as implementaes desse conjunto de APIs tenham uma classe que implemente as funcionalidades do PersistenceManagerFactory. Essa classe obtida a partir da leitura das informaes sobre a persistncia contidas em um arquivo criado pela ferramenta JDO Genie, nesse caso intitulado de locadora.jdogenie (linha 7). Ao criar uma instncia dessa classe (linha 9) pode-se obter um PersistenceManager, atravs do qual as funcionalidades referentes s operaes do banco de dados podem ser executadas. Alm do PersistenceManager, temos que trabalhar tambm com o objeto do tipo Transaction que referencia a transao atual que est sendo executada (linha 18) . A cada alterao, os mtodos commit() ou rollback() desse objeto devem ser invocados caso se deseje, respectivamente, salvar as alteraes ou desfaz-las. o Inserindo um objeto Para inserir um objeto no banco de dados, o primeiro passo consiste em instanciar o objeto desejado. Em seguida, os valores de seus atributos so definidos para que ento o PersistenceManager seja invocado para persistir esse objeto, como pode ser visto na linha 19 da Listagem 3. //Arquivo: 1: 2: 3: 4: 5: 6: 7: locadora.ui.JCadastraVideo.java Object getObject() { video.setTipo(cbTipoVideo.getSelectedIndex()); try video.setValorDiaria(tfValor.getValor()); } catch(Exception e)

public

8: 9: 10: 11: 12: { 13: 14:

private

void

e.printStackTrace(); } return video; } btnSalvarActionPerformed(java.awt.event.ActionEvent evt) video =

(Video) getObject(); Main.factory.save(video); /* Para facilitar o seu uso, o objeto Factory foi definido dentro da classe Main (classe principal do programa) como um atributo pblico que instanciado quando o programa se inicia. Ele pode ser usado em qualquer classe que faa parte do projeto e invocado da seguinte forma : Main.factory */ 15: this.setVisible(false); 16: } //Arquivo: locadora.factory.Factory.java 17: public void save(Video film) 18: { 19: pm.makePersistent(film); 20: trans.commit(); 21: init(); 22: } Listagem 3. Cdigo de insero de um novo Vdeo o Realizando consultas Para executar uma consulta atravs da camada de persistncia, deve-se criar um objeto Query passando como parmetro a classe dos objetos que se deseja obter (linha 3 da Listagem 4). Aps isso, essa Query executada e um Collection retornado com os objetos obtidos. Usando essa abordagem, a consulta retorna todos os objetos do tipo da classe especificado. possvel tambm passar parmetros para essa Query para que se possam obter objetos especficos (mtodo da linha 15 da Listagem 4). Uma propriedade interessante em se usar a camada de persistncia que alm dos objetos retornados diretamente pela consulta, os objetos relacionados tambm so obtidos. Porm, por motivos de performance, o acesso a esses dados no banco s feito no momento que o objeto relacionado for invocado Por exemplo, no caso da Listagem 4, tem um mtodo que retorna Vdeos contudo, dado um desses vdeos, temos acesso ao respectivo filme, que um objeto e um atributo do vdeo escolhido. importante ressaltar que isso ocorre sem a necessidade de realizar uma outra Query. //Arquivo: 1: public 2: { 3: Query q 4: res 5: 6: 7: res 8: 9: 10: 11: 12: 13: return 14: 15: public Vector 16: { locadora.factory.Factory.java Vector getFilmes() Collection res; = pm.newQuery(Filme.class); = null; try { = (Collection)q.execute(); } catch(Exception e) { e.printStackTrace(); } new Vector(res); } getVideobyFilme(Filme parametroFilme) Collection res;

17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30:

Query q = pm.newQuery(Video.class); q.declareParameters(locadora.core.Filme f); q.setFilter(filme == f); res = null; try { res = (Collection)q.execute(parametroFilme); } catch(Exception e) { e.printStackTrace(); } return new Vector(res);

Listagem 4. Cdigo para realizar a consulta de todos os filmes cadastrados o Deletando objetos e realizando alteraes Aps obter um objeto e realizar as operaes requisitadas com esse objeto, a camada de persistncia oferece funcionalidades para que esse objeto seja excludo ou ento persistido no banco de dados visando salvar as alteraes do valor de seus atributos. Para realizar uma excluso (Listagem 5), utilizamos o mtodo do PersistenceManager chamado deletePersitent(), e para persistir as alteraes realizadas sobre um objeto basta que o mtodo commit() do objeto Transaction seja acionado. //Arquivo: 1: 2: 3: 4: 5: 6: } locadora.factory.Factory.java delete(Video vid) { pm.deletePersistent(vid); trans.commit(); init();

public

void

Listagem 5. Cdigo para excluir um video Concluso Apresentamos aqui a etapa de codificao do sistema referente aos mdulos especificados para a primeira iterao do processo de desenvolvimento especificado. Nesta etapa pudemos apresentar como os conceitos associados ao desenvolvimento orientado a objeto, como camada de persistncia, so refletidos no momento da sua codificao. Foram apresentados conceitos e ferramentas que auxiliam nas atividades de desenvolvimento, tornando-as mais simples. Mesmo com a extensa quantidade de passos necessrios para permitir que o NetBeans integre ao projeto as funcionalidades da camada de persistncia, o uso dessas funcionalidades durante o desenvolvimento facilita a atividade de codificao, alm de possibilitar obteno de um cdigo simplificado e de fcil entendimento. O principal ponto que contribui para isso consiste na eliminao de cdigo SQL que passa a ser gerado automaticamente pela camada de persistncia de objetos. Por fim, a ltima fase do processo de desenvolvimento que estamos apresentando consiste nas atividades de teste, onde o objetivo principal a identificao de erros no sistema antes que uma nova iterao seja iniciada ou o sistema seja entregue aos seus usurios finais.

Desenvolvimento de aplicaes orientadas a tecnologias Java - Parte V Teste e Implantao

objeto

apoiado

por

Aps a realizao das fases de anlise, projeto e codificao, o passo seguinte consiste na realizao de testes nos mdulos desenvolvidos minimizando a possibilidade de falhas aps a entrega do sistema aos seus usurios finais. Aps os erros identificados terem sido solucionados, simulamos o trmino do desenvolvimento e chegamos na tarefa final do processo, a sua disponibilizao para o usurio. Ao longo desse artigo ser descrita a fase de teste (Figura 1).

Figura 1. Etapa do processo abordada neste artigo. Realizando testes Teste de software consiste na anlise dinmica do produto, ou seja, na sua execuo com o objetivo de verificar a presena de defeitos e desta forma minimizar efeitos negativos em sua confiabilidade. Devemos nos conscientizar que o desenvolvimento de software uma atividade humana e desta forma passvel de erros, o que torna fundamental a realizao de testes durante seu desenvolvimento. Teste de software orientado a objetos Apesar do paradigma orientado a objetos (OO) permitir construir softwares de melhor qualidade e proporcionar rapidez no desenvolvimento, a realizao de testes nesse paradigma mais complexa devido hierarquia de classes, encapsulamento, polimorfismo, etc. Existem, principalmente, duas tcnicas para a realizao de teste em software: estrutural e funcional. Teste estrutural O teste estrutural tambm conhecido como teste caixa-branca (white-box). Nesse tipo de teste, os casos de teste (so realizados a partir da anlise da estrutura interna do programa. O objetivo dos casos de teste causar a execuo de caminhos identificados no programa (possibilidades de utilizao), baseados no fluxo de controle e/ou no fluxo de dados. Teste funcional O teste funcional tambm conhecido como teste de caixa preta (black box). Os mtodos de teste de caixa preta concentram-se nos requisitos funcionais do software. As tcnicas de teste funcional derivam os casos de teste a partir da anlise da funcionalidade (dados de entrada/sada e especificao) do programa, sem levar em considerao sua estrutura interna.

A abordagem funcional tem o objetivo de complementar a abordagem que as tcnicas do teste estrutural apresentam. As categorias de erros mais evidenciadas pelo teste funcional so: erros de interface, funes incorretas ou ausentes, erros nas estruturas de dados ou no acesso a bancos de dados externos, erros de desempenho e erros de inicializao e trmino. Etapas de teste de software A atividade de teste divida em fases: unidade, integrao e de sistema. etapas. Basicamente, existem trs

O teste de unidade tem por objetivo explorar a menor unidade do projeto, procurando identificar erros de lgica e de implementao em cada mdulo do sistema separadamente. Em softwares orientados a objeto, pode-se ver a menor unidade a ser testada como sendo o mtodo de uma classe. O teste de integrao objetiva descobrir erros associados s interfaces entre os mdulos quando esses so integrados para construir a estrutura do software que foi estabelecida na fase de projeto. O teste de sistema tem por objetivo identificar erros de funes e caractersticas de desempenho que no estejam de acordo com a especificao. A Tabela 1 sintetiza os elementos de software que so objeto de teste em cada fase em um sistema orientado a objeto. Tabela 1. Relao entre as fases de teste e o paradigma de orientao a objetos. Fase de Teste Unidade Integrao Teste orientado a objetos Mtodo Classe Componente Subclasse Toda a aplicao

Sistema

Para esta srie de artigos, iremos abordar somente a fase de teste de unidade. As demais fases de teste no sero abordadas devido aos seguintes fatores: o teste de integrao busca verificar a integrao entre elementos desenvolvidos em iteraes diferentes (e nesta srie estamos realizando somente uma iterao do processo incremental) e o teste de sistema s pode ser realizado aps a concluso do sistema, o que no ocorrer pelo mesmo motivo ser desenvolvida uma nica iterao. Para a realizao de teste de unidade em classes, a plataforma Java possui um framework que permite a sua realizao com um esforo baixo para a criao dos casos de teste, alm da possibilidade de reutilizao dos testes em diferentes programas com caractersticas semelhantes. Este framework denominado JUnit e ser descrito a seguir. JUnit Framework Java para criao de testes JUnit um framework (ambiente de trabalho) que possibilita a criao de testes na linguagem Java. Ele permite a criao de casos de teste para cdigos desenvolvidos na linguagem Java, possibilitando a execuo automtica de testes atravs da uma ferramenta disponibilizada pelo framework ou atravs de ambientes de desenvolvimento, como NetBeans. Alm da automatizao dos testes, esse framework permite a reutilizao dos casos de teste produzidos entre diferentes projetos, diminuindo o esforo da criao dos testes em um projeto.

O JUnit de simples utilizao para a criao das classes de testes. Cada classe de teste criada a partir de uma classe do sistema original, e seus mtodos buscam testar os mtodos dessa classe do sistema. Ele integrado s principais ferramentas de desenvolvimento Java e composto basicamente por: o Uma classe base (TestCase) que deve ser estendida pelas classes que realizaro o teste (SuaClasseTeste) (Figura 2); o Um conjunto de mtodos auxiliares (Assert) para a verificao de asseres que verificam a validade das comparaes (Figura 2); O JUnit disponibiliza uma ferramenta para execuo dos testes (TestRunner). No entanto, esta ferramenta no ser apresentada neste artigo, pois os testes sero descritos atravs da ferramenta NetBeans.

Figura 2. Criando classes de teste. A Figura 2 indica que para criar uma classe de teste do JUnit, necessrio estender a classe TestCase e criar mtodos com o prefixo test. As subclasses de TestCase so automaticamente reconhecidas pelo ambiente de execuo do JUnit, presente junto com o pacote JUnit ou implementados pelas ferramentas que adotam JUnit como framework padro para teste, como o caso do NetBeans. JUnit disponibiliza uma srie de facilidades para a execuo de testes de unidade em cdigos Java, como: Permite a automao dos testes e a implementao das classes e mtodos de testes; Disponibiliza a execuo dos testes de forma visual atravs da interface grfica e textual; Permite criao de testes individuais para os mtodos pertencentes a uma mesma classe; Relato de problemas ocorridos aps a realizao dos testes com identificao especfica de onde ocorreram as falhas. Realizando teste a partir da ferramenta NetBeans Aps a configurao do NetBeans descrita no quarto artigo desta srie (edio 15 da SQL Magazine: Desenvolvimento de aplicaes orientadas a objeto apoiado por tecnologias Java: Parte IV Codificao), a ferramenta cria os pacotes de desenvolvimento, entre os quais est o pacote de Testes (Figura 3).

Figura 3. Pacote de teste na ferramenta NetBeans. Para a criao de uma classe de teste que ir executar o teste de unidade sobre uma das classes do sistema, o seguinte procedimento deve ser realizado: 1. Selecione na rvore de classes do projeto a classe a ser testada; 2. Execute o comando Tools JUnit Tests Create Tests do popup-menu, conforme apresentado na Figura 4. Aps isso, o NetBeans se encarrega em criar uma classe com o nome Test no pacote de testes.

Figura 4. Criando uma classe de teste com NetBeans. Ao criar as classes de teste, a ferramenta NetBeans gera automaticamente em cada classe trs mtodos padres (ver Nota 2): setUp(), tearDown() e suite(). setUp(): o primeiro mtodo que ser executado no incio da realizao dos teste. Nele devem ser inseridos cdigos de inicializao que sejam teis para a execuo dos demais mtodos de teste, como, a criao da conexo com o banco de dados ou a instanciao de objetos utilizados no decorrer do teste de unidade. tearDown(): o mtodo que ser executado aps a execuo de cada caso de teste. Pode ser usado para liberar recursos alocados durante o mtodo de teste. Um exemplo de utilizao deste mtodo pode ser a realizao de persistncia das informaes geradas em cada caso de teste executado.

suite(): um mtodo que cria um cenrio de teste para a classe de teste em questo. Um cenrio de teste consiste na reunio de diversos casos de teste que sero executados em um mesmo momento.

Nota 2. Criao das classes de teste Aps a criao das classes de teste respectivas a todas as classes do sistema a serem testadas, a equipe de teste deve ser encarregada de programar os casos de teste, ou seja, os mtodos da classe de teste. Alm desses mtodos, NetBeans cria um mtodo de teste (caso de teste) para cada mtodo existente na classe original (Listagem 1). Esses mtodos devem seguir um padro definido pelo JUnit: (1) devem retornar void (no retorna valor) (Listagem 1, linha 27) e (2) deve ser finalizado por um dos mtodos da classe Assert (Listagem 1, linha 30) que servem para comparar se o que era esperado foi obtido durante a execuo do mtodo. Os mtodos asserts usados para verificar o resultado da operao dos testes so os seguintes (Figura 2): assertTrue(condio): verifica se a condio atribuda como parmetro um valor verdadeiro. Caso seja, assume-se que o caso de teste foi realizado com xito; assertFalse(condio): verifica se a condio atribuda como parmetro um valor falso. Caso seja, assume-se que o caso de teste foi realizado com xito; assertNotNull(objeto): verifica se o objeto em questo no NULL. Caso o objeto seja diferente de NULL, assume-se que o caso de teste foi realizado com xito; assertNull(objeto): verifica se o objeto em questo NULL. Caso seja, assume-se que o caso de teste foi realizado com xito; assertSame(objeto1, objeto2): verifica se os objetos passados como parmetros so os mesmos. Caso sejam iguais, assume-se que o caso de teste foi realizado com xito; assertNotSame(objeto1, objeto2): verifica se os objetos passados como parmetros so diferentes. Caso sejam diferentes, assume-se que o caso de teste foi realizado com xito; assertEquals(objEsperado,objObtido): verifica se o valor esperado igual ao valor obtido. Caso sejam iguais, assume-se que o caso de teste foi realizado com xito; fail(): assume-se que o caso de teste falhou, independente de clusulas.

Como padro na ferramenta NetBeans, os mtodos de teste criados automaticamente so finalizados com o mtodo fail(), indicando que o teste falhou. A equipe de teste deve ento implementar cada caso de teste, substituindo esse mtodo por um outro adequado. Alm desses mtodos criados automaticamente, outros mtodos podem ser implementados nesta classe como se fossem mtodos de teste. No entanto, devem ser implementados com a mesma estrutura dos demais mtodos j existentes (no retornar valor e deve ser finalizado com um mtodo da classe Assert). Aps a construo dos casos de teste, o passo seguinte consiste na execuo desses testes. Para executar a classe de teste, deve se clicar na classe de teste com o boto direito do mouse e em seguida escolher a opo Run File, (Figura 5).

Figura 5. Executando os testes com NetBeans. Aps a execuo, a ferramenta apresenta os resultados dos testes indicando quais casos de testes foram bem sucedidos e quais falharam. A Figura 6 apresenta os resultados de teste gerado atravs da ferramenta NetBeans indicando quantos casos de teste foram executados e quantos falharam.

Figura 6. Resultados dos Testes em NetBeans. Os passos para a realizao dos testes utilizando a ferramenta Netbeans so esses apresentados. A partir de agora, apresentaremos os testes relativos ao nosso estudo de caso (sistema de vdeo locadora). Testando os mdulos para o estudo de caso Para a realizao dos testes para nosso estudo de caso, optamos pela criao de uma classe de teste. A classe a ser testada Emprstimo foi escolhida por realizar a persistncia de seus objetos em um banco de dados, alm de ter sido desenvolvida nesta primeira iterao do processo incremental que estamos seguindo. Os objetivos da realizao de testes na classe Emprstimo assegurar a corretude dos seus mtodos com relao, principalmente, persistncia dos valores dos atributos a um objeto dessa classe, garantindo assim que informaes no sejam perdidas durante a execuo do sistema. Para a realizao dos testes na classe Emprstimo, foi definido um mtodo setEmprestimoTest (linhas 1 a 26 da Listagem 1) responsvel pela criao e persistncia de um objeto da classe Emprstimo que ser invocado no inicio de cada caso de teste (atravs do mtodo setUp). Aps isto, foram desenvolvidos casos de teste para cada atributo da classe a fim de verificar se os dados do objeto foram persistidos corretamente. A Listagem 1 apresenta tambm o cdigo referente aos casos de teste para o atributo Cliente (linhas 27 a 31) e Data de devoluo (linhas 32 a 36). O cdigo completo para esta classe de teste est disponibilizado no site da SQL Magazine.

//Arquivo: Emprestimotest.java 1: protected void setEmprestimoTest() 2: { 3: emprestimo = new Emprestimo(); 4: cliente = new Cliente(); 5: filme = new Filme(); 6: video = new Video(); 7: dataDevolucao= new Date(); 8: dataLocacao= new Date(); 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: } aluguel = 550.5; status = Emprestimo.ATRASADO; cliente.setCPF("455.456.789-10"); cliente.setNome("Lindsen Dias"); emprestimo.setCliente(cliente); filme.setTitulo("Titanic"); filme.setNumeroCopias(5); video.setFilme(filme); video.setTipo(Video.DVD); video.setValorDiaria(5); video.setAlugado(false); emprestimo.addVideos(video); emprestimo.setDataDevolucao(dataDevolucao); emprestimo.setDataLocacao(dataLocacao); emprestimo.setValorAlguel(aluguel); emprestimo.setStatus(status); factory.save(emprestimo);

/* Caso de Teste para o atributo Cliente da classe Emprstimo */ 27: public void testCliente() 28: { System.out.println("testCliente"); 29: emprestimo factory.getEmprestimo(dataLocacao,dataDevolucao,cliente,video); 30: assertSame(cliente,emprestimo.getCliente()); 31: }

/* Caso de Teste para o atributo Valor de Aluguel da classe Emprstimo */ 32: public void testDataLocacao() 33: { System.out.println("testGetDataLocacao"); 34: emprestimo = factory.getEmprestimo(dataLocacao,dataDevolucao,cliente,video); 35: assertEquals(dataLocacao.getTime(),emprestimo.getDataLocacao().getTime() ); 36: } ... Listagem 1. Cdigo dos casos de teste para os atributos Cliente e Valor de Aluguel da classe Emprstimo. Aps a execuo dos testes para a classe Emprstimo, obtivemos falha na execuo dos casos de teste para dois atributos da classe. Com isso, identificamos que a camada de persistncia utilizada altera os valores relativos aos milisegundos

dos atributos dataLocacao (Listagem 1 linhas 32 a 36) e dataDevolucao durante a persistncia, porm, sem afetar o funcionamento do sistema. Os resultados deste teste, com destaque falha detectada no caso de teste para o atributo dataLocacao, podem ser visualizados na Figura 7.

Figura 7. Resultados dos testes para a classe Emprstimo.

Disponibilizando o sistema para o usurio final Aps o desenvolvimento do software ou de um mdulo funcional, dependendo do que foi acordado com o cliente, os desenvolvedores devem disponibilizar a aplicao aos usurios. Essa atividade, tambm conhecida como deployment, no consiste somente na instalao do cdigo binrio do sistema nas mquinas do cliente. Outras tarefas como a documentao do sistema (criao de arquivos de ajuda) e a realizao do treinamento dos usurios devem ser tambm realizadas. Uma das razes para a execuo dessas tarefas aumentar a familiaridade do usurio com o novo sistema, o que auxilia na diminuio do risco da aplicao no ser utilizada. Contudo, neste artigo ser abordado somente as solues oferecidas pela plataforma Java para a disponibilizao de arquivos binrios ao usurio. Uma soluo para esse problema de extrema importncia, uma vez que, dependendo do tipo de software desenvolvido, pode ser difcil e tambm muito custosa a atividade de deployment do cdigo binrio da aplicao. No caso de um sistema cliente-servidor, por exemplo, se o sistema necessitar que a parte cliente seja instalada em muitos clientes, os custos para se instalar em cada mquina, ou para atualiz-la quando novas verses forem disponibilizadas, podem inviabilizar a realizao dessa atividade. Com o advento da Internet, abordagens de deployment foram desenvolvidas visando facilitar essa tarefa. Uma das abordagens desenvolvidas consiste na atualizao automtica da aplicao quando ela for executada e novas verses forem disponibilizadas pelos desenvolvedores. Para isso, a aplicao acessa um servidor especfico e verifica se uma nova verso foi disponibilizada. Muitos sistemas utilizam essa abordagem como, o MSN e o prprio Windows. No contexto da plataforma Java, foi desenvolvido uma tecnologia chamada de JNLP (Java Network Launching Protocol), que visa facilitar o deployment utilizando a abordagem de atualizao automtica.

Apndices
Apndice 1 Normalizao
Manuel Antnio de Castro Jnior e Pablo Vieira Florentino Armadilhas da modelagem de dados Um esquema de banco de dados relacional deve representar atributos agrupados em tabelas, utilizando-se para isto, ou do bom senso do projetista da base de dados ou de um mapeamento a partir de um esquema conceitual de dados (ER, OO ou ER Estendido) para o modelo relacional. Estes modelos conceituais permitem ao projetista identificar os elementos que formaro o agrupamento lgico das tabelas com seus respectivos campos. Mesmo seguindo alguns procedimentos para realizao do mapeamento entre modelos conceituais e modelo lgico relacional, ainda faz-se necessrio algum tipo de avaliao formal no sentido de identificar esquemas de banco de dados mais bem projetados do que outros. Para que esta avaliao possa ser realizada, uma tcnica foi desenvolvida com o intuito de, dado um esquema de banco de dados, verific-lo e transform-lo para, assim, conceber esquemas de tabelas de dados com organizao mais apropriada. Com esta verificao, almeja-se alcanar um esquema de dados formado por tabelas que possuam as propriedades desejveis para o projeto relacional como distribuio uniforme dos dados sem redundncias, facilidade de conservao da integridade de dados e de manuteno dos dados. Quando estas propriedades no se fazem presentes, alguns problemas podem ocorrer no banco de dados, como a perda da integridade e dificuldade de manuteno dos dados. Para facilitar o entendimento dos passos a serem seguidos para uma modelagem de dados apropriada, sero abordados neste artigo alguns aspectos da normalizao como: anomalias e problemas gerados por uma modelagem no apropriada, como implementar tcnicas que corrijam o modelo da base de dados; como re-elaborar a modelagem para aumentar o desempenho de consultas base de dados. Neste artigo tambm sero apresentados exemplos prticos de modelagens de dados no normalizados, com suas conseqncias negativas, e algumas abordagens prticas de aplicao do processo de normalizao. Engenharia reversa de dados Outro aspecto importante sobre normalizao seu uso na engenharia reversa de dados. O termo engenharia reversa vem do fato de usar-se como ponto de partida do processo de engenharia um produto j implementado (modelo de implementao) para obter sua especificao (modelo conceitual). A engenharia reversa pode ser utilizada com dois intuitos: Apenas construir a especificao do armazenamento de dados; ou facilitar o processo de reengenharia, onde um novo sistema ser construdo para substituir o sistema legado. O conceito de normalizao vital para este processo, pois o principal meio de deteco e eliminao das redundncias de dados presentes nestes arquivos. Neste intuito, as regras de normalizao so aplicadas aos arquivos do sistema e, uma vez normalizados, os diferentes esquemas resultantes da normalizao de cada um destes integrada, gerando o esquema relacional do banco de dados do sistema. Nesta etapa, informaes comuns a diferentes esquemas devem ser identificadas para que seja representada somente uma vez. Por fim, o esquema relacional desenvolvido analisado e, atravs de regras de transformao reversa, este convertido em um esquema conceitual. O resultado final da engenharia reversa de dados , ento, este esquema conceitual. Caso o objetivo seja construir um novo sistema, os diagramas conceitual e relacional so utilizados para construir o banco de dados relacional.

Problemas e anomalias possvel citar como problemas comuns de integridade e manuteno dos dados: Redundncia de dados; Inconsistncia de dados; Anomalia de excluso; Anomalia de incluso; Anomalia de modificao. Estes problemas sero descritos e exemplificados atravs do banco de dados ilustrado na Figura 1. FUNCIONARIO_DEPARTAMENTO MATFUNC NOMEFUNC DATANASC ENDERECOFUNC NUMDEPTO NOMEDEPTO MATGERENTE F1 F2 F3 F4 F5 F6 Helder Antonio Jabes Amorim Arthur Chico 31/08/1978 R.Boca do Rio, D1 27 18/12/1985 R. do Retiro, 33 D2 03/07/1969 R. Vermelha, 21 17/01/1966 R. do Peixe, 78 23/05/1983 Lad. Cabula, 132 D1 D2 D1 Logstica Qualidade Logstica Qualidade Logstica Qualidade F5 F6 F5 F6 F5 F6

28/02/1977 R. Monteiro, 133 D2

FUNCIONARIO_PROJETO MATFUNC F1 F2 F3 F1 F4 F3 NUMPROJ HORAS NOMEFUNC NOMEPROJ PR3 20 Helder P-de-serra PR1 PR2 PR2 PR1 PR3 10 30 15 25 10 Antonio Jabes Helder Amorim Jabes Sisaleira Macaxeira Macaxeira Sisaleira P-de-serra LOCALPROJ Campina Grande, Caruar, Piritiba So Domingos, Stio Novo, Valente Ibicu, Mossor Ibicu, Mossor So Domingos, Stio Novo, Valente Campina Grande, Caruar, Piritiba

Figura 1. Banco de dados no-normalizado. Redundncia de dados Quando um modelo de dados est definido de forma inapropriada, um dos problemas comuns que podem ocorrer a redundncia de dados. A redundncia de dados pode ser definida como uma replicao no controlada de um dado em diferentes partes do banco de dados. Por exemplo, no banco de dados representado na Figura 1, o nome do funcionrio representado pelo campo NOMEFUNC na tabela FUNCIONARIO_DEPARTAMENTO e pelo campo NOMEFUNC na tabela FUNCIONARIO_PROJETO. Em um banco de dados que apresenta este tipo de problema, a manuteno dos dados torna-se complexa. Por exemplo, caso se deseje modificar o nome do funcionrio Helder, necessrio realizar operaes de atualizao nas duas tabelas. Ainda neste exemplo, deve-se atentar para o fato de que na tabela

FUNCIONARIO_PROJETO, dois registros devem ser modificados. Raciocnio anlogo pode ser utilizado para as operaes de insero e excluso de dados, que tambm se tornam complexas, j que devem ser executadas em maior nmero e em diferentes tabelas. Por fim, a redundncia de dados implica tambm em uma maior alocao de espao de armazenamento em disco. Um outro exemplo de redundncia de dados pode ser observado exclusivamente na tabela FUNCIONARIO_DEPARTAMENTO, na qual as informaes sobre diversos departamentos, como nmero, nome e gerente do departamento (respectivamente, os campos NUMERODEPTO, NOMEDEPTO e MATGERENTE) so continuamente repetidas medida que funcionrios para um mesmo departamento so inseridos. O espao em disco necessrio para armazenamento aumenta consideravelmente. Inconsistncia de dados Quando a definio da base de dados determina tabelas com grande redundncia de dados, um outro problema com grande probabilidade de acontecer a inconsistncia dos dados. Por exemplo, ao se incluir um novo registro de funcionrio para o departamento D1 na tabela FUNCIONARIO_PROJETO, por acidente, foi digitado o nome Lofstica. Numa segunda ocasio, tambm acidentalmente, ao inserir um novo registro na tabela, digita-se Logstica. medida que novos registros so inseridos, maior a possibilidade de um erro desta natureza acontecer, fazendo com que o mesmo departamento tenha diferentes nomes, tornando os dados inconsistentes. Neste caso, uma consulta base de dados que envolva estes registros dificultada, pois o usurio do banco deve saber que estes erros podem ocorrer na base. Assim, a consulta Quais so os funcionrios do departamento de logstica? deve incluir todas as possibilidades de nome, Logstica, Lofstica, Logstica e qualquer outra variao do nome do departamento de Logstica como restrio de linhas. Em um pior caso, o usurio pode no ter conhecimento sobre estes erros, realizando uma consulta que retornar menos informaes do que o realmente desejado. Anomalias de excluso Dependendo da forma de organizao das informaes nas tabelas, a excluso indesejada de alguns dados pode acontecer. Neste caso, observando a tabela FUNCIONARIO_PROJETO, se todos os funcionrios alocados em um projeto especfico forem excludos, sero perdidas tambm todas as informaes referentes a este projeto. No caso do projeto Macaxeira, se os funcionrios Jabes e Helder forem excludos da base de dados, todos os dados referentes a este projeto deixam de existir. Anomalias de incluso Neste tipo de anomalia possvel identificar duas dificuldades bsicas. Primeiramente, devemos nos preocupar em manter a consistncia dos dados. Na tabela FUNCIONARIO_PROJETO, por exemplo, ao se incluir um novo funcionrio alocado ao projeto Macaxeira, apesar da base de dados j possuir informaes referentes a este projeto para os funcionrios Jabes e Helder, estas informaes devem ser digitadas novamente. Caso no sejam digitadas corretamente, problemas j ressaltados de inconsistncia de dados ocorrero na base de dados. A outra dificuldade refere-se ao fato de inserir um projeto que ainda no possua funcionrios alocados para o mesmo. Seria necessrio inserir valores nulos ou indevidos para os campos referentes a funcionrio na tabela FUNCIONARIO_PROJETO (MATFUNC e NOMEFUNC). Alm deste, um outro problema gerado: MATFUNC um dos campos que compem a chave primria desta tabela.

Anomalias de modificao Outro ponto problemtico a questo da modificao de dados. Em modelos mal projetados, como no caso apresentado, ao se modificar uma determinada informao, por exemplo, nome do departamento, deve-se faz-lo em mais de uma linha. Alm disso, pode-se levar a base de dados a um estado inconsistente caso a atualizao no seja corretamente efetuada, ou seja, no tenha sido atualiza todas as linhas que possuem tal informao. Por exemplo, o nome do departamento de Qualidade (campo NOMEDEP da tabela FUNCIONARIO_DEPARTAMENTO) pode ter seu contedo modificado para Qualidade e Mtrica em somente um dos registros da tabela. Desta forma, a informao deste registro estar diferindo das demais linhas que se referem ao mesmo departamento, perdendo mais uma vez a consistncia dos dados. Assim, necessrio modificar todos os registros que dizem respeito a este departamento em especfico a cada atualizao para que seja mantida a integridade dos dados. Isto terminar gerando um processamento adicional para o sistema. Normalizao Para impedir a ocorrncia destes problemas, possvel efetuar uma anlise do modelo de dados e aplicar nele regras de normalizao. Estas regras so baseadas, em geral, na identificao de dependncias funcionais que podem existir entre os dados. Estas regras devem ser aplicadas seguindo-se uma determinada ordem, revisando todas as relaes existentes no modelo lgico de dados. A seguir so apresentados alguns conceitos importantes para o entendimento das formas normais. Dependncia funcional A dependncia funcional caracterizada pela existncia de campos em uma determinada tabela relacional cuja ocorrncia de valores est associada a valores que so preenchidos em outros campos na mesma tabela. Por exemplo, na tabela FUNCIONARIO_DEPARTAMENTO, o campo NOMEFUNC dependente funcional do campo MATFUNC, ou seja, existe uma relao de dependncia nos valores que preenchem estes campos. Sempre que o valor F1 aparece no campo MATFUNC, o valor Helder deve aparecer no campo NOMEFUNC. Outro exemplo a dependncia funcional entre os campos NOMEPROJ e LOCALPROJ. Toda vez que um determinado valor atribudo ao campo NOMEPROJ, pode-se pr-determinar o valor a ser atribudo ao campo LOCALPROJ. Considerando-se a existncia de dois campos CX e CY em uma determinada tabela do modelo de dados, pode-se dizer que CX depende funcionalmente de CY quando, em todos os registros da tabela, para cada ocorrncia de um valor particular a CX, um valor particular a CY se repete. Para efetuar a normalizao de um modelo de dados relacional, dois tipos de dependncias funcionais so de extrema relevncia: Parcial: ocorre quando a chave primria composta, e existe um campo que depende somente de parte desta chave primria composta. Por exemplo, a dependncia existente entre NOMEFUNC e MATFUNC: NOMEFUNC parcialmente dependente de MATFUNC, que por sua vez faz parte da chave primria da tabela FUNCIONARIO_PROJETO (MATFUNC e NUMEROP). Transitiva: ocorre quando uma coluna depende no somente da chave primria da tabela, mas tambm de uma segunda coluna (ou conjunto de colunas) da tabela. Um exemplo deste caso ocorre na tabela FUNCIONARIO_DEPARTAMENTO, onde o campo NOMEDEPTO depende funcionalmente do campo NUMDEPTO, que por sua vez depende da chave primria MATFUNC.

Formas Normais Definida a primeira verso do modelo relacional, necessrio analis-lo procurando identificar casos em que as tabelas no estejam de acordo com as formas normais. A este processo, baseado na aplicao das formas normais, dado o nome de normalizao. Estas formas normais representam regras a serem obedecidas para que um modelo de dados e suas tabelas sejam considerados apropriadamente projetados. Neste artigo somente sero abordadas as formas normais mais relevantes. 1 forma normal A 1 forma normal (1FN) est relacionada com a definio formal de uma relao: no deve permitir atributos multivalorados, atributos compostos e suas combinaes (tabelas aninhadas). Em nosso primeiro exemplo, na tabela FUNCIONARIO_PROJETO, possvel observar que os projetos acontecem em diferentes locais. Por exemplo, o projeto P-de-serra acontece em trs localidades: Campina Grande, Caruar e Piritiba. Isto caracteriza um campo (LOCALPROJ) como um atributo multivalorado contendo mais do que um valor atmico. Este fato conflita com os princpios do modelo relacional, que prega que os valores dos atributos de uma tabela sejam sempre atmicos. Para aplicar a 1FN a esta tabela no-normalizada possvel utilizar duas abordagens: Definir uma tabela nica com dados redundantes Neste caso, ter-se-ia uma tabela com a mesma estrutura, na qual a coluna LOCALPROJ passa a somente receber valores atmicos (ver Figura 1). MATFUNC NUMEROP HORAS NOMEFUNC NOMEP 1234 PR3 Helder P-de-serra 5 1234 1234 4567 4567 4567 8901 8901 0123 0123 0123 0123 PR3 PR3 PR1 PR1 PR1 PR2 PR2 PR3 PR3 PR3 PR3 5 5 8 8 8 7 7 3 3 3 3 Helder Helder Antonio Antonio Antonio Jabes Jabes Chico Chico Chico Chico P-de-serra P-de-serra Sisaleira Sisaleira Sisaleira Macaxeira Macaxeira P-de-serra P-de-serra P-de-serra P-de-serra LOCALPROJ Campina Grande Caruaru Piritiba Valente Stio Novo So Domingos Ibicu Mossor Campina Grande Piritiba Caruaru Piritiba

Figura 2. Tabela em 1FN. Com esta modificao, a nova tabela passa para a 1FN. No entanto, teremos um grande aumento da redundncia de dados. Definir uma nova tabela para cada tabela aninhada Nesta segunda abordagem, uma nova tabela gerada a partir da tabela original e, para cada tabela aninhada (por exemplo, um campo multivalorado) identificada,

deve ser criada uma nova tabela. No caso apresentado, obter-se-ia a tabela original reduzida de alguns campos e uma nova tabela LOCAL_PROJETO (ver Figura 3). FUNCIONARIO_PROJETO MATFUNC NUMPROJ HORAS NOMEFUNC NOMEPROJ F1 PR3 20 Helder P-deserra F2 PR1 10 Antonio Sisaleira F3 PR2 30 Jabes Macaxeira F1 PR2 15 Helder Macaxeira F4 PR1 25 Amorim Sisaleira F3 PR3 10 Jabes P-deserra

LOCAL_PROJETO CODLOCAL NUMPROJ L1 PR3 L2 PR3 L3 PR3 L4 PR1 L5 PR1 L6 PR1 L7 PR2 L8 PR2 Figura 3. Tabela em 1FN.

LOCALPROJ Campina Grande Caruar Piritiba So Domingos Stio Novo Valente Ibicu Mossor

Como pode ser observado na Figura 3, a redundncia dos dados sobre as localidades dos projetos deixa de existir, fazendo com que a quantidade de dados sendo acessados seja menor. Isto permite que o desempenho do sistema seja melhorado. Definio da 1 Forma Normal: Uma tabela est na primeira forma normal (1FN) quando esta no contm aninhamento de tabelas. 2 forma normal O objetivo da 2 forma normal (2FN) identificar dependncias funcionais parciais de dados e eliminar possveis redundncias de informao em tabelas que j estejam na primeira forma normal. Como foi definido anteriormente, para checar dependncias parciais preciso analisar aquelas tabelas cuja chave primria composta e verificar se no existe qualquer campo dependente exclusivamente de parte da chave primria. Como pode ser observado na tabela FUNCIONARIO_PROJETO, em 1FN, existem duas dependncias parciais: 1. MATFUNC NOMEFUNC; 2. NUMPROJ NOMEPROJ; Ou seja:

FUNCIONARIO_PROJETO ( MATFUNC , NUMPROJ , HORAS, NOMEFUNC, NOMEPROJ)

Nesta tabela, somente o campo HORAS depende da chave primria completa (para determinar a quantidade de horas em que um FUNCIONARIO est alocado em um PROJETO, necessrio saber tanto a matrcula do funcionrio quanto o nmero do projeto). Para que esta tabela seja passada para a 2FN, acabando com as dependncias parciais da chave primria, necessrio separar os dados em tabelas livres de dependncias funcionais. Assim, duas novas tabelas (FUNCIONARIO e PROJETO) devem ser definidas, redefinindo a tabela FUNCIONARIO_PROJETO e eliminando desta os campos que passaro para as novas tabelas. Feito isto, teremos a seguinte configurao:

FUNCIONARIO_PROJETO (MATFUNC, NUMPROJ, HORAS) FUNCIONARIO (MATFUNC, NOMEFUNC) PROJETO (NUMPROJ, NOMEPROJ)

Definio da 2 Forma Normal: Uma tabela est na segunda forma normal (2FN) quando, alm de estar de acordo com a primeira forma normal (1FN), no contm dependncias parciais entre seus atributos. 3 forma normal Juntamente com a 1FN e a 2FN, a 3 forma normal (3FN) fecha o conjunto das regras normais de maior relevncia para definio de um modelo de dados livre das anomalias j citadas. A 3FN foca nas dependncias funcionais transitivas que podem acontecer entre os dados de tabelas que j estejam na segunda forma normal (2FN). Por exemplo, a tabela FUNCIONARIO_DEPARTAMENTO (apresentada na Figura 1) est na primeira forma normal, pois no possui atributos multivalorados e est na segunda forma normal, j que no existem dependncias parciais neste caso, deve-se atentar para o fato de a tabela no possuir chave primria composta. Entretanto, podem ser identificadas as dependncias entre os campos MATFUNC e NUMDEPTO; NUMDEPTO e NOMEDEPTO; e NUMDEPTO e MATGERENTE, conforme ilustrado a seguir: FUNCIONARIO_DEPARTAMENTO ( MATFUNC ,NOMEFUNC, DATANASC,ENDERECOFUNC, NUMDEPTO ,NOMEDEPTO, MATGERENTE) MATFUNC NUMDEPTO NUMDEPTO NOMEDEPTO NUMDEPTO MATGERENTE Ou seja, para todas as ocorrncias de um determinado valor no campo MATFUNC, o mesmo valor para o campo NUMEDEPTO se repete. Ainda, para todas as ocorrncias de um determinado valor no campo NUMDEPTO, os mesmo valores para os campos NOMEDEPTO e MATGERENTE se repetem. Por exemplo, toda vez que o valor F2 ocorrer no campo MATFUNC, o valor D2 ocorre em NUMDEPTO e toda vez que o valor D2 ocorrer para o campo NUMDEPTO, ocorrero os valores Qualidade e F6 para os campos NOMEDEPTO e MATGERENTE, respectivamente. importante observar que o campo NUMDEPTPO no faz parte da chave primria da tabela. Diante deste cenrio, onde um dos problemas a redundncia de dados, a aplicao da 3FN leva gerao de uma nova tabela DEPARTAMENTO com os dados dos campos com dependncia indireta entre si. Nesta nova tabela criada, a chave dever ser aquele campo que determina o valor dos demais campos. Como se

considera o campo NUMDEPTO o determinador dos demais campos, ele ser a chave primria da tabela criada. Alm disso, a tabela original FUNCIONARIO_DEPARTAMENTO deve ser modificada, pois ela deixa de conter dados referentes a funcionrios e departamentos, e passa a referir-se somente a funcionrios. Deve-se, assim, modificar seu nome para FUNCIONARIO (a tabela FUNCIONARIO criada pela normalizao 2FN da tabela FUNCIONARIO_PROJETO deve ser substituda por esta, por ser mais completa). O campo NUMDEPTO deve permanecer nesta tabela para que sirva como chave estrangeira que representa relacionamento de FUNCIONARIO com a nova tabela DEPARTAMENTO. Assim, temse uma nova verso das duas tabelas que formavam o modelo de dados inicial, apresentado na listagem abaixo: FUNCIONARIO (MATFUNC, NOMEFUNC, DATANASC,ENDERECOFUNC,NUMDEPTO) DEPARTAMENTO (NUMDEPTO,NOMEDEPTO, MATGERENTE) FUNCIONARIO_PROJETO (MATFUNC, NUMPROJ, HORAS) PROJETO (NUMPROJ, NOMEPROJ)

Definio da 3 Forma Normal: Uma tabela est na terceira forma normal (3FN) quando, alm de estar de acordo com a segunda forma normal (2FN), no contm dependncias transitivas entre seus atributos. Desnormalizao A desnormalizao uma tcnica utilizada para maximizar o desempenho e/ou simplificar a gerao de relatrios para o usurio final a partir das tabelas da base de dados. Este processo se faz necessrio por que o modelo de dados normalizado na 3FN pode requerer um maior nmero de junes para processar uma consulta que atenda a um determinado relatrio do que se o modelo estivesse na 2FN ou 1FN. Estas junes extras podem custar muito caro em termos de CPU ou I/O do disco rgido. Assim, a desnormalizao d um passo atrs no processo de normalizao, retornando 2FN ou 1FN, a depender do caso (ler Nota 1). Antes de aplic-la, faz-se necessrio uma avaliao criteriosa. Suponha que no exemplo utilizado at este ponto tenha-se um contexto definindo que base de dados contem dados de uma multinacional com filiais nos cinco continentes. A tabela FUNCIONARIO possui uma cardinalidade de dois milhes de registros, ao passo que a tabela DEPARTAMENTO possui 200 mil registros e a de PROJETO, 100 mil registros. Na matriz da empresa existe um diretor de RH com idias um tanto quanto excntricas: deseja um relatrio completo de todos os funcionrios com seus respectivos projetos e departamentos a cada 15 dias. No entanto, a gerao deste relatrio leva muito tempo para ser executada, alm de sobrecarregar o sistema. Tudo isto se d pelo fato das junes entre as tabelas DEPARTAMENTO, FUNCIONARIO, FUNCIONARIO_PROJETO e PROJETO serem necessrias para o relatrio. Outra razo para a desnormalizao simplificar a formulao de consultas ad-hoc. Este tipo de consulta geralmente formulado por usurios finais com o intuito de gerar relatrios aleatrios do dia-a-dia. No entanto, estes usurios possuem grande dificuldade ao ter que realizar junes entre um nmero significante de tabelas. Para diminuir este problema, os DBAs geralmente criam um conjunto especial de tabelas projetadas justamente para estes relatrios ad-hoc. Assim, se os dados so somente utilizados para gerao de relatrios, e no em ambientes OLTP, evita-se problemas inerentes a desnormalizao (ler Nota 2). Para aplicar a desnormalizao, podem ser usadas algumas tcnicas como replicao de dados ou fragmentao vertical. No caso da replicao, criado um menor nmero de tabelas reunindo uma maior quantidade de informaes. No

exemplo de relatrio para o diretor de RH, pode ser necessrio retroceder no processo de normalizao, desnormalizando os dados em somente uma tabela. Neste caso, poderia ser criada uma tabela FUNCIONARIO_PROJETO_DEPT que reuniria todos os dados necessrios a este relatrio. Os dados seriam replicados ento nesta tabela, reduzindo uso de CPU e I/O em disco. A Figura 4 traz uma possvel representao para a tabela desnormalizada. FUNCIONARIO_PROJETO_DEPARTAMENTO

Figura 4. Tabela desnormalizada para melhorar o processamento de consultas para relatrios. Nota 1. Desnormalizao importante destacar que a desnormalizao usada para atender a requisitos especficos das aplicaes que acessam a base de dados. Requisitos futuros podem no se beneficiar das decises de desnormalizao. Assim, somente desnormalize quando for realmente necessrio. Nota 2. Consultas aleatrias No caso de consultas aleatrias, possvel usar vises para facilitar a formulao dos acessos como uma alternativa desnormalizao. No entanto, neste caso continua-se com o problema do desempenho. Concluso Como pode ser observado, a aplicao da normalizao a um modelo de dados um passo fundamental para garantir integridade aos dados e estabilidade ao modelo. A utilizao das trs primeiras formas normais representa uma das partes mais relevante no processo de definio do esquema de dados. No entanto, a depender da situao e utilizando-se do bom senso, o projetista do banco de dados pode recorrer a tcnicas de desnormalizao para satisfazer a questes de desempenho do sistema. Para a maioria dos esquemas e arquivos de dados, a decomposio at a terceira forma normal (3FN) suficiente para obter um esquema de banco de dados relacional satisfatrio. Contudo, h na literatura outras formas normais que garantem um esquema relacional ainda menos sujeitos a redundncia de dados, as Formas Normais de Boyce-Codd (FNBC) e a Quarta e Quinta formas normais (4FN e 5 FN). Estas formas normais sero abordadas em uma prxima edio.
Referncias

HEUSER, C. A., 2001, Projeto de Banco de Dados. 4 Edio, Porto Alegre, Brasil, Sagra Luzzatto-UFRGS. SILBERSCHATZ, A., KORTH, H., SUDARSHAN, S., 1999, Sistema de Banco de Dados. 3 Edio, Nova Iorque, EUA, McGraw-Hill. NAVATHE, S.,ELMASRI, R., 2001, Fundamentals of Database Systems. 3 Edio, AddisonWesley, EUA. DATE, C. J., 2000, Introduo a Sistemas de Bancos de Dados. Traduo da 7a edio Americana, Rio de Janeiro, Editora Campus.

Pablo Vieira Florentino bacharel em Cincia da Computao pela UFBA (www.ufba.br) e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ (www.cos.ufrj.br), na rea de banco de dados. Foi diretor-fundador da EmpresaJR. de informtica Ufba (www.infojr.ufba.br), onde desenvolveu diversos sistemas web, e analista de sistemas, prestando servios para diversas organizaes na rea de desenvolvimento de sistemas. Alm disso, Professor da UniGranrio e analista de sistemas do IBGE. Manuel Antonio de Castro Jnior doutorando da rea de banco de dados pela PUC-Rio (www.inf.puc-rio.br), Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ (www.cos.ufrj.br) e bacharel em Cincia da Computao pela UFF (www.uff.br). Alm disso, possui experincia como professor de graduao da UNESA, professor do curso de Administrao e Tuning de Banco de Dados I e II da Coordenao Central de Extenso da PUC-Rio (www.cce.puc-rio.br) e analista de sistemas, j tendo trabalhado em diversas empresas como EDS do Brasil, Embratel e Interbrain.

APENDICE B JPA 46 781,91 237736479