Uso de Padroes de Analise e Padroes de Projeto

7/10/2019 Uso de Padroes de Analise e Padroes de Projeto

http://slidepdf.com/reader/full/uso-de-padroes-de-analise-e-padroes-de-projeto 1/130

UNIVERSIDADE FEDERAL DE SANTA CATARINA

DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA

CURSO DE CIÊNCIAS DA COMPUTAÇÃO

USO DE PADRÕES DE ANÁLISE E PADRÕES DEPROJETO NO DESENVOLVIMENTO DE UMA

APLICAÇÃO DE CONTROLE DE ATACADO

Autor: Igor Tibes Ghisi

Orientadora: Dr.ª Patrícia Vilain

Banca Examinadora: Dr. Ricardo Pereira e Silva

Dr. Ronaldo dos Santos Mello

Palavras-chave: padrões de análise, padrões de projeto

Florianópolis, 10 de março de 2004



Agradecimentos

Agradeço primeiro e mais especialmente à minha orientadora, Prof. Patrícia

Vilain, pela paciência, preocupação e dedicação na orientação do trabalho.

Ao Prof. Ronaldo dos Santos Mello, pela correção e pelas orientações.

Ao Prof. Ricardo Pereira e Silva, pela avaliação criteriosa e imparcial.

Ao Prof. Orestes Estevam Alarcon e à Renata Santos, que cederam

equipamentos para implementação e apresentação do trabalho.

A minha família, Ivo, Arlete e Alice, pela compreensão e força que me deram.

Aos meus amigos, colegas de faculdade e colegas de trabalho pelo apoio e pelas

informações que me ajudaram a realizar o trabalho.



RESUMO

Este trabalho tem como objetivo desenvolver um estudo sobre o uso de padrões de

análise e padrões de projeto no processo de produção de software. Foram descritos

alguns padrões de análise e de projeto e fez-se um mapeamento dos padrões de análise

para padrões de projeto, quando pertinente. Para aplicar os padrões estudados e o

mapeamento definido desenvolveu-se uma aplicação de Controle de Atacado, utilizando

alguns padrões descritos. Também foi discutido o impacto destes na qualidade do

software desenvolvido.

Palavras-chave: padrões de análise, padrões 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.



SUMÁRIO

RESUMO

ABSTRACT

SUMÁRIO

ÍNDICE DE FIGURAS

1 INTRODUÇÃO ...................................................................................................... 10

1.1 CARACTERIZAÇÃO DO TEMA E MOTIVAÇÃO....................................................... 10

1.2 OBJETIVOS ............................................................................................................ 11

1.2.1 OBJETIVO GERAL ................................................................................................. 11

1.2.2 OBJETIVOS ESPECÍFICOS ...................................................................................... 11

2 RATIONAL UNIFIED PROCCESS .................................................................... 12

2.1 ESTRUTURA ........................................................................................................... 13

2.2 W ORKFLOW MODELAGEM DE NEGÓCIOS............................................................. 16

2.3 W ORKFLOW DE REQUISITOS.................................................................................. 16

2.4 W ORKFLOW DE ANÁLISE E PROJETO .................................................................... 17

3 PADRÕES DE ANÁLISE...................................................................................... 19

3.1 RESPONSABILIDADE .............................................................................................. 19

3.1.1 ENTIDADE............................................................................................................ 19

3.1.2 HIERARQUIA DE ORGANIZAÇÕES ......................................................................... 21

3.1.3 ESTRUTURA DE ORGANIZAÇÕES .......................................................................... 22

3.1.4 RESPONSABILIDADE ............................................................................................ 24

3.1.5 NÍVEL DE INFORMAÇÃO DE RESPONSABILIDADE ................................................. 25

3.2 ESTOQUE E CONTABILIDADE ................................................................................ 27

3.2.1 PADRÃO CONTA .................................................................................................. 273.2.2 TRANSAÇÕES ....................................................................................................... 28

3.2.3 TRANSAÇÕES MÚLTIPLAS.................................................................................... 29

3.2.4 CONTA RESUMIDA ............................................................................................... 30

3.2.5 CONTA GATILHO ................................................................................................. 31

3.2.6 REGRA DE LANÇAMENTO .................................................................................... 32

3.2.7 REGRAS DE LANÇAMENTOS PARA VÁRIAS CONTAS.............................................. 33

3.3 COMÉRCIO ............................................................................................................ 35



3.3.1 CONTRATO .......................................................................................................... 36

3.3.2 PORTFÓLIO .......................................................................................................... 38

4 PADRÕES DE PROJETO..................................................................................... 41

4.1 S INGLETON ............................................................................................................. 41

4.2 F ACTORY M ETHOD................................................................................................. 43

4.2.1 ESTRUTURA ......................................................................................................... 45

4.2.2 IMPLEMENTAÇÃO ................................................................................................ 46

4.3 P ROXY .................................................................................................................... 46

4.3.1 IMPLEMENTAÇÃO ................................................................................................ 47

4.3.2 ESTRUTURA ......................................................................................................... 48

4.4 F ACADE.................................................................................................................. 49

4.4.1 IMPLEMENTAÇÃO ................................................................................................ 51

4.4.2 ESTRUTURA ......................................................................................................... 52

4.5 STATE ..................................................................................................................... 53

4.5.1 ESTRUTURA ......................................................................................................... 54

4.5.2 IMPLEMENTAÇÃO ................................................................................................ 54

4.6 C OMPOSITE ............................................................................................................ 56

4.6.1 ESTRUTURA ......................................................................................................... 56

4.6.2 IMPLEMENTAÇÃO ................................................................................................ 57

4.7 STRATEGY .............................................................................................................. 58

4.7.1 ESTRUTURA ......................................................................................................... 58

4.7.2 IMPLEMENTAÇÃO ................................................................................................ 58

5 MAPEAMENTO DE PADRÕES DE ANÁLISE PARA PADRÕES DE

PROJETO ..................................................................................................................... 60

5.1 PADRÃO DE ANÁLISE TRANSAÇÕES E PADRÃO DE PROJETO P ROXY ................... 60

5.2 PADRÃO DE ANÁLISE CONTA RESUMIDA E PADRÃO DE PROJETO C OMPOSITE .. 61

5.3 PADRÃO DE ANÁLISE PORTFÓLIO E PADRÃO DE PROJETO STRATEGY ............... 64

5.3.1 USO DO S INGLETON .............................................................................................. 66

5.4 PADRÃO DE ANÁLISE REGRA DE LANÇAMENTO E PADRÃO STRATEGY ............... 67

6 DESENVOLVIMENTO......................................................................................... 69

6.1 LEVANTAMENTO DE REQUISITOS......................................................................... 69



6.1.1 DESCRIÇÃO DO DOMÍNIO DA APLICAÇÃO ............................................................ 69

6.1.2 CASOS DE USO..................................................................................................... 70

6.2 ANÁLISE ................................................................................................................ 80

6.2.1 MODELO CONCEITUAL ........................................................................................ 80

6.3 PROJETO................................................................................................................ 88

6.3.1 LINGUAGEM E BANCO DE DADOS ........................................................................ 88

6.3.2 DIAGRAMAS DE SEQUÊNCIA ................................................................................ 89

6.3.2.1 Consignar......................................................................................................... 90

6.3.2.2 Vender ............................................................................................................. 91

6.3.3 DIAGRAMA DE CLASSES ...................................................................................... 92

6.3.3.1 Contratos.......................................................................................................... 926.3.3.2 Conta Caixa ..................................................................................................... 94

6.3.3.3 Camada de Persistência ................................................................................... 96

6.4 IMPLEMENTAÇÃO.................................................................................................. 98

6.4.1 MÉTODO VENDER................................................................................................ 98

6.4.2 MÉTODO OBTERVENDAS ..................................................................................... 99

6.4.3 CAMADA DE PERSISTÊNCIA ............................................................................... 100

6.4.4 PROTÓTIPO ........................................................................................................ 1016.4.4.1 Funcionamento do Protótipo ......................................................................... 102

7 CONCLUSÃO....................................................................................................... 104

7.1 FATORES DE QUALIDADE ALCANÇADOS ............................................................ 104

7.1.1 ESTENDIBILIDADE ............................................................................................. 104

7.1.2 DESEMPENHO .................................................................................................... 105

7.1.3 REUSABILIDADE ................................................................................................ 105

7.1.4 PORTABILIDADE ................................................................................................ 1057.2 CONSIDERAÇÕES FINAIS ..................................................................................... 106

BIBLIOGRAFIA CONSULTADA ........................................................................... 107

ANEXOS ..................................................................................................................... 109

ANEXO I: ARTIGO ..................................................................................................... 110

ANEXO II: DIAGRAMA DE CLASSES (CAMADA DE APLICAÇÃO).............................. 112

ANEXO III: CÓDIGO DA APLICAÇÃO ........................................................................ 114



ÍNDICE DE FIGURAS

Figura 3.1 – Padrão Entidade ......................................................................................... 20

Figura 3.2 – Modelo de hierarquia simples.................................................................... 21

Figura 3.3 – Modelo de hierarquia com restrições ......................................................... 22

Figura 3.4 – Estrutura de Organização ........................................................................... 23

Figura 3.5 – Hierarquia utilizando padrão Entidade....................................................... 24

Figura 3.6 – Divisão em camadas................................................................................... 26

Figura 3.7 – Conta e Lançamento................................................................................... 27

Figura 3.8 - Transação.................................................................................................... 29

Figura 3.9 – Transação Múltipla .................................................................................... 30

Figura 3.10 – Conta Resumida ....................................................................................... 30Figura 3.11 – Regra de Lançamento............................................................................... 32

Figura 3.12 – Metodo de Cálculo para saida .................................................................. 33

Figura 3.13 – Conta e Tipo de Conta.............................................................................. 34

Figura 3.14 – Localizador de Conta ............................................................................... 35

Figura 3.15 – Contrato com especificação ..................................................................... 36

Figura 3.16 – Contrato com associações ........................................................................ 37

Figura 3.17 - Contrato .................................................................................................... 37Figura 3.18 - Portfólio .................................................................................................... 38

Figura 3.19 – Seleção de Contratos por método booleano............................................. 39

Figura 3.20 – Seleção de Contratos por comparação com Seletor ................................. 40

Figura 4.1 – Estrutura do Padrão Singleton.................................................................... 42

Figura 4.2 – Estrutura do Factory Method ..................................................................... 45

Figura 4.3 – Exemplo do Proxy...................................................................................... 47

Figura 4.4 – Etrutura do Proxy ....................................................................................... 49Figura 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 – Padrão State................................................................................................ 53

Figura 4.9 – Estrutura do State ....................................................................................... 54

Figura 4.10 – Estrutura do Composite ............................................................................ 56

Figura 4.11 – Estrutura do padrão Strategy.................................................................... 58



Figura 4.12 – Estrutura do Strategy................................................................................ 59

Figura 5.1 – Estrutura do Proxy ..................................................................................... 61

Figura 5.2 – Padrão de Análise Conta Resumida ........................................................... 62

Figura 5.3 - Padrão de Projeto Composite...................................................................... 62

Figura 5.4 – Diagrama de classe do mapeamento .......................................................... 63

Figura 5.5 – Seleção de contrato por método ................................................................. 64

Figura 5.6 – Estrutura da implementação....................................................................... 65

Figura 5.7 – Portfólio mapeado para Singleton e Strategy ............................................. 66

Figura 5.8 – Padrão de análise Regra de Lançamento.................................................... 67

Figura 5.9 – Mapeamento do Padrão Regra de Lançamento para o Strategy ................ 67

Figura 6.1 – Modelo baseado no padrão Entidade ......................................................... 81Figura 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 – Lançamentos nos Caixas............................................................................ 86

Figura 6.7 – Modelo conceitual da aplicacao................................................................. 87

Figura 6.8 – Diagrama de Sequência Consignar ............................................................ 90Figura 6.9 – Diagrama de Sequência Vender................................................................. 91

Figura 6.10 – Contrato com Proxy ................................................................................. 93

Figura 6.11 – Heranças de contrato com Proxy.............................................................. 94

Figura 6.12 – Conta Resumida projetada para Caixas.................................................... 95

Figura 6.13 – Camada de Persistencia............................................................................ 97

Figura 6.14 - Protótipo da Aplicação............................................................................ 102

