UNIVERSIDADE FEDERAL DE SANTA CATARINA DEPARTAMENTO DE INFORMTICA E ESTATSTICA CURSO DE CINCIAS DA COMPUTAO

USO DE PADRES DE ANLISE E PADRES DE PROJETO NO DESENVOLVIMENTO DE UMA APLICAO DE CONTROLE DE ATACADO

Autor: Igor Tibes Ghisi Orientadora: Dr. Patrcia Vilain Banca Examinadora: Dr. Ricardo Pereira e Silva Dr. Ronaldo dos Santos Mello Palavras-chave: padres de anlise, padres de projeto

Florianpolis, 10 de maro de 2004

Agradecimentos

Agradeo primeiro e mais especialmente minha orientadora, Prof. Patrcia Vilain, pela pacincia, preocupao e dedicao na orientao do trabalho. Ao Prof. Ronaldo dos Santos Mello, pela correo e pelas orientaes. Ao Prof. Ricardo Pereira e Silva, pela avaliao criteriosa e imparcial. Ao Prof. Orestes Estevam Alarcon e Renata Santos, que cederam equipamentos para implementao e apresentao do trabalho. A minha famlia, Ivo, Arlete e Alice, pela compreenso e fora que me deram. Aos meus amigos, colegas de faculdade e colegas de trabalho pelo apoio e pelas informaes que me ajudaram a realizar o trabalho.

RESUMO

Este trabalho tem como objetivo desenvolver um estudo sobre o uso de padres de anlise e padres de projeto no processo de produo de software. Foram descritos alguns padres de anlise e de projeto e fez-se um mapeamento dos padres de anlise para padres de projeto, quando pertinente. Para aplicar os padres estudados e o mapeamento definido desenvolveu-se uma aplicao de Controle de Atacado, utilizando alguns padres descritos. Tambm foi discutido o impacto destes na qualidade do software desenvolvido.

Palavras-chave: padres de anlise, padres de projeto.

ABSTRACT

The goal of this work is develop a study about the use of analysis patterns and design patterns on the software development. Some analysis and design patterns were described and a mapping of some analysis patterns to design patterns was proposed. A software for Inventory Control was built applying some patterns and the mapping defined. Also, the impact of patterns application in the quality of developed software was discussed.

Key words: analisys patterns, design patterns.

SUMRIO RESUMO ABSTRACT SUMRIO NDICE DE FIGURAS 1 1.1 1.2 1.2.1 1.2.2 2 2.1 2.2 2.3 2.4 3 3.1 3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 3.2.7 3.3 INTRODUO ...................................................................................................... 10 CARACTERIZAO DO TEMA E MOTIVAO ....................................................... 10 OBJETIVOS ............................................................................................................ 11 OBJETIVO GERAL ................................................................................................. 11 OBJETIVOS ESPECFICOS ...................................................................................... 11

RATIONAL UNIFIED PROCCESS .................................................................... 12 ESTRUTURA ........................................................................................................... 13 WORKFLOW MODELAGEM DE NEGCIOS ............................................................. 16 WORKFLOW DE REQUISITOS .................................................................................. 16 WORKFLOW DE ANLISE E PROJETO .................................................................... 17 PADRES DE ANLISE...................................................................................... 19 RESPONSABILIDADE .............................................................................................. 19 ENTIDADE ............................................................................................................ 19 HIERARQUIA DE ORGANIZAES ......................................................................... 21 ESTRUTURA DE ORGANIZAES .......................................................................... 22 RESPONSABILIDADE ............................................................................................ 24 NVEL DE INFORMAO DE RESPONSABILIDADE ................................................. 25 ESTOQUE E CONTABILIDADE ................................................................................ 27 PADRO CONTA .................................................................................................. 27 TRANSAES ....................................................................................................... 28 TRANSAES MLTIPLAS.................................................................................... 29 CONTA RESUMIDA ............................................................................................... 30 CONTA GATILHO ................................................................................................. 31 REGRA DE LANAMENTO .................................................................................... 32 REGRAS DE LANAMENTOS PARA VRIAS CONTAS.............................................. 33 COMRCIO ............................................................................................................ 35

3.3.1 3.3.2 4 4.1 4.2 4.2.1 4.2.2 4.3 4.3.1 4.3.2 4.4 4.4.1 4.4.2 4.5 4.5.1 4.5.2 4.6 4.6.1 4.6.2 4.7 4.7.1 4.7.2 5

CONTRATO .......................................................................................................... 36 PORTFLIO .......................................................................................................... 38

PADRES DE PROJETO..................................................................................... 41 SINGLETON............................................................................................................. 41 FACTORY METHOD................................................................................................. 43 ESTRUTURA ......................................................................................................... 45 IMPLEMENTAO ................................................................................................ 46 PROXY .................................................................................................................... 46 IMPLEMENTAO ................................................................................................ 47 ESTRUTURA ......................................................................................................... 48 FACADE .................................................................................................................. 49 IMPLEMENTAO ................................................................................................ 51 ESTRUTURA ......................................................................................................... 52 STATE ..................................................................................................................... 53 ESTRUTURA ......................................................................................................... 54 IMPLEMENTAO ................................................................................................ 54 COMPOSITE ............................................................................................................ 56 ESTRUTURA ......................................................................................................... 56 IMPLEMENTAO ................................................................................................ 57 STRATEGY .............................................................................................................. 58 ESTRUTURA ......................................................................................................... 58 IMPLEMENTAO ................................................................................................ 58

MAPEAMENTO DE PADRES DE ANLISE PARA PADRES DE

PROJETO ..................................................................................................................... 60 5.1 5.2 5.3 5.3.1 5.4 6 6.1 PADRO DE ANLISE TRANSAES E PADRO DE PROJETO PROXY................... 60 PADRO DE ANLISE CONTA RESUMIDA E PADRO DE PROJETO COMPOSITE .. 61 PADRO DE ANLISE PORTFLIO E PADRO DE PROJETO STRATEGY ............... 64 USO DO SINGLETON .............................................................................................. 66 PADRO DE ANLISE REGRA DE LANAMENTO E PADRO STRATEGY ............... 67 DESENVOLVIMENTO......................................................................................... 69 LEVANTAMENTO DE REQUISITOS ......................................................................... 69

6.1.1 6.1.2 6.2 6.2.1 6.3 6.3.1 6.3.2 6.3.2.1 6.3.2.2 6.3.3 6.3.3.1 6.3.3.2 6.3.3.3 6.4 6.4.1 6.4.2 6.4.3 6.4.4 6.4.4.1 7 7.1 7.1.1 7.1.2 7.1.3 7.1.4 7.2

DESCRIO DO DOMNIO DA APLICAO ............................................................ 69 CASOS DE USO ..................................................................................................... 70 ANLISE ................................................................................................................ 80 MODELO CONCEITUAL ........................................................................................ 80 PROJETO ................................................................................................................ 88 LINGUAGEM E BANCO DE DADOS ........................................................................ 88 DIAGRAMAS DE SEQUNCIA ................................................................................ 89 Consignar......................................................................................................... 90 Vender ............................................................................................................. 91 DIAGRAMA DE CLASSES ...................................................................................... 92 Contratos.......................................................................................................... 92 Conta Caixa ..................................................................................................... 94 Camada de Persistncia ................................................................................... 96

IMPLEMENTAO .................................................................................................. 98 MTODO VENDER ................................................................................................ 98 MTODO OBTERVENDAS ..................................................................................... 99 CAMADA DE PERSISTNCIA ............................................................................... 100 PROTTIPO ........................................................................................................ 101 Funcionamento do Prottipo ......................................................................... 102

CONCLUSO....................................................................................................... 104 FATORES DE QUALIDADE ALCANADOS ............................................................ 104 ESTENDIBILIDADE ............................................................................................. 104 DESEMPENHO .................................................................................................... 105 REUSABILIDADE ................................................................................................ 105 PORTABILIDADE ................................................................................................ 105 CONSIDERAES FINAIS ..................................................................................... 106

BIBLIOGRAFIA CONSULTADA ........................................................................... 107 ANEXOS ..................................................................................................................... 109 ANEXO I: ARTIGO ..................................................................................................... 110 ANEXO II: DIAGRAMA DE CLASSES (CAMADA DE APLICAO).............................. 112 ANEXO III: CDIGO DA APLICAO ........................................................................ 114

NDICE DE FIGURAS Figura 3.1 Padro Entidade ......................................................................................... 20 Figura 3.2 Modelo de hierarquia simples .................................................................... 21 Figura 3.3 Modelo de hierarquia com restries ......................................................... 22 Figura 3.4 Estrutura de Organizao ........................................................................... 23 Figura 3.5 Hierarquia utilizando padro Entidade....................................................... 24 Figura 3.6 Diviso em camadas................................................................................... 26 Figura 3.7 Conta e Lanamento................................................................................... 27 Figura 3.8 - Transao.................................................................................................... 29 Figura 3.9 Transao Mltipla .................................................................................... 30 Figura 3.10 Conta Resumida ....................................................................................... 30 Figura 3.11 Regra de Lanamento............................................................................... 32 Figura 3.12 Metodo de Clculo para saida .................................................................. 33 Figura 3.13 Conta e Tipo de Conta.............................................................................. 34 Figura 3.14 Localizador de Conta ............................................................................... 35 Figura 3.15 Contrato com especificao ..................................................................... 36 Figura 3.16 Contrato com associaes ........................................................................ 37 Figura 3.17 - Contrato .................................................................................................... 37 Figura 3.18 - Portflio .................................................................................................... 38 Figura 3.19 Seleo de Contratos por mtodo booleano ............................................. 39 Figura 3.20 Seleo de Contratos por comparao com Seletor ................................. 40 Figura 4.1 Estrutura do Padro Singleton.................................................................... 42 Figura 4.2 Estrutura do Factory Method ..................................................................... 45 Figura 4.3 Exemplo do Proxy...................................................................................... 47 Figura 4.4 Etrutura do Proxy ....................................................................................... 49 Figura 4.5 Sem o uso do Facade ................................................................................. 50 Figura 4.6 Com o uso do Facade ................................................................................. 51 Figura 4.7 Estrutura do Facade ................................................................................... 52 Figura 4.8 Padro State................................................................................................ 53 Figura 4.9 Estrutura do State ....................................................................................... 54 Figura 4.10 Estrutura do Composite ............................................................................ 56 Figura 4.11 Estrutura do padro Strategy.................................................................... 58

Figura 4.12 Estrutura do Strategy................................................................................ 59 Figura 5.1 Estrutura do Proxy ..................................................................................... 61 Figura 5.2 Padro de Anlise Conta Resumida ........................................................... 62 Figura 5.3 - Padro de Projeto Composite...................................................................... 62 Figura 5.4 Diagrama de classe do mapeamento .......................................................... 63 Figura 5.5 Seleo de contrato por mtodo ................................................................. 64 Figura 5.6 Estrutura da implementao....................................................................... 65 Figura 5.7 Portflio mapeado para Singleton e Strategy ............................................. 66 Figura 5.8 Padro de anlise Regra de Lanamento.................................................... 67 Figura 5.9 Mapeamento do Padro Regra de Lanamento para o Strategy ................ 67 Figura 6.1 Modelo baseado no padro Entidade ......................................................... 81 Figura 6.2 Modelo sem conceito de Contrato.............................................................. 82 Figura 6.3 Conceito de Contrato ................................................................................. 83 Figura 6.4 Modelo com conceito de Contrato ............................................................. 84 Figura 6.5 Conta Caixa, Receita e Despesa................................................................. 85 Figura 6.6 Lanamentos nos Caixas ............................................................................ 86 Figura 6.7 Modelo conceitual da aplicacao ................................................................. 87 Figura 6.8 Diagrama de Sequncia Consignar ............................................................ 90 Figura 6.9 Diagrama de Sequncia Vender ................................................................. 91 Figura 6.10 Contrato com Proxy ................................................................................. 93 Figura 6.11 Heranas de contrato com Proxy.............................................................. 94 Figura 6.12 Conta Resumida projetada para Caixas.................................................... 95 Figura 6.13 Camada de Persistencia............................................................................ 97 Figura 6.14 - Prottipo da Aplicao............................................................................ 102 Figura 6.15 Consultando o estoque ........................................................................... 103 Figura 6.16 Realizando a venda ................................................................................ 103 Figura 6.17 Consultando a venda realizada............................................................... 103

INTRODUO

1.1 Caracterizao do Tema e Motivao

A capacidade da indstria de software dos dias atuais de desenvolver sistemas de grande complexidade se deve implementao de um tratamento sistemtico e controlado etapa de desenvolvimento da soluo computacional, o qual denomina-se engenharia de software. A Engenharia de Software uma disciplina da engenharia que se ocupa de todos os aspectos da produo de software, desde os estgios iniciais de especificao do sistema at a manuteno desse sistema (SOMMERVILLE, 2003). A engenharia de software surgiu nos anos 70 e hoje se tornou imprescindvel para qualquer softwarehouse que deseja, alm de desenvolver aplicaes maiores e mais complexas, tambm garantir produtos de qualidade. Dentre as ferramentas de engenharia de software que tornam possvel a complexidade dos sistemas atuais, esto os padres. Os padres so solues utilizadas no processo de desenvolvimento de uma aplicao que podem ser utilizadas novamente em outro processo, mesmo que o domnio do problema seja diferente. Dessa maneira, no necessrio dispender esforo na resoluo de um problema que j foi solucionado no passado.

Cada padro descreve um problema que ocorre mais de uma vez em um certo contexto, e descreve o ncleo da soluo para este problema de uma forma que voc pode usar essa soluo um milho de vezes, sem ter que elabora-la novamente (ALEXANDER, 1977 apud GAMMA, 1994)

Padres so usados em vrios campos de trabalho como construo civil e gerenciamento empresarial. Foi adotado no desenvolvimento de software a partir dos anos 90. Nos ltimos anos os padres tm sido bastante discutidos.

11

Padres no so inventados, mas sim descobertos (FOWLER, 1997). Isso porque a maioria dos padres nasce de um modelo feito para um domnio particular, e o desenvolvedor nota que o modelo pode ser usado em outros domnios. Assim o modelo se torna um padro. Neste trabalho realizou-se o estudo de padres para duas fases do desenvolvimento de software. Padres para anlise e padres para projeto. Analisou-se, tambm, como ocorre a utilizao destes padres no desenvolvimento da aplicao. E quais os benefcios desta utilizao.

1.2 Objetivos
1.2.1 Objetivo geral

Ao fim do trabalho deve-se ter uma descrio de vrios padres de anlise e padres de projeto e, com o estudo de cada um, ver quais se adequam ao domnio da aplicao e que facilidades estes trazem para desenvolvimento de uma aplicao de controle de atacado.

1.2.2

Objetivos especficos

Fazer um estudo de alguns padres de anlise. Fazer um estudo de alguns padres de projetos. Fazer um mapeamento dos padres de anlise para os padres de projeto. Desenvolver um modelo (anlise e projeto) para o domnio de controle de atacado, utilizando, sempre que pertinente, os padres de anlise e padres de projeto estudados.

Implementar um prottipo da aplicao.

RATIONAL UNIFIED PROCCESS

Dentro de um processo de desenvolvimento, o Rational Unified Proccess (RUP) (KRUCHTEN, 2000) disponibiliza uma abordagem disciplinada para a atribuio de tarefas e responsabilidades e assegura a produo de um software de alto padro. De acordo com Booch (BOOCH apud KRUCHTEN, 2000) um processo de desenvolvimento de software deve possuir quatro funes:

