terça-feira, 30 de agosto de 2011

Tunning em banco de dados Postgres

1. Editando as configurações do banco.

Edite o arquivo postgresql.conf:

# nano /usr/local/pgsql/data/postgresql.conf
.

Altere as sentenças nos seguintes grupos para:

# CONNECTIONS AND AUTHENTICATION (refere-se a parte de conexões e autenticação do banco)

listen_addresses = '*'
#ip que ele está escutando
port = 5432
#porta postgres
max_connections = 40
#número de conexões ao banco, depende da quantidade de memória deste

# RESOURCE USAGE (esse grupo se refere ao uso de recursos utilizados pelo banco)

# Memory
shared_buffers = 8192
#min 16MB ou 2x o max_connections
temp_buffers = 8192
#min 100, 8KB each
work_mem = 65536
#min 64, size in KB
maintenance_work_mem = 524288
#min 1024, size in KB
max_stack_depth = 8192
#min 100, size in KB

# Free Space Map
max_fsm_pages = 120000
#min max_fsm_relations*16, 6 bytes each


# WRITE AHEAD LOG (refere-se a escrita dos logs na base do banco)

# Settings
wal_buffers = 512
#min 4, 8KB each


# QUERY TUNING (refere-se à otimização das querys do banco, lembrando que habilitar alguma tag nesse grupo não significa que você melhorá-lo)

# Planner Cost Constants
effective_cache_size = 8192000
#typically 8KB each
random_page_cost = 2.0
#units are one sequential page fetch


# ERROR REPORTING AND LOGGING (refere-se a coleta e ao armazenamento dos logs de erros do banco)

log_destination = 'stderr'

redirect_stderr = on
#log do banco em um arquivo separado
log_directory = '/var/log/pgsql'
#diretório dos logs
log_filename = '%Y-%m-%d_%H%M%S.log'
#nome do log
log_rotation_size = 10240
#rotação automatica dos logs
silent_mode = off
#habilita os logs no terminal


#Query/Index Statistics Collector
stats_start_collector = on
stats_row_level = on


# AUTOVACUUM PARAMETERS (refere-se ao vaccuum do banco, rotina que serve para otimizar e limpar o lixo deixado na base do banco)

autovacuum = on
#habilitar o autovaccum
autovacuum_naptime = 600
#Tempo entre rodar os autovaccums em segundos
autovacuum_vacuum_threshold = 1000
#min de updates depois do vaccum
autovacuum_analyze_threshold = 500
#min de updates depois da analize

Crie uma pasta para armazenar os logs e após altere suas permissões:

# mkdir /var/log/pgsql
# chmod -R 775 /var/log/pgsql
# chown -R pgsql:pgsql /var/log/pgsql


2. Adicionando Segurança.

Edite o arquivo pg_hba.conf para liberação de acesso externo ao banco:

# vi /usr/local/pgsql/data/pg_hba.conf

Caso outro servidor ou rede precise, acesse esse banco, adicione os IPs dos mesmos no grupo IPv4 local connections (Não retirar a permissão do 127.0.0.1).

Segue o formato:

a) liberação para de uma rede especifica: 

host all all 192.168.0.0/24 trust  

b) liberação para um determinado IP:

host all all 192.168.0.1/32 trust

3. Crie um usuário no banco para acessar ao banco.

Para aumentar a segurança usaremos um usuário próprio no banco de dados:

# createuser -U pgsql (nome do usuário que você quer criar) -W 

segunda-feira, 29 de agosto de 2011

Sistema de banco de dados relacional

ABORDAGEM RELACIONAL

O modelo relacional está baseado na teoria matemática das relações.

Relação: Dada uma coleção de conjuntos D1, D2,…………….Dn (não necessariamente distintos), R é uma relação naqueles n conjuntos se ele for um conjunto de n-tuplas ordenadas, d1, d2,……., dn tais que d1 pertença a D1, d2 pertença a D2, .... são os domínios de R. O valor n é o grau de R.

A abordagem apresenta como características: 

Estrutura de Dados Tabular

Na prática uma relação toma a forma de uma tabela. Nesta as linhas/tuplas representam as ocorrências de registros e as colunas/atributos os campos que compõem os registros. Ao conjunto dos possíveis valores que cada atributo pode assumir damos o nome de domínio.

Emprego da Álgebra Relacional 

É necessário ressaltar que as tabelas do ambiente relacional não são simplesmente os arquivos convencionais. A diferença fundamental é que nos métodos de acesso convencionais a recuperação das informações se faz registro a registro. No ambiente relacional faz-se uso dos fundamentos da teoria das relações na construção, implantação e operação do SGBD. Dentre estes fundamentos, destaca-se um conjunto de operadores que compõem a álgebra relacional.

Álgebra Relacional

É um conjunto de operações e relações. Cada operação usa urna ou mais relações como seus operandos, e produz outra relação como resultado.

Desta forma, a recuperação das informações em um SGBD relacional se faz em conjuntos de registros que comporão uma nova relação. Para isso dispomos das seguintes operações: 

União: A união de duas relações A e B, é o conjunto de todas as tuplas pertencentes a A ou B (ou ambos). A e B devem ter a mesma estrutura (união-compatíveis).

Intersecção: É tudo aquilo que dentro dos arquivos vai ser igual A intersecção de duas relações A e B, é o conjunto de todas as tuplas pertencentes a A e B. A e B devem ser união-compatíveis.

Diferença: A diferença entre duas relações A e B é o conjunto de todas as tuplas t pertencentes a A mas não a B. A e B devem ser união compatíveis.

Produto Cartesiano: O produto cartesiano de duas relações A e B é o conjunto de todas as tuplas t tais que t é a concatenação de uma tupla a pertencente a A com uma tupla b pertencente a B.

Seleção (Questionamento ao arquivo): É a operação utilizada para selecionar uma tupla ou conjunto de tuplas de uma relação a partir de uma condição de seleção.