Figura 6.15 – Consultando o estoque ........................................................................... 103Figura 6.16 – Realizando a venda ................................................................................ 103

Figura 6.17 – Consultando a venda realizada............................................................... 103



1 INTRODUÇÃO

1.1 Caracterização do Tema e Motivação

A capacidade da indústria de software dos dias atuais de desenvolver sistemas de

grande complexidade se deve à implementação de um tratamento sistemático e

controlado à etapa de desenvolvimento da solução computacional, o qual denomina-seengenharia de software.

“A Engenharia de Software é uma disciplina da engenharia que se ocupa de

todos os aspectos da produção de software, desde os estágios iniciais de especificação

do sistema até a manutenção desse sistema” (SOMMERVILLE, 2003).

A engenharia de software surgiu nos anos 70 e hoje se tornou imprescindível

para qualquer softwarehouse que deseja, além de desenvolver aplicações maiores e mais

complexas, também garantir produtos de qualidade.Dentre as ferramentas de engenharia de software que tornam possível a

complexidade dos sistemas atuais, estão os padrões. Os padrões são soluções utilizadas

no processo de desenvolvimento de uma aplicação que podem ser utilizadas novamente

em outro processo, mesmo que o domínio do problema seja diferente.

Dessa maneira, não é necessário dispender esforço na resolução de um problema

que já foi solucionado no passado.

“Cada padrão descreve um problema que ocorre mais de uma vez em um

certo contexto, e descreve o núcleo da solução para este problema de uma

forma que você pode usar essa solução um milhão de vezes, sem ter que

elabora-la novamente” (ALEXANDER, 1977 apud GAMMA, 1994)

Padrões são usados em vários campos de trabalho como construção civil e

gerenciamento empresarial. Foi adotado no desenvolvimento de software a partir dos

anos 90. Nos últimos anos os padrões têm sido bastante discutidos.



11

“Padrões não são inventados, mas sim descobertos” (FOWLER, 1997). Isso

porque a maioria dos padrões nasce de um modelo feito para um domínio particular, e o

desenvolvedor nota que o modelo pode ser usado em outros domínios. Assim o modelose torna um padrão.

Neste trabalho realizou-se o estudo de padrões para duas fases do

desenvolvimento de software. Padrões para análise e padrões para projeto. Analisou-se,

também, como ocorre a utilização destes padrões no desenvolvimento da aplicação. E

quais os benefícios desta utilização.

1.2 Objetivos

1.2.1 Objetivo geral

Ao fim do trabalho deve-se ter uma descrição de vários padrões de análise e

padrões de projeto e, com o estudo de cada um, ver quais se adequam ao domínio da

aplicação e que facilidades estes trazem para desenvolvimento de uma aplicação de

controle de atacado.

1.2.2 Objetivos específicos

• Fazer um estudo de alguns padrões de análise.

• Fazer um estudo de alguns padrões de projetos.

• Fazer um mapeamento dos padrões de análise para os padrões de projeto.

• Desenvolver um modelo (análise e projeto) para o domínio de controle deatacado, utilizando, sempre que pertinente, os padrões de análise e padrões de

projeto estudados.

• Implementar um protótipo da aplicação.



2 RATIONAL UNIFIED PROCCESS

Dentro de um processo de desenvolvimento, o Rational Unified Proccess (RUP)

(KRUCHTEN, 2000) disponibiliza uma abordagem disciplinada para a atribuição de

tarefas e responsabilidades e assegura a produção de um software de alto padrão.

De acordo com Booch (BOOCH apud KRUCHTEN, 2000) um processo de

desenvolvimento de software deve possuir quatro funções:

1. Ordenar as atividades da equipe de desenvolvimento.

2. Especificar quais artefatos de software deverão ser desenvolvidos e quando

deverão ser desenvolvidos.

3. Definir as tarefas que serão individuais e tarefas executadas em conjunto

pela equipe.

4. Sugerir um critério de monitoração e avaliação dos produtos e atividades do

projeto.

“O processo de desenvolvimento de software sistematiza o desenvolvimento de

aplicações complexas e possibilita produzir um software de qualidade de uma maneira

previsível. Com isso, os custos de produção são reduzidos e a produtividade é elevada”

(KRUCHTEN, 2000)

Por ser um moderno processo de engenharia de software, provendo ferramentas

eficientes para assegurar a produção de sistemas de qualidade, o RUP se tornou um

padrão 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 organização” (KRUCHTEN, 2000).

“O objetivo do RUP é produzir software de qualidade, que promova uma

solução adequada as necessidades do usuário final.” (KRUCHTEN, 2000) Por isso, é

feita a adoção de casos de uso como elemento fundamental na construção 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 primários de modelagem” (KRUCHTEN,

2000)

• Papéis: quem;

• Atividades: como;

• Artefatos: o que;

• Workflows: quando;

Papéis: Um papel define o comportamento e as responsabilidades de um

indivíduo ou um grupo de trabalho. Os comportamentos são expressos na forma de

atividades. Cada papel está associado a um conjunto de atividades que serão executadas.

“A responsabilidade de um papel está usualmente expressa em relação a certos artefatos

que os papéis criam, modificam ou controlam” (KRUCHTEN, 2000).

Um participante do projeto pode apresentar vários papéis durante o

desenvolvimento do software, e vários participantes podem apresentar o mesmo papel.

Kruchten faz uma analogia de papéis com “um chapéu que o indivíduo usa durante o

projeto. Uma pessoa pode usar vários chapéus” (KRUCHTEN, 2000) e um chapéu pode

ser usado por várias pessoas.

Exemplos de papéis:

• Analista: coordena a análise do domínio, compreensão dos requisitos e adescrição dos casos de uso.

• Projetista: define as responsabilidades, operações, atributos e associações

de uma ou mais classes e determina sua ambientação no sistema.

Atividades: como visto anteriormente, as atividades descreverão o

comportamento dos papéis. Uma atividade é uma operação que um indivíduo num papel

deve executar, “e que produz um resultado significativo no contexto do projeto”



14

(KRUCHTEN, 2000) Normalmente, a atividade tem como objetivo a criação ou

modificação de um artefato.

A granularidade de uma atividade pode ir de algumas horas até dias. A atividadedeve ser usada como elemento de avanço do projeto. Ela pode se repetir muitas vezes

em cima do mesmo artefato “especialmente de uma iteração para outra, em que o

sistema está sendo refinado e expandido” (KRUCHTEN, 2000). A repetição 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 pedaço de informação que é produzido, modificado

ou usado por um processo” (KRUCHTEN, 2000) Os artefatos vão sendo construídos 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 estão: um modelo conceitual do domínio;

um documento com a descrição do domínio do problema, um código fonte.

Um artefato também pode ser a composição de vários 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 criação dos mesmos. Nem todo artefato é um documento em papel

com texto ou representações. Geralmente eles são 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 são classificados em cinco conjuntos de informação:

• Gerencial: artefatos relacionados ao gerenciamento do projeto.• Requisitos: artefatos relacionados à definição do software a ser

desenvolvido como modelo de casos de uso e descrição de domínio.

• Projeto: artefatos relacionados à descrição do sistema como diagrama de

classes.

• Implementação: código fonte e executáveis.

• Implantação: material de instalação e documentação para o usuário.

Workflow: “é preciso uma forma para descrever uma seqüência de atividades que

produz resultados efetivos e mostre iteração entre os papéis. Um workflow é uma

seqüência de atividades que produz um resultado de considerável valor”. (KRUCHTEN,

2000)

O RUP é composto de nove workflows: seis workflows de engenharia e três

workflows de suporte. Eles representam uma divisão das atividades e papéis em áreas

lógicas. Os seis workflows de engenharia são:

• Modelagem de Negócios

• Requisitos

• Análise e Projeto

• Implementação

• Teste

•

Implantação

Os três workflows de suporte:

• Gerenciamento de Projeto

• Gerenciamento de Configuração e Alterações

• Ambiente



16

A seguir serão abordados os workflows utilizados no desenvolvimento da

aplicação de controle de atacado até o presente momento.

2.2 Workflow Modelagem de Negócios

No workflow de modelagem de negócio a equipe irá fazer um estudo do

funcionamento da organização para a qual será desenvolvida uma aplicação. Como

resultado o workflow deve prover informações sobre toda a dinâmica do trabalho para o

qual será construída uma solução de software, identificar todos os processos, seus

problemas e indicar possíveis aperfeiçoamentos.

Principais artefatos desenvolvidos são: Descrição do Domínio, Descrição dos

Casos de Uso do Domínio.

2.3 Workflow de Requisitos

Os principais objetivos do workflow de requisitos são:

• Estabelecer, em acordo com cliente, o que o sistema que será desenvolvido

irá fazer

• Prover mais informações sobre os requisitos do sistema para os

desenvolvedores.

• Definir os limites do sistema (definir que parte do processo de trabalho irá

ser automatizada pela aplicação)

• Estabelecer prazos e custos.

• Definir a interface com o usuário do sistema.

Um requisito é “uma condição ou capacidade que um sistema deve obedecer”

(KRUCHTEN, 2000). Pode-se dividir os requisitos em funcionais e não-funcionais.

Os requisitos funcionais são ações que o sistema deve ser capaz de realizar.

Normalmente, esta ação é 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 não-funcionais não são ações, mas sim características defuncionamento do sistema. Exemplos de requisitos não-funcionais: o banco de dados

deve suportar mais de 1 milhão de registros; o sistema deve ter capacidade para

trabalhar com leitor de código de barras.

O primeiro passo para coletar os requisitos é elaborar um documento onde se

descreve o que o cliente espera do sistema,. que funções ele espera que o sistema realize

e que resultados devem ser apresentados. Este documento, chamado de documento de

visão, também deve conter as funções de alto nível do sistema. Serão as funções quefarão 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 seqüência 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 também é feita a coleta de informações para projetar a

interface com o usuário do sistema. O modelo de caso de uso servirá como base de

informação para se desenvolver um protótipo de interface com o usuário. Com o

protótipo pronto o cliente e a própria equipe de desenvolvimento podem ter uma noção

da aplicação e assim elaborar os requisitos finais do sistema.

Principais artefatos desenvolvidos neste workflow são: documento de visão,

modelo de caso de uso e protótipo de interface com o usuário.

2.4 Workflow de Análise e Projeto

O objetivo deste workflow é transformar os requisitos em especificações que

descreverão como será feita a implementação do sistema. Para isso deve-se fazer um

estudo dos requisitos e transformá-los num modelo de sistema. Este modelo será então

ajustado de acordo com o ambiente de programação escolhido.

A primeira atividade do workflow consiste na construção de um modelo de análise

a partir do modelo de caso de uso. Através do modelo de casos de uso identificam-se



18

classes significativas para a construção de um modelo conceitual e neste modelo define-

se como estas classes interagem entre si.

Na segunda etapa, usa-se o modelo conceitual de análise para elaborar o projetodo software. Os elementos do projeto serão baseados nos elementos do modelo

conceitual da análise e adicionam-se os artefatos de software. Descreve-se a

organização do sistema e sua arquitetura de execução.

Na terceira etapa, faz-se o projeto de artefatos de software como banco de dados,

protocolo de comunicação, ou outro artefato necessário ao atendimento dos requisitos

do sistema.

Principais artefatos desenvolvidos neste workflow são: modelo conceitual daanálise, diagrama de classes do projeto.

Os papéis do workflow descritos por Kruchten (2000) são:

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 operações, atributos,

responsabilidades e relacionamento de uma ou mais classes que definirão a

implementação do sistema. Normalmente um projetista fica responsável pela

modelagem de um ou mais subsistemas definidos pelo arquiteto.

Projetista de Banco de Dados: elabora o modelo de banco de dados, caso seja

necessário.



3 PADRÕES DE ANÁLISE

“Padrões de Análise são grupos de conceitos que representam uma construção

comum em modelagem de negócios. Podem ser relevantes em um domínio, ou abranger

muitos domínios” (FOWLER 1997, p. 8).

Os padrões de análise podem ser definidos como um conjunto de classes e

associações que representam de forma sistemática um contexto de uma aplicação. Esta

representação de contexto muitas vezes é válida para mais de uma aplicação, e isso faz

dos padrões de análise uma valiosa ferramenta de reuso.

Fez-se um estudo de vários padrões de análise descritos por Fowler (1997) no

livro Analysis Patterns. Para descrever os modelos, Fowler usou a notação de Odell

