Desenho

Desenho de Software
Tem por objetivo definir uma estrutura
Implementável que atenda aos requisitos
especificados.
Aspectos do desenho do produto de software:
• Atendimento dos requisitos não funcionais;
• Detalhes suficientes para a implementação;
• Decomposição do produto em componentes;
• A definição adequada e rigorosa das interfaces
entre os componentes do produto;
• Documentação da decisões de desenho;
• Reutilização de componentes;
 O MODELO DE DESENHO

É a continuação do modelo de análise, geralmente

apresenta mais detalhes.

Veremos uma tabela comparativa

 MODELO DE ANÁLISE MODELO DE DESENHO
Descreve o problema Descreve uma solução
Conceitual Físico
Suporta vários possíveis desenhos Específico em relação a uma implementação
Classes estereotipadas conceituais Classes estereotipadas de acordo com o ambiente
de implementação (formulários, módulos etc.)
Pouco formal e detalhado Muito formal e detalhado
Pouco formal e detalhado Mais pacotes lógicos, organizados em camadas
Criação manual (por exemplo, em oficinas de Criação parcialmente automatizada (usando
análise) engenharia reversa)
Mantido opcionalmente Mantido obrigatoriamente
 DESENHO para a testabilidade
A testabilidade é um objetivo chave no desenho
de software. Os engenheiros de software devem desenhar
os componentes de um produto pensado em como
estes serão testados

Algumas vezes, é necessário alterar o desenho

de módulos de um produto para facilitar os testes.
Pode ser necessário expor operações ou parâmetros
adicionais, que permitam melhor exercitar as funções do
módulos.
 Atividades do desenho arquitetônico
Essas atividades dividem o produto em subsistemas:

 Visão lógica
 Visão desdobramento
 Desenho dos dados persistentes
 Estudo de usabilidade
 Pacotes lógicos de desenho

Na UML, os subsistemas e outros componentes são

representados por pacotes lógicos de desenho.

Estes pacotes lógicos são grupos de classes e outros elementos

de modelagem, que apresentam fortes relacionamentos entre si
(alta coesão interna) e poucos relacionamentos com elementos de
outros pacotes lógicos (baixo acoplamento externo).
 TABELA DE DESCRIÇÃO DE Pacotes lógicos
Pacote lógico Descrição Exemplo de componente
Classes de fronteira Realizam as interfaces de usuário frmFornecedores
da aplicação.
Classes de controle Coordenam as colaborações entre Controle_de_Gestao_de_
as demais classes, que realizam os Fornecedores
casos de uso.

Classes VB Classes integrantes do ambiente de modErrorHandling

desenvolvimento Visual Basic.
Classes de Entidade Classes que representam os Incluem as Coleções e os
elementos do modelo do domínio. Elementos.
Coleções Representam os conjuntos de Fornecedores
dados do domínio.
Elementos Representam as entidades de Fornecedor
dados do domínio, que são os
elementos básicos das coleções.
 Estudo da usabilidade
Para assegurar a qualidade das interfaces de usuário de um produto de
software, é preciso ser capaz de medir a usabilidade deste, ou seja, sua
facilidade de uso.

Propõe as seguintes métricas para a avaliação de sistemas interativos:

 Facilidade de aprendizagem;

 Produtividade dos asuários;

 Taxa de erros;

 Retenção ao longo do tempo;

 Satisfação do usuário;
 Desenho dos dados persistentes
Os objetos persistentes são aqueles que continuam a existir após
a execução dos programas que os criaram ou atualizaram.

Sistemas de gerência de bancos de dados orientados a objetos são a

solução mais direta para a implementação de objetos persistentes,
principalmente aqueles que representam dados mais complexos.

Versões mais recentes de alguns sistemas de gestão de bancos de

dados relacionais têm oferecido extensões de orientação a objetos,
criando-se uma tecnologia híbrida objeto-relacional.
 Detalhamento das classes de desenho