1. Ordenar as atividades da equipe de desenvolvimento. 2. Especificar quais artefatos de software devero ser desenvolvidos e quando devero ser desenvolvidos. 3. Definir as tarefas que sero individuais e tarefas executadas em conjunto pela equipe. 4. Sugerir um critrio de monitorao e avaliao dos produtos e atividades do projeto.

O processo de desenvolvimento de software sistematiza o desenvolvimento de aplicaes complexas e possibilita produzir um software de qualidade de uma maneira previsvel. Com isso, os custos de produo so reduzidos e a produtividade elevada (KRUCHTEN, 2000) Por ser um moderno processo de engenharia de software, provendo ferramentas eficientes para assegurar a produo de sistemas de qualidade, o RUP se tornou um padro para a industria de desenvolvimento de software no mundo. Ele considerado como um framework de processo que pode ser adaptado e estendido para satisfazer as necessidades de uma organizao (KRUCHTEN, 2000). O objetivo do RUP produzir software de qualidade, que promova uma soluo adequada as necessidades do usurio final. (KRUCHTEN, 2000) Por isso, feita a adoo de casos de uso como elemento fundamental na construo do software, servindo como base para todo o processo de desenvolvimento.

13

2.1 Estrutura
Um processo descreve quem est fazendo o que, como e quando. O RUP representado usando-se quatro elementos primrios de modelagem (KRUCHTEN, 2000)

Papis: quem; Atividades: como; Artefatos: o que; Workflows: quando;

Papis: Um papel define o comportamento e as responsabilidades de um indivduo ou um grupo de trabalho. Os comportamentos so expressos na forma de atividades. Cada papel est associado a um conjunto de atividades que sero executadas. A responsabilidade de um papel est usualmente expressa em relao a certos artefatos que os papis criam, modificam ou controlam (KRUCHTEN, 2000). Um participante do projeto pode apresentar vrios papis durante o desenvolvimento do software, e vrios participantes podem apresentar o mesmo papel. Kruchten faz uma analogia de papis com um chapu que o indivduo usa durante o projeto. Uma pessoa pode usar vrios chapus (KRUCHTEN, 2000) e um chapu pode ser usado por vrias pessoas. Exemplos de papis:

Analista: coordena a anlise do domnio, compreenso dos requisitos e a descrio dos casos de uso. Projetista: define as responsabilidades, operaes, atributos e associaes de uma ou mais classes e determina sua ambientao no sistema.

Atividades:

como

visto

anteriormente,

as

atividades

descrevero

comportamento dos papis. Uma atividade uma operao que um indivduo num papel deve executar, e que produz um resultado significativo no contexto do projeto

14

(KRUCHTEN, 2000) Normalmente, a atividade tem como objetivo a criao ou modificao de um artefato. A granularidade de uma atividade pode ir de algumas horas at dias. A atividade deve ser usada como elemento de avano do projeto. Ela pode se repetir muitas vezes em cima do mesmo artefato especialmente de uma iterao para outra, em que o sistema est sendo refinado e expandido (KRUCHTEN, 2000). A repetio de uma atividade deve ser feita pelo mesmo papel. Exemplo de atividades:

Procurar Casos de Uso e Atores: executada pelo papel Analista. Executar um teste de performance: executada pelo papel Testador de Performance.

Artefatos: Um artefato um pedao de informao que produzido, modificado ou usado por um processo (KRUCHTEN, 2000) Os artefatos vo sendo construdos e utilizados ao longo do projeto. Normalmente, servem de entrada para uma atividade que produz um outro artefato ou modifica este mesmo artefato. Entre as formas que um artefato pode ter esto: um modelo conceitual do domnio; um documento com a descrio do domnio do problema, um cdigo fonte. Um artefato tambm pode ser a composio de vrios artefatos. Por exemplo, o diagrama de classes de projeto composto por classes. A melhor maneira de criar e apresentar artefatos utilizar-se das ferramentas apropriadas para a criao dos mesmos. Nem todo artefato um documento em papel com texto ou representaes. Geralmente eles so o resultado da ferramenta no qual foram elaborados. Exemplo de artefatos:

Um modelo conceitual do Together. Um modelo de projeto do Rational Rose.

15

Os artefatos do RUP so classificados em cinco conjuntos de informao:

Gerencial: artefatos relacionados ao gerenciamento do projeto. Requisitos: artefatos relacionados definio do software a ser desenvolvido como modelo de casos de uso e descrio de domnio. Projeto: artefatos relacionados descrio do sistema como diagrama de classes. Implementao: cdigo fonte e executveis. Implantao: material de instalao e documentao para o usurio.

Workflow: preciso uma forma para descrever uma seqncia de atividades que produz resultados efetivos e mostre iterao entre os papis. Um workflow uma seqncia de atividades que produz um resultado de considervel valor. (KRUCHTEN, 2000) O RUP composto de nove workflows: seis workflows de engenharia e trs workflows de suporte. Eles representam uma diviso das atividades e papis em reas lgicas. Os seis workflows de engenharia so:

Modelagem de Negcios Requisitos Anlise e Projeto Implementao Teste Implantao

Os trs workflows de suporte:

Gerenciamento de Projeto Gerenciamento de Configurao e Alteraes Ambiente

16

A seguir sero abordados os workflows utilizados no desenvolvimento da aplicao de controle de atacado at o presente momento.

2.2 Workflow Modelagem de Negcios

No workflow de modelagem de negcio a equipe ir fazer um estudo do funcionamento da organizao para a qual ser desenvolvida uma aplicao. Como resultado o workflow deve prover informaes sobre toda a dinmica do trabalho para o qual ser construda uma soluo de software, identificar todos os processos, seus problemas e indicar possveis aperfeioamentos. Principais artefatos desenvolvidos so: Descrio do Domnio, Descrio dos Casos de Uso do Domnio.

2.3 Workflow de Requisitos

Os principais objetivos do workflow de requisitos so:

Estabelecer, em acordo com cliente, o que o sistema que ser desenvolvido ir fazer Prover mais informaes sobre os requisitos do sistema para os desenvolvedores. Definir os limites do sistema (definir que parte do processo de trabalho ir ser automatizada pela aplicao) Estabelecer prazos e custos. Definir a interface com o usurio do sistema.

Um requisito uma condio ou capacidade que um sistema deve obedecer (KRUCHTEN, 2000). Pode-se dividir os requisitos em funcionais e no-funcionais. Os requisitos funcionais so aes que o sistema deve ser capaz de realizar. Normalmente, esta ao fruto de uma ordem externa ao sistema que deve gerar algum

17

resultado. Exemplo de requisitos funcionais: o sistema de supermercado deve registrar a venda do produto e dar baixa do mesmo no estoque. Os requisitos no-funcionais no so aes, mas sim caractersticas de funcionamento do sistema. Exemplos de requisitos no-funcionais: o banco de dados deve suportar mais de 1 milho de registros; o sistema deve ter capacidade para trabalhar com leitor de cdigo de barras. O primeiro passo para coletar os requisitos elaborar um documento onde se descreve o que o cliente espera do sistema,. que funes ele espera que o sistema realize e que resultados devem ser apresentados. Este documento, chamado de documento de viso, tambm deve conter as funes de alto nvel do sistema. Sero as funes que faro com que os requisitos do cliente sejam atendidos. A partir deste documento ser elaborado um modelo de caso de uso. Um caso de uso um documento narrativo que descreve a seqncia de eventos de um ator (um agente externo) que usa um sistema para completar um processo (JACOBSON, 1992 apud LARMAN, 1997) O modelo de caso de uso usado como coleta dos requisitos. No workflow de requisitos tambm feita a coleta de informaes para projetar a interface com o usurio do sistema. O modelo de caso de uso servir como base de informao para se desenvolver um prottipo de interface com o usurio. Com o prottipo pronto o cliente e a prpria equipe de desenvolvimento podem ter uma noo da aplicao e assim elaborar os requisitos finais do sistema. Principais artefatos desenvolvidos neste workflow so: documento de viso, modelo de caso de uso e prottipo de interface com o usurio.

2.4 Workflow de Anlise e Projeto

O objetivo deste workflow transformar os requisitos em especificaes que descrevero como ser feita a implementao do sistema. Para isso deve-se fazer um estudo dos requisitos e transform-los num modelo de sistema. Este modelo ser ento ajustado de acordo com o ambiente de programao escolhido. A primeira atividade do workflow consiste na construo de um modelo de anlise a partir do modelo de caso de uso. Atravs do modelo de casos de uso identificam-se

18

classes significativas para a construo de um modelo conceitual e neste modelo definese como estas classes interagem entre si. Na segunda etapa, usa-se o modelo conceitual de anlise para elaborar o projeto do software. Os elementos do projeto sero baseados nos elementos do modelo conceitual da anlise e adicionam-se os artefatos de software. Descreve-se a organizao do sistema e sua arquitetura de execuo. Na terceira etapa, faz-se o projeto de artefatos de software como banco de dados, protocolo de comunicao, ou outro artefato necessrio ao atendimento dos requisitos do sistema. Principais artefatos desenvolvidos neste workflow so: modelo conceitual da anlise, diagrama de classes do projeto. Os papis do workflow descritos por Kruchten (2000) so: Arquiteto: o arquiteto o coordenador geral do workflow. Ele define a estrutura geral dos modelos gerados e a interface entre os subsistemas modelados. Projetista: elabora o modelo de projeto, constituido de operaes, atributos, responsabilidades e relacionamento de uma ou mais classes que definiro a implementao do sistema. Normalmente um projetista fica responsvel pela modelagem de um ou mais subsistemas definidos pelo arquiteto. Projetista de Banco de Dados: elabora o modelo de banco de dados, caso seja necessrio.

PADRES DE ANLISE

Padres de Anlise so grupos de conceitos que representam uma construo comum em modelagem de negcios. Podem ser relevantes em um domnio, ou abranger muitos domnios (FOWLER 1997, p. 8). Os padres de anlise podem ser definidos como um conjunto de classes e associaes que representam de forma sistemtica um contexto de uma aplicao. Esta representao de contexto muitas vezes vlida para mais de uma aplicao, e isso faz dos padres de anlise uma valiosa ferramenta de reuso. Fez-se um estudo de vrios padres de anlise descritos por Fowler (1997) no livro Analysis Patterns. Para descrever os modelos, Fowler usou a notao de Odell (ODELL, 1995 apud FOWLER, 1997). Na transcrio dos modelos de Fowler para este trabalho foi usada a notao UML.

3.1 Responsabilidade
Nesta seo esto descritos padres que lidam com o conceito de responsabilidade. Responsabilidade um conceito abstrato que pode representar vrios tpicos como hierarquia de organizao, vnculo empregatcio, etc.

3.1.1

Entidade

Este , freqentemente, um dos primeiros padres com que um analista iniciante se depara. O padro Entidade utilizado para definir pessoas e organizaes dentro do modelo. Como organizaes e pessoas tem vrios atributos comuns, como nome, endereo e formas de contato (telefone, e-mail), pode-se generalizar pessoa e organizao numa classe chamada Entidade (figura 3.1).

20

Figura 3.1 Padro Entidade

Mas no so s os atributos que tornam Pessoa e Organizao especificaes da mesma classe. Vrias aes como pagamentos, envio de correspondncia (e-mail ou carta), pagamento de impostos e muitas outras so comuns s duas classes. Fowler (1997) faz uma analogia de Entidade com uma agenda telefnica pessoal. A maioria dos registros de uma agenda so de pessoas, mas alguns podem ser de empresas, e nenhuma diferenciao vista entre os registros de pessoas e empresas. Logo abaixo do telefone de Paulo, por exemplo, pode estar o telefone da Panificadora Po Quente. Segundo Fowler (1997), este padro representa um caso tpico de conceito no nomeado:
conceito no nomeado todo mundo conhece e usa, mas ningum tem um nome para ele. Eu j o vi em incontveis modelos de dados com vrios nomes: person/organization, player, legal entity e muitos outros. (FOWLER, 1997)

21

No Brasil encontra-se este padro com nome de Pessoa/Organizao ou mesmo Pessoa, que generaliza Pessoa Fsica e Pessoa Jurdica.

3.1.2

Hierarquia de Organizaes

Considere uma multinacional qualquer: Cervejaria Kicerva Ltda por exemplo. Ela tem vrias unidades operacionais espalhadas pelo mundo, as quais so divididas em regies, que por sua vez so divididas em sub-regies, e estas divididas em escritrios de venda. Pode-se representar esta situao com o seguinte modelo (figura 3.2):

Figura 3.2 Modelo de hierarquia simples

Apesar de ser satisfatria a representao acima pouco flexvel. Se, por exemplo, a Kicerva deseje fechar os escritrios sub-regionais (as regies gerenciariam diretamente os escritrios de venda), seriam necessrias alteraes no modelo. O modelo de hierarquia com associao recursiva (figura 3.3) possibilita essa flexibilidade. Para definir as hierarquias no modelo, adiciona-se restries aos subtipos de organizao para que eles saibam quem deve ser sua subordinada.

22

Figura 3.3 Modelo de hierarquia com restries

Caso haja uma mudana na hierarquia das organizaes da empresa, simplesmente altera-se a restrio de um subtipo. Neste ponto ganha-se flexibilidade, j que geralmente mais fcil mudar uma restrio do que alterar a estrutura de um modelo.

3.1.3

Estrutura de Organizaes

Apesar de ser bastante flexvel, algumas situaes no podem ser representadas no modelo de hierarquia com restries (figura 3.3). Suponha que os escritrios de venda da Kicerva sejam subordinados a uma sub-regio, a qual devem reportar sobre suas vendas, e subordinado tambm a uma unidade operacional de produo, a qual devem reportar sobre a qualidade do produto Kicerva (o escritrio subordinado a duas organizaes). Para representar este caso transforma-se a associao de hierarquia (associao gerencia) em um conceito, e diferenciam-se os vrios tipos de hierarquias atravs de outro conceito, o conceito Tipo de Estrutura, como mostra a Figura 3.4.

23

Figura 3.4 Estrutura de Organizao

Exemplo 1: O escritrio de vendas da Kicerva em Florianpolis est subordinado sub-regio de vendas do Sul e a unidade operacional de qualidade de produto. Esta representao seria feita com dois Tipos de Estrutura: vendas e qualidade de produto. O Tipo de Estrutura venda definiria uma Estrutura de Organizao com Sub-Regio como gerente e Escritrio de Venda como subordinada. O Tipo de Estrutura qualidade de produto definiria uma Estrutura de Organizao com Unidade Operacional como gerente e Escritrio de Venda como subordinada. Para apenas duas hierarquias, como no exemplo acima, talvez o modelo seja subutilizado. Mas em casos onde h vrios tipos de hierarquia, este modelo fornece a flexibilidade necessria para lidar com tal complexidade. As restries, que antes eram definidas nos subtipos de Organizao, agora podem ser definidas no Tipo de Estrutura. Isso facilita a adio de novos Tipos de Estrutura, mas por outro lado, dificulta a adio de novos subtipos de Organizaes, j que cada adio de um novo subtipo provoca uma alterao nas restries de todos os Tipos de Estruras que definem a hierarquia do subtipo adicionado.

24

Ento a escolha de onde definir as restries depende de uma anlise do modelo para verificar que rea deste sofrer mais adio de novos elementos. Projete um modelo para que as modificaes mais frequentes do modelo cause o menor nmero de alteraes dos conceitos (FOWLER 1997).