(ODELL, 1995 apud FOWLER, 1997). Na transcrição dos modelos de Fowler para este

trabalho foi usada a notação UML.

3.1 Responsabilidade

Nesta seção estão descritos padrões que lidam com o conceito de

responsabilidade. Responsabilidade é um conceito abstrato que pode representar vários

tópicos como hierarquia de organização, vínculo empregatício, etc.

3.1.1 Entidade

Este é, freqüentemente, um dos primeiros padrões com que um analista iniciante

se depara. O padrão Entidade é utilizado para definir pessoas e organizações dentro do

modelo.

Como organizações e pessoas tem vários atributos comuns, como nome, endereço

e formas de contato (telefone, e-mail), pode-se generalizar pessoa e organização numa

classe chamada Entidade (figura 3.1).



20

Figura 3.1 – Padrão Entidade

Mas não são só os atributos que tornam Pessoa e Organização especificações da

mesma classe. Várias ações como pagamentos, envio de correspondência (e-mail ou

carta), pagamento de impostos e muitas outras são comuns às duas classes.

Fowler (1997) faz uma analogia de Entidade com uma agenda telefônica pessoal.

A maioria dos registros de uma agenda são de pessoas, mas alguns podem ser de

empresas, e nenhuma diferenciação é vista entre os registros de pessoas e empresas.

Logo abaixo do telefone de Paulo, por exemplo, pode estar o telefone da Panificadora

Pão Quente.Segundo Fowler (1997), este padrão representa um caso típico de conceito não

nomeado:

“conceito não nomeado – todo mundo conhece e usa, mas ninguém tem

um nome para ele. Eu já o vi em incontáveis modelos de dados com vários

nomes: person/organization, player, legal entity e muitos outros”.

(FOWLER, 1997)



21

No Brasil encontra-se este padrão com nome de Pessoa/Organização ou mesmo

Pessoa, que generaliza Pessoa Física e Pessoa Jurídica.

3.1.2 Hierarquia de Organizações

Considere uma multinacional qualquer: Cervejaria Kicerva Ltda por exemplo. Ela

tem várias unidades operacionais espalhadas pelo mundo, as quais são divididas em

regiões, que por sua vez são divididas em sub-regiões, e estas divididas em escritórios

de venda. Pode-se representar esta situação com o seguinte modelo (figura 3.2):

Figura 3.2 – Modelo de hierarquia simples

Apesar de ser satisfatória a representação acima é pouco flexível. Se, por exemplo,

a Kicerva deseje fechar os escritórios sub-regionais (as regiões gerenciariamdiretamente os escritórios de venda), seriam necessárias alterações no modelo.

O modelo de hierarquia com associação recursiva (figura 3.3) possibilita essa

flexibilidade. Para definir as hierarquias no modelo, adiciona-se restrições aos subtipos

de organização para que eles saibam quem deve ser sua subordinada.



22

Figura 3.3 – Modelo de hierarquia com restrições

Caso haja uma mudança na hierarquia das organizações da empresa, simplesmente

altera-se a restrição de um subtipo. Neste ponto ganha-se flexibilidade, já que

geralmente é mais fácil mudar uma restrição do que alterar a estrutura de um modelo.

3.1.3 Estrutura de Organizações

Apesar de ser bastante flexível, algumas situações não podem ser representadas no

modelo de hierarquia com restrições (figura 3.3). Suponha que os escritórios de venda

da Kicerva sejam subordinados a uma sub-região, a qual devem reportar sobre suas

vendas, e subordinado também a uma unidade operacional de produção, a qual devem

reportar sobre a qualidade do produto Kicerva (o escritório é subordinado a duas

organizações).

Para representar este caso transforma-se a associação de hierarquia (associação

gerencia) em um conceito, e diferenciam-se os vários tipos de hierarquias através de

outro conceito, o conceito Tipo de Estrutura, como mostra a Figura 3.4.



23

Figura 3.4 – Estrutura de Organização

Exemplo 1: O escritório de vendas da Kicerva em Florianópolis está subordinadoà sub-região de vendas do Sul e a unidade operacional de qualidade de produto. Esta

representação seria feita com dois Tipos de Estrutura: vendas e qualidade de produto. O

Tipo de Estrutura venda definiria uma Estrutura de Organização com Sub-Região como

gerente e Escritório de Venda como subordinada. O Tipo de Estrutura qualidade de

produto definiria uma Estrutura de Organização com Unidade Operacional como

gerente e Escritório de Venda como subordinada.

Para apenas duas hierarquias, como no exemplo acima, talvez o modelo sejasubutilizado. Mas em casos onde há vários tipos de hierarquia, este modelo fornece a

flexibilidade necessária para lidar com tal complexidade.

As restrições, que antes eram definidas nos subtipos de Organização, agora podem

ser definidas no Tipo de Estrutura. Isso facilita a adição de novos Tipos de Estrutura,

mas por outro lado, dificulta a adição de novos subtipos de Organizações, já que cada

adição de um novo subtipo provoca uma alteração nas restrições de todos os Tipos de

Estruras que definem a hierarquia do subtipo adicionado.



24

Então a escolha de onde definir as restrições depende de uma análise do modelo

para verificar que área deste sofrerá mais adição de novos elementos. “Projete um

modelo para que as modificações mais frequentes do modelo cause o menor número dealterações dos conceitos” (FOWLER 1997).

3.1.4 Responsabilidade

Pode-se estender o padrão anterior para ser usado não apenas com organizações,

mas com qualquer tipo de entidade que possua algum tipo de relacionamento de

responsabilidade.O padrão Responsabilidade usa o mesmo modelo de Estrutura de Organizações,

apenas dando novos nomes aos conceitos e usando o padrão Entidade no lugar das

organizações. (figura 3.5)

Figura 3.5 – Hierarquia utilizando padrão Entidade



25

Exemplo 1: João da Silva trabalha na Cervejaria Kicerva. Isto pode ser modelado

como uma Responsabilidade na qual o responsável é a Kicerva e o dependente é JoãoBoanerges. O Tipo de Responsabilidade é emprego.

Exemplo 2: João da Silva é o gerente da equipe de vendas de Florianópolis. Isto

pode ser modelado como uma Responsabilidade em que o Responsável e João, o

dependente é a equipe de vendas de Florianópolis e o Tipo de Responsabilidade é

gerência.

3.1.5 Nível de Informação de Responsabilidade

O número de tipos de responsabilidade que se consegue representar é muito maior

que o número de tipos de estrutura no modelo de Estrutura de Organizações. Por isso as

restrições e regras entre as relações de dependência ficam bem mais complexas no

modelo Responsabilidade.

Essa complexidade pode ser gerenciada dividindo-o em duas camadas: uma de

nível operacional e uma de nível de informação. O nível operacional abriga conceitos

como Responsabilidade, Entidade e seus relacionamentos. O nível de informação abriga

conceitos como Tipo de Responsabilidade, Tipo de Entidade (figura 3.6).

O nível operacional registra atividades do dia-a-dia do domínio. O nível de

informação regulamenta essas atividades. No modelo da figura 3.6, uma instância de

Responsabilidade sofre as restrições definidas entre as relações de Tipo de

Responsabilidade e Tipo de Entidade.



26

Figura 3.6 – Divisão em camadas

Neste modelo, a associação “especifica” substitui as especializações de entidade.Assim, Entidade pode ter seu comportamento definido pelo Tipo de Entidade ao qual

ele está associado.

A reflexão entre o nível de informação e o nível operacional é bastante parecida,

mas não igual. No nível operacional as associações dependente e responsável são de 1

para muitos, já no nível de informação elas passam a ser de muitos para muitos, pois o

nível operacional registra somente a Entidade em uso na operação, enquanto o nível de

informação registra todas as associações possíveis entre Entidades e Responsabilidades.A divisão dos modelos em níveis de informação e operacional é comum, mas nem

sempre são explicitadas. Porém, 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 movimentação de dinheiro de uma empresa, basicamente registrando

como o dinheiro é ganho e depois gasto. A idéia básica por trás do gerenciamento de

contabilidade e estoque é que existem vários recipientes contendo dinheiro ou produtos

e é preciso registrar a movimentação do dinheiro e dos produtos através desses

recipientes.

Desta idéia básica nasceram os padrões Estoque e Contabilidade que serão

descritos neste trabalho. Eles apresentam uma coleção de conceitos que pode-se usar

como base para sistemas de contabilidade, controle de estoque e gerenciamento de

recursos.

3.2.1 Padrão Conta

O padrão Conta fornece conceitos básicos para o gerenciamento de

movimentação de um produto qualquer em um estoque genérico, como por exemplo,litros de combustível em um posto de gasolina ou quantidade de dinheiro em um caixa

eletrônico.

Para isso é preciso detalhar as operações que modificam a quantidade dos

mesmos neste estoque.

No padrão Conta isso é feito registrando-se um Lançamento em uma respectiva

Conta a cada modificação no estoque destes produtos (Figura 3.7).

Figura 3.7 – Conta e Lançamento



28

Em Lançamento tem-se a data_lançamento que é a data real em que a operação

foi feita e a data_registro que é a data em que a operação foi registrada no sistema.

Em Conta tem-se o atributo saldo que é a soma da quantidade de todos os seus

Lançamentos.

Um Lançamento será definido como depósito ou retirada de acordo com o sinal

de seu valor quantidade.

Através dos Lançamentos um usuário do sistema pode visualizar a

movimentação da Conta em determinado período de tempo.

Exemplo 1: O Restaurante Universitário comprou 100 Kg de feijão esta semana.

Isso é representado como um Lançamento de 100 na Conta de estoque de feijão do RU.

Exemplo 2: André pagou a prestação de R$ 250,00 de seu carro. Isso é

representado como um Lançamento de –250 na Conta de finanças pessoais de André.

3.2.2 Transações

No padrão Conta tem-se o registro da movimentação de um certo produto em um

estoque ou uma conta. Mas em alguns casos é necessário registrar a movimentação de

um produto de um local para outro. Por exemplo, suponha que uma pessoa tem várias

contas correntes, em bancos diferentes. Neste caso, o padrão Conta não pode registrar a

movimentação de dinheiro entre essas contas.

Uma Transação assume que toda retirada em uma Conta gerará um depósito no

mesmo valor, em outra Conta, e vice-versa. Assim registra-se a origem e o destino de

todas as movimentações (Figura 3.8).

Para explicar o conceito de Transação, Fowler (1997) usa o princípio da

conservação, que diz que o dinheiro (ou qualquer outro produto) nunca é criado ou

destruído e sim movimentado de um local (conta) para outro. Uma Transação contém

uma restrição que diz que a soma de seus lançamentos precisa ser igual a 0 (zero).

Assim o dinheiro é sempre movimentado, nunca criado ou destruído.



29

Figura 3.8 - Transação

Exemplo: Pedro transferiu R$ 1000,00 de sua conta no Banco Brasileiro para sua

conta no Banco Catarinense. Isso é representado por uma Transação com um

Lançamento de -1000 na Conta Banco Brasileiro e outro Lançamento de 1000 na Conta

Banco Catarinense.

Em estruturas mais complexas este padrão é uma boa alternativa ao padrão Conta,

pois além de ter mais informações sobre as movimentações, o princípio de conservação

usado neste padrão ajuda a previnir falhas no sistema.

3.2.3 Transações Múltiplas

O padrão Transação limita-se a representar uma única retirada de alguma Conta e

um único depósito em outra Conta. Assim não há possibilidade de representar a

movimentação de várias Contas em uma única transação.

Por exemplo, se Pedro retirou R$ 1000,00 de sua conta no Banco Brasileiro, e

retirou R$ 1200,00 do Fundo de Ações e depositou o total desse dinheiro na sua contado Banco Catarinense, esta movimentação tem de ser representada por duas Transações,

apesar de Pedro ter feito apenas um único depósito na Conta do Banco Catarinense.

Para representar a movimentação de Pedro em uma única Transação usa-se o

modelo de Transações Múltiplas (Figura 3.9).



30

Figura 3.9 – Transação Múltipla

Assim há a possibilidade de se associar dois ou mais Lançamentos a uma

Transação. O princípio da conservação continua valendo neste caso. Assim a Transação

simples (com apenas dois Lançamentos) se torna um caso particular da TransaçãoMúltipla.

3.2.4 Conta Resumida

