Engenharia de Software

Engenharia de Software

Hélia Guerra

[email protected] Departamento de Matemática

Universidade dos Açores

desenho

• Desenho (dicionário Priberam on-line)

do Lat.! designu s. m.,

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

3

desenho conceptual e

desenho técnico

• O desenho é um processo iterativo feito em duas partes

–Desenho conceptual (desenho do sistema)

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

desenho conceptual

7

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

decomposição

• Descrição dos dados do sistema

• Descrições funcionais de alto nível

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

9

modularidade

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

desenho

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

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

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

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 camadas17

camadas

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

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

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

abstracção

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

Ordenar L por ordem crescente

25

desenho colaborativo

• Muitos projectos constituem trabalho colaborativo

• Aspectos a considerar no desenho colaborativo

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

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

• 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

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

interna de outro

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

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

controlam a actividade de outro componente

• O componente controlado não pode funcionar independentemente do componente controlador

ligação de estrutura

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

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

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

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

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

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₄₇

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