Capítulo 8
n
Conceitos de Desenho
Slide Set to accompany
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman
Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman
For non-profit educational use only
May be reproduced ONLY for student use at the university level when used in conjunction
with
Software Engineering: A Practitioner's Approach, 7/e.
Any other reproduction or use is
prohibited without the express written permission of the author.
Desenho
n
Mitch Kapor, o criador do Lotus 1-2-3,
apresentou um “manifesto do desenho do
software” no
Dr. Dobbs Journal.
Ele diz:
n
O bom desenho de software deve apresentar:
n
Firmeza:
Um programa não deve ter qualquer bug
que inibe sua função.
n
Comodidade:
Um programa deve ser adequado para
os propósitos para os quais ele foi pretendido.
n
Encanto:
A experiência de uso do programa deve ser
Desenho e Qualidade
n
o desenho precisa implementar todos os
requisitos explícitos contidos no modelo de
análise, e precisa acomodar todos os
requisitos implícitos desejados pelo cliente.
n
o desenho precisa ser um guia legível,
compreensível para quem for gerar Código e e
para aqueles que testam o software.
n
o desenho precisa fornecer uma fotografia
Diretrizes de Qualidade
n
Um desenho deve exibir uma arquitetura que (1) tenha sido criada utilizando
estilos ou padrões arquiteturais reconhecíveis, (2) é composta de componentes
que apresentem boas características e (3) pode ser implementada de forma
evolutiva
n Para sistemas pequenos, desenho pode algumas vezes ser desenvolvido linearmente.
n
Um desenho deve ser modular, ou seja, o software deve ser logicamente
particionada em elementos ou subsistemas.
n
Um desenho deve conter representações distintas de dados, arquitetura,
interfaces e componentes.
n
Um desenho deve levar a estruturas de dados que são apropriadas para as
classes que serão implementadas e se baseiam em padrões de dados
reconhecidos.
n
Um desenho deve levar a componentes que apresentem características de
independência functional.
n
Um desenho deve levar a interfaces que reduzam a complexidade de
conexões entre componentes e com o ambiente externo.
n
Um desenho deve ser derivado por um método iterativo que é dirigido por
informações obtidas durante a análise de requisitos.
n
Um desenho deve ser representado utilizando uma notação que transmita
Princípios de Desenho
n
O processo de desenho não deve sofrer da “visão de túnel”.
n
O desenho deve ser rastreável a partir do modelo de análise.
n
O desenho não deve reinventar a roda.
n
O desenho deve “minimizar a distância intelectual” [DAV95] entre o
software e o problema que existe no mundo real.
n
O desenho deve apresentar uniformidade e integração.
n
O desenho deve ser estruturado para acomodar mudanças.
n
O desenho deve ser estrutuados para degradar pouco, mesmo quando
dados, eventos ou condições de operação anormais são encontrados.
n
Desenho não é implementação, implementação não é desenho.
n
O desenho deve ser avaliado quanto a qualidade à medida que está
sendo criado e, não após ser criado.
n
O desenho deve ser revisado para minimizar erros conceituais.
Conceitos Fundamentais
n
Abstração—dados, procedimentos e controle
n
Arquitetura—a estrutura geral do software
n
Padrões— “transmitem a essência” de uma solução aprovada de
desenho
n
Separação de interesses — qualquer problema complexo pode ser
melhor manipulado se ele é subdividido em pedaços
n
Modularidade—compartimentalização de dados e funções
n
Ocultamento—interfaces controladas
n
Independência funcional—função com papel específico e baixo
acoplamento
n
Refinamento—elaboração de detalhes para todas abstrações
n
Aspectos—um mecanismo para entender como requisitos globais
afetam o desenho
n
Refatoração—uma técnica de reorganização que simplifica o desenho
n
Conceitos de desenho OO —Apêndice II
n
Classes de desenho—apresentam detalhes para o desenho que irão
Abstração de Dados
door
implemented as a data structure
manufacturer
model number
type
swing direction
inserts
lights
type
number
weight
Abstração Procedural
open
implemented with a "knowledge" of the
object that is associated with enter
Arquitetura
“A estrutura global do software e a forma pela qual essa
estrutura fornece integridade conceitual para um
sistema” [SHA95a]
Propriedades estruturais.
Esse aspecto da representação do desenho
arquitetural define os componentes de um sistema (e.g., módulos,
objetos, filtros) e a maneira pela qual estes componentes são
empacotados e interagem uns com os outros. Por exemplo, objetos são
empacotados para encapsular dados e o processo que manipula os dados
e interagem pela chamada de métodos
Propriedades extra funcionais.
A descrição do desenho arquitetural
deve tratar como a arquitetura alcança requisitos para desempenho,
capacidade, confiabilidade, segurança, adaptabilidade e outras
características do sistema.
Famílias de sistemas relacionados.
O desenho arquitetural deve
basear-se em padrões repetíveis que são frequentemente encontrados no
Padrões
Gabarito para Padrões de Projeto
Nome do Padrão—descreve a essência do padrão em um nome curto, porém
significativo
Propósito—descreve o padrão e o que ele faz
Também-conhecido-como—lista quaisquer sinônimos para o padrão
Motivação—fornece um exemplo para o problema
Aplicabilidade—destaca situações específicas de desenho nas quais o padrão se
aplica
Estrutura—descreve as classes que são necessárias para a implementação do padrão
Participantes—descreve as responsabilidades das classes que são necessárias para a
implementação do padrão
Colaborações—descreve como os participantes colaboram para realizar suas
responsabilidades
Consequências—descreve os potenciais compromissos que precisam ser
considerados quando o padrão é implementado
Separação de Interesses
n
Qualquer problema complexo pode ser melhor
tratado se ele for subdividido em partes que
possam ser resolvidas/otimizadas de forma
independente
n
Um
interesse
é uma característica ou
comportamento que é especificado como parte
do modelo de requisitos para o software
n
Pela separação de interesses em partes menores
Modularidade
n
“modularidade é o único atributo do software que
permite
que
um
programa
seja
intelectualmente
gerenciável” [Mye78].
n
Software monolítico (um programa extenso composto de
um
único
modulo)
não
pode
ser
facilmente
compreendido por um engenheiro de software.
n
O número de caminhos de controle, alcance de referências,
número de variáveis e complexidade geral tornariam o
entendimento quase impossível.
Modularidade: Compromissos
Qual é o número de módulos “correto”
para um desenho de software específico?
optimal number
of modules
cost of
software
number of modules
module
integration
Ocultamento de Informação
module
controlled
interface
"secret"
• algorithm
• data structure
• details of external interface
• resource allocation policy
clients
Por que ocultar informações?
n
reduz a probabilidade de “efeitos
colaterais”
n
limita o impacto global de decisões de
desenho locais
n
enfatiza a comunicação através de
interfaces controladas
n
desestimula o uso de dados globais
n
leva ao encapsulamento – um atributo do
desenho de alta qualidade
n
resulta em software de qualidade mais
Refinamentos sucessivos
open
walk to door;
reach for knob;
open door;
walk through;
close door.
repeat until door opens
turn knob clockwise;
if knob doesn't turn, then
take key out;
find correct key;
insert in lock;
endif
Independência Funcional
n
Independência
funcional
é
alcançada
pelo
desenvolvimento de módulos com “papéis únicos” e
uma “aversão” à interação excessiva com outros
módulos.
n
Coesão
é uma indicação da força funcional de um
modulo.
n
Um módulo coesivo realiza uma única tarefa, realizando
pouca interação com outros componentes em outras partes
de um programa. De forma simples, um módulo coesivo
deve (idealmente) fazer uma única coisa.
n
Acoplamento
é uma indicação da interdependência
relativa entre módulos.
n
Acoplamento depende da complexidade de interface entre
Aspectos
n
Considere dois requisitos, A e B. O Requisito A
atravessa (crosscuts) o Requisito B “se, em uma
decomposição de software [refinamento]
escolhida, B não pode ser satisfeito sem levar
em consideração A. [Ros04]
n
Um aspecto
é uma representação de uma
Aspectos—Um Exemplo
n
Considere dois requisitos para a WebApp
SafeHomeAssured.com
. O
Requisito
A
é descrito pelo caso de uso
Access camera surveillance
via the Internet.
Um refinamento de desenho focaria em módulos que
permitissem a usuários registrados acessar o vídeo de camêras
diversas. O Requisito
B
é um requisito genérico de segurança que
estabelece que
um usuário registrado precisa ser validado antes de utilizar
SafeHomeAssured.com.
Este requisito é válido para todas as funções
disponíveis para usuários registrados no
SafeHome
. À medida que o
refinamento do desenho ocorre,
A*
é uma representação de desenho
para o requisito
A
e
B*
é uma representação de desenho para o
requisito
B
. Portanto,
A*
e
B*
são representações de assuntos, e B*
atravessa
A*.
n
Um
aspecto
é uma representação de um conceito transversal. Portanto,a
representação de desenho,
B*
, do requisito
um usuário registrado precisa
ser validado para utilizar
SafeHomeAssured.com,
é um aspecto da
Refatoração
n
Fowler [FOW99] define refatoração da seguinte maneira:
n
”Refatoração é o processo de mudar um software de uma
maneira que isso não altere o comportamento externo do código
[desenho] e ainda melhore sua estrutura externa.”
n
Quando o software é refatorado, o desenho existente é
examinado em busca de
n
redundância
n
elementos de desenho não utilizados
nalgoritmos ineficientes ou desnecessários
n
estruturas de dados mal construídas ou inapropriadas
n
qualquer outra falha de desenho que possa ser corrigida para
Conceitos de Desenho OO
n
Classes de desenho
n
Classes de Entidade
n
Classes de Fronteira
n
Classes Controladoras
n
Herança
—todas responsabilidades de uma superclasse é
herdada por todas subclasses
n
Mensagens
—estimulam que algum comportamento ocorra
no objeto receptor
n
Polimorfismo
—uma característica que reduz drasticamente o
Classes de Desenho
n
Classes de análise são refinadas durante o desenho para se
tornarem classes de entidades
n
Classes de fronteira são desenvolvidas durante o desenho para
criar a interface (e.g., telas ou relatórios impressos) que o
usuário vê e com os quais pode interagir quando o software é
utilizado.
n
Classes de fronteira são desenhadas com a responsabilidade de
gerenciar a maneira como os objetos de entidade são representados
para os usuários.
n
Classes controladoras são desenhadas para gerenciar
n
a criação ou atualização dos objetos de entidade;
n
a instanciação de objetos de fronteira à medida que obtem
informações dos objetos de entidade;
n
comunicação complexa entre conjuntos de objetos;
n
validação de dados comunicados entre objetos ou entre o usuário e
Elementos do Modelo de Desenho
n
Elementos de dados
n
Modelo de dados --> estruturas de dados
n
Modelo de dados --> arquitetura do banco de dados
n
Elementos arquiteturais
n
Domínio da aplicação
n
Classes de análise, suas realizações, colaborações e comportamentos
são transformados em realizações do desenho
n
Padrões e “estilos” (Capítulos 9 e 12)
n
Elementos de interface
n
a interface com o usuário (UI)
n
interfaces externas para outros sistemas, dispositivos, redes ou outros
produtores ou consumidores de informação
n