Para sistemas de contabilidade um pouco mais complexos, utiliza-se o padrão

Conta Resumida, que faz um agrupamento de várias Contas numa única Conta

Resumida. Este tipo de estruturação pode ser feito conforme o modelo da Figura 3.10

Figura 3.10 – Conta Resumida



31

Exemplo: Na contabilidade de Simão há uma Conta Resumida para gastos

essenciais que agrupa as seguintes Contas Detalhadas: gastos combustível, gastos saúde,

gastos mercado.

Neste modelo apenas, as Contas Detalhadas podem ter Lançamentos. Para calcular

o saldo de uma Conta Resumida, esta consultará as Contas nela agrupadas. Nota-se que

uma Conta Resumida pode agrupar várias Contas Resumidas, criando assim uma árvore

de Contas.

3.2.5 Conta Gatilho

Este padrão teve como base o controle do valor dos impostos sobre movimentação

de dinheiro.

Normalmente, o valor dos impostos de uma empresa só é conhecido quando esta

realiza um balanço no fim do mês, ou do ano. Usando este padrão o sistema irá

contabilizar o valor total do imposto a cada entrada no caixa da empresa.

Ele funciona da seguinte maneira: Para cada Lançamento de entrada de dinheiro

na conta caixa da empresa, haverá também um Lançamento Gatilho em uma outra

conta, uma Conta Gatilho. Este Lançamento Gatilho terá como valor a quantidade de

imposto gerado pelo Lançamento 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 movimentação de dinheiro que ela já fez.

Exemplo 1: Quando João recebe o pagamento de um cliente, ele paga 25% deste

pagamento em impostos. João então registra um Lançamento na sua conta de

pagamentos e também um Lançamento na Conta Gatilho Imposto. O Lançamento na

Conta Gatilho será 25% do valor do Lançamento na Conta de João.



32

3.2.6 Regra de Lançamento

No exemplo da Conta Gatilho para imposto, o usuário deve sempre realizar doislançamentos no sistema para registrar a taxação da movimentação. Um lançamento para

a conta real e um lançamento registrando o valor da taxação.

Se o imposto tem um valor fixo, como 25% no exemplo anterior, pode-se

programar o sistema para realizar os lançamentos na Conta Gatilho automaticamente,

simplesmente criando uma regra para as contas as quais os lançamentos são taxados.

A regra calcularia o imposto de todos os lançamentos de uma conta associada

como gatilho e geraria um lançamento, no valor calculado, numa Conta Gatilho,associada à Regra de Lançamento como saída. (figura 3.11).

Figura 3.11 – Regra de Lançamento

Exemplo: Todo pagamento recebido por um serviço é taxado em 12% pelo ISS

(imposto sobre serviços). Modela-se esta taxação com a Conta pagamento de serviços

sendo o gatilho da Regra de Lançamento cálculo de ISS e a saída desta Regra sendo a

Conta total do ISS.

Há casos em que o cálculo do valor do imposto é um pouco mais complexo, e não

apenas uma mera multiplicação. Um exemplo é o cálculo de impostos gradativos, emque movimentações abaixo de um valor são isentas de cobrança, e acima de outro valor,

tem uma cobrança diferenciada.

Para estes casos é necessário um algoritmo arbitrário para o cálculo do imposto.

Então um Método de Cálculo é associado a classe Regra de Lançamento. Assim cada

instância de Regra de Lançamento terá seu próprio Método de Cálculo (figura 3.12).



33

Figura 3.12 – Metodo de Cálculo para saida

3.2.7 Regras de Lançamentos para várias contas

Pode-se estender o padrão Regra de Lançamento de maneira que uma única regra

possa tratar de várias contas, sem a necessidade de criar uma regra para cada conta do

sistema.

Assim, tomando uma empresa genérica como exemplo, pode-se ter uma Conta

para cada empregado e apenas uma Regra de Lançamento para tratar o cálculo do

imposto de renda sobre o salário dos trabalhadores.

Pode-se modelar a solução de duas maneiras: a primeira é dividir o modelo em

dois níveis: nível de informação e nível operacional. Colocam-se as Regras de

Lançamento no nível de informação e associam-nas com Tipo de Conta. Assim pode-se

ter Tipo de Conta para salário, horas-extras, etc. No nível operacional colocam-se as

contas reais do domínio da aplicação (figura 3.13).



34

Figura 3.13 – Conta e Tipo de Conta

Quando um Lançamento for feito na Conta, esta vai executar as regras de

lançamento do Tipo de Conta associado a ela.

A segunda maneira proposta é usar Contas Resumida (seção 3.2.4). Uma Regra de

Lançamento é definida para uma conta resumo e quando um lançamento é feito em uma

conta detalhada, esta executará a Regra de Lançamento de sua conta resumo.

A escolha entre os dois métodos depende do comportamento do Tipo de Conta.

Caso a divisão de nível de informação e nível operacional seja bem clara, e todas as

regras de lançamento estejam associadas ao Tipo de Conta e os lançamentos só sãofeitos em uma conta, então o modelo de níveis é mais apropriado.

Mas em muitos casos os lançamentos podem ser feitos em níveis mais gerais.

Lançamentos podem estar associados a Tipos de Conta e regras de lançamentos

associadas a contas, o que infringiria a divisão entres os níveis operacionais e de

informação. Neste caso o melhor é usar o modelo da segunda proposta, com contas

resumo.



35

Pode-se estender os modelos para abranger situações mais complexas, como casos

em que a conta de saída da regra de lançamento pode mudar de acordo com certos

parâmetros. Como exemplo, tem-se o caso em que o desempenho de um programadordentro de um projeto afeta o salário do gerente deste projeto. Neste caso, a regra de

lançamento teria a conta desempenho do programador como gatilho, e deve “procurar”

a conta salário do gerente do projeto para colocar como saída. Isso se faz através da

associação da regra de lançamento a um método de procura (figura 3.14).

Figura 3.14 – Localizador de Conta

O método localizador vai consultar a conta gatilho desta regra para saber qual

programador é a fonte deste lançamento. Consultando o programador, o método obtem

informações sobre o projeto deste programador e o seu gerente. Assim o método

localizador encontra a conta salário do gerente, que irá receber um lançamento de bônus

pelo desempenho deste programador.

3.3 Comércio

Neste capítulo serão descritos padrões que realizam o controle de compra e venda

de produtos, e como o valor destes produtos pode modificar as condições do mercado.

Os padrões descrevem como uma instituição pode registrar suas operações comerciais

para usar como base para tomada de decisões.



36

3.3.1 Contrato

O tipo mais simples de relação comercial é de uma entidade (pessoa/organização)comprando um produto de outra entidade. O produto é qualquer item comercializável,

como por exemplo, sacas de café e toneladas de ferro. Um simples modelo como da

figura 3.15 pode representar essa operação.

Em contrato representa-se uma transação comercial como um Contrato. Um

Contrato pode ser uma compra, uma venda ou qualquer outra transação feita entre

entidades. Ele tem como atributos Quantidade e Preço. O produto a ser comercializado é

representado como um Produto que está associado a Contrato (Figura 3.15).

Figura 3.15 – Contrato com especificação

Exemplo: a UFSC registra a compra de 500 resmas de papel Folhex ao preço deR$ 8,00 cada, como sendo uma Compra com o Contratante sendo a Folhex Fornecedora

de Papel e o Produto sendo resmas de papel. Preço fica em 8 e quantidade 500.

As operações que serão representadas em Contrato nem sempre precisam ser

especificações do mesmo. Para operações de Compra e Venda, tem-se como alternativa

à especificação a criação de duas associações entre Contrato e Parte (Figura 3.16).



37

Figura 3.16 – Contrato com associações

Este segundo modelo também possibilita que sejam registradas transações 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

Tecnológico. 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

junção dos dois primeiros modelos. Os dois lados da transação foram definidos como

Contratado e Contratante e as especificações de contrato serão as operações 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 não

precisam necessariamente envolver a Entidade que controla o sistema. Caso seja válido,

pode-se registrar transações comerciais entre Entidades externas ao sistema.Nota-se a possibilidade de relacionar este modelo com o modelo de Transações do

capítulo anterior. Um contrato de venda, por exemplo, pode ser representado por uma

Transação que faz um Lançamento de um produto na Conta de um comprador e faz

outro Lançamento de dinheiro na Conta de um vendedor.

3.3.2 Portfólio

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 seleção dos contratos que serão analisados

pode ser feita pelo tipo de produto comercializado, pela entidade contratante ou por

qualquer outra propriedade relevante de contrato.

Um Portfólio representa este grupo, ou seja, uma coleção de contratos que irão ser

avaliados (figura 3.18).

Figura 3.18 - Portfólio

A seleção dos contratos associados a um Portfólio pode ser feita através de um

método que recebe um Contrato como parâmetro. Caso o método retorne um valor

verdadeiro, o Contrato pertencerá àquele Portfólio (figura 3.19).



39

Figura 3.19 – Seleção de Contratos por método booleano

Outra maneira para a construção da coleção dos contratos que pertencerão a um

portfólio é a implementação de um Seletor de Contratos. Este seletor irá combinar

alguns atributos de Contrato, como contratante, produto, data de início, etc. e os

utilizará para filtrar um grupo particular de contratos. (figura 3.20).



40

Figura 3.20 – Seleção de Contratos por comparação com Seletor

Apesar de ser menos abrangente que um método de seleção, o Seletor de

Contratos é bem mais flexível, podendo ser modificado em tempo de execução apenas

alterando o valor de suas propriedades.

Portfólios podem ser temporários ou persistentes. Porfólios temporários são

criados por demanda. Um filtro é especificado e todas as instâncias de Contrato são

consultadas. Ao fim da utilização, o Portfólio perde a sua coleção de Contratos.

Portfólios persistentes são criados da mesma maneira, mas não são descartados ao

fim de sua utilização. Quando um novo Contrato é criado, este passa pelos filtros dos

Portfólios permanentes. Caso o novo Contrato preencha os requisitos do filtro, é

anexado ao Portfólio.

“Portfólios são úteis em muitos domínios. A característica essencial de um

Portfólio é a de que é um objeto que encapsula um mecanismo de seleção de um grupo

de objetos” (FOWLER, 2000)



4 PADRÕES DE PROJETO

Pode-se definir padrões de projetos como um conjunto de classes de software

que descrevem uma solução comum para determinados tipos de problemas. Essas

classes têm papéis bem definidos e interagem entre si para construir uma solução lógica

que será implementada em uma linguagem de programação.

No decorrer do desenvolvimento do trabalho foi feito um estudo de alguns dos

padrões de projeto do livro Design Patterns de Erich Gamma (1994). Segundo o próprio

Gamma, os padrões descritos em seu livro “são descrições de classes e objetos

comunicantes, que são configuradas para resolver algum problema comum de projeto de

software, dentro de um contexto particular”.

Gamma (1994) classifica os padrões em 3 grupos distintos, levando em conta o

tipo de problema ao qual o padrão se destina: criação, estrutural e comportamental

(creational, structutral and behavioral).

Padrões de criação delegam partes do processo de criação de um objeto para

subclasses ou para outros objetos. Padrões estruturais usam herança para compor as

classes. Padrões comportamentais usam herança para implementar algorítmos e fluxos

de controle.

Os padrões estudados foram o Singleton (criação), Factory Method (criação),

Proxy (estrutural), Facade (estrutural), State (comportamental), Strategy

(comportamental) e Composite (estrutural). Mais a frente será discutida a viabilidade do

uso dos padrões no projeto da aplicação de Controle de Atacado.

4.1 Singleton

O padrão Singleton é usado para assegurar que uma referida classe possa ter

apenas uma instância no sistema e essa instância tenha um ponto de acesso global. Pode

ser usado, por exemplo, num sistema de impressão 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 padrão, a classe de instância única, ou classe Singleton, será responsávelem assegurar que apenas uma instância sua poderá ser criada. Para isso, o construtor

dessa classe deve ser uma operação de classe (static em Java ou C++). O acesso à

instância também se dará através de uma operação de classe.

A classe Singleton faz o encapsulamento da sua instância única, armazenada

num atributo da própria classe. Isso permite total controle de quando e como se dará o

acesso à instância (Figura 4.1).

Figura 4.1 – Estrutura do Padrão Singleton

Para implementar uma classe Singleton em Java, declara-se o construtor como