3.1.4

Responsabilidade

Pode-se estender o padro anterior para ser usado no apenas com organizaes, mas com qualquer tipo de entidade que possua algum tipo de relacionamento de responsabilidade. O padro Responsabilidade usa o mesmo modelo de Estrutura de Organizaes, apenas dando novos nomes aos conceitos e usando o padro Entidade no lugar das organizaes. (figura 3.5)

Figura 3.5 Hierarquia utilizando padro Entidade

25

Exemplo 1: Joo da Silva trabalha na Cervejaria Kicerva. Isto pode ser modelado como uma Responsabilidade na qual o responsvel a Kicerva e o dependente Joo Boanerges. O Tipo de Responsabilidade emprego.

Exemplo 2: Joo da Silva o gerente da equipe de vendas de Florianpolis. Isto pode ser modelado como uma Responsabilidade em que o Responsvel e Joo, o dependente a equipe de vendas de Florianpolis e o Tipo de Responsabilidade gerncia.

3.1.5

Nvel de Informao de Responsabilidade

O nmero de tipos de responsabilidade que se consegue representar muito maior que o nmero de tipos de estrutura no modelo de Estrutura de Organizaes. Por isso as restries e regras entre as relaes de dependncia ficam bem mais complexas no modelo Responsabilidade. Essa complexidade pode ser gerenciada dividindo-o em duas camadas: uma de nvel operacional e uma de nvel de informao. O nvel operacional abriga conceitos como Responsabilidade, Entidade e seus relacionamentos. O nvel de informao abriga conceitos como Tipo de Responsabilidade, Tipo de Entidade (figura 3.6). O nvel operacional registra atividades do dia-a-dia do domnio. O nvel de informao regulamenta essas atividades. No modelo da figura 3.6, uma instncia de Responsabilidade sofre as restries definidas entre as relaes de Tipo de Responsabilidade e Tipo de Entidade.

26

Figura 3.6 Diviso em camadas

Neste modelo, a associao especifica substitui as especializaes de entidade. Assim, Entidade pode ter seu comportamento definido pelo Tipo de Entidade ao qual ele est associado. A reflexo entre o nvel de informao e o nvel operacional bastante parecida, mas no igual. No nvel operacional as associaes dependente e responsvel so de 1 para muitos, j no nvel de informao elas passam a ser de muitos para muitos, pois o nvel operacional registra somente a Entidade em uso na operao, enquanto o nvel de informao registra todas as associaes possveis entre Entidades e Responsabilidades. A diviso dos modelos em nveis de informao e operacional comum, mas nem sempre so explicitadas. Porm, isso ajuda a identificar melhor os comportamentos dos conceitos no modelo.

27

3.2 Estoque e Contabilidade

Uma grande quantidade de sistemas computacionais comerciais desenvolvida para gerenciar a movimentao de dinheiro de uma empresa, basicamente registrando como o dinheiro ganho e depois gasto. A idia bsica por trs do gerenciamento de contabilidade e estoque que existem vrios recipientes contendo dinheiro ou produtos e preciso registrar a movimentao do dinheiro e dos produtos atravs desses recipientes. Desta idia bsica nasceram os padres Estoque e Contabilidade que sero descritos neste trabalho. Eles apresentam uma coleo de conceitos que pode-se usar como base para sistemas de contabilidade, controle de estoque e gerenciamento de recursos.

3.2.1 Padro Conta

O padro Conta fornece conceitos bsicos para o gerenciamento de movimentao de um produto qualquer em um estoque genrico, como por exemplo, litros de combustvel em um posto de gasolina ou quantidade de dinheiro em um caixa eletrnico. Para isso preciso detalhar as operaes que modificam a quantidade dos mesmos neste estoque. No padro Conta isso feito registrando-se um Lanamento em uma respectiva Conta a cada modificao no estoque destes produtos (Figura 3.7).

Figura 3.7 Conta e Lanamento

28

Em Lanamento tem-se a data_lanamento que a data real em que a operao foi feita e a data_registro que a data em que a operao foi registrada no sistema. Em Conta tem-se o atributo saldo que a soma da quantidade de todos os seus Lanamentos. Um Lanamento ser definido como depsito ou retirada de acordo com o sinal de seu valor quantidade. Atravs dos Lanamentos um usurio do sistema pode visualizar a movimentao da Conta em determinado perodo de tempo.

Exemplo 1: O Restaurante Universitrio comprou 100 Kg de feijo esta semana. Isso representado como um Lanamento de 100 na Conta de estoque de feijo do RU.

Exemplo 2: Andr pagou a prestao de R$ 250,00 de seu carro. Isso representado como um Lanamento de 250 na Conta de finanas pessoais de Andr.

3.2.2

Transaes

No padro Conta tem-se o registro da movimentao de um certo produto em um estoque ou uma conta. Mas em alguns casos necessrio registrar a movimentao de um produto de um local para outro. Por exemplo, suponha que uma pessoa tem vrias contas correntes, em bancos diferentes. Neste caso, o padro Conta no pode registrar a movimentao de dinheiro entre essas contas. Uma Transao assume que toda retirada em uma Conta gerar um depsito no mesmo valor, em outra Conta, e vice-versa. Assim registra-se a origem e o destino de todas as movimentaes (Figura 3.8). Para explicar o conceito de Transao, Fowler (1997) usa o princpio da conservao, que diz que o dinheiro (ou qualquer outro produto) nunca criado ou destrudo e sim movimentado de um local (conta) para outro. Uma Transao contm uma restrio que diz que a soma de seus lanamentos precisa ser igual a 0 (zero). Assim o dinheiro sempre movimentado, nunca criado ou destrudo.

29

Figura 3.8 - Transao

Exemplo: Pedro transferiu R$ 1000,00 de sua conta no Banco Brasileiro para sua conta no Banco Catarinense. Isso representado por uma Transao com um Lanamento de -1000 na Conta Banco Brasileiro e outro Lanamento de 1000 na Conta Banco Catarinense.

Em estruturas mais complexas este padro uma boa alternativa ao padro Conta, pois alm de ter mais informaes sobre as movimentaes, o princpio de conservao usado neste padro ajuda a previnir falhas no sistema.

3.2.3

Transaes Mltiplas

O padro Transao limita-se a representar uma nica retirada de alguma Conta e um nico depsito em outra Conta. Assim no h possibilidade de representar a movimentao de vrias Contas em uma nica transao. Por exemplo, se Pedro retirou R$ 1000,00 de sua conta no Banco Brasileiro, e retirou R$ 1200,00 do Fundo de Aes e depositou o total desse dinheiro na sua conta do Banco Catarinense, esta movimentao tem de ser representada por duas Transaes, apesar de Pedro ter feito apenas um nico depsito na Conta do Banco Catarinense.

Para representar a movimentao de Pedro em uma nica Transao usa-se o modelo de Transaes Mltiplas (Figura 3.9).

30

Figura 3.9 Transao Mltipla

Assim h a possibilidade de se associar dois ou mais Lanamentos a uma Transao. O princpio da conservao continua valendo neste caso. Assim a Transao simples (com apenas dois Lanamentos) se torna um caso particular da Transao Mltipla.

3.2.4

Conta Resumida

Para sistemas de contabilidade um pouco mais complexos, utiliza-se o padro Conta Resumida, que faz um agrupamento de vrias Contas numa nica Conta Resumida. Este tipo de estruturao pode ser feito conforme o modelo da Figura 3.10

Figura 3.10 Conta Resumida

31

Exemplo: Na contabilidade de Simo h uma Conta Resumida para gastos essenciais que agrupa as seguintes Contas Detalhadas: gastos combustvel, gastos sade, gastos mercado.

Neste modelo apenas, as Contas Detalhadas podem ter Lanamentos. Para calcular o saldo de uma Conta Resumida, esta consultar as Contas nela agrupadas. Nota-se que uma Conta Resumida pode agrupar vrias Contas Resumidas, criando assim uma rvore de Contas.

3.2.5

Conta Gatilho

Este padro teve como base o controle do valor dos impostos sobre movimentao de dinheiro. Normalmente, o valor dos impostos de uma empresa s conhecido quando esta realiza um balano no fim do ms, ou do ano. Usando este padro o sistema ir contabilizar o valor total do imposto a cada entrada no caixa da empresa. Ele funciona da seguinte maneira: Para cada Lanamento de entrada de dinheiro na conta caixa da empresa, haver tambm um Lanamento Gatilho em uma outra conta, uma Conta Gatilho. Este Lanamento Gatilho ter como valor a quantidade de imposto gerado pelo Lanamento de entrada de dinheiro. Assim, a Conta Gatilho ter no seu saldo o valor do imposto a ser pago sempre atualizado. Assim uma empresa pode saber, a qualquer momento, o valor que ela ter que pagar em impostos de acordo com a movimentao de dinheiro que ela j fez.

Exemplo 1: Quando Joo recebe o pagamento de um cliente, ele paga 25% deste pagamento em impostos. Joo ento registra um Lanamento na sua conta de pagamentos e tambm um Lanamento na Conta Gatilho Imposto. O Lanamento na Conta Gatilho ser 25% do valor do Lanamento na Conta de Joo.

32

3.2.6

Regra de Lanamento

No exemplo da Conta Gatilho para imposto, o usurio deve sempre realizar dois lanamentos no sistema para registrar a taxao da movimentao. Um lanamento para a conta real e um lanamento registrando o valor da taxao. Se o imposto tem um valor fixo, como 25% no exemplo anterior, pode-se programar o sistema para realizar os lanamentos na Conta Gatilho automaticamente, simplesmente criando uma regra para as contas as quais os lanamentos so taxados. A regra calcularia o imposto de todos os lanamentos de uma conta associada como gatilho e geraria um lanamento, no valor calculado, numa Conta Gatilho, associada Regra de Lanamento como sada. (figura 3.11).

Figura 3.11 Regra de Lanamento

Exemplo: Todo pagamento recebido por um servio taxado em 12% pelo ISS (imposto sobre servios). Modela-se esta taxao com a Conta pagamento de servios sendo o gatilho da Regra de Lanamento clculo de ISS e a sada desta Regra sendo a Conta total do ISS. H casos em que o clculo do valor do imposto um pouco mais complexo, e no apenas uma mera multiplicao. Um exemplo o clculo de impostos gradativos, em que movimentaes abaixo de um valor so isentas de cobrana, e acima de outro valor, tem uma cobrana diferenciada. Para estes casos necessrio um algoritmo arbitrrio para o clculo do imposto. Ento um Mtodo de Clculo associado a classe Regra de Lanamento. Assim cada instncia de Regra de Lanamento ter seu prprio Mtodo de Clculo (figura 3.12).

33

Figura 3.12 Metodo de Clculo para saida

3.2.7

Regras de Lanamentos para vrias contas

Pode-se estender o padro Regra de Lanamento de maneira que uma nica regra possa tratar de vrias contas, sem a necessidade de criar uma regra para cada conta do sistema. Assim, tomando uma empresa genrica como exemplo, pode-se ter uma Conta para cada empregado e apenas uma Regra de Lanamento para tratar o clculo do imposto de renda sobre o salrio dos trabalhadores. Pode-se modelar a soluo de duas maneiras: a primeira dividir o modelo em dois nveis: nvel de informao e nvel operacional. Colocam-se as Regras de Lanamento no nvel de informao e associam-nas com Tipo de Conta. Assim pode-se ter Tipo de Conta para salrio, horas-extras, etc. No nvel operacional colocam-se as contas reais do domnio da aplicao (figura 3.13).

34

Figura 3.13 Conta e Tipo de Conta

Quando um Lanamento for feito na Conta, esta vai executar as regras de lanamento do Tipo de Conta associado a ela. A segunda maneira proposta usar Contas Resumida (seo 3.2.4). Uma Regra de Lanamento definida para uma conta resumo e quando um lanamento feito em uma conta detalhada, esta executar a Regra de Lanamento de sua conta resumo. A escolha entre os dois mtodos depende do comportamento do Tipo de Conta. Caso a diviso de nvel de informao e nvel operacional seja bem clara, e todas as regras de lanamento estejam associadas ao Tipo de Conta e os lanamentos s so feitos em uma conta, ento o modelo de nveis mais apropriado. Mas em muitos casos os lanamentos podem ser feitos em nveis mais gerais. Lanamentos podem estar associados a Tipos de Conta e regras de lanamentos associadas a contas, o que infringiria a diviso entres os nveis operacionais e de informao. Neste caso o melhor usar o modelo da segunda proposta, com contas resumo.

35

Pode-se estender os modelos para abranger situaes mais complexas, como casos em que a conta de sada da regra de lanamento pode mudar de acordo com certos parmetros. Como exemplo, tem-se o caso em que o desempenho de um programador dentro de um projeto afeta o salrio do gerente deste projeto. Neste caso, a regra de lanamento teria a conta desempenho do programador como gatilho, e deve procurar a conta salrio do gerente do projeto para colocar como sada. Isso se faz atravs da associao da regra de lanamento a um mtodo de procura (figura 3.14).

Figura 3.14 Localizador de Conta

O mtodo localizador vai consultar a conta gatilho desta regra para saber qual programador a fonte deste lanamento. Consultando o programador, o mtodo obtem informaes sobre o projeto deste programador e o seu gerente. Assim o mtodo localizador encontra a conta salrio do gerente, que ir receber um lanamento de bnus pelo desempenho deste programador.

3.3 Comrcio
Neste captulo sero descritos padres que realizam o controle de compra e venda de produtos, e como o valor destes produtos pode modificar as condies do mercado. Os padres descrevem como uma instituio pode registrar suas operaes comerciais para usar como base para tomada de decises.

36

3.3.1

Contrato

O tipo mais simples de relao comercial de uma entidade (pessoa/organizao) comprando um produto de outra entidade. O produto qualquer item comercializvel, como por exemplo, sacas de caf e toneladas de ferro. Um simples modelo como da figura 3.15 pode representar essa operao. Em contrato representa-se uma transao comercial como um Contrato. Um Contrato pode ser uma compra, uma venda ou qualquer outra transao feita entre entidades. Ele tem como atributos Quantidade e Preo. O produto a ser comercializado representado como um Produto que est associado a Contrato (Figura 3.15).

Figura 3.15 Contrato com especificao

Exemplo: a UFSC registra a compra de 500 resmas de papel Folhex ao preo de R$ 8,00 cada, como sendo uma Compra com o Contratante sendo a Folhex Fornecedora de Papel e o Produto sendo resmas de papel. Preo fica em 8 e quantidade 500.

As operaes que sero representadas em Contrato nem sempre precisam ser especificaes do mesmo. Para operaes de Compra e Venda, tem-se como alternativa especificao a criao de duas associaes entre Contrato e Parte (Figura 3.16).

37

Figura 3.16 Contrato com associaes

Este segundo modelo tambm possibilita que sejam registradas transaes com mais de uma Entidade de ambos os lados (vendedor e comprador).

Exemplo: A UFSC deseja registrar a compra de resmas de papel do Centro Tecnolgico. O sistema da UFSC registraria como um Contrato com Folhex Fornecedora de Papel como vendedor e o CTC como comprador.

Um modelo mais abrangente utilizando Contratos pode ser definido fazendo a juno dos dois primeiros modelos. Os dois lados da transao foram definidos como Contratado e Contratante e as especificaes de contrato sero as operaes que podem ser realizadas, com seus devidos comportamentos (Figura 3.17).

Figura 3.17 - Contrato

38

