Desenho de Software Desenho de Software 1
Sumário Caracterização Conceitos fundamentais Desenho funcional e desenho OO Qualidades Desenho de Software 2
Bibliografia Pfleeger, Capítulo 6 Design the Modules Desenho de Software 3
Bibliografia Adicional Bertrand Meyer, Object-Oriented Software Construction Desenho de Software 4
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
Porquê produzir um desenho Para guiar a implementação Para documentar a implementação Desenho de Software 6
Desenho de Software 7
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
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
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 - 10- Desenho de Software 10
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 - 11- Desenho de Software 11
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 - 12- Desenho de Software 12
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 - 13- Desenho de Software 13
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
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
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
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
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
Pedido HTTP (Linux+Apache) Desenho de Software 19
Pedido HTTP (Windows+IIS) Desenho de Software 20
Qualidades do desenho Independência Coesão (Cohesion) Ligação (Coupling) Inteligibilidade Flexibilidade (ou Adaptabilidade) Desenho de Software 21
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
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
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
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
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
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
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
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
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
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
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
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