privativo. O acesso a classe se dará através do método obterInstancia que fornecerá

sempre a mesma instância. Caso nenhuma instância da classe tenha sido criada, o

método cria a instância.

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 padrão Singleton para substituir classes totalmente estáticas

(classes sem instâncias, apenas com métodos estáticos) com a vantagem de o padrão

possibilitar o uso de subclasses da classe estática (classes totalmente estáticas nãopodem ter seus métodos sobrescritos, não suportam polimorfismo).

4.2 Factory Method

O padrão Factory Method é geralmente utilizado em situações onde a definição do

tipo de objeto a ser criado só é especificada na subclasse de uma classe. A utilização do

Factory Method dá mais flexibilidade a classe por deixar que sua subclasse tome a

decisão de que tipo de objeto será craido.

Pode-se citar o exemplo da classe Desenho para demonstrar a utilização do

Factory Method . A classe abstrata desenho trabalha com os objetos da classe abstrata

FormaGeometrica, que generaliza as classes Circulo, Triangulo e Quadrado. Um

método 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 implementação torna a classe Desenho pouco extensível. Caso haja

necessidade de criar uma extensão de desenho, como por exemplo DesenhoColorido,

utilizando nessa extensão as classes CirculoColorido , TrianguloColorido , e

QuadradoColorido, o método desenharCasa teria que ser refeito.

O padrão Factory Method torna as extensões da classe Desenho mais simples

utilizando-se de "métodos de criação", ou factory methods, para instanciar as classes

Circulo, Triangulo e Quadrado. Abaixo o método de criação 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 método desenharCasa fica da seguinte forma

public void desenharCasa() {

telhado = criarForma("triangulo"); //não há definição da classe

parede = criarForma("quadrado"); //não há definição da classe

telhado.desenhar;parede.desenhar;

}

Dessa maneira, para estender a classe Desenho para DesenhoColorido, reescreve-

se apenas os métodos de criação.

public class DesenhoColorido extends Desenho {

public FormaGeometrica criarForma(forma) {

if (forma == "circulo") {

r = new CirculoColorido(); //modificacao da extensao da

classe

}

else {

if (forma == "triangulo") {

r = new TrianguloColorido(); //modificacao da

extensao da classe

.



45

4.2.1 Estrutura

A estrutra do padrão é 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 extensão da classe Produto. As classes TrianguloColorido é

um ProdutoConcreto de Triangulo.

No Criador é declarado o método criador, ou factory method , que retorna um

objeto da classe Produto. A classe Desenho é um criador e criarForma é o factorymethod.

O CriadorConcreto reescreve o método criador para retornar uma instância de

ProdutoConcreto (figura 4.2).

Figura 4.2 – Estrutura do Factory Method



46

4.2.2 Implementação

Como visto no exemplo, a implementação de um Factory Method érelativamente simples. Na classe Criador o factoryMethod pode ser abstrato, contendo

apenas a assinatura do método. Na classe CriadorConcreto o factoryMethod é

definitivamente implementado, podendo ter como argumento, variáveis que tenham

influência na decisão 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 padrão 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 criação de um objeto até que o mesmo seja realmente utilizado,

ou fazer a representação de um objeto remoto localmente.

Numa aplicação 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 várias junções de tabelas para ser obtida. O Proxy evita que a definição de

uma propriedade complexa seja feita na construção do objeto, e prorroga a definição



47

dessa propriedade até que seja realmente necessária. Isto torna todo o trabalho mais

eficiente.

Para isso cria-se um intermediário ( proxy) do objeto persistente. O objetointermediário terá uma interface em comum com o objeto persistente, além de ter uma

referência para o mesmo (figura 4.3).

Figura 4.3 – Exemplo do Proxy


Como foi dito anteriormente, a classe Intermediário terá uma referência para o

objeto real. No caso específico do exemplo, a diferença das classes Intermediário e

PersistenteReal estará no construtor das mesmas. O construtor da classe Intermediário

não 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 instância de Intermediario só inicializa propriedadeSimples.

Quando propriedadeComplexa é requistada, Intermediario faz a criação de uma

instância de PersistenciaReal, e desta instância obtém 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 eficiênte.

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 SujeitoReale as duas compartilham a mesma interface (figura 4.4).



49

Figura 4.4 – Etrutura do Proxy

Algumas variações do Padrão Proxy são:

Remote proxy - fornece uma representação 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 criação de objetos com alto custo de criação (exemplo

de classe persistente descrito anteriormente);

4.4 Facade

O objetivo do padrão Facade é unificar em uma interface a manipulação de

vários objetos de um subsistema. Assim, as classes do núcleo de cada subsistema podem

ser modificadas sem que a interface para o cliente seja afetada. Em um conjunto de

subsistemas, isso diminui a interdependência entre os mesmos. Outra consequência de

seu uso é a diminuição da complexidade de utilização dos subsistemas, pois reduz o

número de objetos que precisam ser acessados externamente.



50

Pode-se exemplificar o uso do Facade supondo que o sistema de matrícula e

alocação 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 várias classes, promovendo um

acomplamento forte entre o sistema e o cliente. Utilizando o padrão Facade, o sistema

fornece uma interface única para o cliente, facilitando a utlização e diminuindo o

acoplamento. No exemplo da Figura 4.6 matricula_aloca é um Facade para o sistema de

alocação e matrícula.



51

Figura 4.6 – Com o uso do Facade


A classe Facade deve implementar operações gerais do sistema. O acesso ao

sistema deve ser feito unicamente pela classe Facade.

Implementação 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) {

.

.

.

}

Simplificação 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 Padrão State implementa o conceito de “estado de classe”. Ele permite queuma classe possua vários estados e que a alteração destes estados possa ser feita em

tempo de execução, mudando também o comportamento da classe.

Exemplo 1: Em uma empresa, várias operações, como calculo de impostos,

dependem da classificação da mesma em micro, pequena ou média empresa. Esta

classificação é feita baseando-se no número de empregados da empresa. Neste caso

pode-se utilizar o padrão State para modelar o sistema como mostra a Figura 4.8:

Figura 4.8 – Padrão State

Cada subclasse de Tipo terá sua própria implementação 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 vários estados. Contextoterá uma instância de um EstadoConcreto que definirá seu estado atual.

A classe Estado define uma interface comum para as implementações 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


Seguindo o padrão, 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 associações com as instâncias que implementamseus estados.

Quando requisistada uma alteração no atributo n_empregados, o procedimento

altere_n_empregados define o tipo de empresa verificando o argumento n_emp e

chamando a função altere_tipo_empresa.

O padrão State não especifica que classe de sua estrutura deve definir o estado

atual de Contexto. Na implementação a definição foi feita na classe Empresa, pois esta



56

possui o conhecimento do critério de alteração dos estados. Em alguns casos define-se a

alteração do estado nas classes de EstadoConcreto.

4.6 Composite

O padrão Composite é usado em aplicações em que se utiliza composição de

objetos individuais para implementação de objetos mais complexos. Este padrão

permite que a forma de manipulação 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

composição e implementa os comportamentos que são comuns aos objetos simples e

complexos.



57

A classe ComponenteComplexo representa um objeto composto. A associação

filho permite que esta composição seja tanto de objetos simples como de objetos

complexos.ComponenteSimples representa o objeto simples.


A classe abstrata Componente implementa apenas os métodos comuns aos dois

tipos de objetos, definindo o restante dos métodos como abstratos.

A classe ComponenteComplexo implementa os métodos de manipulação 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 não possui associação com nenhum outro

componente e não implementa os métodos de manipulação de “filhos”.



58

4.7 Strategy

O padrão Strategy cria a possibilidade de se definir mais de um tipo de algorítmo

para um mesmo método. É útil nos casos onde a implementação do método depende de

algum fator externo à classe em que será implementado.

4.7.1 Estrutura

O padrão será aplicado a uma classe Contexto. Os diferentes algorítmos serão

implementados em diferentes classes, mas com uma interface comum (Estratégia) como

mostra a Figura 4.11:

Figura 4.11 – Estrutura do padrão Strategy


Pode-se exemplificar a aplicação do Strategy na implementação de script para

visualização em browsers. Apesar da padronização, browsers como Internet Explorer e

Mozilla interpretam scripts de forma diferente. Usa-se o padrão 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();

}

}



5 MAPEAMENTO DE PADRÕES DE ANÁLISE PARA

PADRÕES DE PROJETO

Um dos objetivos do trabalho é a elaboração de mapeamentos de padrões de

análise para padrões de projeto. Isto é, após estudo aprofundado de um padrão de

análise, o seu modelo conceitual é transformado em um diagrama de classes de projeto

utilizando padrões de projeto. Neste capítulo estão descritos alguns mapeamentos que

foram desenvolvidos durante o trabalho.

5.1 Padrão de Análise Transações e Padrão de Projeto Proxy.

O primeiro projeto refere-se ao mapeamento do padrão de análise Transações

para o padrão de projeto Proxy.

O padrão Proxy se aplica ao modelo de Transações quando as transações são

armazenadas em uma base de dados. Muitos clientes da classe Conta acessarão esta para

consultar somente seu atributo saldo. Nestes casos, não é necessário que Conta tenha

referência para as instâncias da classe Lançamento associadas.

Utiliza-se então o padrão Proxy para que as intâncias da classe Lançamento

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 instância da classe ContaProxy. Esta instância irá carregar apenas o

atributo saldo através da camada de persistência para o banco de dados, prorrogando o

carregamento das instâncias de Lançamento somente quando forem necessárias.

Assim a implementação de calcularSaldo fica da seguinte maneira:

Public float calcularSaldo() {

If (real == null) {

real = new ContaReal();

}

return real.calcularSaldo();

}

5.2 Padrão de Análise Conta Resumida e Padrão de Projeto Composite

Este mapeamento toma como base o padrão de análise Conta projetado pelo

padrão Composite.



62

Figura 5.2 – Padrão de Análise Conta Resumida

Figura 5.3 - Padrão de Projeto Composite

O conceito de Conta será implementado como a classe Componente do padrão

Composite. ContaResumida será o objeto composto do padrão, 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 implementação segue as regras do padrão Composite. Conta é uma classe

abstrata, mas implementa os métodos comuns à ContaDetalhada e à ContaResumida

como obterSaldo. Conta também define o atributo saldo comum as duas classes. Em

ContaResumida há um método particular, calcularSaldo. Este método 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 implementação segue

abaixo.

Public float calcularSaldo() {

Conta _conta;

While (agrupadas.hasNext()) {

_conta = agrupadas.next();

this.saldo = this.saldo + _conta.obterSaldo();

}

return saldo;

}



64

5.3 Padrão de Análise Portfólio e Padrão de Projeto Strategy

O padrão de análise Portfólio (seção 4.6.2) consiste em uma coleção de contratos

que obedecem a certos critérios de seleção. Uma das maneiras abordadas para a

construção desta coleção é através de um método de seleção que recebe um contrato

como parâmentro. Caso este método retorne um valor verdadeiro, o contrato será

associado ao Portfólio (figura 5.5).

Figura 5.5 – Seleção de contrato por método

A utilização do padrão Strategy para implementação do Método de Seleção do

Portfólio possibilita a utilização de vários métodos de seleção distintos, e a escolha de

que método de seleção será utilizado pelo Portfólio para seleção de contratos pode ser

feita por externamente à classe, dando grande flexibilidade ao sistema.

A seguir, tem-se o diagrama de classes de um Portfólio projetado usando-se

Strategy.



65

Figura 5.6 – Estrutura da implementação

A implementação 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 método selecionarMetodo recebe um parametro selecao

que define qual método de seleção será usado pela instância de Portfolio.

5.3.1 Uso do Singleton

De acordo com o padrão de análise Portfólio, um mesmo método de seleção

pode ser usado por vários portfólios. Neste caso pode-se evitar o custo da criação de

várias instâncias de MétodoSeleção implementando-se as classes concretas dos métodos

de seleção como Singletons.

Assim tem-se o mapeamento do padrão de análise Portfólio para os padrões deprojeto Singleton e Strategy (figura 5.7).

Figura 5.7 – Portfólio mapeado para Singleton e Strategy

Abaixo segue a implementação 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 Padrão de Análise Regra de Lançamento e Padrão Strategy

Em um caso semelhante ao anterior, o padrão de análise Regra de Lançamento

possui um método para cálculo do valor do lançamento que será efetuado na sua Conta

de saída (figura 5.8). Para flexibilizar a classe de Regra de Lançamento, também faz-se

usar do padrão Strategy na sua implementação.

Figura 5.8 – Padrão de análise Regra de Lançamento

Figura 5.9 – Mapeamento do Padrão Regra de Lançamento para o Strategy



68

A implementação 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 parâmetro, e a

partir dele decide que método de cálculo será usado.



6 DESENVOLVIMENTO

O objetivo final do trabalho é desenvolver um modelo de análise e de projeto e

implementar uma aplicação fazendo uso de alguns padrões estudados durante a fase de

pesquisa. Neste capítulo será descrito como os padrões estudados foram utilizados no

processo de desenvolvimento da aplicação de controle de atacado.

6.1 Levantamento de Requisitos

6.1.1 Descrição do Domínio da Aplicação

O domínio desta aplicação é a consignação e venda de produtos. A empresa que

serviu de base para o desenvolvimento é um atacado de jóias. Lá são vendidos vários

tipos de jóias e semijóias, além de relógios, embalagens e mostruários.

A maioria dos clientes da joalheria trabalha com produtos consignados. O

processo de consignação se dá da seguinte maneira: um consignador (cliente da

empresa) vai até a empresa e retira alguns produtos para levar em consignação. Este

vendedor tem um período para vender os produtos (fora da empresa). Após este período

ele retorna à empresa, e realiza o fechamento: faz o pagamento dos produtos que foram

vendidos e faz a devolução dos produtos que não conseguiu vender.

A empresa também faz vendas sem consignação. Ou seja, um cliente vem até a

empresa e faz a compra de um produto diretamente, sem consigná-lo.Além de controlar a parte de consignação e venda, o software deve fazer o

controle de estoque, fluxo de caixa, e geração relatórios gerais (lucro, gastos, estoque

etc.).

O estoque fica dividido em produtos que estão 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 (promissórias e cheques) e os gastos administrativos da

empresa.

6.1.2 Casos de Uso

A seguir a descrição dos casos de uso p/ aplicação.

Caso de Uso: Consignar ProdutosAtores: Funcionário.

Tipo: Primário

Descrição: O cliente escolhe os produtos que deseja levar em consignação. O

funcionário registra os produtos em poder do cliente.

Seqüência Típica de EventosAção do Ator Resposta do Sistema

1- O funcionário se identifica através

do código do funcionário.

2- O funcionário identifica o cliente

através do código do cliente.

3- O sistema informa os dados do

cliente (nome, telefones, RG, CPF,

endereço) e os produtos consignados (código

do produto, nome do produto, quantidade),

caso ele tenha alguma.

4- O funcionário identifica os

produtos escolhidos pelo cliente através dos

códigos dos produtos.

Caso haja mais de um produto do

mesmo tipo, o funcionário entra também

com a quantidade.

5- O sistema informa o valor total

dos produtos e o valor mínimo que deve ser

vendido para alcançar a meta de venda.



71

6- O funcionário confirma a

operação.

7- O sistema imprime um relatório

contendo o código e nome do cliente; nome

do funcionário que realizou a operação;código, nome, quantidade, valor unitário e

valor total dos produtos consignados na

operação.

Seqüências Alternativas

1.1 – O código do funcionário é inválido. Cancelar a operação.

2.1 – O código do cliente é inválido (não está cadastrado). Cancelar a operação eperguntar ao usuário se deseja cadastrar o cliente (caso de uso Cadastrar Cliente).

4.1 – O código do produto é inválido (não está cadastrada). Perguntar ao usuário

se deseja cadastrar o produto (caso de uso Cadastrar Produto).

Caso de Uso: Fazer Fechamento

Atores: Funcionário.

Tipo: Primário

Descrição: O cliente informa os produtos que foram vendidos e os produtos que

serão devolvidos. O funcionário registra os produtos devolvidos e,

consultando o registro de produtos em poder do cliente, informa o

débito do cliente. Este faz o pagamento à vista ou escolhe formas de

pagamento a prazo.



72

Seqüência Típica de Eventos

Ação do Ator Resposta do Sistema

1- O funcionário se identifica atravésdo código do funcionário.





endereço) e seus produtos consignados

