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 DE PROJETO 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
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
7/10/2019 Uso de Padroes de Analise e Padroes de Projeto
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.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
7/10/2019 Uso de Padroes de Analise e Padroes de Projeto
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
7/10/2019 Uso de Padroes de Analise e Padroes de Projeto
“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.
7/10/2019 Uso de Padroes de Analise e Padroes de Projeto
(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.
7/10/2019 Uso de Padroes de Analise e Padroes de Projeto
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
7/10/2019 Uso de Padroes de Analise e Padroes de Projeto
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.
7/10/2019 Uso de Padroes de Analise e Padroes de Projeto
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.
7/10/2019 Uso de Padroes de Analise e Padroes de Projeto
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.
7/10/2019 Uso de Padroes de Analise e Padroes de Projeto
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.
7/10/2019 Uso de Padroes de Analise e Padroes de Projeto
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
7/10/2019 Uso de Padroes de Analise e Padroes de Projeto
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).
7/10/2019 Uso de Padroes de Analise e Padroes de Projeto
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).
7/10/2019 Uso de Padroes de Analise e Padroes de Projeto
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.
7/10/2019 Uso de Padroes de Analise e Padroes de Projeto
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).
7/10/2019 Uso de Padroes de Analise e Padroes de Projeto
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).
7/10/2019 Uso de Padroes de Analise e Padroes de Projeto
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;}
7/10/2019 Uso de Padroes de Analise e Padroes de Projeto
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
4.3.1 Implementação
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;
7/10/2019 Uso de Padroes de Analise e Padroes de Projeto
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.
7/10/2019 Uso de Padroes de Analise e Padroes de Projeto
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.
7/10/2019 Uso de Padroes de Analise e Padroes de Projeto
funcionário que realizou a operação; código,nome, quantidade, valor unitário e valor total
dos produtos vendidas 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 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
Atores: Funcionário.
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.
Seqüência Típica de Eventos
Ação do Ator Resposta do Sistema
1- O funcionário identifica-se através
do código do funcionário.
2- O funcionário identifica os
produtos escolhidos pelo cliente através do
código do produto.
Caso haja mais de um produto do
mesmo tipo, o funcionário entra também
com a quantidade.
3- O sistema informa o valor total
dos produtos
7/10/2019 Uso de Padroes de Analise e Padroes de Projeto
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
7/10/2019 Uso de Padroes de Analise e Padroes de Projeto
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
7/10/2019 Uso de Padroes de Analise e Padroes de Projeto
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).
7/10/2019 Uso de Padroes de Analise e Padroes de Projeto
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.
7/10/2019 Uso de Padroes de Analise e Padroes de 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,
7/10/2019 Uso de Padroes de Analise e Padroes de Projeto
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.
7/10/2019 Uso de Padroes de Analise e Padroes de Projeto
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.
7/10/2019 Uso de Padroes de Analise e Padroes de Projeto
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).
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.
7/10/2019 Uso de Padroes de Analise e Padroes de Projeto
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.