Classes de análise podem ser partidas ou agrupadas, já que
razões tecnológicas ou requisitos não funcionais podem
prevalecer sobre a visão basicamente funcional do modelo de
análise. Novas classes podem ser criadas, para realizar atributos
que não são tipos simples da linguagem de implementação,
para realizar mecanismos de desenho, ou para encapsular
componentes externos ou sistemas legados.

As classes de coleção ajudam a implementar relacionamentos de

multiplicidade maior que um. Outros aspectos dos relacionamentos
precisam ser detalhados para decidir-se quanto à implementação
deles. Os aspectos de visibilidade dos elementos das classes devem
ser resolvidos.
 Adição de classes de coleção
Relacionamentos de 1..n ou 0..n podem ser implementados
através de classes de coleção, que contêm uma estrutura de
dados cujos itens são objetos de mesma classe. A representação
de coleções é dependente do ambiente de desenvolvimento.
Agora é com nosso amigo:

Ronan
Desenho das entidades
Detalhamento dos Relacionamentos
Exemplo de direções de navegação:
 é possível localizar eficientemente a mercadoria correspondente a
um determinado item de mercadoria...
 ...mas a localização dos itens de mercadoria que correspondem a
uma mercadoria exige uma pesquisa.

especifica

-aMercadoria

Mercadoria ItemDeMercadoria

© 2002 Wilson de Pádua Paula Filho

Realização dos casos de uso
Definição do controle de acesso
Tipos de acesso a operações ou dados:
público:
 qualquer outra classe pode usar;
protegido:
 só subclasses desta classe podem usar;
privado:
 nenhuma outra classe pode usar diretamente;
implementação:
 interpretação dependente da linguagem:
 em Java, significa visibilidade padrão (de pacote).

© 2002 Wilson de Pádua Paula Filho

Realização dos casos de uso
Determinar tipo de acesso dos métodos:
resultados de interesse de outras classes:
 devem ser públicos;
resultados de interesse apenas das subclasses:
 devem ser protegidos;
resultados de interesse interno da classe:
 devem ser privados;

© 2002 Wilson de Pádua Paula Filho

Realização dos casos de uso
Determinar tipo de acesso:
atributos devem ser privados;
acesso deve ser feito através de operações específicas:
 consulta e atualização;
possível exceção:
 constantes públicas estáticas;
 usadas para uniformizar denominação de constantes.

© 2002 Wilson de Pádua Paula Filho

Detalhamento dos casos de uso
Detalhamento dos Fluxos dos Casos de Uso

Descrição de casos de uso de desenho:

mecanismos de acesso;
fluxos:
 fluxo principal;
 subfluxos;
 fluxos alternativos;

representações gráficas:
 diagramas de estado;
 diagramas de seqüência (só para detalhar interações ator-
produto);
exceções;
mensagens.

© 2002 Wilson de Pádua Paula Filho

Desenho das liberações
Planejamento da Liberações
Principais áreas de risco:
requisitos funcionais mais importantes;
interfaces de usuário:
 mais complexas ou menos entendidas;
unidades e mecanismos que exercitam novas
tecnologias;
requisitos não-funcionais mais críticos.

© 2002 Wilson de Pádua Paula Filho

Desenho das liberações
Especificações das Liberações
Liberações - versões parciais formadas por:
código novo:
 deverá ser parte do sistema definitivo;
código antigo:
 produzido em liberações anteriores;
unidades de teste:
 Cotos(stubs), controladores(drivers) e base de dados de teste;
implementações simplificadas:
 de algumas das classes mais complexas.

© 2002 Wilson de Pádua Paula Filho

Revisão do desenho
Revisões técnicas da descrição do desenho:
focalizam documentação;
revisão na primeira iteração:
 focaliza documentação de arquitetura e estratégias;
revisão na última iteração:
 focaliza qualidade e completeza da documentação;
 objetivo: manutenibilidade.

© 2002 Wilson de Pádua Paula

Filho
 TÉCNICAS
Visão Geral

Desenho de Interfaces de usuário

Modelos de conhecimento
Visão Geral
• Conhecimento sintático
• Conhecimento semântico de computação
• Conhecimento semântico das tarefas