(código do produto, nome do produto,

quantidade).

4- O funcionário seleciona dentre osprodutos consignados ao cliente, quais serão

devolvidos, caso haja devolução.

5- O sistema informa o valor totaldos produtos devolvidos e o valor total dos

produtos comprados pelo cliente.

5- O funcionário registra a forma de

pagamento escolhida pelo cliente – avista ou

a prazo.

Na forma de pagamento a prazo deve

ser identificado se será usado cheque ou

promissória.

6- Se a forma de pagamento a prazo

for escolhida o sistema mostra o valor das

prestações.

7- O cliente faz o pagamento (se for o

caso) e o funcionário confirma a operação.


contendo código e nome do cliente; nome do

funcionário que realizou a operação; código,

nome, quantidade, valor unitário e valor total

dos produtos vendidas na operação.



4.1 – O cliente deseja devolver mais produtos que o permitido pela meta de

vendas. O gerente entra com o código do gerente para permitir a devolução.



73

Caso de Uso: Comprar Produtos

Atores: Funcionário

Tipo: PrimárioDescrição: O fornecedor é identificado e os produtos são comprados. É feito o

pagamento à vista ao fornecedor, ou escolhe-se formas de

pagamento a prazo.



1- O funcionário se identifica atravésdo código do funcionário.

2- O funcionário identifica o

fornecedor através do código do fornecedor.


fornecedor (nome, telefones, RG, CPF,

endereço)

4- O funcionário registra os produtos

que serão comprados no sistema, informando

código, descrição e preço de compra.

5- O sistema informa o total da

compra.

6- O funcionário escolhe a forma de

pagamento – à vista ou à prazo.



promissória (carnê).


contendo código e nome do fornecedor;

nome do funcionário que realizou a

operação; código, nome, quantidade, valor

unitário e valor total dos produtos

comprados na operação.



2.1 – O código do fornecedor é inválido. Cancelar a operação e dispara caso de

uso Cadastrar Fornecedor.



74

Caso de Uso: Vender Produtos


Tipo: PrimárioDescrição: O funcionário apresenta os produtos ao cliente. O cliente escolhe os

produtos e faz o pagamento, ou escolhe formas de pagamento a

prazo.


Ação do Ator Resposta do Sistema1- O funcionário se identifica através






endereço) e seus produtos consignados

(código do produto, nome do produto,

quantidade).


produtos escolhidos pelo cliente através do

código do produto.



com a quantidade.


dos produtos

6- O funcionário registra a forma de

pagamento escolhida pelo cliente – a vista

ou a prazo.



promissória.

7- Se a forma de pagamento a prazo

for escolhida o sistema mostra o valor das

prestações.



75




contendo código e nome do cliente; nome do

funcionário que realizou a operação; código,nome, quantidade, valor unitário e valor total

dos produtos vendidas na operação.



2.1 – O código do cliente é inválido (não está cadastrado). Cancelar a operação e

perguntar ao usuário se deseja cadastrar o cliente (caso de uso Cadastrar Cliente).4.1 – O código do produto é inválido (não está cadastrada). Disparar caso de uso

Cadastrar Produtos.

Caso de Uso: Vender Produtos à Vista


Tipo: Primário

Descrição: O funcionário apresenta os produtos ao cliente. O cliente escolhe os

produtos e faz o pagamento a vista. Neste caso de uso o cliente não

é identificado.



1- O funcionário identifica-se através



produtos escolhidos pelo cliente através do

código do produto.



com a quantidade.


dos produtos



76




2.1 – O código do produto é inválido (não está cadastrada). Disparar o caso de

uso Cadastrar Produtos.

Caso de Uso: Fazer Pagamento ao Fornecedor

Atores: FuncionárioTipo: Primário

Descrição: O pagamento é feito ao fornecedor e o débito é eliminado



1- O funcionário identifica o

fornecedor através do código do fornecedor.

2- O sistema exibe a lista de débitos

com o fornecedor identificado.3- O funcionário escolhe o

pagamento dentre a lista de débitos.

4- O sistema imprime um recibo

contendo o nome do fornecedor e o valor do

pagamento.

Caso de Uso: Receber Pagamento


Tipo: Primário

Descrição: O cliente faz o pagamento e seu débito é liquidado.



77



1- O funcionário identifica o clienteatravés do código do cliente.

2- O sistema exibe a lista de débitosdo cliente identificado (nome do cliente, data

e valor do débito).

3- O funcionário escolhe qual débito

será liquidado.

4- O sistema imprime um recibo

contendo o nome do cliente e o valor do

pagamento.

Seqüências Alternativas3.1 – O cliente paga um valor inferior ao valor do débito. O gerente entra com o

código do gerente e o débito é alterado com o novo valor (valor da dívida – valor pago).

Caso de Uso: Definir Meta de Venda

Atores: Gerente

Tipo: SecundárioDescrição: O gerente define a porcentagem de produtos consignados que deve

ser vendidas, ou seja, que não podem ser devolvidas.



1- O gerente define a porcentagem de

produtos consignados que deve ser vendidas(não pode ser devolvidas) para todos os

clientes.

2- O gerente confirma a operação



78

Caso de Uso: Fazer Pagamento Administrativo


Tipo: SecundárioDescrição: O funcionário descreve um gasto administrativo e fornece seu valor.



1- O funcionário identifica-se através


2- O funcionário descreve o gastoadministrativo e fornece o valor.

Caso de Uso: Cadastrar Cliente


Tipo: Primário

Descrição: Cadastra um cliente.



1- O funcionário preenche um

cadastro com os dados do cliente (nome,

telefone, RG, CPF, data de nascimento,

endereço)

2- O funcionário confere os dados e

confirma a operação.



79

Caso de Uso: Cadastrar Produto


Tipo: PrimárioDescrição: Cadastra umo produto.



1- O funcionário preenche um

cadastro com os dados do produto

(descrição, quantidade, preço)2- O funcionário confere os dados e

confirma a operação.



80

6.2 Análise

Como descreve Craig Larman (1997) “Para criar o software de uma aplicação, é

necessário uma descrição do problema e dos seus requisitos”. A análise nada mais é do

que a transformação dos requisitos da aplicação em especificações que descreverão uma

solução lógica para o domínio do problema.

Nesta fase procura-se pesquisar e entender o domínio do problema, a partir da

descrição dos requisitos, para o desenvolvimento de um modelo conceitual. É o que

Craig Larman (2001) chama de “investigação do problema”.

6.2.1 Modelo Conceitual

A palavra modelo pode ser definida como “uma representação abstrata que

permite descrever e/ou prever comportamentos específicos de um sistema, através do

estudo de um número reduzido de características relevantes do sistema” (MAFFEO,

1992) Esta representação pode ser de um fenômeno do mundo real (as leis físicas de

movimento são um modelo do movimento no mundo real), de uma máquina ou de umsoftware. Os resultados dos processos de análise serão modelos do domínio da aplicação

que está sendo desenvolvida.

O modelo conceitual “ilustra os conceitos significativos em um domínio de

problema” (LARMAN, 1997). Ele é um resultado da fase de análise e será a base para a

fase de projeto.

A partir da análise dos casos de uso e dos requisitos, decompõe-se o “problema em

conceitos e objetos individuais” (LARMAN, 1997). Nesta parte do desenvolvimentoocorre a elaboração de um modelo conceitual do problema.

No modelo da análise não se descreve artefatos de implementação de software

como classes de interface com o usuário ou camadas de persistência. O objetivo do

modelo conceitual não é ser um projeto de software, mas uma descrição de coisas do

mundo real que fazem parte do domínio do problema e sua solução.

“Modelos não são certos ou errados, eles são mais ou menos úteis” (FOWLER,

1997). A escolha do modelo terá conseqüências na flexibilidade e reusabilidade do



81

projeto. Por isso, um estudo aprofundado do domínio é importante antes de iniciar a

modelagem.

No modelo conceitual do controle de atacado a classe Atacado representa aempresa proprietária. Os clientes do atacado são representados pela classe Cliente. Os

fornecedores são representados pela classe Fornecedor. Atacado, Cliente, Fornecedor e

Funcionário são especificações de Entidade, pois representam conceitos de

pessoa/organização (figura 6.1).

Figura 6.1 – Modelo baseado no padrão Entidade

