Desenho de Software. Desenho de Software 1

Transcrição

1 Desenho de Software Desenho de Software 1

2 Sumário Caracterização Conceitos fundamentais Desenho funcional e desenho OO Qualidades Desenho de Software 2

3 Bibliografia Pfleeger, Capítulo 6 Design the Modules Desenho de Software 3

4 Bibliografia Adicional Bertrand Meyer, Object-Oriented Software Construction Desenho de Software 4

5 Objectivos Desenho é o processo da passagem do espaço do problema para o espaço da solução. À descrição da solução também se chama desenho. O desenho descreve uma solução para o problema que satisfaz os seus requisitos note-se que muitas outras soluções satisfazendo os mesmo requisitos são possíveis Desenho de Software 5

6 Porquê produzir um desenho Para guiar a implementação Para documentar a implementação Desenho de Software 6

7 Desenho de Software 7

8 Decomposição O desenho visa lidar com a complexidade do software O processo de desenho requer sempre alguma forma de decomposição. Existem duas estratégias de decomposição: Desenho Funcional em que o estado do sistema está centralizado e é partilhado pelas funções que manipulam esse estado Desenho com Objectos em que o sistema é visto como um conjunto de objectos interactuantes que encapsulam a informação que manipulam. Os clientes têm usualmente uma visão mais funcional do sistema... Desenho de Software 8

9 Conceitos fundamentais Abstracção (dual de refinamento) Generalização obtida eliminando os aspectos irrelevantes e amplificando os essenciais para determinada finalidade Encapsulamento Regulação do acesso à representação interna Modularidade Construção à custa de elementos de menor granularidade

10 Desenho Funcional Foco Funções ou acções que o sistema tem que realizar Decomposição sucessiva de funções Passos do método: Escreve-se a função do topo Decompor a função de topo em sub-funções Considerar independentemente cada sub -função e decompô-la em sub-funções mais detalhadas Repetir processo até poder programar facilmente cada sub-função Desenho de Software 10

11 Desenho Funcional - Exemplo Função de topo Funções de 2º nível Funções de 3º nível Fazer uma chávena de café Ferver água Buscar chávena Pôr café na chávena Adicionar água Mexer Adicionar açúcar Decomposição Pôr Fervedor no fogão Ligar fogão Enquanto água não ferver fazer Ver TV FimCiclo Desligar fogão Se açúcar é requerido Pôr açucar chávena Mexer FimDoSe Desenho de Software 11

12 Desenho Funcional Características principais do método de decomposição funcional: O primeiro método sistemático para desenho de software Baseado na decomposição do sistema num conjunto de funções Abordagem top-down Processo de refinamento por etapas com uma diminuição de abstracção dos níveis superiores para os inferiores As funções partilham o estado global do sistema que se encontra centralizado As funções podem possuir estado local, mas apenas durante a duração da sua execução Desenho de Software 12

13 Desenho Funcional Vantagens: Aplicável para qualquer tipo de aplicações Flexível para desenho arquitectural de alto nível, ou desenho estuturado detalhado de nível inferior Um excelente método para guiar o nosso pensamento Os clientes pensam deste modo Desenho de Software 13

14 Desenho Funcional Desvantagens: Consideração dos dados é mais ou menos ignorada ou atrasada. As operações dos dados podem quebrar o desenho Possivelmente fornece várias soluções mas sem indicações sobre que desenho é o melhor Os detalhes dos algoritmos estão nas funções mas o estado não está escondido pelo que: A alteração do estado global por uma função pode ter efeitos colaterais com um impacto indesejável noutras funções Desenho de Software 14

15 Desenho com Objectos Primitivas Objecto: agrega os dados e as operações que os manipulam Classe: especifica um conjunto de objectos, a sua interface, estrutura e implementação Herança: uma classe pode ser definida como extensão ou restrição de outra Polimorfismo (de subtipos): Um objecto pode responder como se fosse outro objecto. Desenho de Software 15

16 Desenvolvimento OO em 5 passos 1. Identificação dos objectos e seus atributos Clientes, servidores e agentes Nomes Objectos semelhantes -> classe 2. Identificação das operações realizadas no ou requeridas pelo objecto Estabelecer o comportamento dinâmico (restricções) 3. Estabelecer a visibilidade de cada objecto relativamente aos restantes Captura a topologia de objectos 4. Estabelecer a interface de cada objecto Definição do contracto 5. Concretizar cada objecto Escolher uma representação apropriada Desenho de Software 16