Projeção (Trazer a lista de um campo): É a operação utilizada para extrair o domínio de um atributo de todas as instâncias de uma entidade.

Junção: É a operação utilizada para concatenar relações. Quando desejamos concatenar apenas as tuplas de diferentes relações que tenham algum atributo com o mesmo valor, empregamos uma condição de seleção e denominamos a operação de EQUI-JOIN. Quando realizamos a concatenação também com as tuplas que não tem correspondência estaremos utilizando a operação OUTER-JOIN.

Divisão: O resultado da divisão de uma relação A por uma relação B é o conjunto de valores x tais que o par (x, y) aparecem em A para todos os valores y que aparecem em B. 

Cálculo Relacional: É o conjunto de expressões lógicas capazes de estabelecer condições de relacionamento entre tabelas. Com base nesta teoria, os SGBD relacionais dispõe em suas linguagens de criação e manipulação de dados de comandos que permitem a implementação das operações. 

Recursos quanto à Integridade de Dados

No ambiente relacional temos:

Índice: É um recurso físico que tem por objetivo otimizar a recuperação de informações. 

Chave: É um dado utilizado nas consultas as bases de dados. Neste sentido podemos ter chaves primárias, secundárias e estrangeiras.

Chave Primária: É o dado dentro de uma tabela que nos permite identificar cada linha da mesma. 

Chave Secundária: É um dado ou conjunto de dados que nos permitirá a identificação de um conjunto de linhas. 

Chave Estrangeira: Sejam duas tabelas A e B que tem um atributo comum o, sendo c chave primária de A, dizemos que ele é uma chave estrangeira de B. Chaves estrangeiras são empregadas para estabelecer relacionamentos entre tabelas.

A partir destes conceitos temos duas regras de integridade dos dados no modelo relacional: 

Integridade de Identidade: O valor da chave primária de uma tabela não poderá ser nulo.

Integridade Referencial: Se uma determinada tabela A possui uma chave estrangeira que é chave primária de uma tabela B, então ela deve:
     a. Ser igual a um valor de chave primária existente em B, ou
     b. Ser nula para indicar que a relação lógica está desativada.

Dicionário de Dados Ativo e Integrado

Dicionário de Dados

É um banco de dados que contém descrições dos objetos existentes no sistema de aplicações da organização. É uma ferramenta fundamental no desenvolvimento de sistemas bem como no gerenciamento dos sistemas já implantados. Deve ser ativo no sentido de estar sempre disponível a utilização e integrado na medida em que englobe todas as informações a respeito dos sistemas. Permite efetuar referências cruzadas sobre os dados, auxiliando na verificação dos locais em que cada dado, tabela, programa, rotina ou sistema, é utilizado.

Consistência Automática de Dados

O próprio sistema trata de validar os dados no que diz respeito a tamanho, formato, tipo e integridade.

Mapeamento para esquema lógico

Esquema lógico

É a representação do esquema conceitual ER (Entidade-Relacionamento) do banco de dados em um modelo lógico de dados, que pode ser: relacional, orientado a objeto, objeto-relacional, etc.
Para isso, é realizado o mapeamento das relações existentes no esquema conceitual para o modelo lógico escolhido.

Em seguida, será abordado o mapeamento do esquema conceitual ER para o modelo relacional, que se baseia em tabelas (relações).

Mapeamento de relacionamento binário 1:1

Um carro possui um motor e um motor pertence somente a um carro.

Regras para mapeamento: cria uma única tabela que contenha o atributo de todas as entidades envolvidas.
Carros (PLACA, MODELO, NUM_SERIE, POTENCIA)

Observação: o(s) campo(s) que forma(m) a chave primária da entidade deve(m) ser sublinhado(s).

Mapeamento de relacionamento binário 1:N

Um cliente pode realizar várias compras.

Regras para mapeamento: criar uma tabela para cada entidade e inserir uma chave estrangeira na tabela que possui cardinalidade N que faz referência à chave primária da tabela que possui cardinalidade 1.
Clientes (CPF, NOME)
Compras (COD_COMPRA, DATAHORA, CPF)

Observação: o campo CPF é uma chave estrangeira que faz referência à chave primária CPF da tabela Clientes.

Mapeamento de relacionamento binário N:N

Um produto pode ser vendido em várias vendas e uma venda possui vários produtos.

Regras para mapeamento: criar uma tabela para cada entidade e uma nova tabela com chaves estrangeiras que referenciam as chaves primárias das entidades envolvidas no relacionamento.
Vendas (COD_VENDA, DATAHORA)
Produtos (COD_PRODUTO, DESCRICAO, PRECO)
ProdutosVendas (COD_VENDA, COD_PRODUTO)

Mapeamento de relacionamento com atributos da relação

Ainda utilizando o exemplo anterior de Produtos e Vendas, é necessário enfatizar que podem existir relações que possuam atributos. Caso isso ocorra, os atributos da relação deverão ser inseridos na mesma tabela em que for(em) inserida(s) a(s) chave(s) estrangeira(s).

Vendas (COD_VENDA, DATAHORA)
Produtos (COD_PRODUTO, DESCRICAO, PRECO)
ProdutosVendas (COD_VENDA, COD_PRODUTO, QTDE_VENDIDA, PRECO_VENDA)

Mapeamento de auto-relacionamento

Um usuário coordena outros usuários.

Regras para mapeamento: criar uma única tabela com os atributos da entidade e acrescentar um campo que referencie a própria chave primária da tabela.
Usuários (LOGIN, Senha, LOGIN_COORDENADOR)

Mapeamento de relacionamento N-Ário

Uma turma assiste aulas de várias disciplinas ministradas por vários professores.