A consignação, compra e venda de produtos, descrita nos casos de uso de Compra

de Produtos, Venda de Produtos e Consignação de Produtos são representadas através



82

das classes Compra, Venda e Consignação. Toda venda e toda consignação são feitas do

atacado para um cliente. Então associou-se o Cliente à Consignação 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 operação Venda, Consignação e Compra estão

associadas sempre à duas entidades, sendo uma das entidades o Atacado. Assim sendo,

baseou-se no padrão Contratos, que diz que “Um Contrato pode ser uma compra, uma

venda ou qualquer outra transação feita entre entidades”, para generalizar as trêsoperações em uma classe Contrato como descrito na figura 6.3.



83

Figura 6.3 – Conceito de Contrato

A data_fechamento de Consignação é 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 operações de compra, vendae consignação sempre tem o atacado como parte contratada. Contrato também é

associado a um Funcionário, o qual irá iniciar o contrato no sistema. Finalmente tem-se

a associação de Contrato com Produto, pois as operações realizam a comercialização de

produtos do atacado (figura 6.4).



84

Figura 6.4 – Modelo com conceito de Contrato

O padrão 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. Lançamentos feitos em

Receita representam entrada de dinheiro na empresa. Lançamentos feitos em Despesa

representam os gastos. O atributo saldo de Caixa será diferença 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 Lançamentos. A classe Atacado

também pode gerar Lançamentos que serão referentes a despesas administrativas como

pagamentos de salário, compra de material de escritório, etc. (figura 6.6).



86

Figura 6.6 – Lançamentos nos Caixas

Em Lançamento o atributo valor representa o valor do lançamento em reais. O tipo

de lançamento pode ser cheque, promissória ou dinheiro. A data_lançamento será a dataem que o lançamento será contabilizado no sistema. A data_registro é a data em que o

lançamento foi inserido no sistema. Por exemplo, um pagamento com cheque para 30

dias feito no dia 1º de maio será registrado como um Lançamento do tipo cheque com

data_registro 01/05 e data_lançamento 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 definição de quais artefatos de software serão usadosna implementação de uma solução lógica para o problema. E “como eles (os artefatos)

irão colaborar para preencher todos os requisitos” (LARMAN, 2001).

Os artefatos do projeto serão criados com base na inverstigação feita na fase de

análise.

“Seu projeto precisa ser específico para resolver o problema, mas também

suficientemente flexível para tratar problemas e requisitos que surgirem no futuro”

(GAMMA, 1994). Projetistas iniciantes dificilmente conseguem um bom projeto desoftware. 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

experiências anteriores. Quando um problema de projeto é solucionado, esta solução é

registrada, para que no futuro, quando surgir um problema igual ou semelhante, não seja

necessário dispender tempo desenvolvendo um novo projeto. Assim nasce um padrão de

projeto.

6.3.1 Linguagem e Banco de Dados

A linguagem escolhida para o desenvolvimento da aplicação foi Java. Os fatores

que influenciaram na escolha foram sua natureza multi-plataforma, robustez e relativa

facilidade de programação (quando comparada com C++).

Como a aplicação a ser desenvolvida utiliza objetos persistentes, fez-se

necessário o estudo de um sistema gerenciador de banco de dados (SGBD).

Um fator preponderante na escolha do SGBD foi a portabilidade, pois a

aplicação desenvolvida utiliza linguagem Java, que tem portabilidade como uma das

caracterísiticas principais.

Outro fator foi o custo do software. Os SGBDs mais populares normalmente

exigem altos custos para sua aquisição. Neste trabalho pretende-se desenvolver uma

aplicação de baixo custo, que poderá ser utilizada em um sistema operacional gratuito,



89

como Linux. Isso possibilita que os usuários da aplicação arquem com os custos apenas

de equipamento e treinamento.

Levando em conta os fatores descritos acima, escolheu-se o Firebird comoSGBD da aplicação a ser desenvolvida. O Firebird é um banco de dados relacional de

código aberto que deriva do Interbase. O Interbase também é um SGBD freeware

pertencente a Borland. Apesar de ser freeware, o Interbase é um projeto com direções

mais comerciais.

O Firebird se mostrou um banco de dados estável. Oferece suporte a triggers e

stored procedures. A versão usada foi a 1.5 ClassicServer (IBPHOENIX, 2004).

A instalação do Firebird não inclui interface gráfica para manipulação de dados.Mas interfaces são encontradas facilmente na Internet, principalmente porque a maioria

das interfaces para Interbase são compatíveis com o Firebird.

Iniciou-se o trabalho usando o IBAccess, que se mostrou muito limitada e

instável. Na procura de uma interface mais robusta, encontrou-se o IBExpert, que

mesmo na versão mais simples (Personal) possui vários recursos que ajudam a tirar

proveito de todas as funcionalidades do banco de dados Firebird.

6.3.2 Diagramas de Sequência

Das ferramentas UML para descrição de um projeto de software, duas serão

utilizadas para o desenvolvimento da aplicação de Controle de Estoque: os diagramas de

sequência que descreve “como os objetos interagem via menssagens” (LARMAN,

2001) e o diagrama de classe, que descreve as classes do projeto e suas associações.

Dando continuidade a fase de projeto, foram criados diagramas de interação para

os casos de uso correspondentes. Os diagramas de interação mostram “como os objetos

interagem através de mensagens para cumprir tarefas.” (LARMAN, 1997).

Os diagramas de interação podem ser representados através de dois tipo distintos:

diagramas de colaboração, que representam a interação entre os objetos do software

através de um grafo, e diagramas de sequência. A seguir tem-se os diagramas de

sequência para os casos de uso mais relevantes do sistema.



90

6.3.2.1 Consignar

O diagrama de sequência de consignar que representa o caso de uso Consignar

Produto é descrito na Figura 6.8.

Figura 6.8 – Diagrama de Sequência Consignar



91

6.3.2.2 Vender

Diagrama de Sequência do Caso de Uso Vender Produto descrito na Figura 6.9.

Figura 6.9 – Diagrama de Sequência Vender



92

6.3.3 Diagrama de Classes

Em paralelo com a criação dos diagramas de colaboração é feita a elaboração dodiagrama de classes de projeto. Utilizando como base os métodos e relações

encontrados nos diagramas de sequência, o diagrama de classes vai descrever as classes

do projeto, seus métodos, atributos e associações. Diferente do modelo conceitual, o

diagrama de classes “mostra definições 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

Consignação. A classe Contrato também possui uma associação com Produtos. Ao

carregar um objeto de Contrato do banco de dados, todas as instâncias de Produtos

associadas a este Contrato serão carregadas e instânciadas. Isso cria um problema de

desempenho caso várias instâncias de Contrato precisem ser carregadas, por exemplo,para geração de relatórios.

Para solucionar este problema, foi utilizado o padrão Proxy na implementação

de Contrato e suas subclasses. Assim duas classes podem representar um contrato:

ContratoReal e ContratoProxy. A classe ContratoProxy não carrega as instâncias de

Produto na sua criação, eliminando o problema de desempenho nas operações 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 padrão Proxy descrito por Gamma (1994) não prevê herança no uso do Proxy.

Como Contrato tem subclasses, houve a necessidade de estender o padrão para estas

classes. Para isso aplicou-se o padrão as subclasses de Contrato. Assim cada

participante de Proxy especializa a superclasse que representa o mesmo papel, como

segue abaixo:



94

Figura 6.11 – Heranças de contrato com Proxy

6.3.3.2 Conta Caixa

Como o padrão de análise Conta Resumida (seção 3.2.4) foi aplicado para

modelar o controle de caixa, e no mapeamento de padrões de análise para padrões de

projeto desenvolveu-se o mapeamento do padrão Conta Resumida para o padrão