O diferencial destes dois ltimos modelos que os contratos registrados no precisam necessariamente envolver a Entidade que controla o sistema. Caso seja vlido, pode-se registrar transaes comerciais entre Entidades externas ao sistema. Nota-se a possibilidade de relacionar este modelo com o modelo de Transaes do captulo anterior. Um contrato de venda, por exemplo, pode ser representado por uma Transao que faz um Lanamento de um produto na Conta de um comprador e faz outro Lanamento de dinheiro na Conta de um vendedor.

3.3.2

Portflio

Raramente considera-se um modelo de contratos sozinho. Tipicamente uma empresa que gerencia contratos vai analisar um grupo de contratos de um certo tipo para estimar os riscos em contratos futuros. A seleo dos contratos que sero analisados pode ser feita pelo tipo de produto comercializado, pela entidade contratante ou por qualquer outra propriedade relevante de contrato. Um Portflio representa este grupo, ou seja, uma coleo de contratos que iro ser avaliados (figura 3.18).

Figura 3.18 - Portflio

A seleo dos contratos associados a um Portflio pode ser feita atravs de um mtodo que recebe um Contrato como parmetro. Caso o mtodo retorne um valor verdadeiro, o Contrato pertencer quele Portflio (figura 3.19).

39

Figura 3.19 Seleo de Contratos por mtodo booleano

Outra maneira para a construo da coleo dos contratos que pertencero a um portflio a implementao de um Seletor de Contratos. Este seletor ir combinar alguns atributos de Contrato, como contratante, produto, data de incio, etc. e os utilizar para filtrar um grupo particular de contratos. (figura 3.20).

40

Figura 3.20 Seleo de Contratos por comparao com Seletor

Apesar de ser menos abrangente que um mtodo de seleo, o Seletor de Contratos bem mais flexvel, podendo ser modificado em tempo de execuo apenas alterando o valor de suas propriedades. Portflios podem ser temporrios ou persistentes. Porflios temporrios so criados por demanda. Um filtro especificado e todas as instncias de Contrato so consultadas. Ao fim da utilizao, o Portflio perde a sua coleo de Contratos. Portflios persistentes so criados da mesma maneira, mas no so descartados ao fim de sua utilizao. Quando um novo Contrato criado, este passa pelos filtros dos Portflios permanentes. Caso o novo Contrato preencha os requisitos do filtro, anexado ao Portflio. Portflios so teis em muitos domnios. A caracterstica essencial de um Portflio a de que um objeto que encapsula um mecanismo de seleo de um grupo de objetos (FOWLER, 2000)

PADRES DE PROJETO

Pode-se definir padres de projetos como um conjunto de classes de software que descrevem uma soluo comum para determinados tipos de problemas. Essas classes tm papis bem definidos e interagem entre si para construir uma soluo lgica que ser implementada em uma linguagem de programao. No decorrer do desenvolvimento do trabalho foi feito um estudo de alguns dos padres de projeto do livro Design Patterns de Erich Gamma (1994). Segundo o prprio Gamma, os padres descritos em seu livro so descries de classes e objetos comunicantes, que so configuradas para resolver algum problema comum de projeto de software, dentro de um contexto particular. Gamma (1994) classifica os padres em 3 grupos distintos, levando em conta o tipo de problema ao qual o padro se destina: criao, estrutural e comportamental (creational, structutral and behavioral). Padres de criao delegam partes do processo de criao de um objeto para subclasses ou para outros objetos. Padres estruturais usam herana para compor as classes. Padres comportamentais usam herana para implementar algortmos e fluxos de controle. Os padres estudados foram o Singleton (criao), Factory Method (criao), Proxy (estrutural), Facade (estrutural), State (comportamental), Strategy

(comportamental) e Composite (estrutural). Mais a frente ser discutida a viabilidade do uso dos padres no projeto da aplicao de Controle de Atacado.

4.1 Singleton
O padro Singleton usado para assegurar que uma referida classe possa ter apenas uma instncia no sistema e essa instncia tenha um ponto de acesso global. Pode ser usado, por exemplo, num sistema de impresso que contenha apenas um spooler,

42

num sistema operacional, que deve contar apenas um sistema de arquivos ou num sistema de controle de estoque, que deve ter apenas um caixa. Neste padro, a classe de instncia nica, ou classe Singleton, ser responsvel em assegurar que apenas uma instncia sua poder ser criada. Para isso, o construtor dessa classe deve ser uma operao de classe (static em Java ou C++). O acesso instncia tambm se dar atravs de uma operao de classe. A classe Singleton faz o encapsulamento da sua instncia nica, armazenada num atributo da prpria classe. Isso permite total controle de quando e como se dar o acesso instncia (Figura 4.1).

Figura 4.1 Estrutura do Padro Singleton