Regras para mapeamento: criar uma tabela para cada entidade da relação e criar uma nova tabela que contenha chaves estrangeiras que referenciem as chaves primárias das entidades envolvidas no relacionamento.
PROFESSORES (CPF, NOME)
TURMAS (COD_TURMA, ANO, SEMESTRE)
DISCIPLINAS (SIGLA, NOME)
PROFTURMADISC (CPF, COD_TURMA, SIGLA)

Mapeamento de relacionamento N-Ário com auto-relacionamento

Um usuário escreve recados para outros usuários.

Regras para mapeamento: a mesma regra do mapeamento de relacionamento n-ário.
USUARIOS (LOGIN, SENHA)
RECADOS (COD_RECADO, TEXTO, DATAHORA)
USUARIOSRECADOS (LOGIN_REMETENTE, COD_RECADO, LOGIN_DESTINATARIO)

Mapeamento de generalização de entidades

Funcionários e Clientes são um tipo de Pessoa.

Regras para mapeamento: criar uma única tabela que contenha todos os atributos das entidades. Os atributos das entidades-filhas devem ser opcionais. Deve ser acrescentado um campo “tipo” para informar a qual entidade o registro se refere.
PESSOAS (CPF, NOME, SAUDACAO, DATAADMISSAO, TIPO)

Projeto de banco de dados: projeto conceitual

O Projeto conceitual produz um esquema conceitual a partir de “requisitos” de um mundo real.
• Projeto conceitual usa modelo de dados para descrever a realidade.
• Um modelo de dados se ampara em um conjunto de blocos de construção primitivas. 

Abstração

Processo que consiste em mostrar as características e propriedades essenciais de um conjunto de objetos, ou esconder as características não essenciais.

Quando pensamos no objeto “bicicleta” de uma forma abstrata, normalmente “esquecemos” seus detalhes e as particularidades que as diferem entre si.

Abstrações em projetos conceituais

Existem 3 Tipos:
• Classificação
• Agregação
• Generalização 

Classificação

Usada para reunir objetos do mundo real com propiedades comuns, formando (ou definindo) classes.

Agregação

Usada para definir uma nova classe a partir de um conjunto de classes que representam suas partes componentes.
 

Generalização

Usada para definir uma classe mais genérica a partir de duas ou mais classes.


Cobertura da Generalização

• Total / Exclusiva
• Total / Não Exclusiva

MODELOS DE DADOS

Conceitos: modelo e esquema

Um modelo de dados é uma coleção de conceitos usados para descrever uma dada realidade. Estes conceitos são construidos com base nos mecanismos de abstração e são descritos através de representações gráficas e linguísticas.

Um esquema é uma representação de uma porção específica da realidade usando-se um particular modelo de dados.

Para exemplificar vamos utilizar o modelo de entidades e relacionamentos (M.E.R.).


Há dois tipos de modelos de dados:

• Modelos conceituais: são ferramentas que representam a realidade num alto nível de abstração.
• Modelos lógicos: suportam descrições de dados que podem ser processadas (por um computador). Incluem os modelos relacional, hierárquico e rede.

Obs: projeto de base de dados não é a única aplicação de modelos conceituais. Eles podem ser excelentes ferramentas para gestão em empresas.

Por recomendação do comitê ANSI/SPARC (metade dos anos 70) todo sistema de base de dados deveria ser organizado de acordo com 3 níveis de abstração de dados:
• Externo: também chamado de visão. Descreve o ponto de vista de grupos específicos de usuários sobre a porção da base de dados que é interessante preservar para aquele grupo particular.
• Conceitual: representação de alto nível, independente da máquina, sobre toda a base de dados. Também chamada de “Enterprise Scheme”.
• Interno: descrição da implementação física da base de dados. Dependente da máquina.


sábado, 27 de agosto de 2011

Tutorial do MySQL

Disponibilizo no link abaixo um excelente tutorial do MySQL.

Clique aqui para acessar o texto completo

sexta-feira, 26 de agosto de 2011

Modelagem de processos utilizando BPMN

Publico abaixo um paper escrito para a disciplina de Business Process Management do curso de Especialização em Governança de Tecnologia da Informação da Universidade do Sul de Santa Catarina.

1 INTRODUÇÃO

Business Process Modeling Notation – BPMN – é uma linguagem de notação gráfica para apresentação de passos em um processo de negócio.

A BPMN tem como seu objetivo o suporte à gestão de processos de negócios para profissionais técnicos e profissionais de negócio, fazendo com que estes sejam capazes de representarem semânticas de processos simples ou complexos através de uma notação intuitiva.

“A BPMN retrata o fluxo fim-a-fim de um processo de negócio” (Business Process Management Initiative, 201-?). Esta linguagem foi criada para a coordenação da sequência de processos e mensagens que fluem entre participantes em um conjunto de atividades correlacionadas.exto do artigo.

2 DESENVOLVIMENTO

2.1 A MODELAGEM DE PROCESSOS DE NEGÓCIOS COM BPMN

A notação BPMN é uma notação simples para analistas de negócios, tendo em conta o paradoxo existente entre a necessidade de um modelo de processo de negócio e sua execução em um sistema de gestão de processos de negócios – BPMS.

A linguagem de notação BPMN aborda esta situação propondo que sejam usados os diferentes elementos do diagrama BPD – Business Process Diagram – pelos analistas de negócios e profissionais de Tecnologia da Informação.

Os elementos de linguagem destinados aos analistas de negócios representam os elementos básicos mantendo apenas os aspectos genéricos da modelagem dos processos de negócios. Estes elementos básicos são então complementados pelos analistas de Tecnologia da Informação, que adicionam as informações necessárias à execução.

Estes elementos comuns da linguagem BPMN formalizam diversas situações dos processos de negócios. Eles são baseados em quatro categorias citadas na especificação da linguagem de notação BPMN:
  • Objetos de fluxo de atividades e de mensagens.
  • Objetos de conexão.
  • Raias de piscina (swimlanes).
  • Artefatos.