Composite (seção 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 instância de Receita e

uma instância de Despesa. Obedecendo ao padrão Composite todas as classesimplementam 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

método obterCaixa é implementado como métodos de classe (static). O mesmo é valido

para as classes Receita e Despesa.



96

6.3.3.3 Camada de Persistência

Como a aplicação utiliza-se de banco de dados para tornar seus objetos

persistentes, houve a necessidade de se implementar uma camada de persistência.

A camada de persitência desenvolvida consiste de uma coleção de mapeadores

de classe. Cada classe persistente do sistema possui um mapeador na camada de

persistência. O mapeador tem as informações de como uma instância da classe é

armazenada no banco de dados, e implementa as querys SQL para armazenar um objeto

no banco, carrega-lo no sistema, fazer alterações, etc.

Todos os mapeadores tem uma interface comum, com métodos comocarregar(int id), salvar(Object objeto), existe(int codigo).

Seguindo o padrão Facade (seção 5.6), criou-se uma classe que serve de

interface de comunicação da camada de aplicação com todos os mapeadores da camada

de persistência. Esta classe, chamada de Persistência, também é responsável pela

criação da conexão com o sistema de banco de dados. Caso o sistema de banco de dados

da aplicação seja alterado, a classe Persistência é a única a sofrer alteração na sua

implementação.Como a aplicação possui somente um banco de dados, a classe Persistência foi

implementada como um Singleton.



97

Figura 6.13 – Camada de Persistencia



98

6.4 Implementação

Com os artefatos UML gerados na fase de projeto, tem-se uma base para o inícioda fase de implementação da aplicação. Nesta fase, os artefatos UML são transformados

em código de alguma linguagem de programação.

Para implementação desta aplicação a linguagem de programação escolhida foi

Java. O ambiente de programação utilizado foi o NetBeans IDE 3.5.1.

A seguir serão detalhados alguns métodos que merecem atenção.

6.4.1 Método Vender

O caso de uso vender é implementado pelo método vender da classe Atacado.

Baseando-se no diagrama de sequência, este método recebe como parâmetro o código

do funcionário, código do cliente, um vetor com os códigos dos produtos vendidos, um

vetor com as quantidades de cada produto e o número de produtos. Os parâmetros

código do funcionário e código do cliente não serão utilizados no protótipo. Abaixo

segue a assinatura do método:

Public void vender(int codigoFun, int codigoCliente, int[]

codigoProdutos, int[] quantidades, int

Produtos)

O método vender carrega as informações do banco de dados através da

referência que atacado têm à classe Persistência. Através do método carregar, todos os

produtos cujo código está no vetor codigoProdutos serão carregados para uma instância

da classe Vector (classe da biblioteca Java que implementa um array dinâmico).

Vector vetorProdutos = bd.carregar(codigoProdutos, Produto.class,

nProdutos);

Após o carregamento, é executado o método vender para todas as instâncias da

classe Produto armazenadas em vetorProdutos. O método vender, da classe Produto,

recebe como parâmetro a quantidade de produtos vendidos. Este método diminui a

quantidade passada como parâmetro do atributo quantidade da instância (faz a retirada



99

do estoque), e retorna uma instância clone do produto.O valor do atributo quantidade

deste clone tem o mesmo valor do parâmetro quantidade passado para o método (o

clone representa o produto vendido). Abaixo segue o método 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 método vender, da classe Produto, são armazenados

em uma instância da classe Vector , chamada vetorProdVendidos. Esse vetor é passado

como argumento para uma instância da classe VendaReal, que vai registrar a operação

de venda. Essa instância de VendaReal é então salva no banco de dados. Os produtos os

quais as quantidades foram alteradas (instâncias de Produto as quais o método vender

foi executado) também são salvos no banco.

VendaReal venda = new VendaReal( 0, 0, vetorProdVendido);

bd.salvar(venda);

bd.salvar(vetorProdEstoque);

6.4.2 Método obterVendas

O método obterVendas da Classe atacado carrega todas as vendas registradas no

banco de dados. Para melhorar o desempenho, este método faz uso de objetos Proxy de

Vendas (ver subseção 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 instância de Vendas, a instância

Proxy fará o carregamento da instância real, como foi explicado no padrão Proxy

(subcapítulo 4.3). Segue a implementação do método obterProduto na classeVendaProxy.

public Vector obterProdutos() {

vendaReal = (VendaReal)bd.carregar(this.codigoContrato,

VendaReal.class);

return vendaReal.obterProdutos();

}

6.4.3 Camada de Persistência

A camada de persistência foi elaborada para que a aplicação ganhe em

estendibilidade e portabilidade. Assim foi criada uma classe Persistência, que servirá de

Fachada (ver sub capítulo 4.4, padrão Facade) para toda a camada de persistência, que

se constitui dos mapeadores das classes da camada de aplicação (ver subseção 6.3.3.3).

Para salvar um objeto, primeiramente a instância de Persistência define que

mapeador será usado. Isso é feito através do método retornarMapeador que recebe uma

classe como parâmetro e retorna uma instância da classe Mapeador. A classe que é

passada como argumento para o método retornarMapeador é a classe do parâmetro do

método salvar.

Para carregar um objeto, o sistema deve informar para a instância de Persistência

a classe do objeto que será carregado, e também um atributo identificador do objeto. A

implementação dos métodos 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 Protótipo

Tendo uma parte da aplicação implementada, construiu-se uma simples interface

para demonstração do protótipo (figura 6.14). A interface limita-se a verificar o estoque,

realizar vendas, e obter as vendas feitas pelo sistema (utilizando o método obterVendaspara demonstração da aplicação do Proxy).



102

Figura 6.14 - Protótipo da Aplicação

6.4.4.1 Funcionamento do Protótipo

O protótipo inicia com um menu inicial de 3 opções. Estoque, Vender e

Consultar Vendas. Em Estoque pode-se conferir o estoque de produtos registrados, seu

código, seu preço e sua quantidade (figura 6.15).

Em Vender pode se efetuar uma venda de produtos. Na primeira coluna coloca-

se o código 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 são mostradas na tabela de vendas.

Selecionando uma venda na tabela e clicando no botão Detalhar Vendas, são 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



7 CONCLUSÃO

Através deste estudo, pode-se comprovar o grande potencial do uso dos padrões

no desenvolvimento de software. O domínio do problema escolhido para a construção

de uma aplicação, que demonstrasse os benefícios do uso de padrões, era relativamente

simples. Mesmo assim pode-se constatar ganhos em estendibilidade, desempenho,

reusabilidade e portabilidade.

7.1 Fatores de Qualidade Alcançados

7.1.1 Estendibilidade

Estendibilidade é a capacidade que a aplicação tem de se adaptar a novos

requisitos. Quanto menor for o esforço utilizado em uma alteração de requisitos, maior aestendibilidade do sistema.

Pode-se comprovar a estendibilidade da aplicação de Controle de Atacado no

uso do padrão Contratos. A adição de uma nova atividade na empresa que envolva

contratos, exige apenas a adição 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, seriaadicionada ao projeto.

O uso do padrão de análise Conta, projetado usando-se o padrão Composite,

também aprimora a estendibilidade da aplicação, permitindo que se adicione um número

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 funcionário, despesa com impostos, etc.



105

7.1.2 Desempenho

O desempenho de uma aplicação tem grande impacto na aceitação da aplicaçãopelo usuário. Uma aplicação que não soluciona os problemas com velocidade perde um

pouco de sua aplicabilidade.

O ganho de desempenho é claramente demonstrado com o uso do padrão Proxy

na construção das subclasses de Contrato. No atacado usado como base para a

construção da aplicação, cada operação de consignação registra uma média de 80

produtos. O atacado tem cerca de 100 clientes que realizam 3 consignações por mês.

Assim uma consulta de todas as consignações do mês, sem a utilização do Proxy resultaria no carregamento de 24000 objetos do banco de dados. Considerando que o

referido atacado é uma microempresa, o número pode crescer para valores inaceitáveis.

7.1.3 Reusabilidade

Todos os padrões utilizados na análise e no projeto são genéricos o bastante para

serem utilizados mais de uma vez. Reusabilidade é uma característica inata a um

software que foi analisado e projetado usando padrões.

7.1.4 Portabilidade

A aplicação desenvolvida tem um de seus pontos fortes na portabilidade, não só

por ser implementada numa linguagem multi-plataforma, mas o uso do padrão Facade

para implementação da camada de persistência torna toda a camada de aplicação

independente do sistema gerenciador de banco de dados.

A aplicação 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 alterações na classe Persistência.



106

7.2 Considerações Finais

Analisando os resultados, pode-se concluir que a utilização de padrões favorece

vários aspectos de qualidade de um software. Esta qualidade que possibilita as

constantes atualizações promovidas pelas grandes empresas de software, possibilita que

os erros de aplicações extremamente complexas sejam rapidamente detectados e

corrigidos e torna possível a portabilidade das aplicações num mundo onde a variedade

de sistemas e plataformas crescem a cada dia.

É imprescindível que softwares de médio e grande porte tenham sua análise e

seu projeto baseado em padrões, para tornar economicamente viável a uma

softwarehouse, operações como manutenção e atualização de seus programas.

Por outro lado, o uso dos padrões ainda sofre resistência por parte de analistas e

projetistas, principalmente iniciantes, pois a primeira vista, padrões se demonstram

confusos e sem utilidade. Iniciantes não conseguem visualizar os benefícios que um

esforço extra nas fases de análise e projeto irão trazer num futuro próximo.

Na grande maioria dos casos, a economia de trabalho que um padrão promove é

muito superior ao esforço extra que se faz na pesquisa e implementação 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 padrões: uma introdução à análise e ao projeto

orientados a objetos. Tradução 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 Especificação 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 deBanco de Dados. 3. ed. Makron Books, 1999.



108

IBPHOENIX. What is Firebird? Disponível em <http://www.ibphoenix.com>. Acesso

em: 4 de Janeiro de 2004.

SUN. Java 2 Platform, Standard Edition, v 1.4.2 API Specification. Disponível 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

Aplicações de Padrões de Análise e Padrões de Projeto noDesenvolvimento de uma Aplicação de Controle de Atacado

Igor Ghisi

Ciências da ComputaçãoINE – Departamento de Informática e Estatística

Universidade Federal de Santa Catarina (UFSC), Brasil, [email protected]

O trabalho “Uso de Padrões de

Análise e Padrões de Projeto noDesenvolvimento de uma Aplicação de

Controle de Atacado” apresenta umconceito bastante novo no processo dedesenvolvimento de software, oconceito de padrão.

Um padrão é uma solução para umdeterminado tipo de problema. Adiferença desta solução está na forma decomo ela é descrita. Sua descrição, maisgeral e estruturada, favorece a suautilização em problemas pertencentes aum mesmo contexto. Problemas cujo

núcleo da solução seja semelhante.Os padrões de análise descritos notrabalho são soluções de análise – ummodelo conceitual orientado a objeto –para certos domínios de aplicação.

Já os padrões de projeto descrevemsoluções de projeto e implementaçãopara problemas de projeto de software.Os padrões descritos foram retirados dolivro Design Patterns de Erich Gamma,considerado a Bíblia dos padrões de

projeto de software.No trabalho, foi sugerido um

mapeamento de alguns padrões deanálise para padrões de projeto, ou seja,formas de projeto e implementação para

os modelos conceituais descritos nopadrão de análise. Assim, os domíniosde aplicação cuja solução se encaixa em

um dos padrões de análise mapeados, játerão uma solução definida para seuprojeto.

Para comprovar a eficiência do usodos padrões, foi desenvolvida umaaplicação usando-se um domíniocomum. A aplicação era basicamenteum sistema de controle de estoque econtrole de caixa. Foi descrito todo oprocesso de desenvolvimento daaplicação. Nas partes do

desenvolvimento onde foram utilizadospadrões, foi explicado como e porquetais padrões eram utilizados.

Os benefícios e dificuldades do usodos padrões foram demonstrados ao fimdo trabalho, dando ênfase ao fatorestendibilidade que os padrõesagregaram a aplicação desenvolvida. Otrabalho destaca que o tempo gasto noestudo e na aplicação dos padrões leva aum maior índice de reuso dos artefatos

de desenvolvimento de software,inclusive o código de programação,concluindo como válida a aplicação depadrões para qualquer processo dedesenvolvimento de software.

mailto:[email protected]

mailto:[email protected]



112

ANEXO II: Diagrama de Classes (Camada de Aplicação)



113



114

ANEXO III: Código da Aplicação



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, Datedata_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() {

}

*/


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, Datedata_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 String Nome;

protected String Telefone1;

protected String Telefone2;

protected String 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);

}


}

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 = result.getInt("PR_CODIGO");

prod.preco = result.getDouble("PR_PRECO");

prod.descricao = result.getString("PR_DESCRICAO");

prod.quantidade = result.getInt("PR_QUANTIDADE");

}


return prod;

}

public void excluir(int codigo) {

int i =0;

}

public boolean existe(int codigo) {

return false;

}


Produto prod;



121

prod = (Produto)objeto;

int codigo = prod.codigo;

try {


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));

}

}


try {

conn.commit();

}


}

public Vector carregarTudo() {

Vector vetorProduto = new Vector();

Produto prod;

try {


ResultSet result = trans.executeQuery(sqlSelect());

while (result.next()) {

prod = new Produto();

prod.codigo = result.getInt("PR_CODIGO");

prod.preco = result.getDouble("PR_PRECO");

prod.descricao = result.getString("PR_DESCRICAO");

prod.quantidade = result.getInt("PR_QUANTIDADE");



122

vetorProduto.add(prod.clonar());

}

}


return vetorProduto;

}

public class MapeadorVendaReal implements Mapeador {

private static Mapeador map = null;


/** Creates a new instance of MapeadorVenda */

private MapeadorVendaReal(Connection _conn) {

this.conn = _conn;

}

public Object carregar(int codigo) {

VendaReal venda;

venda = new VendaReal();

try {


ResultSet result = trans.executeQuery("SELECT * FROM venda

WHERE VE_CODIGO = " + String.valueOf(codigo));

result.next();

venda.codigoContrato = result.getInt("VE_CODIGO");

}


venda.vetorProduto =

this.carregarProdutos(venda.codigoContrato);

return venda;

}

public Vector carregarTudo() {

Vector vetorVenda = new Vector();

VendaReal venda;

try {




123

ResultSet result = trans.executeQuery(sqlSelectAll());


venda = new VendaReal();

venda.codigoContrato = result.getInt("VE_CODIGO");

venda.valorTotal = result.getDouble("VE_VALOR");

vetorVenda.add(venda.obterClone());

}

}


return vetorVenda;

}


VendaReal venda;

venda = (VendaReal)objeto;

int codigoVenda = this.carregeMaxCodigoVenda() + 1;

int codigo = venda.codigoContrato;

try {


ResultSet result =

trans.executeQuery(sqlSelectCodigo(codigo));

if (result.next()) {

//trans.executeQuery(this.sqlUpdate(codigo,venda.valorTotal));

}

else {

trans.executeUpdate(this.sqlInsere(codigoVenda,venda.valorTotal));

}

}


try {

conn.commit();

}


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();


trans.executeUpdate(this.sqlInsereVendaProd(codigoVenda, prod.codigo,

prod.quantidade));

conn.commit();

}

}


}

private Vector carregarProdutos(int codigoVenda) {

Vector vetorProdutos = new Vector();

Produto prod = null;

Persistencia bd = Persistencia.obterPersistencia();

try {




125

vetorProdutos.add(prod.clonar());

ResultSet result = trans.executeQuery("SELECT PR_CODIGO,

VE_PR_QUANT FROM venda_produto WHERE VE_CODIGO = "+

String.valueOf(codigoVenda));


int codigo = result.getInt("PR_CODIGO");

prod = (Produto)bd.carregar(codigo, Produto.class);

prod.quantidade = result.getInt("VE_PR_QUANT");

}

}


return vetorProdutos;}

private int carregeMaxCodigoVenda() {

int max = 0;

try {


ResultSet result = trans.executeQuery("SELECT

max(VE_CODIGO) FROM venda");

result.next();

max = result.getInt(1);

}


return max;

}

public class Persistencia {

private static Persistencia single;


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");

}


}

public static Persistencia obterPersistencia() {

if (single == null) {

single = new Persistencia();

}

return single;

}

public Object carregar(int codigo, Class classe) {

Mapeador mapeador;


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;


return mapeador.carregarTudo();

}


Mapeador mapeador;


mapeador.salvar(objeto);}

public void salvar(Vector vetorObjetos) {

Mapeador mapeador;

Object objeto = vetorObjetos.firstElement();


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 double preco;

protected int codigo;

protected int quantidade;protected 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) {

}


vendaReal = (VendaReal)bd.carregar(this.codigoContrato,

VendaReal.class);

return vendaReal.obterProdutos();

}

}

Uso de Padroes de Analise e Padroes de Projeto

Documents

Transcript of Uso de Padroes de Analise e Padroes de Projeto