Padrões de Software
Exemplos
Exemplos
Valéria Lelli
Agenda
Introdução
Requisitos
Padrão de Caso de Uso CRUD
Análise Análise Padrão Party Projeto Padrões GoF Singleton Padrão arquitetural – MVC Implementação Padrão de idiomas Testes
Requisitos
Padrões de Requisitos
Documentam as necessidades do usuário
Documentam as necessidades do usuário e o
comportamento genérico do sistema em um alto nível
comportamento genérico do sistema em um alto nível
de abstração
Englobam a captura de requisitos funcionais e
não-funcionais
Ações que os desenvolvedores de software podem
tomar para melhorar os requisitos não-funcionais
Padrão de Caso de Uso CRUD
[Souza et al., 2005]
Contexto
Este padrão é utilizado para a documentação dos requisitos
de manutenção em sistemas da informação, por meio do uso de modelos e especificações de casos de uso. Os requisitos de de modelos e especificações de casos de uso. Os requisitos de manutenção são caracterizados por operações de Inclusão, Consulta, Alteração e Exclusão
Problema
Como documentar os requisitos funcionais de inserção,
Padrão de Caso de Uso CRUD
[Souza et al., 2005]
Forças
As operações de manutenção podem ocorrer tanto sobre entidades
simples, com poucos atributos, como em entidades complexas, com vários atributos e relacionamentos.
vários atributos e relacionamentos.
As operações de inclusão, alteração, remoção e consulta devem ser
tratadas e seus requisitos documentados. Esses requisitos incluem validação de atributos e regras de negócio.
Os atributos mantidos de cada entidade devem ser documentados. Os requisitos documentados devem ser de fácil entendimento para
os usuários e para a equipe de desenvolvimento.
Padrão de Caso de Uso CRUD
[Souza et al., 2005]
Solução
Organizar o fluxo de eventos do caso de uso em cinco
subfluxos (Fluxo básico, Incluir, Alterar, Remover e Consultar)
O Fluxo básico descreve a condição de início e desvia o fluxo
para um dos sub-fluxos, de acordo com as operações disponíveis: Incluir, Alterar, Excluir e Consultar.
Padrão de Caso de Uso CRUD
[Souza et al., 2005]
Solução
O subfluxo Incluir apresenta os atributos para a inclusão e descreve
o comportamento da inclusão.
O subfluxo Alterar apresenta os atributos atualizáveis, exibe seus
O subfluxo Alterar apresenta os atributos atualizáveis, exibe seus
valores e descreve o comportamento da atualização.
O subfluxo Remover descreve o comportamento da remoção e
documenta as restrições da exclusão da entidade.
O subfluxo Consultar documenta requisitos para localização da
entidade, que atributos devem ser filtros para a consulta, quais são obrigatórios e quais atributos são exibidos no resultado.
Padrão de Caso de Uso CRUD
Padrão de Caso de Uso CRUD
[Souza et al., 2005]
Padrões de Caso de Uso CRUD
Estrutura
Fluxo básico (happy day)
Fluxo básico (happy day)
Subfluxo Incluir <nome da entidade>
Subfluxo Alterar <nome da entidade>
Subfluxo Remover <nome da entidade>
Subfluxo Consultar <nome da entidade>
Padrão de Caso de Uso CRUD
[Souza et al., 2005]
Estrutura
1. Este fluxo inicia quando o <nome do ator> solicita
consultar <nome da entidade>;
2. O sistema solicita o preenchimento dos seguintes filtros:
- <lista de filtros>
3. O <nome do ator> preenche os filtros e solicita a consulta; 4. O sistema apresenta as seguintes informações dos <nome
da entidade> obtidos na consulta: - <lista de atributos>
Análise
Padrões de Análise
Documentam as necessidades do usuário
Inicialmente apresentados como complementos aos
padrões de projeto
É composto, entre outras partes, de um fragmento de diagrama de classes que pode ser customizado para uma situação de modelagem
padrões de projeto
Um passo antes do projeto
Modelo de análise que focaliza nas estruturas
conceituais
Padrões de análise do Martin Fowler
Domínio de conhecimento de software de negócios
Party, quantity, subtype state machines, dentre
Party
Analysis Patterns: Reusable Object Models
[Martin Fowler, 1997]
Problema
Modelar uma agenda de endereços que contém informação
sobre pessoas e organizações.
Motivação
“Observe a sua agenda de endereços: o que vê?
Verá um conjunto de endereços, números de telefone, e
endereços de e-mail … todos ligados a algo. Geralmente esse algo é uma pessoa, embora por vezes também
Party
Analysis Patterns: Reusable Object
Models
[Martin Fowler, 1997]
Contexto
Pessoas e organizações estão presentes em praticamente
todos os sistemas que lidam com o fator humano. A agenda de endereços é apenas um exemplo. Pessoas e organizações de endereços é apenas um exemplo. Pessoas e organizações partilham um comportamento semelhante: acedem a um
conjunto de objectos comuns (e.g., números de telefone, endereços de e-mail) e efetuam operações sobre eles.
Party
Analysis Patterns: Reusable Object
Models
[Martin Fowler, 1997]
Requisitos
Funcionais
Cada Pessoa ou Organização tem um conjunto de:
R1: números de telefone
R1: números de telefone R2: endereços
R3: endereços de e-mail que são superiores ou iguais a
zero
R4: Pessoa e Organização partilham alguns dados
descritivos.
R5: cada Pessoa ou Organização pode obter, adicionar
ou modificar informação sobre outras pessoas ou organizações.
Party
Analysis Patterns: Reusable Object
Models
[Martin Fowler, 1997]
Party
Analysis Patterns: Reusable Object
Models
[Martin Fowler, 1997]
Requisitos
Não-funcionais
R6: Pessoa/Organização tem de ser autorizada
(segurança). (segurança).
R7: Informação tem de ser obtida rapidamente
(performance).
R8: Informação tem de estar correta (precisão).
Resolução de conflitos
Os requisitos não-funcionais de performance (R7) e
segurança (R6) podem entrar em conflito. Este é
solucionado pela atribuição de prioridades aos diferentes requisitos.
Party
Analysis Patterns: Reusable Object
Models
[Martin Fowler, 1997]
Prioridades
--- Alta prioridade --- Baixa prioridade R8 R7 R6 R8 R7 R6Party
Analysis Patterns: Reusable Object
Models
[Martin Fowler, 1997]
Estrutura
Party
Analysis Patterns: Reusable Object
Models
[Martin Fowler, 1997]
Descrição dos objetos
Party
: supertipo que define uma pessoa ou
organização, contendo as funcionalidades comuns a
ambas, de maneira que a associação entre informações
ambas, de maneira que a associação entre informações
fosse relativa às partes e não à pessoa ou organização
diretamente.
Pessoa
e
Organização
contêm dados específicos a cada
uma das entidades que descrevem.
Party
é definida através das relações com as classes
Party
Analysis Patterns: Reusable Object
Models
[Martin Fowler, 1997]
Participantes
Pessoa e Organização
Padrões Relacionados
Role Object
Para adaptar um objeto a diferente necessidades de cliente de forma transparente.
Associando papéis a objetos, um objeto pode ser usado em
contextos diferentes, sendo conhecido, em cada um, por
Role Object
Implementação
Use uma linguagem orientada a objetos para a
implementação deste padrão. Apesar de ser um sistema muito simples, deverá resistir à tentação de implementar numa única classe. Evitar o anti-padrão: The Blob.
Os padrões indicam exatamente o contrário. O foco dos anti-padrões são os erros comuns dos projetistas e as principais falhas
conhecido, em cada um, por um diferente papel.
Projeto
Padrões de Projetos
Definem soluções para problemas de projeto de
software
“Um esquema para o refinamento de subsistemas ou de
“Um esquema para o refinamento de subsistemas ou de
componentes de sistemas ou as relações entre eles.”
“...resolvem um problema geral de projeto num
contexto particular.”, [GoF]
Padrões de projeto que incluem detalhes de código de
baixo nível
Aplicados a diferentes tipos de problemas
Singleton
[Gamma et al., 1995]
Intenção
Garantir que uma classe tenha uma única instância e
um único ponto de acesso a essa instância
Motivação
Motivação
Sistemas podem precisar de classes com uma única
instância
Um único valor de precisão Um único sistema de arquivos
Uma aplicação que precisa de uma infra-estrutura de log de
dados, pode-se implementar uma classe no padrão singleton. Dessa forma, existe apenas um objeto responsável pelo log em
Singleton
[Gamma et al., 1995]
Use um Singleton quando:
É preciso que exista apenas uma instância de uma
classe e essa instância deve ser acessada através de um
único ponto bem conhecido
único ponto bem conhecido
Quando essa classe possa ser estendida através de
derivação e que os seus clientes possam usar a
instância estendida sem modificar seu código
Singleton
[Gamma et al., 1995]
Estrutura
Exemplo: Seu sistema pode ter apenas um gerenciador de janelas,
ou gerenciador de impressão, ou então um
único ponto de acesso ao banco de dados.
Acesso controlado à instância única
Evita poluição do espaço de nomes com variáveis globais
Padrão Arquitetural – Model View
Controller (MVC)
[Buschmann et al.,1996]
Objetivos
Separa uma aplicação interativa em três componentes:
Modelo, Visão e Controlador.
O Modelo contém as funcionalidades básicas (lógica de O Modelo contém as funcionalidades básicas (lógica de
negócios) e os dados
A Visão exibe a informações para o usuário O Controlador manipula a entrada do usuário
A idéia é permitir que uma mesma lógica de negócios possa
ser acessada e visualizada através de várias interfaces.
Na arquitetura MVC, a lógica de negócios (chamaremos de
Modelo) não sabe de quantas e nem quais as interfaces com o usuário estão exibindo seu estado.
Padrão Arquitetural – Model View
Controller (MVC)
[Buschmann et al.,1996]
Padrão Arquitetural – Model View
Controller (MVC)
[Buschmann et al.,1996]
Problema
Interfaces com o usuário são sensíveis a mudanças:
Estender uma funcionalidade de uma aplicação pode
modificar menus para acessar essas novas funções e modificar menus para acessar essas novas funções e
requer uma adaptação na interface que pode implicar em mudanças no código.
A aplicação pode ter que ser implementada em outra
plataforma com diferente look and feel.
O usuário está sempre querendo mudar funcionalidades
e a interface das aplicações. Se o sistema não suporta estas mudanças, temos um grande problema!
Padrão Arquitetural – Model View
Controller (MVC)
[Buschmann et al.,1996]
Problema
A mesma aplicação possui diferentes requisitos
dependendo do usuário:
Um digitador prefere uma interface onde tudo pode ser feito
através do teclado e visualizado como texto.
Um digitador prefere uma interface onde tudo pode ser feito através do teclado e visualizado como texto.
Um gerente prefere uma interface através do mouse e de
menus com visualização gráfica
Nesse contexto, se o código para a interface gráfica é
muito acoplado ao código da aplicação, o
desenvolvimento pode se tornar muito caro e difícil.
Quantas interfaces possíveis existem para a lógica de
Padrão Arquitetural – Model View
Controller (MVC)
[Buschmann et al.,1996]
Solução
O MVC separa a modelagem do domínio, a apresentação e as
ações com base na entrada do usuário em três classes distintas:
Modelo: gerencia o comportamento e os dados do
Modelo: gerencia o comportamento e os dados do
domínio da aplicação, responde aos pedidos de
informações sobre seu estado (geralmente da visão), e responde às instruções para mudança de estado
(geralmente do controlador).
Visão: a visão gerencia a exibição de informações e
obtém os dados do Modelo.
Controlador: o controlador interpreta as entradas de
Padrão Arquitetural – Model View
Controller (MVC)
[Buschmann et al.,1996]
É importante notar que tanto a visão e o controlador dependem do
Padrão Arquitetural – Model View
Controller (MVC)
[Buschmann et al.,1996]
Benefícios
Suporta várias visões
Porque a visão é separada do modelo e não há nenhuma
dependência direta do modelo para a visão. dependência direta do modelo para a visão.
A interface do usuário pode exibir múltiplas visualizações
dos mesmos dados ao mesmo tempo.
Por exemplo, várias páginas em uma aplicação Web pode
usar os objetos do mesmo modelo.
Uma aplicação Web que permite ao usuário mudar a
aparência das páginas. Essas páginas exibem os mesmos dados do modelo compartilhado, mas mostram de uma maneira diferente.
Padrão Arquitetural – Model View
Controller (MVC)
[Buschmann et al.,1996]
Benefícios
Acomoda mudanças
Requisitos de interface do usuário tendem a mudar
mais rapidamente do que regras de negócio.
mais rapidamente do que regras de negócio.
Usuários podem preferir diferentes cores, fontes,
layouts
de tela e níveis de suporte para novos
dispositivos, como telefones celulares ou PDAs.
Como o modelo não depende de visões,
adicionando novos tipos de visão para o sistema
geralmente não afetam o modelo.
Implementação
Padrões de Idiomas
Relacionados com a implementação de características
de projeto específicas
Padrão de baixo nível específico para uma linguagem de
programação
Um idioma descreve como implementar aspectos
particulares de componentes ou os relacionamentos
entre eles usando as características da linguagem.
Idiomas em C++ [C++ Programming Styles and
Implementação
Padrões de Idiomas
Formam uma base para a padronização da
nomenclatura e da estrutura do código fonte.
Agem como diretrizes de projeto ou, ainda, como
Idioma de Pree
[Pree, 1995]
Pree apresenta uma outra abordagem que se refere a
convenções de nomes a serem dados a variáveis, constantes e
métodos.
O trabalho de Pree é baseado nas convenções descritas no
O trabalho de Pree é baseado nas convenções descritas no
framework ET++.
A utilização de convenções de nomenclatura em
frameworks é importante, pois facilita o aprendizado e
utilização do mesmo.
Idioma de Pree
[Pree, 1995]
Nomes de classes e de métodos: devem iniciar
com letras maiúsculas seguidos de letras minúsculas.
Variáveis locais devem iniciar com letras minúsculas.
Se um nome consiste de várias palavras, a segunda e as
Se um nome consiste de várias palavras, a segunda e as
palavras subsequentes iniciam com letras maiúsculas, como
por exemplo
DoLeftButtonDownCommand(...).
Variáveis globais: devem iniciar com o prefixo g, como:
Idioma de Pree
[Pree, 1995]
Constantes: devem iniciar com o prefixo c, tais como:
cldNone.
Métodos: quando definem o valor de uma variável instanciada
devem iniciar com Set
devem iniciar com Set
SetSaldo(..).
Métodos que retornam tais valores devem iniciar com Get
GetOrigin(...).
Métodos que desenham objetos na tela devem iniciar com Gr
Testes
Padrões de Testes
São orientações para as atividades de teste, incluindo
documentação, execução e divulgação de resultados
documentação, execução e divulgação de resultados
[Rising 2000].
Os padrões de testes auxiliam a equipe de testes com
um vocabulário comum e útil, apresentando soluções
para problemas que ocorrem repetidamente quando se
testa o software.
Padrões de Testes
[Lange, 2001]
Apresenta quatro padrões de testes para melhorar os testes
funcionais
Se encaixam perfeitamente na metodologia XP (Extreme Se encaixam perfeitamente na metodologia XP (Extreme
Programming), onde os casos de testes constroem um elemento central da metodologia
Separate Test Interface Error Simulator
Call Stack Tracer
Separate Test Interface
Mostra como empregar uma interface de teste separada
para o teste proposto. Com o uso dessa interface é possível testar classes internas de componentes sem mudar as
Padrões de Testes
testar classes internas de componentes sem mudar as
interfaces oficiais dos componentes, ela permite inspecionar automaticamente estados internos ou desempenhar testes para classes somente visíveis dentro do componente do software.
Padrões de Testes
Test Case with Time Specification
As especificações funcionais ou características são escritas como
casos de testes. Uma completa automatização do caso de teste é um pedaço de código executado, quando um caso de teste termina é pedaço de código executado, quando um caso de teste termina é verificado se os resultados das operações levaram a um resultado correto. A corretude funcional do caso de teste é checada através do seu tempo de execução, verificando se ele está dentro da
especificação.
Repositório de padrões de testes via web [Marick]
Padrões do PoST (Patterns of Software Testing)
Padrões de testes específicos para linguagem de programação
Referências
Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M. (1996).
Pattern-Oriented Software Architecture, John Wiley and Sons, New York, NY, 1996.
Gamma E., Helm R., Johnson R., Vlissides J. (1995). “Design Patterns: Element of
Reusable Object-Oriented Software”, 1995.
Lange, M. (2001). It’s Testing Time! - Patterns for Testing Software. In: Proceedings
of XI European Conference on Pattern Languages of Programs (EUROPLOP 2001), Bard Irsee, Germany, 2001.
of XI European Conference on Pattern Languages of Programs (EUROPLOP 2001), Bard Irsee, Germany, 2001.
Martin Fowler (1997). Analysis Patterns: Reusable Object Models.
Addison-Wesley,1997.
Marick, B. Software Testing Patterns. Disponível em:
<http://www.exampler.com/testing-com/test-patterns/ >. Acesso em: 29 out. 2010.
PREE, W.(1995). Design Patterns for Object-Oriented Software Development.
Addison- Wesley Publishing Company, ACM Press, 1995.
SOUZA, Gabriela, Pires, Carlo Giovano, Marinho, Fabiana e Belchior, Arnaldo Dias
(2005). Padrões de Requisitos para Especificação de Casos de Uso em Sistemas de Informação. 5th Latin American Conference on Pattern Languages of Programming SugarLoafPloP.