"Os objetos de fluxos são os principais elementos gráficos para definir o comportamento do processo de negócio" (GNOFI TECNOLOGIA, 201-?). Ao analista de negócios são dispostos três tipos de objetos:
  • Eventos de inicialização, intermediários e de finalização, do tipo vazio com um gatilho lidando unicamente da perspectiva de negócio do processo.
  • Atividades compostas de tarefas e de seus processos sem detalhes dos atributos individuais relacionados à execução, contudo, com o analista de negócios podendo adicionar as propriedades relacionadas à perspectiva de negócio como o tempo de execução ou ainda os custos da execução de uma tarefa.
  • Conexões de decisão exclusiva indicando os fluxos de atividades alternativos.
O analista de negócio utiliza três maneiras para conectar os objetos em fluxo:
  • Conexão de fluxo de sequência representado com uma flecha simples de um único traço.
  • Conexão de fluxo de mensagem representando as trocas de informações entre os participantes do processo.
  • Associação conectando os artefatos aos objetos de fluxo.
Os elementos do fluxo de atividades são agrupados de acordo com as responsabilidades das unidades organizacionais e dos papéis em utilização:
  • As piscinas (pools) definem os participantes ou unidades organizacionais.
  • As raias (lanes) identificam os papéis de cada participante.
O analista de negócio utiliza também os artefatos, que "[...] são usados para fornecer informações adicionais sobre o processo" (GNOFI TECNOLOGIA, 201-?), ou seja, para o fluxo das atividades. São eles:
  • Os objetos de dados.
  • Os grupos.
  • As anotações.
