Você está na página 1de 24

Engenharia de Software

Desenho de Software

Departamento de Matemática Hélia Guerra


Universidade dos Açores helia@uac.pt

desenho

• Desenho (dicionário Priberam on-line)

do Lat.! designu

s. m.,

arte de representar os objectos por meio de linhas e sombras;

delineamento ou traçado geral de um quadro;

plano;

projecto;

arte de desenhar;

acto de desenhar;
2
desenho

• Desenho é o processo criativo de transformar o


problema numa solução

• A descrição da solução também é designada desenho

–A especificação dos requisitos define o problema

–A documentação do desenho especifica uma solução


particular para o problema

desenho conceptual e
desenho técnico
• O desenho é um processo iterativo feito em duas partes
– Desenho conceptual (desenho do sistema)

– Desenho técnico

4
desenho conceptual

• Indica ao cliente o que o sistema irá fazer

–a origem dos dados

–o que acontece aos dados no sistema

–o aspecto do sistema para os utilizadores

–as escolhas oferecidas aos utilizadores

–a duração dos eventos

–o aspecto dos relatórios e dos ecrãs


5

desenho conceptual

• Características de um bom desenho conceptual

–linguagem do cliente

–sem termos técnicos

–descreve as funções do sistema

–independente da implementação

–com ligações aos requisitos

6
desenho conceptual

desenho técnico

• Indica aos programadores o que o sistema fará

–as componentes de hardware e as suas funções

–a hierarquia e as funções das componentes de


software

–as estruturas de dados

– o fluxo de dados

8
decomposição
• Descrição dos dados do sistema

• Descrições funcionais de alto nível

• Criação de hierarquia da informação

modularidade

• Módulos ou componentes: partes que compõe o


desenho

• Sistema modular

–cada actividade é executada por uma componente

–inputs e outputs de cada actividade estão bem


definidos

• todos os inputs são essenciais para a função

• cada output resulta de alguma das suas acções


10
formas de criar desenhos

• Decomposição modular

• Decomposição orientada aos dados

• Decomposição orientada aos eventos

• Desenho “Outside-in”

• Desenho orientado aos objectos

11

níveis de desenho

• Arquitectura: associa as capacidades do sistema


identificadas nos requisitos às componentes do sistema
que as vão implementar

• Desenho do código: especifica os algoritmos e


estrutura de dados para cada componente

• Desenho executável: desenho de baixo nível que


inclui a atribuição de memória, o formato dos dados

12
Estilos de desenho

• Pipes e filtros

• Desenho orientado aos objectos

• Camadas

• Repositórios

• Cliente-servidor

• ...

13

Pipes e filtros

• Streams de dados (pipes) para I/O

• Filtros que transformam os dados

14
Pipes e filtros

• Propriedades importantes

–O designer entende o efeito do input/output no


sistema como a composição de filtros

–Os filtros podem ser facilmente reutilizados em


outros sistemas

–A evolução do sistema é simples

–pode-se ter filtros concorrentes


15

Desenho orientado aos


objectos
• Características

–cada objecto tem que preservar a integridade da


representação dos dados

–a representação tem que estar escondidada dos


outros objectos

• facilita as alterações sem causar perturbações no


resto do sistema

• Cada objecto tem que conhecer a identidade dos


restantes para poder comunicar com eles
16
camadas

• As camadas são hierárquicas


– cada camada fornece serviços à camada exterior e é cliente da
camada interior

• O desenho inclui protocolos que explicam como é que


cada par de camadas irá comunicar
• Vantagens
– Nível elevado de abstracção
– É relativamente fácil acrescentar ou modificar uma camada
• Desvantagens
– Nem sempre é fácil estruturar um sistema em camadas
– O desempenho do sistema pode ser prejudicado pela
coordenação (extra) entre as camadas
17

camadas

• sistema de segurança

18
repositórios

• Componentes

–Armazém de dados centralizado

–Uma coleccção de componentes que operam sobre os


dados (guardar, obter, actualizar)