Para implementar uma classe Singleton em Java, declara-se o construtor como privativo. O acesso a classe se dar atravs do mtodo obterInstancia que fornecer sempre a mesma instncia. Caso nenhuma instncia da classe tenha sido criada, o mtodo cria a instncia.
public class Singleton { private static Singleton instancia; private Singleton() {} public static Singleton obterInstancia() { if (instancia == null) { instancia = new Singleton(); } return instancia; }

43

Pode-se usar o padro Singleton para substituir classes totalmente estticas (classes sem instncias, apenas com mtodos estticos) com a vantagem de o padro possibilitar o uso de subclasses da classe esttica (classes totalmente estticas no podem ter seus mtodos sobrescritos, no suportam polimorfismo).

4.2 Factory Method

O padro Factory Method geralmente utilizado em situaes onde a definio do tipo de objeto a ser criado s especificada na subclasse de uma classe. A utilizao do Factory Method d mais flexibilidade a classe por deixar que sua subclasse tome a deciso de que tipo de objeto ser craido. Pode-se citar o exemplo da classe Desenho para demonstrar a utilizao do Factory Method. A classe abstrata desenho trabalha com os objetos da classe abstrata FormaGeometrica, que generaliza as classes Circulo, Triangulo e Quadrado. Um mtodo para da classe Desenho sem o uso do Factory Method ficaria da seguinte forma:
public class desenho { public void desenharCasa() { telhado = new Triangulo(); parede = new Circulo(); telhado.desenhar; parede.desenhar; } }

Esse tipo de implementao torna a classe Desenho pouco extensvel. Caso haja necessidade de criar uma extenso de desenho, como por exemplo DesenhoColorido, utilizando nessa extenso as classes CirculoColorido, TrianguloColorido, e

QuadradoColorido, o mtodo desenharCasa teria que ser refeito. O padro Factory Method torna as extenses da classe Desenho mais simples utilizando-se de "mtodos de criao", ou factory methods, para instanciar as classes Circulo, Triangulo e Quadrado. Abaixo o mtodo de criao criarForma:

44

public class Desenho { public FormaGeometrica criarForma(forma) { if (forma == "circulo") { r = new Circulo(); } else { if (forma == "triangulo") { r = new Triangulo(); . . . return r; } }

O mtodo desenharCasa fica da seguinte forma

public void desenharCasa() { telhado = criarForma("triangulo"); //no h definio da classe parede = criarForma("quadrado"); //no h definio da classe telhado.desenhar; parede.desenhar; }

Dessa maneira, para estender a classe Desenho para DesenhoColorido, reescrevese apenas os mtodos de criao.
public class DesenhoColorido extends Desenho { public FormaGeometrica criarForma(forma) { if (forma == "circulo") { r = new CirculoColorido(); classe } else { if (forma == "triangulo") { r extensao da classe . = new TrianguloColorido(); //modificacao da //modificacao da extensao da

45

4.2.1

Estrutura

estrutra

do

padro

representada

por

quatro

classes:

Produto,

ProdutoConcreto, Criador e CriadorConcreto (figura 4.2). O Produto define a interface do objeto a ser criado. No exemplo anterior, o Produto seriam as classes Triangulo, Circulo e Quadrado. ProdutoConcreto a extenso da classe Produto. As classes TrianguloColorido um ProdutoConcreto de Triangulo. No Criador declarado o mtodo criador, ou factory method, que retorna um objeto da classe Produto. A classe Desenho um criador e criarForma o factory method. O CriadorConcreto reescreve o mtodo criador para retornar uma instncia de ProdutoConcreto (figura 4.2).

Figura 4.2 Estrutura do Factory Method

46

4.2.2

Implementao

Como visto no exemplo, a implementao de um Factory Method relativamente simples. Na classe Criador o factoryMethod pode ser abstrato, contendo apenas a assinatura do mtodo. Na classe CriadorConcreto o factoryMethod definitivamente implementado, podendo ter como argumento, variveis que tenham influncia na deciso da classe concreta a ser criada. Classe Criador:
public abstract class Criador { public Produto factoryMethod(); }

Classe CraidorConcreto:
public class CriadorConcreto extends Criador { public Produto factoryMethod() { return new ProdutoConcreto(); } }

4.3 Proxy
O padro Proxy tem como objetivo prover um substituto ou ponto de acesso (GAMMA, 1994) que far o controle de acesso a outro objeto. Dessa maneira, pode-se prorrogar os custos da criao de um objeto at que o mesmo seja realmente utilizado, ou fazer a representao de um objeto remoto localmente. Numa aplicao com acesso banco de dados, uma consulta ao banco pode ser uma tarefa de alto custo. Um objeto persistente pode ter uma propriedade complexa, que necessita de vrias junes de tabelas para ser obtida. O Proxy evita que a definio de uma propriedade complexa seja feita na construo do objeto, e prorroga a definio

47

dessa propriedade at que seja realmente necessria. Isto torna todo o trabalho mais eficiente. Para isso cria-se um intermedirio (proxy) do objeto persistente. O objeto intermedirio ter uma interface em comum com o objeto persistente, alm de ter uma referncia para o mesmo (figura 4.3).

Figura 4.3 Exemplo do Proxy

4.3.1

Implementao

Como foi dito anteriormente, a classe Intermedirio ter uma referncia para o objeto real. No caso especfico do exemplo, a diferena das classes Intermedirio e PersistenteReal estar no construtor das mesmas. O construtor da classe Intermedirio no far a consulta para obter propriedadeComplexa.
public class Intermediario implements Persistente { private PersistenteReal real; protected int propriedadeSimples; protected String propriedadeComplexa;

48

protected BD BancoDeDados public Intermediario() { BD = BancoDeDados.obterBanco(); propriedadeSimples = BD.consulta(consultaSimples); } public String obterPropriedadeComplexa() { if (real == null) { real = new PersistenteReal(); } return real.obterPropriedadeComplexa(); } }

Nota-se que uma instncia de Intermediario s inicializa propriedadeSimples. Quando propriedadeComplexa requistada, Intermediario faz a criao de uma instncia de PersistenciaReal, e desta instncia obtm a propriedadeComplexa. Caso haja necessidade de consultar a propriedadeSimples de uma grande quantidade de dados, o uso do Proxy far com que a tarefa fique muito mais eficinte.

4.3.2

Estrutura

SujeitoReal a classe original, que ter um substituto equivalente com uma interface em comum. O Proxy a classe que ir substituir SujeitoReal. Proxy referencia SujeitoReal e as duas compartilham a mesma interface (figura 4.4).

49

Figura 4.4 Etrutura do Proxy

Algumas variaes do Padro Proxy so:

Remote proxy - fornece uma representao local para um objeto remoto; Protection proxy faz controle de acesso ao objeto real. til para quando o objeto real possui acesso restrito; Virtual proxy prorroga criao de objetos com alto custo de criao (exemplo de classe persistente descrito anteriormente);

4.4 Facade
O objetivo do padro Facade unificar em uma interface a manipulao de vrios objetos de um subsistema. Assim, as classes do ncleo de cada subsistema podem ser modificadas sem que a interface para o cliente seja afetada. Em um conjunto de subsistemas, isso diminui a interdependncia entre os mesmos. Outra consequncia de seu uso a diminuio da complexidade de utilizao dos subsistemas, pois reduz o nmero de objetos que precisam ser acessados externamente.

50

Pode-se exemplificar o uso do Facade supondo que o sistema de matrcula e alocao de salas da UFSC tenha a estrutura mostra na Figura 4.5:

Figura 4.5 Sem o uso do Facade

O cliente do sistema precisa conhecer vrias classes, promovendo um acomplamento forte entre o sistema e o cliente. Utilizando o padro Facade, o sistema fornece uma interface nica para o cliente, facilitando a utlizao e diminuindo o acoplamento. No exemplo da Figura 4.6 matricula_aloca um Facade para o sistema de alocao e matrcula.

51

Figura 4.6 Com o uso do Facade

4.4.1

Implementao

A classe Facade deve implementar operaes gerais do sistema. O acesso ao sistema deve ser feito unicamente pela classe Facade.

Implementao sem Facade:

public class Cliente { public void matricularCalouro(Aluno umAluno, Curso curso) { Turma[] turmas1fase = curso.materias1fase(); for (int i = 0; i < turmas1fase.length; I++) { turmas1fase[I].adiciona(umAluno); } curso.adicione(umAluno); } }

52

Usando Facade:
public class Matricula_aloca { public void matricular(Aluno oAluno, Curso oCurso, int fase) { . . . }

Simplificao da classe Cliente:

public class Cliente { Matricula_aloca sistemaMatriculaAloca public void matricularCalouro(Aluno umAluno, Curso curso) { sistemaMatriculaAloca.matricular(umAluno, curso, 1); } }

4.4.2

Estrutura

O Facade cria uma interface nica para todo sistema como mostra a Figura 4.7

Figura 4.7 Estrutura do Facade

53

4.5 State
O Padro State implementa o conceito de estado de classe. Ele permite que uma classe possua vrios estados e que a alterao destes estados possa ser feita em tempo de execuo, mudando tambm o comportamento da classe.

Exemplo 1: Em uma empresa, vrias operaes, como calculo de impostos, dependem da classificao da mesma em micro, pequena ou mdia empresa. Esta classificao feita baseando-se no nmero de empregados da empresa. Neste caso pode-se utilizar o padro State para modelar o sistema como mostra a Figura 4.8:

Figura 4.8 Padro State

Cada subclasse de Tipo ter sua prpria implementao do calculo do imposto. Assim empresa repassa esta responsabilidade para uma dessas subclasses. O estado da empresa pode ser definido toda vez que a propriedade n_empregados for alterada.

54

4.5.1

Estrutura

A classe Contexto representa um objeto real que possui vrios estados. Contexto ter uma instncia de um EstadoConcreto que definir seu estado atual. A classe Estado define uma interface comum para as implementaes dos estados de Contexto. Cada classe EstadoConcreto implementa um estado real do Contexto. Pode-se ver o diagrama da estrutura na Figura 4.9:

Figura 4.9 Estrutura do State

4.5.2

Implementao

Seguindo o padro, a classe Empresa (exemplo 1) fica da seguinte maneira:

public class Empresa { public final Tipo Micro = new MicroEmpresa(); public final Tipo Pequena = new PequenaEmpresa(); public final Tipo Media = new MediaEmpresa(); protected n_empregados; private Tipo tipo_empresa;

55

public float calcularImposto() { return tipo_empresa.calcularImposto(); }

public void alterar_n_empregados(int n_emp) { if (n_emp > 20) { altere_tipo_empresa(Pequena); } else { if (n_emp > 100) { altere_tipo_empresa(Media); } else { altere_tipo_empresa(Micro); } } n_empregados = n_emp; }

private void altere_tipo_empresa(Tipo tipo_emp) { tipo_empresa = tipo_emp; } }

Nota-se que a classe possui associaes com as instncias que implementam seus estados. Quando requisistada uma alterao no atributo n_empregados, o procedimento altere_n_empregados define o tipo de empresa verificando o argumento n_emp e chamando a funo altere_tipo_empresa. O padro State no especifica que classe de sua estrutura deve definir o estado atual de Contexto. Na implementao a definio foi feita na classe Empresa, pois esta

56

possui o conhecimento do critrio de alterao dos estados. Em alguns casos define-se a alterao do estado nas classes de EstadoConcreto.

4.6 Composite
O padro Composite usado em aplicaes em que se utiliza composio de objetos individuais para implementao de objetos mais complexos. Este padro permite que a forma de manipulao dos objetos seja a mesma, tanto para objetos simples como para objetos complexos (compostos).

4.6.1

Estrutura

Figura 4.10 Estrutura do Composite

A classe abstrata Componente declara uma interface para os objetos da composio e implementa os comportamentos que so comuns aos objetos simples e complexos.

57

A classe ComponenteComplexo representa um objeto composto. A associao filho permite que esta composio seja tanto de objetos simples como de objetos complexos. ComponenteSimples representa o objeto simples.

4.6.2

Implementao

A classe abstrata Componente implementa apenas os mtodos comuns aos dois tipos de objetos, definindo o restante dos mtodos como abstratos. A classe ComponenteComplexo implementa os mtodos de manipulao dos componentes filhos como inserir, remover e retornarFilho.
public class ComponenteComplexo extends Componente {

private Vector composicao;

public void inserir(Componente filho) {

composicao.add(filho); }

public Componente retornarFilho(int id) {

return (Componente)composicao.get(id); } }

A classe ComponenteSimples no possui associao com nenhum outro componente e no implementa os mtodos de manipulao de filhos.

58

4.7 Strategy
O padro Strategy cria a possibilidade de se definir mais de um tipo de algortmo para um mesmo mtodo. til nos casos onde a implementao do mtodo depende de algum fator externo classe em que ser implementado.

4.7.1

Estrutura

O padro ser aplicado a uma classe Contexto. Os diferentes algortmos sero implementados em diferentes classes, mas com uma interface comum (Estratgia) como mostra a Figura 4.11:

Figura 4.11 Estrutura do padro Strategy

4.7.2

Implementao

Pode-se exemplificar a aplicao do Strategy na implementao de script para visualizao em browsers. Apesar da padronizao, browsers como Internet Explorer e Mozilla interpretam scripts de forma diferente. Usa-se o padro para implementar diferentes algoritmos de acordo com o browser.

59

Figura 4.12 Estrutura do Strategy

public class PaginaWeb { private Script script; public PaginaWeb() { if (navigator.name == "IE") { script = new ScriptIE(); } else { script = new ScriptMozilla(); } }

public PaginaWeb(Script novoScript) { script = novoScript; }

public void desenhaPopUp() { script.implementaPopUp(); } }

MAPEAMENTO

DE

PADRES

DE

ANLISE

PARA

PADRES DE PROJETO

Um dos objetivos do trabalho a elaborao de mapeamentos de padres de anlise para padres de projeto. Isto , aps estudo aprofundado de um padro de anlise, o seu modelo conceitual transformado em um diagrama de classes de projeto utilizando padres de projeto. Neste captulo esto descritos alguns mapeamentos que foram desenvolvidos durante o trabalho.

5.1 Padro de Anlise Transaes e Padro de Projeto Proxy.

O primeiro projeto refere-se ao mapeamento do padro de anlise Transaes para o padro de projeto Proxy. O padro Proxy se aplica ao modelo de Transaes quando as transaes so armazenadas em uma base de dados. Muitos clientes da classe Conta acessaro esta para consultar somente seu atributo saldo. Nestes casos, no necessrio que Conta tenha referncia para as instncias da classe Lanamento associadas. Utiliza-se ento o padro Proxy para que as intncias da classe Lanamento sejam carregadas e criadas por demanda.

61

Figura 5.1 Estrutura do Proxy

Um cliente que necessite somente da consulta do saldo de uma conta ir ter acesso a uma instncia da classe ContaProxy. Esta instncia ir carregar apenas o atributo saldo atravs da camada de persistncia para o banco de dados, prorrogando o carregamento das instncias de Lanamento somente quando forem necessrias. Assim a implementao de calcularSaldo fica da seguinte maneira:
Public float calcularSaldo() { If (real == null) { real = new ContaReal(); } return real.calcularSaldo(); }

5.2 Padro de Anlise Conta Resumida e Padro de Projeto Composite

Este mapeamento toma como base o padro de anlise Conta projetado pelo padro Composite.

62

Figura 5.2 Padro de Anlise Conta Resumida

Figura 5.3 - Padro de Projeto Composite

O conceito de Conta ser implementado como a classe Componente do padro Composite. ContaResumida ser o objeto composto do padro, ou seja, o ComponenteComplexo. ContaDetalhada ser o objeto simples, ou a classe ComponenteSimples. O diagrama de classe do mapeamento descrito na Figura 5.4.

63

Figura 5.4 Diagrama de classe do mapeamento

A implementao segue as regras do padro Composite. Conta uma classe abstrata, mas implementa os mtodos comuns ContaDetalhada e ContaResumida como obterSaldo. Conta tambm define o atributo saldo comum as duas classes. Em ContaResumida h um mtodo particular, calcularSaldo. Este mtodo deve consultar o saldo de todos os objetos de Conta associados ao objeto ContaResumida, que podem, pos sua vez, serem contas detalhadas ou contas resumidas. A implementao segue abaixo.
Public float calcularSaldo() { Conta _conta; While (agrupadas.hasNext()) { _conta = agrupadas.next(); this.saldo = this.saldo + _conta.obterSaldo(); } return saldo; }

64

5.3 Padro de Anlise Portflio e Padro de Projeto Strategy

O padro de anlise Portflio (seo 4.6.2) consiste em uma coleo de contratos que obedecem a certos critrios de seleo. Uma das maneiras abordadas para a construo desta coleo atravs de um mtodo de seleo que recebe um contrato como parmentro. Caso este mtodo retorne um valor verdadeiro, o contrato ser associado ao Portflio (figura 5.5).

Figura 5.5 Seleo de contrato por mtodo

A utilizao do padro Strategy para implementao do Mtodo de Seleo do Portflio possibilita a utilizao de vrios mtodos de seleo distintos, e a escolha de que mtodo de seleo ser utilizado pelo Portflio para seleo de contratos pode ser feita por externamente classe, dando grande flexibilidade ao sistema. A seguir, tem-se o diagrama de classes de um Portflio projetado usando-se Strategy.

65

Figura 5.6 Estrutura da implementao

A implementao da classe Contrato fica da seguinte forma:

public class Portfolio { protected MetodoSelecao filtro; public selecionarMetodo(String selecao) { if (selecao == "porValor") { filtro = new SelecaoValor(); } else { filtro = new SelecaoData(); } } public void analisar() { Contrato contrato; while selecao.hasNext() { contrato = selecao.next(); if (filtro.filtrar(contrato) == false) { selecao.remove(contrato); } } }

66

No exemplo acima o mtodo selecionarMetodo recebe um parametro selecao que define qual mtodo de seleo ser usado pela instncia de Portfolio.

5.3.1 Uso do Singleton

De acordo com o padro de anlise Portflio, um mesmo mtodo de seleo pode ser usado por vrios portflios. Neste caso pode-se evitar o custo da criao de vrias instncias de MtodoSeleo implementando-se as classes concretas dos mtodos de seleo como Singletons. Assim tem-se o mapeamento do padro de anlise Portflio para os padres de projeto Singleton e Strategy (figura 5.7).

Figura 5.7 Portflio mapeado para Singleton e Strategy

Abaixo segue a implementao da classe SelecaoValor como um Singleton:

public class SelecaoValor implements MetodoSelecao { protected SelecaoValor(){} public boolean filtrar(Contrato contrato){ }

67

public static SelecaoValor obterInstancia(){ if (instancia == null) { instancia = new SelecaoValor(); } return instancia; } private static SelecaoValor instancia = null; }

5.4 Padro de Anlise Regra de Lanamento e Padro Strategy

Em um caso semelhante ao anterior, o padro de anlise Regra de Lanamento possui um mtodo para clculo do valor do lanamento que ser efetuado na sua Conta de sada (figura 5.8). Para flexibilizar a classe de Regra de Lanamento, tambm faz-se usar do padro Strategy na sua implementao.

Figura 5.8 Padro de anlise Regra de Lanamento

Figura 5.9 Mapeamento do Padro Regra de Lanamento para o Strategy

68

A implementao da classe RegraLancamento segue abaixo:

public class RegraLancamento { protected Conta saida; protected MetodoCalculo calculo; public alterarSaldo(float saldo) { if (saldo > 1000) { calculo = new MetodoCalculoA(); } else { calculo = new MetodoCalculoB(); } } public void calcular() { saida.lanca(calculo.calcular()); } }

O metodo alterarSaldo de RegraLancamento recebe saldo como parmetro, e a partir dele decide que mtodo de clculo ser usado.

DESENVOLVIMENTO

O objetivo final do trabalho desenvolver um modelo de anlise e de projeto e implementar uma aplicao fazendo uso de alguns padres estudados durante a fase de pesquisa. Neste captulo ser descrito como os padres estudados foram utilizados no processo de desenvolvimento da aplicao de controle de atacado.

6.1 Levantamento de Requisitos

6.1.1 Descrio do Domnio da Aplicao

O domnio desta aplicao a consignao e venda de produtos. A empresa que serviu de base para o desenvolvimento um atacado de jias. L so vendidos vrios tipos de jias e semijias, alm de relgios, embalagens e mostrurios. A maioria dos clientes da joalheria trabalha com produtos consignados. O processo de consignao se d da seguinte maneira: um consignador (cliente da empresa) vai at a empresa e retira alguns produtos para levar em consignao. Este vendedor tem um perodo para vender os produtos (fora da empresa). Aps este perodo ele retorna empresa, e realiza o fechamento: faz o pagamento dos produtos que foram vendidos e faz a devoluo dos produtos que no conseguiu vender. A empresa tambm faz vendas sem consignao. Ou seja, um cliente vem at a empresa e faz a compra de um produto diretamente, sem consign-lo. Alm de controlar a parte de consignao e venda, o software deve fazer o controle de estoque, fluxo de caixa, e gerao relatrios gerais (lucro, gastos, estoque etc.). O estoque fica dividido em produtos que esto no estoque da empresa e produtos consignados.

70

Como fluxo de caixa, o sistema deve registrar os pagamentos aos fornecedores, o recebimento de contas a prazo (promissrias e cheques) e os gastos administrativos da empresa.

6.1.2 Casos de Uso A seguir a descrio dos casos de uso p/ aplicao.

Caso de Uso: Consignar Produtos

Atores: Tipo: Descrio: Funcionrio. Primrio O cliente escolhe os produtos que deseja levar em consignao. O funcionrio registra os produtos em poder do cliente.

Seqncia Tpica de Eventos Ao do Ator 1- O funcionrio se identifica atravs do cdigo do funcionrio. 2- O funcionrio identifica o cliente atravs do cdigo do cliente. cliente

Resposta do Sistema

3- O sistema informa os dados do (nome, telefones, RG, CPF,

endereo) e os produtos consignados (cdigo do produto, nome do produto, quantidade), caso ele tenha alguma. 4O funcionrio identifica os 5- O sistema informa o valor total

produtos escolhidos pelo cliente atravs dos dos produtos e o valor mnimo que deve ser cdigos dos produtos. vendido para alcanar a meta de venda.

Caso haja mais de um produto do mesmo tipo, o funcionrio entra tambm com a quantidade.

71

6operao.

funcionrio

confirma

7- O sistema imprime um relatrio contendo o cdigo e nome do cliente; nome do funcionrio que realizou a operao; cdigo, nome, quantidade, valor unitrio e valor total dos produtos consignados na operao.

Seqncias Alternativas 1.1 O cdigo do funcionrio invlido. Cancelar a operao. 2.1 O cdigo do cliente invlido (no est cadastrado). Cancelar a operao e perguntar ao usurio se deseja cadastrar o cliente (caso de uso Cadastrar Cliente). 4.1 O cdigo do produto invlido (no est cadastrada). Perguntar ao usurio se deseja cadastrar o produto (caso de uso Cadastrar Produto).

Caso de Uso: Fazer Fechamento

Atores: Tipo: Descrio: Funcionrio. Primrio O cliente informa os produtos que foram vendidos e os produtos que sero devolvidos. O funcionrio registra os produtos devolvidos e, consultando o registro de produtos em poder do cliente, informa o dbito do cliente. Este faz o pagamento vista ou escolhe formas de pagamento a prazo.

72

Seqncia Tpica de Eventos Ao do Ator 1- O funcionrio se identifica atravs do cdigo do funcionrio. 2- O funcionrio identifica o cliente atravs do cdigo do cliente. cliente 3- O sistema informa os dados do (nome, telefones, RG, CPF, Resposta do Sistema

endereo) e seus produtos consignados (cdigo do produto, nome do produto, quantidade). 4- O funcionrio seleciona dentre os 5- O sistema informa o valor total

produtos consignados ao cliente, quais sero dos produtos devolvidos e o valor total dos devolvidos, caso haja devoluo. 5- O funcionrio registra a forma de produtos comprados pelo cliente. 6- Se a forma de pagamento a prazo

pagamento escolhida pelo cliente avista ou for escolhida o sistema mostra o valor das a prazo. prestaes.

Na forma de pagamento a prazo deve ser identificado se ser usado cheque ou promissria. 7- O cliente faz o pagamento (se for o caso) e o funcionrio confirma a operao. 8- O sistema imprime um relatrio contendo cdigo e nome do cliente; nome do funcionrio que realizou a operao; cdigo, nome, quantidade, valor unitrio e valor total dos produtos vendidas na operao.

Seqncias Alternativas 1.1 O cdigo do funcionrio invlido. Cancelar a operao. 4.1 O cliente deseja devolver mais produtos que o permitido pela meta de vendas. O gerente entra com o cdigo do gerente para permitir a devoluo.

73

Caso de Uso: Comprar Produtos

Atores: Tipo: Descrio: Funcionrio Primrio O fornecedor identificado e os produtos so comprados. feito o pagamento vista ao fornecedor, ou escolhe-se formas de pagamento a prazo.

Seqncia Tpica de Eventos Ao do Ator 1- O funcionrio se identifica atravs do cdigo do funcionrio. 2O funcionrio identifica o 3- O sistema informa os dados do Resposta do Sistema

fornecedor atravs do cdigo do fornecedor. fornecedor (nome, telefones, RG, CPF, endereo) 4- O funcionrio registra os produtos 5- O sistema informa o total da

que sero comprados no sistema, informando compra. cdigo, descrio e preo de compra. 6- O funcionrio escolhe a forma de pagamento vista ou prazo. 7- O sistema imprime um relatrio contendo cdigo e nome do fornecedor; nome do funcionrio que realizou a

Na forma de pagamento a prazo deve operao; cdigo, nome, quantidade, valor ser identificado se ser usado cheque ou unitrio promissria (carn). e valor total dos produtos

comprados na operao.

Seqncias Alternativas 1.1 O cdigo do funcionrio invlido. Cancelar a operao. 2.1 O cdigo do fornecedor invlido. Cancelar a operao e dispara caso de uso Cadastrar Fornecedor.

74

Caso de Uso: Vender Produtos

Atores: Tipo: Descrio: Funcionrio. Primrio O funcionrio apresenta os produtos ao cliente. O cliente escolhe os produtos e faz o pagamento, ou escolhe formas de pagamento a prazo.

Seqncia Tpica de Eventos Ao do Ator 1- O funcionrio se identifica atravs do cdigo do funcionrio. 2- O funcionrio identifica o cliente atravs do cdigo do cliente. cliente 3- O sistema informa os dados do (nome, telefones, RG, CPF, Resposta do Sistema

endereo) e seus produtos consignados (cdigo do produto, nome do produto, quantidade). 4O funcionrio identifica os 5- O sistema informa o valor total

produtos escolhidos pelo cliente atravs do dos produtos cdigo do produto.

Caso haja mais de um produto do mesmo tipo, o funcionrio entra tambm com a quantidade. 6- O funcionrio registra a forma de 7- Se a forma de pagamento a prazo

pagamento escolhida pelo cliente a vista for escolhida o sistema mostra o valor das ou a prazo. prestaes.

Na forma de pagamento a prazo deve ser identificado se ser usado cheque ou promissria.

75

8- O cliente faz o pagamento (se for o caso) e o funcionrio confirma a operao.

9- O sistema imprime um relatrio contendo cdigo e nome do cliente; nome do funcionrio que realizou a operao; cdigo, nome, quantidade, valor unitrio e valor total dos produtos vendidas na operao.

Seqncias Alternativas 1.1 O cdigo do funcionrio invlido. Cancelar a operao. 2.1 O cdigo do cliente invlido (no est cadastrado). Cancelar a operao e perguntar ao usurio se deseja cadastrar o cliente (caso de uso Cadastrar Cliente). 4.1 O cdigo do produto invlido (no est cadastrada). Disparar caso de uso Cadastrar Produtos.

Caso de Uso: Vender Produtos Vista

Atores: Tipo: Descrio: Funcionrio. Primrio O funcionrio apresenta os produtos ao cliente. O cliente escolhe os produtos e faz o pagamento a vista. Neste caso de uso o cliente no identificado.

Seqncia Tpica de Eventos Ao do Ator 1- O funcionrio identifica-se atravs do cdigo do funcionrio. 2O funcionrio identifica os 3- O sistema informa o valor total Resposta do Sistema

produtos escolhidos pelo cliente atravs do dos produtos cdigo do produto.

Caso haja mais de um produto do mesmo tipo, o funcionrio entra tambm com a quantidade.

76

4- O cliente faz o pagamento (se for o caso) e o funcionrio confirma a operao.

Seqncias Alternativas 2.1 O cdigo do produto invlido (no est cadastrada). Disparar o caso de uso Cadastrar Produtos.

Caso de Uso: Fazer Pagamento ao Fornecedor

Atores: Tipo: Descrio: Funcionrio Primrio O pagamento feito ao fornecedor e o dbito eliminado

Seqncia Tpica de Eventos Ao do Ator 1O funcionrio identifica o Resposta do Sistema 2- O sistema exibe a lista de dbitos

fornecedor atravs do cdigo do fornecedor. com o fornecedor identificado. 3O funcionrio escolhe o 4- O sistema imprime um recibo contendo o nome do fornecedor e o valor do pagamento.

pagamento dentre a lista de dbitos.

Caso de Uso: Receber Pagamento

Atores: Tipo: Descrio: Funcionrio Primrio O cliente faz o pagamento e seu dbito liquidado.

77

Seqncia Tpica de Eventos Ao do Ator 1- O funcionrio identifica o cliente atravs do cdigo do cliente. Resposta do Sistema 2- O sistema exibe a lista de dbitos do cliente identificado (nome do cliente, data e valor do dbito). 3- O funcionrio escolhe qual dbito ser liquidado. 4- O sistema imprime um recibo contendo o nome do cliente e o valor do pagamento.

Seqncias Alternativas 3.1 O cliente paga um valor inferior ao valor do dbito. O gerente entra com o cdigo do gerente e o dbito alterado com o novo valor (valor da dvida valor pago).

Caso de Uso: Definir Meta de Venda

Atores: Tipo: Descrio: Gerente Secundrio O gerente define a porcentagem de produtos consignados que deve ser vendidas, ou seja, que no podem ser devolvidas.

Seqncia Tpica de Eventos Ao do Ator 1- O gerente define a porcentagem de produtos consignados que deve ser vendidas (no pode ser devolvidas) para todos os clientes. 2- O gerente confirma a operao Resposta do Sistema

78

Caso de Uso: Fazer Pagamento Administrativo

Atores: Tipo: Descrio: Funcionrio Secundrio O funcionrio descreve um gasto administrativo e fornece seu valor.

Seqncia Tpica de Eventos Ao do Ator 1- O funcionrio identifica-se atravs do cdigo do funcionrio. 2- O funcionrio descreve o gasto administrativo e fornece o valor. Resposta do Sistema

Caso de Uso: Cadastrar Cliente

Atores: Tipo: Descrio: Funcionrio Primrio Cadastra um cliente.

Seqncia Tpica de Eventos Ao do Ator 1O funcionrio preenche um Resposta do Sistema

cadastro com os dados do cliente (nome, telefone, RG, CPF, data de nascimento, endereo) 2- O funcionrio confere os dados e confirma a operao.

79

Caso de Uso: Cadastrar Produto

Atores: Tipo: Descrio: Funcionrio Primrio Cadastra umo produto.

Seqncia Tpica de Eventos Ao do Ator 1cadastro O com funcionrio os dados preenche do um Resposta do Sistema

produto

(descrio, quantidade, preo) 2- O funcionrio confere os dados e confirma a operao.

80

6.2 Anlise
Como descreve Craig Larman (1997) Para criar o software de uma aplicao, necessrio uma descrio do problema e dos seus requisitos. A anlise nada mais do que a transformao dos requisitos da aplicao em especificaes que descrevero uma soluo lgica para o domnio do problema. Nesta fase procura-se pesquisar e entender o domnio do problema, a partir da descrio dos requisitos, para o desenvolvimento de um modelo conceitual. o que Craig Larman (2001) chama de investigao do problema.

6.2.1

Modelo Conceitual

A palavra modelo pode ser definida como uma representao abstrata que permite descrever e/ou prever comportamentos especficos de um sistema, atravs do estudo de um nmero reduzido de caractersticas relevantes do sistema (MAFFEO, 1992) Esta representao pode ser de um fenmeno do mundo real (as leis fsicas de movimento so um modelo do movimento no mundo real), de uma mquina ou de um software. Os resultados dos processos de anlise sero modelos do domnio da aplicao que est sendo desenvolvida. O modelo conceitual ilustra os conceitos significativos em um domnio de problema (LARMAN, 1997). Ele um resultado da fase de anlise e ser a base para a fase de projeto. A partir da anlise dos casos de uso e dos requisitos, decompe-se o problema em conceitos e objetos individuais (LARMAN, 1997). Nesta parte do desenvolvimento ocorre a elaborao de um modelo conceitual do problema. No modelo da anlise no se descreve artefatos de implementao de software como classes de interface com o usurio ou camadas de persistncia. O objetivo do modelo conceitual no ser um projeto de software, mas uma descrio de coisas do mundo real que fazem parte do domnio do problema e sua soluo. Modelos no so certos ou errados, eles so mais ou menos teis (FOWLER, 1997). A escolha do modelo ter conseqncias na flexibilidade e reusabilidade do

81

projeto. Por isso, um estudo aprofundado do domnio importante antes de iniciar a modelagem. No modelo conceitual do controle de atacado a classe Atacado representa a empresa proprietria. Os clientes do atacado so representados pela classe Cliente. Os fornecedores so representados pela classe Fornecedor. Atacado, Cliente, Fornecedor e Funcionrio so especificaes de Entidade, pois representam conceitos de pessoa/organizao (figura 6.1).

Figura 6.1 Modelo baseado no padro Entidade

A consignao, compra e venda de produtos, descrita nos casos de uso de Compra de Produtos, Venda de Produtos e Consignao de Produtos so representadas atravs

82

das classes Compra, Venda e Consignao. Toda venda e toda consignao so feitas do atacado para um cliente. Ento associou-se o Cliente Consignao e Venda. Uma compra sempre feita de um fornecedor. Assim associou-se Compra Fornecedor (figura 6.2).

Figura 6.2 Modelo sem conceito de Contrato

Nota-se que as classes de operao Venda, Consignao e Compra esto associadas sempre duas entidades, sendo uma das entidades o Atacado. Assim sendo, baseou-se no padro Contratos, que diz que Um Contrato pode ser uma compra, uma venda ou qualquer outra transao feita entre entidades, para generalizar as trs operaes em uma classe Contrato como descrito na figura 6.3.

83

Figura 6.3 Conceito de Contrato

A data_fechamento de Consignao a data em que o cliente devolve os produtos que levou consignado como descrito no caso de uso consignar produtos. A classe Contrato est associada ao Atacado, pois as operaes de compra, venda e consignao sempre tem o atacado como parte contratada. Contrato tambm associado a um Funcionrio, o qual ir iniciar o contrato no sistema. Finalmente tem-se a associao de Contrato com Produto, pois as operaes realizam a comercializao de produtos do atacado (figura 6.4).

84

Figura 6.4 Modelo com conceito de Contrato

O padro Conta Resumida foi utilizado para elaborar o controle de caixa do sistema. A classe Caixa, uma Conta Resumida, ir representar o caixa da empresa, tendo como Contas Detalhadas a conta Receita e a conta Despesa. Lanamentos feitos em Receita representam entrada de dinheiro na empresa. Lanamentos feitos em Despesa representam os gastos. O atributo saldo de Caixa ser diferena entre as receitas e as despesas da empresa.

85

Figura 6.5 Conta Caixa, Receita e Despesa

Toda Venda e toda Compra gerar um ou mais Lanamentos. A classe Atacado tambm pode gerar Lanamentos que sero referentes a despesas administrativas como pagamentos de salrio, compra de material de escritrio, etc. (figura 6.6).

86

Figura 6.6 Lanamentos nos Caixas

Em Lanamento o atributo valor representa o valor do lanamento em reais. O tipo de lanamento pode ser cheque, promissria ou dinheiro. A data_lanamento ser a data em que o lanamento ser contabilizado no sistema. A data_registro a data em que o lanamento foi inserido no sistema. Por exemplo, um pagamento com cheque para 30 dias feito no dia 1 de maio ser registrado como um Lanamento do tipo cheque com data_registro 01/05 e data_lanamento 31/05. O modelo completo est descrito na figura 6.7.

87

Figura 6.7 Modelo conceitual da aplicacao

88

6.3 Projeto
O projeto do software a definio de quais artefatos de software sero usados na implementao de uma soluo lgica para o problema. E como eles (os artefatos) iro colaborar para preencher todos os requisitos (LARMAN, 2001). Os artefatos do projeto sero criados com base na inverstigao feita na fase de anlise. Seu projeto precisa ser especfico para resolver o problema, mas tambm suficientemente flexvel para tratar problemas e requisitos que surgirem no futuro (GAMMA, 1994). Projetistas iniciantes dificilmente conseguem um bom projeto de software. Um projeto ruim precisa ser alterado toda vez que surge um novo requisito, ou se encontra algum problema. Projetistas exprientes conseguem fazer um bom projeto utilizando suas experincias anteriores. Quando um problema de projeto solucionado, esta soluo registrada, para que no futuro, quando surgir um problema igual ou semelhante, no seja necessrio dispender tempo desenvolvendo um novo projeto. Assim nasce um padro de projeto.

6.3.1

Linguagem e Banco de Dados

A linguagem escolhida para o desenvolvimento da aplicao foi Java. Os fatores que influenciaram na escolha foram sua natureza multi-plataforma, robustez e relativa facilidade de programao (quando comparada com C++). Como a aplicao a ser desenvolvida utiliza objetos persistentes, fez-se necessrio o estudo de um sistema gerenciador de banco de dados (SGBD). Um fator preponderante na escolha do SGBD foi a portabilidade, pois a aplicao desenvolvida utiliza linguagem Java, que tem portabilidade como uma das caractersiticas principais. Outro fator foi o custo do software. Os SGBDs mais populares normalmente exigem altos custos para sua aquisio. Neste trabalho pretende-se desenvolver uma aplicao de baixo custo, que poder ser utilizada em um sistema operacional gratuito,

89

como Linux. Isso possibilita que os usurios da aplicao arquem com os custos apenas de equipamento e treinamento. Levando em conta os fatores descritos acima, escolheu-se o Firebird como SGBD da aplicao a ser desenvolvida. O Firebird um banco de dados relacional de cdigo aberto que deriva do Interbase. O Interbase tambm um SGBD freeware pertencente a Borland. Apesar de ser freeware, o Interbase um projeto com direes mais comerciais. O Firebird se mostrou um banco de dados estvel. Oferece suporte a triggers e stored procedures. A verso usada foi a 1.5 ClassicServer (IBPHOENIX, 2004). A instalao do Firebird no inclui interface grfica para manipulao de dados. Mas interfaces so encontradas facilmente na Internet, principalmente porque a maioria das interfaces para Interbase so compatveis com o Firebird. Iniciou-se o trabalho usando o IBAccess, que se mostrou muito limitada e instvel. Na procura de uma interface mais robusta, encontrou-se o IBExpert, que mesmo na verso mais simples (Personal) possui vrios recursos que ajudam a tirar proveito de todas as funcionalidades do banco de dados Firebird.

6.3.2

Diagramas de Sequncia

Das ferramentas UML para descrio de um projeto de software, duas sero utilizadas para o desenvolvimento da aplicao de Controle de Estoque: os diagramas de sequncia que descreve como os objetos interagem via menssagens (LARMAN, 2001) e o diagrama de classe, que descreve as classes do projeto e suas associaes. Dando continuidade a fase de projeto, foram criados diagramas de interao para os casos de uso correspondentes. Os diagramas de interao mostram como os objetos interagem atravs de mensagens para cumprir tarefas. (LARMAN, 1997). Os diagramas de interao podem ser representados atravs de dois tipo distintos: diagramas de colaborao, que representam a interao entre os objetos do software atravs de um grafo, e diagramas de sequncia. A seguir tem-se os diagramas de sequncia para os casos de uso mais relevantes do sistema.

90

6.3.2.1 Consignar

O diagrama de sequncia de consignar que representa o caso de uso Consignar Produto descrito na Figura 6.8.

Figura 6.8 Diagrama de Sequncia Consignar

91

6.3.2.2 Vender

Diagrama de Sequncia do Caso de Uso Vender Produto descrito na Figura 6.9.

Figura 6.9 Diagrama de Sequncia Vender

92

6.3.3

Diagrama de Classes

Em paralelo com a criao dos diagramas de colaborao feita a elaborao do diagrama de classes de projeto. Utilizando como base os mtodos e relaes encontrados nos diagramas de sequncia, o diagrama de classes vai descrever as classes do projeto, seus mtodos, atributos e associaes. Diferente do modelo conceitual, o diagrama de classes mostra definies de classes de software em vez de conceitos do mundo real (LARMAN, 2001).

6.3.3.1 Contratos

No projeto a classe Contrato foi implementada como abstrata. Esta classe implementa o comportamento comum de suas subclasses Venda, Compra e Consignao. A classe Contrato tambm possui uma associao com Produtos. Ao carregar um objeto de Contrato do banco de dados, todas as instncias de Produtos associadas a este Contrato sero carregadas e instnciadas. Isso cria um problema de desempenho caso vrias instncias de Contrato precisem ser carregadas, por exemplo, para gerao de relatrios. Para solucionar este problema, foi utilizado o padro Proxy na implementao de Contrato e suas subclasses. Assim duas classes podem representar um contrato: ContratoReal e ContratoProxy. A classe ContratoProxy no carrega as instncias de Produto na sua criao, eliminando o problema de desempenho nas operaes que necessitam consultar apenas propriedades da classe Contrato. Uma interface Contrato foi criada para interfacear as classes ContratoReal e ContratoProxy.

93

Figura 6.10 Contrato com Proxy

O padro Proxy descrito por Gamma (1994) no prev herana no uso do Proxy. Como Contrato tem subclasses, houve a necessidade de estender o padro para estas classes. Para isso aplicou-se o padro as subclasses de Contrato. Assim cada participante de Proxy especializa a superclasse que representa o mesmo papel, como segue abaixo:

94

Figura 6.11 Heranas de contrato com Proxy

6.3.3.2 Conta Caixa

Como o padro de anlise Conta Resumida (seo 3.2.4) foi aplicado para modelar o controle de caixa, e no mapeamento de padres de anlise para padres de projeto desenvolveu-se o mapeamento do padro Conta Resumida para o padro Composite (seo 6.2), projetou-se o controle de caixa fazendo uso desse mapeamento.

95

Figura 6.12 Conta Resumida projetada para Caixas

Assim Caixa uma ContaResumida que ir agrupar uma instncia de Receita e uma instncia de Despesa. Obedecendo ao padro Composite todas as classes implementam uma interface comum, que neste caso a interface Conta. Como neste caso a empresa ter apenas um caixa, implementou-se a classe Caixa como um Singleton. O atributo caixa implementado como atributo de classe e o mtodo obterCaixa implementado como mtodos de classe (static). O mesmo valido para as classes Receita e Despesa.

96

6.3.3.3 Camada de Persistncia

Como a aplicao utiliza-se de banco de dados para tornar seus objetos persistentes, houve a necessidade de se implementar uma camada de persistncia. A camada de persitncia desenvolvida consiste de uma coleo de mapeadores de classe. Cada classe persistente do sistema possui um mapeador na camada de persistncia. O mapeador tem as informaes de como uma instncia da classe armazenada no banco de dados, e implementa as querys SQL para armazenar um objeto no banco, carrega-lo no sistema, fazer alteraes, etc. Todos os mapeadores tem uma interface comum, com mtodos como carregar(int id), salvar(Object objeto), existe(int codigo). Seguindo o padro Facade (seo 5.6), criou-se uma classe que serve de interface de comunicao da camada de aplicao com todos os mapeadores da camada de persistncia. Esta classe, chamada de Persistncia, tambm responsvel pela criao da conexo com o sistema de banco de dados. Caso o sistema de banco de dados da aplicao seja alterado, a classe Persistncia a nica a sofrer alterao na sua implementao. Como a aplicao possui somente um banco de dados, a classe Persistncia foi implementada como um Singleton.

97

Figura 6.13 Camada de Persistencia

98

6.4 Implementao
Com os artefatos UML gerados na fase de projeto, tem-se uma base para o incio da fase de implementao da aplicao. Nesta fase, os artefatos UML so transformados em cdigo de alguma linguagem de programao. Para implementao desta aplicao a linguagem de programao escolhida foi Java. O ambiente de programao utilizado foi o NetBeans IDE 3.5.1. A seguir sero detalhados alguns mtodos que merecem ateno.

6.4.1

Mtodo Vender

O caso de uso vender implementado pelo mtodo vender da classe Atacado. Baseando-se no diagrama de sequncia, este mtodo recebe como parmetro o cdigo do funcionrio, cdigo do cliente, um vetor com os cdigos dos produtos vendidos, um vetor com as quantidades de cada produto e o nmero de produtos. Os parmetros cdigo do funcionrio e cdigo do cliente no sero utilizados no prottipo. Abaixo segue a assinatura do mtodo:
Public void vender(int codigoFun, int codigoCliente, int[] codigoProdutos, int[] quantidades, int Produtos)

O mtodo vender carrega as informaes do banco de dados atravs da referncia que atacado tm classe Persistncia. Atravs do mtodo carregar, todos os produtos cujo cdigo est no vetor codigoProdutos sero carregados para uma instncia da classe Vector (classe da biblioteca Java que implementa um array dinmico).
Vector vetorProdutos = bd.carregar(codigoProdutos, Produto.class, nProdutos);

Aps o carregamento, executado o mtodo vender para todas as instncias da classe Produto armazenadas em vetorProdutos. O mtodo vender, da classe Produto, recebe como parmetro a quantidade de produtos vendidos. Este mtodo diminui a quantidade passada como parmetro do atributo quantidade da instncia (faz a retirada

99

do estoque), e retorna uma instncia clone do produto.O valor do atributo quantidade deste clone tem o mesmo valor do parmetro quantidade passado para o mtodo (o clone representa o produto vendido). Abaixo segue o mtodo vender da classe Produto.
public Produto vender(int qtd) { Produto prodVendido; prodVendido = this.clonar(); prodVendido.quantidade = qtd; this.quantidade = this.quantidade - qtd; return prodVendido; }

Os produtos fornecidos pelo mtodo vender, da classe Produto, so armazenados em uma instncia da classe Vector, chamada vetorProdVendidos. Esse vetor passado como argumento para uma instncia da classe VendaReal, que vai registrar a operao de venda. Essa instncia de VendaReal ento salva no banco de dados. Os produtos os quais as quantidades foram alteradas (instncias de Produto as quais o mtodo vender foi executado) tambm so salvos no banco.
VendaReal venda = new VendaReal( 0, 0, vetorProdVendido); bd.salvar(venda); bd.salvar(vetorProdEstoque);

6.4.2

Mtodo obterVendas

O mtodo obterVendas da Classe atacado carrega todas as vendas registradas no banco de dados. Para melhorar o desempenho, este mtodo faz uso de objetos Proxy de Vendas (ver subseo 6.3.3.1) para carregar os objetos do banco de dados.
public Vector obterVendas() { return bd.carregar(VendaProxy.class); }

100

Caso sejam requisitados os produtos de alguma instncia de Vendas, a instncia Proxy far o carregamento da instncia real, como foi explicado no padro Proxy (subcaptulo 4.3). Segue a implementao do mtodo obterProduto na classe VendaProxy.
public Vector obterProdutos() { vendaReal = (VendaReal)bd.carregar(this.codigoContrato, VendaReal.class); return vendaReal.obterProdutos(); }

6.4.3

Camada de Persistncia

A camada de persistncia foi elaborada para que a aplicao ganhe em estendibilidade e portabilidade. Assim foi criada uma classe Persistncia, que servir de Fachada (ver sub captulo 4.4, padro Facade) para toda a camada de persistncia, que se constitui dos mapeadores das classes da camada de aplicao (ver subseo 6.3.3.3). Para salvar um objeto, primeiramente a instncia de Persistncia define que mapeador ser usado. Isso feito atravs do mtodo retornarMapeador que recebe uma classe como parmetro e retorna uma instncia da classe Mapeador. A classe que passada como argumento para o mtodo retornarMapeador a classe do parmetro do mtodo salvar. Para carregar um objeto, o sistema deve informar para a instncia de Persistncia a classe do objeto que ser carregado, e tambm um atributo identificador do objeto. A implementao dos mtodos salvar, carregar e retornarMapeador segue abaixo:
public void salvar(Object objeto) { Mapeador mapeador; mapeador = this.retornarMapeador(objeto.getClass()); mapeador.salvar(objeto); }

101

public Object carregar(int codigo, Class classe) { Mapeador mapeador; mapeador = this.retornarMapeador(classe); return mapeador.carregar(codigo); }

public Mapeador retornarMapeador(Class classe) { Mapeador map; map = null; if (classe == Produto.class) { map = new MapeadorPeca(conn); } else { if (classe == VendaReal.class) { map = new MapeadorVendaReal(conn); } } . . . return map;

6.4.4

Prottipo

Tendo uma parte da aplicao implementada, construiu-se uma simples interface para demonstrao do prottipo (figura 6.14). A interface limita-se a verificar o estoque, realizar vendas, e obter as vendas feitas pelo sistema (utilizando o mtodo obterVendas para demonstrao da aplicao do Proxy).

102

Figura 6.14 - Prottipo da Aplicao

6.4.4.1 Funcionamento do Prottipo

O prottipo inicia com um menu inicial de 3 opes. Estoque, Vender e Consultar Vendas. Em Estoque pode-se conferir o estoque de produtos registrados, seu cdigo, seu preo e sua quantidade (figura 6.15). Em Vender pode se efetuar uma venda de produtos. Na primeira coluna colocase o cdigo do produto, e ao lado, a sua quantidade. Clicando em Vender, a Venda efetuada. A quantidade dos produtos vendidos deduzida dos produtos cadastrados no estoque, e a venda registrada no banco de dados (figura 6.16). Em Consultar Vendas, as vendas realizadas so mostradas na tabela de vendas. Selecionando uma venda na tabela e clicando no boto Detalhar Vendas, so mostrados os produtos associados a respectiva venda na tabela inferior (figura 6.17).

103

Figura 6.15 Consultando o estoque

Figura 6.16 Realizando a venda

Figura 6.17 Consultando a venda realizada

CONCLUSO

Atravs deste estudo, pode-se comprovar o grande potencial do uso dos padres no desenvolvimento de software. O domnio do problema escolhido para a construo de uma aplicao, que demonstrasse os benefcios do uso de padres, era relativamente simples. Mesmo assim pode-se constatar ganhos em estendibilidade, desempenho, reusabilidade e portabilidade.

7.1 Fatores de Qualidade Alcanados

7.1.1 Estendibilidade

Estendibilidade a capacidade que a aplicao tem de se adaptar a novos requisitos. Quanto menor for o esforo utilizado em uma alterao de requisitos, maior a estendibilidade do sistema. Pode-se comprovar a estendibilidade da aplicao de Controle de Atacado no uso do padro Contratos. A adio de uma nova atividade na empresa que envolva contratos, exige apenas a adio de uma subclasse de Contratos, poupando trabalho tanto do projetista como do programador. Por exemplo, caso fosse adicionado o seguinte requisito: o sistema deve registrar o aluguel de produtos, uma classe Aluguel, subclasse de Contrato, seria adicionada ao projeto. O uso do padro de anlise Conta, projetado usando-se o padro Composite, tambm aprimora a estendibilidade da aplicao, permitindo que se adicione um nmero maior de componentes da classe Conta ao sistema. Pode-se facilmente implementar um maior controle de contabilidade no sistema, adicionando, por exemplo, contas como: despesa com material, despesa com funcionrio, despesa com impostos, etc.

105

7.1.2

Desempenho

O desempenho de uma aplicao tem grande impacto na aceitao da aplicao pelo usurio. Uma aplicao que no soluciona os problemas com velocidade perde um pouco de sua aplicabilidade. O ganho de desempenho claramente demonstrado com o uso do padro Proxy na construo das subclasses de Contrato. No atacado usado como base para a construo da aplicao, cada operao de consignao registra uma mdia de 80 produtos. O atacado tem cerca de 100 clientes que realizam 3 consignaes por ms. Assim uma consulta de todas as consignaes do ms, sem a utilizao do Proxy resultaria no carregamento de 24000 objetos do banco de dados. Considerando que o referido atacado uma microempresa, o nmero pode crescer para valores inaceitveis.

7.1.3

Reusabilidade

Todos os padres utilizados na anlise e no projeto so genricos o bastante para serem utilizados mais de uma vez. Reusabilidade uma caracterstica inata a um software que foi analisado e projetado usando padres.

7.1.4

Portabilidade

A aplicao desenvolvida tem um de seus pontos fortes na portabilidade, no s por ser implementada numa linguagem multi-plataforma, mas o uso do padro Facade para implementao da camada de persistncia torna toda a camada de aplicao independente do sistema gerenciador de banco de dados. A aplicao pode ser portada de um PC usando Windows como sistema operacional e Oracle como banco de dados, para um computador usando Linux e MySQL como banco de dados com pequenas alteraes na classe Persistncia.

106

7.2 Consideraes Finais

Analisando os resultados, pode-se concluir que a utilizao de padres favorece vrios aspectos de qualidade de um software. Esta qualidade que possibilita as constantes atualizaes promovidas pelas grandes empresas de software, possibilita que os erros de aplicaes extremamente complexas sejam rapidamente detectados e corrigidos e torna possvel a portabilidade das aplicaes num mundo onde a variedade de sistemas e plataformas crescem a cada dia. imprescindvel que softwares de mdio e grande porte tenham sua anlise e seu projeto baseado em padres, para tornar economicamente vivel a uma softwarehouse, operaes como manuteno e atualizao de seus programas. Por outro lado, o uso dos padres ainda sofre resistncia por parte de analistas e projetistas, principalmente iniciantes, pois a primeira vista, padres se demonstram confusos e sem utilidade. Iniciantes no conseguem visualizar os benefcios que um esforo extra nas fases de anlise e projeto iro trazer num futuro prximo. Na grande maioria dos casos, a economia de trabalho que um padro promove muito superior ao esforo extra que se faz na pesquisa e implementao do mesmo.

107

BIBLIOGRAFIA CONSULTADA

FOWLER, Martin. Analysis patterns: reusable object models. Addison-Wesley, 1997

GAMMA, Erich; HELM, Richard; JOHNSON, Ralph; et al. Design patterns: elements of reusable object-oriented software. Reading, Massachusetts: Addison-Wesley, 1994.

LARMAN, Craig. Applying UML and patterns: an introduction to object-oriented analysis and design and the Unified Process. 2. ed. Upper Saddle River, USA: Prentice Hall PTR, 2001.

LARMAN, Craig. Utilizando UML e padres: uma introduo anlise e ao projeto orientados a objetos. Traduo de Luiz A. Meirelles Salgado, 1. ed. Porto Alegre: Bookman, 2000.

KRUCHTEN, Philippe. The Rational Unified Process, an introduction. 2. ed. Addison-Wesley, 2000.

MAFFEO, Bruno. Engenharia de Software e Especificao de Sistemas. Rio de Janeiro: Campus, 1992.

SOMMERVILLE, Ian. Engenharia de Software. 6. ed. Addison-Wesley, 2003

SILBERSCHATZ, Abraham; KORTH, Henry. F; SUDARRSHAN, S. Sistema de Banco de Dados. 3. ed. Makron Books, 1999.

108

IBPHOENIX. What is Firebird? Disponvel em <http://www.ibphoenix.com>. Acesso em: 4 de Janeiro de 2004.

SUN. Java 2 Platform, Standard Edition, v 1.4.2 API Specification. Disponvel em <http://java.sun.com/j2se/1.4.2/docs/api>. Acesso em: 20 de Dezembro de 2004.

109

ANEXOS

110

ANEXO I: Artigo

111

Aplicaes de Padres de Anlise e Padres de Projeto no Desenvolvimento de uma Aplicao de Controle de Atacado
Igor Ghisi Cincias da Computao INE Departamento de Informtica e Estatstica Universidade Federal de Santa Catarina (UFSC), Brasil, 88040-900 tibes@inf.ufsc.br O trabalho Uso de Padres de Anlise e Padres de Projeto no Desenvolvimento de uma Aplicao de Controle de Atacado apresenta um conceito bastante novo no processo de desenvolvimento de software, o conceito de padro. Um padro uma soluo para um determinado tipo de problema. A diferena desta soluo est na forma de como ela descrita. Sua descrio, mais geral e estruturada, favorece a sua utilizao em problemas pertencentes a um mesmo contexto. Problemas cujo ncleo da soluo seja semelhante. Os padres de anlise descritos no trabalho so solues de anlise um modelo conceitual orientado a objeto para certos domnios de aplicao. J os padres de projeto descrevem solues de projeto e implementao para problemas de projeto de software. Os padres descritos foram retirados do livro Design Patterns de Erich Gamma, considerado a Bblia dos padres de projeto de software. No trabalho, foi sugerido um mapeamento de alguns padres de anlise para padres de projeto, ou seja, formas de projeto e implementao para os modelos conceituais descritos no padro de anlise. Assim, os domnios de aplicao cuja soluo se encaixa em um dos padres de anlise mapeados, j tero uma soluo definida para seu projeto. Para comprovar a eficincia do uso dos padres, foi desenvolvida uma aplicao usando-se um domnio comum. A aplicao era basicamente um sistema de controle de estoque e controle de caixa. Foi descrito todo o processo de desenvolvimento da aplicao. Nas partes do desenvolvimento onde foram utilizados padres, foi explicado como e porque tais padres eram utilizados. Os benefcios e dificuldades do uso dos padres foram demonstrados ao fim do trabalho, dando nfase ao fator estendibilidade que os padres agregaram a aplicao desenvolvida. O trabalho destaca que o tempo gasto no estudo e na aplicao dos padres leva a um maior ndice de reuso dos artefatos de desenvolvimento de software, inclusive o cdigo de programao, concluindo como vlida a aplicao de padres para qualquer processo de desenvolvimento de software.

112

ANEXO II: Diagrama de Classes (Camada de Aplicao)

113

114

ANEXO III: Cdigo da Aplicao

115

public class Atacado extends Entidade{ private Persistencia bd; /** Creates a new instance of Atacado */ public Atacado() { bd = Persistencia.obterPersistencia(); }

public void vender(int codigoFun, int codigoCliente, int[] codigoProdutos, int[] quantidades, int nProdutos) { Vector vetorProdutos; vetorProdutos = bd.carregar(codigoProdutos, Produto.class, nProdutos); Vector vetorProdVendido = new Vector(); Vector vetorProdEstoque = new Vector(); for (int i = 0; i<vetorProdutos.size(); i++) { Produto produtoEstoque = (Produto)vetorProdutos.get(i); Produto produtoVendido = produtoEstoque.vender(quantidades[i]); vetorProdVendido.add(produtoVendido); vetorProdEstoque.add(produtoEstoque); } VendaReal venda = new VendaReal( 0, 0, vetorProdVendido); bd.salvar(venda); bd.salvar(vetorProdEstoque); //FAZER a Venda }

protected void cadastrarProduto(int codigo, String descricao, double preco) { if (!(bd.existe(codigo, Produto.class))) { Produto novoProduto = new Produto(codigo, descricao, preco); bd.salvar(novoProduto); } }

116

public void comprarProduto(int codigo, int quantidade) { Produto prod = (Produto)bd.carregar(codigo, Produto.class); prod.quantidade = prod.quantidade + quantidade; bd.salvar(prod); }

public VendaReal carregarVenda(int codigoVenda) { return (VendaReal)bd.carregar(codigoVenda, VendaReal.class); }

public Vector obterEstoque() { return bd.carregar(Produto.class); }

public Vector obterVendas() { return bd.carregar(VendaReal.class); }

private Vector carregarProdutos(int[] codigoProdutos) { Vector vetorProduto = new Vector(); return bd.carregar(codigoProdutos, Produto.class, 1); }

private void salvarProdutos(Vector vetorProdutos) { }

117

public interface Contrato { void gerarLancamento(double valor, String tipo, Date data_vencimento); //Lancamento[] fornecerLancamentos(); double calcularValorTotal(); Vector obterProdutos(); }

public abstract class ContratoProxy implements Contrato { protected int codigoContrato; protected Date data; protected float valorTotal;

/** Creates a new instance of ContratoProxy */ public ContratoProxy() { } public double calcularValorTotal() { return valorTotal; } public void gerarLancamento(double valor, String tipo, Date data_vencimento) { } protected void incrementarTotal(int valor) { }

118

public class ContratoReal implements Cloneable, Contrato { /** * @clientCardinality 1 * @supplierCardinality 1..* * @label lancamentos*/ //private Lancamento lnkLancamento; protected int codigoContrato; protected Date dataInicio; protected Date dataFim; protected double valorTotal; protected Vector vetorProduto;

/** Creates a new instance of Contrato */ public ContratoReal() { } /* public Lancamento[] fornecerLancamentos() { } */ public Vector obterProdutos() { return vetorProduto; } public double calcularValorTotal() { Iterator itProduto = vetorProduto.iterator(); while (itProduto.hasNext()) { Produto prod = (Produto)itProduto.next(); this.valorTotal = this.valorTotal + (prod.obterPreco() * prod.quantidade); } return valorTotal; } public void gerarLancamento(double valor, String tipo, Date data_vencimento) { } protected void incrementarTotal(int valor) { } public ContratoReal obterClone() { ContratoReal oClone = null; try { oClone = (ContratoReal)super.clone(); }

119

catch (Exception e) { System.out.println(e.getMessage()); } return oClone; } }

public abstract class Entidade { protected protected protected protected String String String String Nome; Telefone1; Telefone2; email;

/** Creates a new instance of Entidade */ public Entidade() { }

public String obterNome() { return Nome; } }

public interface Mapeador { Object carregar(int codigo); public Vector carregarTudo(); void salvar(Object objeto); void excluir(int codigo); boolean existe(int codigo); }

public class MapeadorProduto implements Mapeador { public static Mapeador map = null; protected Connection conn; /** Creates a new instance of MapeadorProduto */ private MapeadorProduto(Connection _conn) { this.conn = _conn; try {

120

conn.setAutoCommit(false); } catch (Exception e) { System.out.println(e.getMessage()); } }

public static Mapeador obterMapeador(Connection _conn) { if (map == null) { map = new MapeadorProduto(_conn); } return map; }

public Object carregar(int codigo) {

Produto prod; prod = new Produto(); try { Statement trans = conn.createStatement(); ResultSet result = trans.executeQuery(sqlSelectCodigo(codigo)); result.next(); prod.codigo = prod.preco = prod.descricao = prod.quantidade = result.getInt("PR_CODIGO"); result.getDouble("PR_PRECO"); result.getString("PR_DESCRICAO"); result.getInt("PR_QUANTIDADE");

} catch (Exception e) { System.out.println(e.getMessage()); } return prod; }

public void excluir(int codigo) { int i =0; } public boolean existe(int codigo) { return false; } public void salvar(Object objeto) { Produto prod;

121

prod = (Produto)objeto; int codigo = prod.codigo; try { Statement trans = conn.createStatement(); ResultSet result = trans.executeQuery(sqlSelectCodigo(codigo)); if (result.next()) {

trans.executeUpdate(this.sqlUpdate(codigo,prod.quantidade, prod.descricao , prod.preco)); } else {

trans.executeUpdate(this.sqlInsere(codigo,prod.quantidade, prod.descricao , prod.preco)); } } catch (Exception e) { System.out.println(e.getMessage()); } try { conn.commit(); } catch (Exception e) { System.out.println(e.getMessage()); } }

public Vector carregarTudo() {

Vector vetorProduto = new Vector(); Produto prod; try { Statement trans = conn.createStatement(); ResultSet result = trans.executeQuery(sqlSelect()); while (result.next()) { prod = new Produto(); prod.codigo = prod.preco = prod.descricao = prod.quantidade = result.getInt("PR_CODIGO"); result.getDouble("PR_PRECO"); result.getString("PR_DESCRICAO"); result.getInt("PR_QUANTIDADE");

122

vetorProduto.add(prod.clonar()); } } catch (Exception e) { System.out.println(e.getMessage()); } return vetorProduto; }

public class MapeadorVendaReal implements Mapeador { private static Mapeador map = null; protected Connection conn; /** Creates a new instance of MapeadorVenda */ private MapeadorVendaReal(Connection _conn) { this.conn = _conn; } public Object carregar(int codigo) { VendaReal venda; venda = new VendaReal(); try { Statement trans = conn.createStatement(); ResultSet result = trans.executeQuery("SELECT * FROM venda WHERE VE_CODIGO = " + String.valueOf(codigo)); result.next(); venda.codigoContrato = result.getInt("VE_CODIGO"); } catch (Exception e) { System.out.println(e.getMessage()); } venda.vetorProduto = this.carregarProdutos(venda.codigoContrato); return venda; }

public Vector carregarTudo() { Vector vetorVenda = new Vector(); VendaReal venda; try { Statement trans = conn.createStatement();

123

ResultSet result = trans.executeQuery(sqlSelectAll()); while (result.next()) { venda = new VendaReal(); venda.codigoContrato = result.getInt("VE_CODIGO"); venda.valorTotal = result.getDouble("VE_VALOR"); vetorVenda.add(venda.obterClone()); } } catch (Exception e) { System.out.println(e.getMessage()); } return vetorVenda; }

public void salvar(Object objeto) { VendaReal venda; venda = (VendaReal)objeto; int codigoVenda = this.carregeMaxCodigoVenda() + 1; int codigo = venda.codigoContrato; try { Statement trans = conn.createStatement(); ResultSet result = trans.executeQuery(sqlSelectCodigo(codigo)); if (result.next()) {

//trans.executeQuery(this.sqlUpdate(codigo,venda.valorTotal)); } else { trans.executeUpdate(this.sqlInsere(codigoVenda, venda.valorTotal)); } } catch (Exception e) { System.out.println(e.getMessage()); } try { conn.commit(); } catch (Exception e) { System.out.println(e.getMessage()); } Vector produtos = venda.obterProdutos(); this.salvarProdutos(codigoVenda, produtos);

124

} public void excluir(int codigo) { } public boolean existe(int codigo) { return true; } public static Mapeador obterMapeador(Connection _conn) { if (map == null) { map = new MapeadorVendaReal(_conn); } return map; }

private void salvarProdutos(int codigoVenda, Vector produtos) { try {

Iterator itProdutos = produtos.iterator(); while (itProdutos.hasNext()) { Produto prod = (Produto)itProdutos.next(); Statement trans = conn.createStatement();

trans.executeUpdate(this.sqlInsereVendaProd(codigoVenda, prod.codigo, prod.quantidade)); conn.commit(); } } catch (Exception e) { System.out.println(e.getMessage()); } }

private Vector carregarProdutos(int codigoVenda) { Vector vetorProdutos = new Vector(); Produto prod = null; Persistencia bd = Persistencia.obterPersistencia(); try { Statement trans = conn.createStatement();

125

ResultSet result = trans.executeQuery("SELECT PR_CODIGO, VE_PR_QUANT FROM venda_produto WHERE VE_CODIGO = "+ String.valueOf(codigoVenda)); while (result.next()) { int codigo = result.getInt("PR_CODIGO"); prod = (Produto)bd.carregar(codigo, Produto.class); prod.quantidade = result.getInt("VE_PR_QUANT"); vetorProdutos.add(prod.clonar()); } } catch (Exception e) { System.out.println(e.getMessage()); } return vetorProdutos; }

private int carregeMaxCodigoVenda() { int max = 0; try { Statement trans = conn.createStatement(); ResultSet result = trans.executeQuery("SELECT max(VE_CODIGO) FROM venda"); result.next(); max = result.getInt(1); } catch (Exception e) { System.out.println(e.getMessage()); } return max; }

public class Persistencia { private static Persistencia single; protected Connection conn;

private Persistencia() { try { Class.forName("org.firebirdsql.jdbc.FBDriver");

126

DriverManager.registerDriver(new org.firebirdsql.jdbc.FBDriver()); } catch (Exception e) { System.out.println(e.getMessage());} try { String databaseURL = "jdbc:firebirdsql:localhost/3050:c:/projetos/sicefree/sicefree.GDB"; this.conn = DriverManager.getConnection(databaseURL, "sysdba", "masterkey"); } catch (Exception e) { System.out.println(e.getMessage()); } }

public static Persistencia obterPersistencia() { if (single == null) { single = new Persistencia(); } return single; }

public Object carregar(int codigo, Class classe) { Mapeador mapeador; mapeador = this.retornarMapeador(classe); return mapeador.carregar(codigo); }

public Vector carregar(int[] codigos, Class classe, int nObjetos) { Vector vetor = new Vector(); int tam = Array.getLength(codigos); for (int i = 0; i<nObjetos; i++) { vetor.add(this.carregar(codigos[i],classe)); } return vetor; }

127

public Vector carregar(Class classe) { Mapeador mapeador; mapeador = this.retornarMapeador(classe); return mapeador.carregarTudo(); }

public void salvar(Object objeto) { Mapeador mapeador; mapeador = this.retornarMapeador(objeto.getClass()); mapeador.salvar(objeto); }

public void salvar(Vector vetorObjetos) { Mapeador mapeador; Object objeto = vetorObjetos.firstElement(); mapeador = this.retornarMapeador(objeto.getClass()); Iterator itObjetos = vetorObjetos.iterator(); while (itObjetos.hasNext()) { mapeador.salvar(itObjetos.next()); } }

public void excluir(Object objeto) { }

public boolean existe(int codigo, Class classe) { return false; }

public Mapeador retornarMapeador(Class classe) { Mapeador map; map = null; if (classe == ConsignacaoReal.class) { map = new MapeadorConsignacaoReal(conn); }

128

if (classe == Produto.class) { map = MapeadorProduto.obterMapeador(conn); } if (classe == VendaReal.class) { map = MapeadorVendaReal.obterMapeador(conn); } return map; } }

129

public class Produto { protected protected protected protected double preco; int codigo; int quantidade; String descricao;

public Produto() { }

public Produto(int _codigo, String _desc, double _preco) { this.codigo = _codigo; this.descricao = _desc; this.preco = _preco; this.quantidade = 0; }

public void consignar() { }

public void devolver() { }

public double obterPreco() { return this.preco; }

public Produto vender(int qtd) { Produto prodVendido; prodVendido = this.clonar(); prodVendido.quantidade = qtd; this.quantidade = this.quantidade - qtd; return prodVendido; }

public Produto clonar() { Produto clone = new Produto(); clone.codigo = this.codigo; clone.preco = this.preco; clone.descricao = this.descricao; clone.quantidade = this.quantidade; return clone;

130

} public interface Venda extends Contrato{ void Vender(int codigoFun,int codigoCliente,Vector Produtos); }

public class VendaProxy extends ContratoProxy implements Venda { private VendaReal vendaReal; private Persistencia bd; public VendaProxy(int codigoFun, int codigoCliente, Vector Produtos) { bd = Persistencia.obterPersistencia(); } public void Vender(int codigoFun, int codigoCliente,Vector Produtos) { } public Vector obterProdutos() { vendaReal = (VendaReal)bd.carregar(this.codigoContrato, VendaReal.class); return vendaReal.obterProdutos(); }

public class VendaReal extends ContratoReal implements Venda { public VendaReal() {} public VendaReal(int codigoFun, int codigoCliente, Vector Produtos) { this.vetorProduto = Produtos; this.calcularValorTotal(); } public void Vender(int codigoFun, int codigoCliente, Vector Produtos) { }