A figura 1 ilustra um diagrama BPD de alto nível que apresenta unicamente os elementos básicos.
    Figura 1 – Diagrama BPD de alto nível

    A informação se completa neste diagrama quando adicionamos os elementos e informações necessários à sua execução em um sistema de informação, como a ilustra a figura 2.

    Figura 2 – Diagrama BPD de projeto

    2.2 A NOTAÇÃO BPMN E A GESTÃO DE PROCESSOS DE NEGÓCIOS

    A notação BPMN traz para a gestão de processos de negócios um meio intermediário entre os modelos de alto nível como os diagramas EPC – Event-driven Process Chain – e a integração de tecnologias de execução de processos de negócios.

    Esta notação facilita a comunicação entre os membros da equipe responsável em colocar os processos de negócios em funcionamento. Ela aumenta a produtividade dominuindo os tempos de tradução e o esforço para colocação em funcionamento dando suporte direto à sua tradução em linguagem de execução de processos de negócios BPEL – Business Processes Execution language.

    As ferramentas de modelagem evoluiram e atualmente oferecem módulos de simulação diretamente integrados com os diagramas BPD. Empresas como a Intelio oferecem "[...] o último padrão industrial para modelar processos" (Intelio, 201-?), soluções completas de gestão de negócios fundamentadas na linguagem de notação BPMN.

    Contudo, a notação BPMN não oferece suporte à modelagem dos aspectos puramente de negócios como os organogramas e as cadeias de valor agregado.

    A elaboração de diagramas BPD se integra com a elaboração dos processos de negócios mais importantes para a sua colocação em funcionamento.

    3 CONCLUSÃO

    BPMN é importante porque o mundo dos negócios tem mudado muito nos últimos anos e atualmente um processo de negócio abrange múltiplos participantes, fazendo com que a coordenação possa ficar complexa. Antes da BPMN não havia uma técnica de modelagem padrão que solucionasse estes problemas. BPMN foi desenvolvida para prover uma notação realmente livre, beneficiando os usuários de uma maneira similar à ocorrida com a UML – Unified Modeling Language – na Engenharia de Software, com simplicidade, objetividade e inteligibilidade.

    REFERÊNCIAS

    BUSINESS PROCESS MANAGEMENT INITIATIVE. Business process management notation information: BPMN. [S.L.: s.n., 201-?]. Disponível em: . Acesso em: 9 ago. 2011.

    GNOFI TECNOLOGIA. BPMN: Business process modeling notation. [S.L.: s.n., 201-?]. Disponível em: . Acesso em: 9 ago. 2011.

    INTALIO. Business process management. [S.L.: s.n., 201-?]. Disponível em: . Acesso em: 9 ago. 2011.


    Ligue a vontade para qualquer celular ou fixo em todo o Brasil, EUA e Canadá, através do 99TelexFREE. Teste nosso serviço por 1 hora gratuitamente: http://www.telexfree.com/ad/marcelmesmo  

    quinta-feira, 25 de agosto de 2011

    UML - Linguagem de Modelagem Unificada

    Excelente apostila de UML, muito bem ilustrada, do autor Rildo Santos.

    Clique aqui para acessar o texto completo

    O que são padrões de projeto (design patterns)

    Padrões de projeto para softwares são soluções de eficiência já comprovadas e amplamente utilizadas para a resolução de problemas comuns em projeto de software. Estas soluções são desenvolvidas e conhecidas por especialistas e tornam-se padrões por serem reutilizadas várias vezes em vários projetos e por terem eficácia comprovada.

    Os padrões de projetos tornam mais fáceis à reutilização de projetos e arquiteturas bem sucedidas. Expressando técnicas comprovadas como padrões de projetos tornam-os mais acessíveis aos desenvolvedores de novos sistemas. Os padrões de projetos ajudam você a escolher alternativas de projeto que tornam um sistema reutilizável. Padrões de projeto podem até mesmo melhorar a documentação e manutenção dos sistemas existentes, fornecendo uma definição explícita da classe e interações de objetos e suas intenções subjacentes. Simplificando, padrões de projetos ajudam designers a ter um modelo "correto" mais rápido.

    Em geral, um padrão tem quatro elementos essenciais:

    a) O nome do padrão é um identificador que podemos usar para descrever um problema de projeto, suas soluções e conseqüências em uma ou duas palavras. A nomeação de um padrão imediatamente aumenta o nosso vocabulário de design. Ela nos permite projetar em um nível maior de abstração. Ter um vocabulário de padrões permite-nos falar sobre eles com os nossos colegas, em nossa documentação, e até mesmo para nós mesmos. Ela torna mais fácil pensar em projetos e comunicá-las e suas vantagens e desvantagens para os outros. Encontrar bons nomes tem sido uma das partes mais difíceis do desenvolvimento de nosso catálogo;

    b) O problema descreve quando aplicar o padrão. Ele explica o problema e o seu contexto. Poderia descrever os problemas de projeto específicos, tais como a forma de representar algoritmos como objetos. Poderia descrever classe ou objeto de estruturas que são sintomáticas de um projeto inflexível. Às vezes, o problema irá incluir uma lista de condições que devem ser atendidas antes que faça sentido aplicar o padrão;

    c) A solução descreve os elementos que compõem o projeto, seus relacionamentos, suas responsabilidades e suas colaborações. A solução não descreve um projeto particular concreto ou de aplicação, porque um padrão é como um modelo que pode ser aplicado em muitas situações diferentes. Em vez disso, o padrão fornece uma descrição abstrata de um problema de projeto e um arranjo geral de elementos (classes e objetos no nosso caso);

    d) As consequências são os resultados e trade-offs da aplicação do modelo. Embora as consequências sejam muitas vezes mudadas quando descrevemos as decisões de design, elas são críticas para avaliar alternativas de projeto e para a compreensão dos custos e dos benefícios da aplicação do padrão. Elas podem tratar de questões de linguagem e de execução, bem. Uma vez que a reutilização é frequentemente um fator de design orientado a objetos, as consequências de um padrão incluem seu impacto sobre a flexibilidade, a extensibilidade e a portabilidade de um sistema. A listagem dessas consequências explicitamente nos ajuda a compreender e avaliar.

    PRINCIPAIS PADRÕES DE PROJETO

    Os padrões de projeto podem ser divididos por sua função ou por seu escopo, sendo apresentados em três categorias principais, quais sejam, padrões de criação, padrões estruturais e padrões comportamentais. Cada uma destas “categorias de padrões de projeto” contém os design patterns que são úteis a cada escopo.

    Padrões Criacionais (Creational Patterns)

    a) Abstract Factory (Fábrica Abstrata): Fornece uma interface para criar famílias de objetos relacionados ou dependentes sem especificar suas classes concretas.
    b) Builder (Construtor): Separa a construção de um objeto complexo da sua representação para que o mesmo processo de construção possa criar diferentes representações.
    c) Factory Method (Método Fabrica): Define uma interface para criar um objeto, mas deixa as subclasses decidirem qual classe instanciar. Factory Method permite que uma classe adie a instanciação para subclasses.
    d) Prototype (Protótipo): Especifica o tipo de objetos a criar usando uma instância prototípica e cria novos objetos copiando este protótipo.
    e) Singleton (Objeto Único): Certifica-se de que uma classe tenha somente uma instância e fornece um ponto global de acesso a ele.

    Padrões Estruturais (Structural Patterns)

    a) Adapter (Adaptador): Converte a interface de uma classe em outra interface esperada pelos clientes. Adapter permite que as classes trabalhem conjuntamente em casos que sem o adapter elas não poderiam por causa de interfaces incompatíveis.
    b) Bridge (Ponte): Desacopla uma abstração de sua implementação de modo que as duas possam variar independentemente.
    c) Composite (Compositor): Compõe objetos em estruturas de árvore para representar hierarquias parte-todo. Composite permite que clientes tratem objetos individuais e composições de objetos uniformemente.
    d) Decorator (Decorador): Anexa responsabilidades adicionais a um objeto dinamicamente. Decoradores proveem uma alternativa flexível à herança para estender funcionalidade.
    e) Facade (Fachada): Fornece uma interface unificada para um conjunto de interfaces em um subsistema. Facade define uma interface de alto nível que torna o subsistema mais fácil de usar.
    f) Flyweight: Usa compartilhamento para suportar um grande número de objetos finos de forma eficiente.
    g) Proxy (Procurador): Proporciona um espaço reservado para substituto ou outro objeto para controlar o acesso a ele.

    Padrões Comportamentais (Behavioral Patterns)

    a) Chain of Responsibility (Cadeia de Responsabilidade): Evita o acoplamento do remetente de uma solicitação ao seu destinatário, dando a um objeto a chance de processar o pedido à cadeia de objetos receptores e passa a solicitação ao longo da cadeia até que um objeto gere.
    b) Command (Comando): Encapsula uma solicitação como um objeto, permitindo parametrizar clientes com diferentes solicitações, enfileirar solicitações ou registros, e apoiar as operações que podem ser desfeitas.
    c) Interpreter (Interpretador): Dada uma linguagem, define uma representação para sua gramática juntamente com um interpretador que usa a representação para interpretar sentenças na linguagem.
    d) Iterator (Iterador): Fornece uma maneira de acessar os elementos de um objeto agregado sequencialmente sem expor sua representação subjacente.
    e) Mediator (Mediador): Defini um objeto que encapsula como um conjunto de objetos interage. Mediator promove o acoplamento fraco, evitando que objetos referenciem uns aos outros de forma explícita, o que lhe permite variar sua interação de forma independente.
    f) Memento (Lembrança): Sem violar o encapsulamento, captura e externaliza o estado interno de um objeto para que o objeto possa ser restaurado para este estado mais tarde.
    g) Observer (Observador): Define uma dependência um-para-muitos entre objetos de modo que quando um objeto muda de estado, todos os seus dependentes sejam notificados e atualizados automaticamente.
    h) State (Estado): Permite que um objeto altere seu comportamento quando seu estado interno muda. O objeto parecerá ter mudado sua classe.
    i) Strategy (Estratégia): Define uma família de algoritmos, encapsula cada um, e torna-os intercambiáveis. Strategy permite que o algoritmo varie independentemente dos clientes que o utilizam.
    j) Template Method (Método Template): Define o esqueleto de um algoritmo numa operação, deixando alguns passos para subclasses. Template Method permite que as subclasses redefinam certos passos de um algoritmo sem alterar a estrutura do algoritmo.
    k) Visitor (Visitante): Representa uma operação a ser realizada sobre os elementos de uma estrutura de objeto. Visitor permite que você defina uma nova operação sem alterar as classes dos elementos sobre os quais opera.

    EXEMPLO DE PADRÃO DE PROJETO

    Design Pattern Observer

    O Design Pattern Observer define uma dependência um-para-muitos entre objetos de modo que, quando um objeto muda de estado, todos os seus dependentes são notificados e atualizados automaticamente. Considerando agora os princípios da Orientação a Objetos que nos diz para encapsular o que varia, dando prioridade à composição (implementação de interfaces) em relação à herança, é possível modelar os projetos levemente ligados entre objetos que interagem.

    Aplicação Observer com Swing

    Para esta aplicação, estão desenvolvidas 3 classes, cada uma abordando os conceitos de MVC, sendo respectivamente Model, View e Controller os nomes das classes. Para a implementação do Design Pattern, foi utilizado as classes-padrão da linguagem Java: java.util.Observable e import java.util.Observer. O diagrama implementado é o seguinte:

    Pode-se observar no diagrama e na codificação da classe modelo que ela estende java.util.Observable, ou seja, ela será observada pelas classes View e Controller. Esta “observação” é criada quando na Controller é adicionada por meio do método addObserver(). Um detalhe importante é que as classes que “podem observar” necessariamente implementam a interface java.util.Observer.

    Código da Classe Model:

    import java.util.Observable;
    public class Model extends Observable{
         private String campo1;
         private Integer campo2;

         public void atualizar(String campo1, Integer campo2){
              this.campo1 = campo1;
              this.campo2 = campo2;

              //Métodos que "avisam" os observadores
              notifyObservers();
              setChanged();
         }

         public String getCampo1(){
              return campo1;
         }

         public void setCampo1(String campo1){
              this.campo1 = campo1
         }

         public Integer getCampo2(){
              return campo2;
         }

         public void setCampo2(Integer campo2){
              this.campo2 = campo2;
         }
    }

    Nas classes abaixo verifica-se o método update(), implementado devido a interface java.util.Observer. Este método é invocado quando a classe Observable, no caso deste projeto a View, invoca o método notifyObserver().

    Código da Classe View:

    import java.awt.GridLayout;
    import java.awt.event.ActionEvent;
    import java.awt.event.ActionListener;
    import java.util.Observable;
    import java.util.Observer;
    import javax.swing.JButton;
    import javax.swing.JFrame;
    import javax.swing.JLabel;
    import javax.swing.JPanel;
    import javax.swing.JTextField;

    public class View extends JFrme implements Observer{

         private Model model;
         private Jpanel pnlCampo1;
         private JPanel pnlCampo2;
         private JPanel pnlBotao;
         private JLabel lblCampo1;
         private JLabel lblCampo2;
         private JTextField txtCampo1;
         private JTextField txtcampo2;
         private JButton botao;

         public View(String titulo, Model model){
              super(titulo);
              this.model = model;
              renderizarComponentes();
         }

         public void renderizarComponentes(){
              pnlCampo1 = new JPanel();
              pnlCampo2 = new JPanel();
              pnlBotao = new JPanel();
              lblCampo1 = new JLabel("Campo1:");
              lblCampo2 = new JLabel("Campo2:");
              txtCampo1 = new JTextField(20);
              txtCampo2 = new JTextField(20);
              botao = new JButton("Funcao");

              pnlCampo1.add(lblCampo1);
              pnlCampo1.add(txtCampo1);

              pnlCampo2.add(lblCampo2);
              pnlCampo2.add(txtCampo2);

              pnlBotao.add(botao);

              botao.addActionListener(new ActionListener(){
                   public void actionPerformed(ActionEvvent e){
                        model.atualizar(txtCampo1.getText(),
                        Integer.parseInt(txtCampo2.getText()));
                   }
              });

              this.setLayout(new GridLayout(3,1));
              this.add(pnlCampo1);
              this.add(pnlCampo2);
              this.add(pnlBotao);

              this.setSize(300,300);
              this.setVisible(true);
         }

         public void update(Observable o, Object arg){
              this.setVisible(false);
         }
    }

    A classe Controller implementa Observer, ou seja, ela será notificada quando houver qualquer mudança. A classe View (Observable) tem em seu método update() a exibição dos dados populados na classe View, sendo este método invocado quando o estado da Observable for modificado.

    Código da Classe Controller:

    import java.util.Observable;
    import java.util.Observer;

    public class Controller implements Observer{
         private Model model;
         private View view;

         public static void main(String[] args){
              new Controller();
         }

         public Controller(){
              model = new Model();
              view = new View("Camada Visão", model);
              model.addObserver(this);
              model.addObserver(view);
         }

         public void update(Observable o, Object arg){
              System.out.println("O modelo contém os seguintes dados:");
              System.out.println("Campo 1:"+ model.getCampo1());
              System.out.println("Campo 2:"+ model.getCampo2());
         }
    }

    Modularização

    O uso de uma técnica de refinamentos sucessivos nos possibilita, já nas etapas iniciais do desenvolvimento de uma solução para um problema computacional, certas abstrações sobre as tarefas a serem executadas no algoritmo. Estas abstrações são definidas apenas pelo seu efeito e constituem uma definição funcional da tarefa. Nas etapas posteriores, cada descrição funcional é substituída por trechos mais elaborados que especificam as etapas do processo: os módulos.

    Identificado também por Programação top-down, temos nessa técnica uma estratégia que busca a solução de um problema a partir "do todo" observando em seguida as "particularidades" necessárias à resolução.

    Quando desenvolvemos um algoritmo por refinamentos sucessivos procuramos dividir o algoritmo em unidades que representam as tarefas mais elementares, que se possa detectar e, para compor a solução do problema.

    Um algoritmo projetado dessa forma será composto de módulos, que representam grupos de comandos que executam uma tarefa específica: no corpo do algoritmo ou espalhados em módulos independentes.

    Vejamos um exemplo com a solução do problema em pseudocódigo e depois sua tradução para Linguagem C.

    Problema: "elaborar um programa para cálculo da Folha de Pagamento de uma Empresa"

    Solução:
    1ª etapa: um algoritmo simples seria 

    PROGRAMA Folha
         LEIA "dados do funcionário"
         Determine o Salário
         ESCREVA "Salário Calculado"
    FIM

    Precisamos refinar o comando "Determine o Salário", resultando:

    PROGRAMA Determine o salário
         Calcule os proventos
         Calcule as deduções
         Calcule o Salário Líquido
    FIM

    Ao elaborar o refinamento não houve preocupação de como o processo de cálculo dos proventos e das deduções seria efetuado. Essas ações constituem funções bem definidas no programa e serão executadas por módulos específicos. Nessa fase podemos optar pelo desenvolvimento de módulos para o cálculo dos proventos e das deduções. Obtemos:

    PROGRAMA Determine o salário
         proventos
         deduções
         Calcule o Salário Líquido
    FIM

    Correspondendo aos módulos:

    PROGRAMA proventos
         Determina o Salário Bruto
    FIM

    PROGRAMA deduções
         Determina as deduções salariais
    FIM

    Vejamos como ficam esses módulos sabendo que:
    - o cálculo dos proventos junta o salário bruto (horas trabalhadas * salário-hora) com o salário família
    - as deduções representam os descontos de INSS e IRPF a partir dos cálculos:
         - desconto INSS = salário bruto * alíquota
         - desconto IRPF = (salário bruto - desconto INSS) * alíquota - desconto tabela IRPF
         - tabelas com alíquotas e descontos baseados nas faixas de salário:

     

    PROGRAMA proventos
         Salário Bruto horas trabalhadas * salário-hora
         Salário Família número de filhos * valor referência de salário família
         Proventos Salário Bruto + Salário Família
    FIM

    PROGRAMA deduções
         INSS Salário Bruto * alíquota INSS
         IRPF (Salário Bruto - INSS) * alíquota IRPF - desconto_IRPF
         Deduções INSS + IRPF
    FIM

    detalhando os cálculos de alíquotas e descontos;

    PROGRAMA alíquota INSS
         SE Salário Bruto <= 1000
              ENTÃO Alíquota 8%
              SENÃO SE Salário Bruto <= 2500
                   ENTÃO Alíquota 10%
                   SENÃO Alíquota 12%
    FIM

    PROGRAMA alíquota IRPF
         SE (Salário Bruto - INSS) <= 1000
              ENTÃO Alíquota 0%
              SENÃO SE (Salário Bruto - INSS) <= 2500
                   ENTÃO Alíquota 15%
                   SENÃO Alíquota 27%
    FIM

    PROGRAMA
    desconto_IRPF
         SE (Salário Bruto - INSS) <= 1000
              ENTÃO Desconto 0
              SENÃO SE (Salário Bruto - INSS) <= 2500
                   ENTÃO Desconto 100
                   SENÃO Desconto 300
    FIM

    Assim, completamos nosso desenvolvimento obtendo:
         - módulos para cálculo de alíquotas e descontos;
         - módulos para cálculo de proventos e deduções.

    PROGRAMA Determine o salário
         proventos
         deduções
         Salário Líquido Proventos - Deduções
    FIM

    PROGRAMA Folha
         LEIA "dados do funcionário"
         Determine o Salário
         ESCREVA "Salário Calculado"
    FIM

    Acoplamento

    O Acoplamento mede o grau de interdependência entre os módulos do diagrama. O que se deseja são módulos de baixo acoplamento para diminuir o máximo possível o efeito em cadeia quando um módulo for alterado.

    Os tipos de acoplamento são:
    - dados;
    - imagem;
    - controle;
    - comum;
    - conteúdo.

    Acoplamento de dados

    Corresponde à comunicação de dados necessária entre módulos. Uma vez que os módulos tem que se comunicar, a ligação de dados é inevitável, e não é crítica desde que mantidas as taxas mínimas.

    Deve-se tomar cuidado com o chamado dado migrante (um grupo de informações que vaga pelo sistema), indesejável e sem sentido para a maioria dos módulos pelos quais passa.

    A figura a seguir ilustra um acoplamento de dados.
    Exemplo de Acoplamento de Dados

    Acoplamento de imagem

    Dois módulos apresentam acoplamento por imagem se eles fazem referência a uma mesma estrutura de dados. Este tipo de acoplamento tende a fornecer mais dados do que o necessário a um módulo.

    A figura a seguir ilustra um exemplo de acoplamento por imagem.
    Exemplo de Acoplamento de Imagem

    Acoplamento de controle

    Dois módulos são acoplados por controle se um passa um grupo de dados (controle) para o outro para controlar sua lógica interna.

    A figura a seguir ilustra um acoplamento de controle.
    Exemplo de Acoplamento de Controle

    No primeiro exemplo, o acoplamento não é tão crítico uma vez que o controle indica uma validação, porém o segundo exemplo exige que o módulo que enviou o controle (validar pedido) conheça o outro módulo.

    Acoplamento comum

    Dois módulos possuem acoplamento comum quando fazem referência a uma área global de dados (ex. Working Storage Section da linguagem Cobol).

    A figura a seguir apresenta um exemplo de acoplamento comum.
    Exemplo de Acoplamento Comum

    Este tipo de acoplamento não é desejável pois:
    - um erro em uma área global pode se propagar por diversos módulos;
    - programas com muitos dados globais são de difícil entendimento;
    - fica difícil descobrir que módulos devem ser alterados quando um dado é modificado.

    Acoplamento de conteúdo

    Dois módulos apresentam acoplamento de conteúdo (ou patológico) se um faz referência ou desvia a sequência de instruções para o interior de um outro módulo (GO TO). Tal acoplamento torna o conceito de caixas-pretas sem sentido.

    A figura a seguir ilustra um exemplo de acoplamento de conteúdo.
    Exemplo de Acoplamento de Conteúdo

    Comparação dos tipos de acoplamento

    Os tipos de acoplamento especificados abaixo são apresentados em ordem descrescente (do melhor para o pior tipo):
    1º. dados;
    2º. imagem;
    3º. controle;
    4º. comum;
    5º. conteúdo.

    Coesão

    Coesão mede a intensidade da associação funcional dos elementos de um módulo. Deseja-se módulos altamente coesos, cujos elementos são relacionados um com os outros.

    Por outro lado, os elementos de um módulo não devem ser fortemente relacionados com os elementos de outros módulos, pois isto levaria a um forte acoplamento entre eles. Ter certeza de que todos os módulos tem boa coesão é a melhor forma de minimizar o acoplamento.

    Os tipos de Coesão são:
    - funcional;
    - sequencial;
    - comunicacional;
    - procedural;
    - temporal;
    - lógica;
    - coincidental.
    Coesão Funcional

    Um módulo apresenta Coesão Funcional quando suas funções internas contribuem para a execução de uma e apenas uma tarefa relacionada ao problema.
    A figura a seguir ilustra módulos com Coesão Funcional.
    Exemplo de Coesão Funcional

    Coesão Sequencial
    Um módulo apresenta Coesão Sequencial quando suas funções internas estão envolvidas em atividades de tal forma, que os dados de saída de uma atividade sirvam como dados de entrada para a próxima.

    Este fluxo estabelece uma sequência de execução das funções, no entanto, não se pode caracterizar o conjunto delas como uma única tarefa.

    A figura a seguir ilustra um módulo com Coesão Sequencial. No exemplo, verifica-se que Exibir Consulta executa duas atividades bem distintas e que poderiam ser representadas pelos módulos:
    - obter registro;
    - exibir dados.
    Exemplo de Coesão Sequencial

    Um módulo com Coesão Sequencial caracteriza-se por ser de fácil manutenção porém de baixa reutilização, pois contém atividades que são utilizadas juntas.
    Coesão Comunicacional

    Um módulo possui Coesão Comunicacional quando suas funções internas estão relacionadas por utilizarem as mesmas informações, ou seja, utilizam a mesma entrada ou mesma saída. Nesta situação o módulo fornece mais informações que o necessário.

    A figura a seguir ilustra um módulo com Coesão Comunicacional. No exemplo Obter Detalhes Cliente recebe um mesmo parâmetro de entrada Num-Conta e executa duas atividades distintas que poderiam ser representadas pelos módulos:
    - obter nome cliente;
    - obter resultado empréstimo.
    Exemplo de Coesão Comunicacional

    Módulos com Coesão Comunicacional e Sequencial são semelhantes, pois ambos contém atividades organizadas em torno dos dados do problema original.

    A principal diferença entre eles é que um módulo sequencialmente coeso opera como uma linha de montagem onde suas atividades são executadas em uma ordem específica. Já em um módulo com coesão comunicacional a ordem de execução não é importante.

    Coesão Procedural

    Um módulo possui Coesão Procedural quando suas funções internas executam atividades diferentes e não correlacionadas, exceto por serem executadas em uma mesma ordem, nas quais o controle flui (e não os dados) de uma atividade para outra.

    É comum em um módulo com Coesão Procedural que os dados de entrada e saída tenham pouca relação. É típico também que tais módulos devolvam resultados parciais, tais como: flags, chaves, etc.
    A figura a seguir ilustra o módulo Tratar Saque isolado (parte esquerda da figura) com Coesão Procedural, e sua fatoração para módulos funcionalmente coesos na parte mais a direita da figura.
    Exemplo de Coesão Procedural

    Coesão Temporal

    Um módulo possui Coesão Temporal quando suas funções internas executam atividades que estão relacionadas apenas com o tempo (as atividades não estão relacionadas entre si). A ordem de execução de atividades é mais importante em módulos procedurais do que em módulos temporais.

    A figura a seguir ilustra um módulo com Coesão Temporal.
    Exemplo de Coesão Temporal

    Coesão Lógica

    Um módulo possui Coesão Lógica quando suas funções internas contribuem para atividades da mesma categoria geral, onde a atividade é selecionada fora do módulo.

    Desta forma, módulos logicamente coesos apresentam uma interface descaracterizada.

    A figura a seguir ilustra um módulo com Coesão Lógica.
    Exemplo de Coesão Lógica
    Coesão Coincidental

    Um módulo possui Coesão Coincidental quando suas funções não possuem nenhuma correlação entre si, não há uma ordem específica de execução, nem sempre todas as funções são ativadas e a ativação das funções é decidida fora do módulo.
    A figura a seguir ilustra uma Coesão Coincidental.
    Exemplo de Coesão Coincidental

    Determinação do Tipo de Coesão

    A figura a seguir mostra uma estratégia para identificar o tipo de Coesão de um determinado módulo.
    Estratégia para identificação dos tipos de Coesão
    Comparando os tipos de Coesão, podemos classificá-los em ordem, como descrito abaixo (do melhor para o pior tipo):
    1º. funcional;
    2º. sequencial;
    3º. comunicacional;
    4º. procedural;
    5º. temporal;
    6º. lógica;
    7º. coincidental.