• O desafio é decidir como é que as componentes


interactuam
–base de dados tradicional
–blackboard
19

repositórios
• Vantagem: abertura
– A representação dos dados está disponível para os programadores que podem
desenvolver ferramentas para aceder ao repositório
• Desvantagem: o formato dos dados tem que ser aceite por todas as
componentes

20
cliente - servidor

• Sistemas distribuídos

–Vantagem: utilizadores obtem a informação que


necessitam apenas quando precisam

–Desvantagem: necessita de maior segurança e gestão


dos sistema; desenvolvimento de aplicações mais
sofisticado

• Arquitectura específica do domínio de aplicação

• Arquitecturas heterogénias que combinam diferentes


estilos
21

cliente - servidor

• Sistemas distribuídos são descritos em termos da


topologia da sua configuração (anel, estrela)

22
Aspectos a ter em conta no
desenho

• Modularidade e níveis de abstracção

• Desenho colaborativo

• Desenho da interface com o utilizador

• Concorrência

• Desenho de padrões e reutilização


23

Modularidade e
abstracção

• Níveis de abstracção: uma componente de um nível


refina as que estão no nível abaixo, à medida que se
desce na hierarquia, encontra-se componentes com
mais detalhes

• Encapsulamento da informação

• Modularidade fornece flexibilidade


–para perceber o sistema
–para traçar o fluxo de dados

24
abstracção
Ordenar L por ordem crescente
DO WHILE I is between 1 and (length of L)-1:
Set LOW to index of smallest value in L(I), ..., L(length of L)

Interchange L(I) and L(LOW)


END DO

25

desenho colaborativo
• Muitos projectos constituem trabalho colaborativo

• Aspectos a considerar no desenho colaborativo


–Quem é que mais se adequa a desenhar determinado
aspecto do desenho
–Como documentar o desenho
–Como coordenar o desenho das componentes

• Problemas na execução do desenho colaborativo


–Diferenças na experiências pessoais, no entendimento
e nas preferencias
–Por vezes o comportamento em grupo das pessoas é
diferente do comportamento
26 individual
desenho da interface com
o utilizador
• Elementos a ter em conta
–Metáforas: termos, imagens, conceitos que podem
ser reconhecidos e aprendido
–Modelo mental de organização e representação dos
dados, das funções, das actividades
–Regras de navegação para o modelo
–Aspecto: características da aparência do sistema que
transmite informação ao utilizador
–A intuição: técnicas de interacção com o utilizador
–Aspectos culturais
–Preferencias culturais
27

concorrência

• Problemas
– Consistencia dos dados partilhados pela componentes ao
mesmo tempo
– Garantir que uma acção não interfere noutra
• Soluções
– Sincronização: método que permite que duas actividades
sejam executadas de forma concorrente sem que uma interfira
com a outra
– Exclusão mútua: quando um processo acede aos dados, os
restantes elementos não podem alterar os dados
– Monitor: objecto abstracto que controla a exclusão mútua de
um processo
28
padrão de desenho

• Um padrão de desenho identifica, abstrai e nomeia os


aspectos essenciais de uma estrutura comum,
tornando-a útil para ser reutilizada num desenho

29

características de um
bom desenho

• Componentes independentes

–ligação

–coesão

• Identificação e suporte de excepções

• Prevenção e tolerância a faltas

–activa

–passiva
30
ligação
• Dois componentes dizem-se fortemente ligados sse existe entre eles
uma grande dependência
• Dois componentes dizem-se fracamente ligados sse existe entre eles
uma fraca dependência
• Dois componentes dizem-se desligados sse não existe entre eles
qualquer dependência

31

ligação
• A ligação entre componentes depende de
– referências entre componentes
– dados passados entre componentes
– controlo entre componentes
– grau de complexidade da interface
• A ligação pode ser medida num intervalo de dependências

32
tipos de ligação

• Ligação de conteúdo (content coupling)

• Ligação de partilha (common coupling)

• Ligação de controlo (Control coupling)

• Ligação de estrutura (Stamp coupling)