17 Quando e Como falha OO? Paradigma OO usa a Classe como a unidade principal de decomposição de um sistema Um bom desenhador decompõe as facetas principais de uma aplicação em classes e hierarquias Muitos requisitos não se decompõem em comportamentos centrados num único ponto Desenho de Software 17

18 Quando e Como falha OO (cont)? A tirania da decomposição dominante: Cada decomposição OO resulta em facetas transversais ao código Independentemente de quão bom é o desenho, há facetas que não podem ser bem modularizadas Scattering Código para a preocupação está distribuído Tangling Código para várias facetas está presente na mesma abstracção (classe, método) Desenho de Software 18

19 Pedido HTTP (Linux+Apache) Desenho de Software 19

20 Pedido HTTP (Windows+IIS) Desenho de Software 20

21 Qualidades do desenho Independência Coesão (Cohesion) Ligação (Coupling) Inteligibilidade Flexibilidade (ou Adaptabilidade) Desenho de Software 21

22 Independência Qualidade que determina a capacidade de reutilização (reusability); A independência entre componentes é uma qualidade do desenho que permite ainda Entendimento Concretização código Concretização de testes Adaptações Rastreabilidade dos requisitos Desenho de Software 22

23 Independência Para aferir a independência entre componentes usam-se duas medidas: Coesão intra-componente Ligação inter-componentes Desenho de Software 23

24 Coesão Medida de proximidade de componentes com determinada finalidade Coesão Funcional Coesão Sequencial Coesão Comunicacional Coesão de Objecto Qual a vantagem da Coesão? Desenho de Software 24

25 Coesão Intra-Componente Um componente é coeso se todos os seus elementos estão envolvidos na satisfação dos objectivos do componente Quando não existe coesão, ao modificar uma determinada função é necessário procurar em todos os componentes as partes relativas à função A coesão determina a localidade das alterações Desenho de Software 25

26 Coesão de Objecto Coesão = cada método e atributo é essencial para cumprir a responsabilidade do objecto O Desenho com objectos promove a coesão Desenho de Software 26

27 Ligação Medida de dependência de um componente em relação a outros Se a ligação é elevada: Para usar um componente tenho de conhecer os restantes Quais as desvantagens da Ligação? Desenho de Software 27

28 Ligação Inter-Componentes Ligação forte quando existe uma grande dependência entre componentes Ligação fraca quando existe uma fraca dependência Desligados quando são completamente independentes Desenho de Software 28

29 Ligação Inter-Componentes A ligação entre componentes depende de: As referências entre componentes Os dados passados entre componentes O controlo entre componentes O nível de complexidade da interface entre componentes Níveis de ligação Ligação de conteúdo Ligação de Partilha Ligação de Controlo Ligação de Estrutura Ligação de Dados Sem ligação Desenho de Software 29

30 Níveis de Ligação Ligação de Conteúdo verifica-se quando um componente conhece a estrutura interna de outro componente Qualquer alteração interna pode ter repercussões nos restantes componentes Ligação de Partilha verifica-se quando vários componentes partilham um conjunto de dados Todos os componentes dependem da estrutura dos dados partilhados, por exemplo, variáveis globais Desenho de Software 30

31 Níveis de Ligação Ligação de Controlo verifica-se quando alterações num componente alteram a sequencia de execução de outro componente Ligação de Estrutura verifica-se quando uma estrutura de dados é usada para passar informação entre componentes A formatação e organização dos dados gera uma dependência entre os componentes Ligação de Dados verifica-se quando dados são passados entre componentes Apenas tipos de dados simples são passados Desenho de Software 31

32 Inteligibilidade Qualidade que influência a capacidade de compreender o desenho A inteligibilidade varia em função de: Nomes os nomes têm significado e reflectem entidades do espaço do problema e do espaço da solução Documentação a documentação justifica e relaciona o desenho com o espaço do problema Complexidade grau de encapsulamento dos algoritmos complexos Ligação e Coesão fraca e forte, respectivamente Desenho de Software 32

33 Adaptabilidade A qualidade que determina a facilidade de adaptação a novos requisitos Requer: Abstracções estáveis Ligação e coesão fraca e forte, respectivamente Desenho de Software 33