• Ligação de dados (Data coupling)

33

ligação de conteúdo

• Ocorre quando um componente conhece a estrutura


interna de outro
• qualquer alteração interna pode ter reprecursões nos
restantes componentes

34
ligação de partilha

• Ocorre quando vários componentes partilham o mesmo


conjunto de dados
• Surgem problemas quando um componente altera dados
comuns a outros componentes

35

ligação de controlo

• Ocorre quando um componente passa parâmetros que


controlam a actividade de outro componente

• O componente controlado não pode funcionar


independentemente do componente controlador

36
ligação de estrutura

• Ocorre quando um componente passa uma estrutura de


dados a outro componente

• Os valores, a formatação e a organização dos dados gera


uma dependência entre os componentes

37

ligação de dados

• Ocorre quando um componente apenas passa dados de


tipo simples a outro componente

• É uma ligação simples que deixa pouca margem para erros

38
Coesão
• Um componente é coeso sse todos os seus elementos estão
directamente envolvidos na satisfação dos objectivos do componente

• Há diversos tipos de coesão

39

coesão

40
identificação e suporte de
excepções
• Excepção: situação conhecida que vai contra o que se
pretende que o sistema faça
–falha no fornecimento de um serviço
–fornecimento incorrecto de serviço ou dados
–dados corrompidos
• As excepções podem ser suportadas de três formas
diferentes
–retry
–correct
–report
41

prevenção e tolerância a
faltas
• Detecção activa de faltas: procura sistemática de
sintomas de faltas, antecipação da ocorrência de falhas
– Mutual suspicous
– n-version programming
– Diagnostic transaction

• Detecção passiva de faltas: espera-se ver as faltas


durante a execução do sistema
• Correcção de faltas: compensação do sistema na
presença de faltas
• Tolerância a faltas: isolamento de um dano causado
por uma falta 42
avaliação e validação do
desenho - revisão do desenho

• Revisão preliminar do desenho conceptual com o


cliente e utilizadores

• Revisão crítica do desenho técnico com a equipa de


desenvolvimento

• Revisão do desenho do programa com os


programadores, antes da implementação

43

revisão do desenho
• É solução do problema?
• É modular, bem estruturado e fácil de entender?
• Pode-se melhorar a estrutura e a percepção?
• É portável para outras plataformas?
• É reutilizável?
• É fácil de modificar e expandir?
• Suporta testes?
• Maximiza o desempenho sempre que necessário?
• Reutiliza sempre que necessário componentes de
outros projectos? 44
revisão do desenho

• Os algoritmos são apropriados ou necessitam de ser


melhorados?

• Se for um processo de desenvolvimento por fases, a


transição entre fases é fácil de fazer?

• Está bem documentado?

• Faz correspondencia entre os componentes e os


requisitos?

• Utiliza técnicas adequadas para prevenção e tolerância


a falhas?
45

documentação do desenho

• Desenho racional

– aponta aspectos críticos e trade-offs

• Descrição dos componentes dos sistema

• Descrição da interface com o utilizador

• Conjunto de diagramas a descrever toda a organização


e estrutura do sistema

• Topologia da rede, no caso de ser um sistema


distribuído
46
interface com o
utilizador
• menus e outros formatos de ecrã
• teclas funcionais, ecrã táctil, layouts de teclado, uso de rato
ou joystick
• formato dos relatórios
• input: origem, formatação e armazenamento dos dados
• output: destino, formatação e armazenamento dos dados
enviados
• características funcionais gerais
• restrições de desempenho
• procedimento de arquivo
• abordagem ao suporte de faltas
47

resumo

• O desenho começa num nível elevado, com decisões


importantes sobre a arquitectura do sistema baseada nos
requisitos do sistema, nos atributos desejáveis e na
intenção de usar o sistema durante muito tempo

• É preciso ter em conta as características de um bom


desenho:
– Modularidade e níveis de abstracção
– Ligação e coesão
– Tolerância a faltas
– Prototipagem
– Interface com utilizador
48