(QJHQKDULDGD3URJUDPDomR Desenho de Software Carla Ferreira Carla.Ferreira@dei.ist.utl.pt Sumário Objectivos Problemas Qualidades Técnicas Avaliação e Validação Casos Notáveis Exemplo Conclusões Desenho de Software 2 1
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 3 Arquitectura e Desenho O processo de desenho deve considerar dois aspectos: Descrever para os clientes RTXHo sistema faz - $UTXLWHFWXUDGH6RIWZDUH Descreve as funções do sistema Está relacionado com os documentos de requisitos Descrever para a equipa de desenvolvimento FRPRo sistema faz - 'HVHQKRGH3URJUDPDV Uma descrição dos principais algoritmos As estruturas e os fluxos de dados Desenho de Software 4 2
Decomposição O processo de desenho usa sempre alguma forma de decomposição. Existem duas estratégias de decomposição: 'HVHQKR)XQFLRQDO em que o estado do sistema está centralizado e é partilhado pelas funções que manipulam esse estado 'HVHQKRFRP2EMHFWRV em que o sistema é visto como um conjunto de objectos que encapsulam a informação que manipulam. Os clientes têm usualmente uma visão mais funcional do sistema... Desenho de Software 5 Problemas Porquê este desenho? Dado um conjunto de requisitos vários desenhos são possíveis Abordagens top-down versus bottomup Propagação de alterações A evolução do software pode obrigar a um re-desenho Não existe uma única decomposição Desenho de Software 6 3
Qualidades Independência Coesão Ligação Inteligibilidade Integridade Adaptabilidade Desenho de Software 7 Componentes Independentes Um desenho de qualidade facilita o entendimento, a implementação, os testes, as alterações e as adaptações do desenho. Mais ainda, facilita o seguimento dos requisitos no desenho A independência entre componentes é uma qualidade do desenho que permite algumas das propriedades acima Para medir a independência entre componentes usam-se duas medidas: Coesão intra-componente Ligação inter-componentes Desenho de Software 8 4
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 O tipo de coesão determina a localidade das alterações Desenho de Software 9 Coesão de Objecto Cada operação fornece a funcionalidade que permite que os atributos do objecto sejam modificados, inspeccionados e usados, numa base de disponibilização de serviços Desenho de Software 10 5
Ligação Inter-Componentes Dois componentes dizem-se IRUWHPHQWH OLJDGRV quando existe uma grande dependência entre eles Dois componentes dizem-se IUDFDPHQWH OLJDGRV quando existe uma fraca dependência entre eles Dois componentes dizem-se GHVOLJDGRV quando são completamente independentes 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 Desenho de Software 11 Níveis de Ligação /LJDomRGH&RQWH~GR verifica-se quando um componente conhece a estrutura interna de outro componente Qualquer alteração interna pode ter repercussões nos restantes componentes /LJDomRGH3DUWLOKD 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 12 6
Níveis de Ligação /LJDomRGH&RQWUROR verifica-se quando um componente passa parâmetros que controlam a actividade de outro componente O componente controlado não pode funcionar independentemente do componente controlador /LJDomRGH(VWUXWXUD 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 /LJDomRGH'DGRV verifica-se quando dados são passados entre componentes Apenas tipos de dados simples são passados Desenho de Software 13 Inteligibilidade Influência a inteligibilidade: Coesão e Ligação o componente pode ser entendido sem referir outros componentes 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 da complexidade dos algoritmos Desenho de Software 14 7
Adaptabilidade A qualidade que determina facilidade de adaptação a novos requisitos Requer: Ligação fraca Abstracções estáveis Self-contained um componente constituído por interfaces fornecidas e interfaces requeridas Desenho de Software 15 Técnicas Estilos arquitecturais Desenho funcional Desenho com objectos Padrões de desenho Refactorização do desenho Técnicas de aperfeiçoamento do desenho Desenho de Software 16 8
Arquitecturas de Software A arquitectura associa os requisitos identificados no sistema com os componentes que os vão implementar Uma arquitectura de software é constituída por dois elementos básicos: Componentes que definem as computações Conectores que descrevem as interacções entre componentes Um estilo arquitectural define uma família de sistemas com o mesmo padrão de organização estrutural: Vocabulário de tipos componente e conector Conjunto de restrições sobre as possíveis combinações de componentes e conectores Desenho de Software 17 Estilos Arquitecturais Camadas Repositórios... Desenho de Software 18 9
Camadas Criptografia Interface ficheiros Gestão de chaves Autenticação Utilizadores Desenho de Software 19 Camadas: Propriedades Vantagens 'HVHQYROYLPHQWRLQFUHPHQWDO pois o desenho possui vários níveis de abstracção (YROXomR pois a alteração de uma camada apenas vai afectar as camadas imediatamente acima e abaixo 5HXWLOL]DomR pois permitem diferentes implementações de uma camada Desvantagens Por vezes é difícil estruturar o problema em níveis de abstracção Problemas de desempenho devido à coordenação entre as camadas Desenho de Software 20 10
Repositórios Aplicação 2 Aplicação 1 Aplicação 3 Repositório (dados partilhados) Aplicação 6 Aplicação 4 Aplicação 5 Desenho de Software 21 Repositórios: Propriedades Exemplos Base de dados Ambientes de programação Blackboard Vantagem Constitui uma arquitectura DEHUWD uma vez que a representação dos dados está acessível a diversos fabricantes de componentes Desvantagem 'HSHQGrQFLD dos dados partilhados pois estes devem estar numa representação aceitável para a todos os componentes Desenho de Software 22 11
Desenho Funcional Baseado na decomposição do sistema num conjunto de funções 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 23 Desenho Funcional 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 As funções têm mais tendência a serem alteradas que os dados Desenho de Software 24 12
Desenho com Objectos Princípios Encapsulação restrição no acesso à representação interna Abstracção eliminação do irrelevante e amplificação do essencial Modularidade construção à custa de elementos de menor granularidade Desenho de Software 25 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 uma variável pode, em tempo de execução, referir objectos de classes diferentes Desenho de Software 26 13
Desenho com Objectos Objectivos o resultado final do desenvolvimento deve ter as seguintes qualidades: Reutilização capacidade de ser reutilizado parcialmente ou como um todo noutros programas Extensibilidade facilidade de adaptação às alterações de especificação de modo a se alcançar o princípio do Aberto/ Fechado Desenho de Software 27 Desenho com Objectos Herança versus composição reutilização white-box versus black-box estática (tempo de compilação) versus dinâmica (tempo de execução) encapsulação Desenho de Software 28 14
Padrões de Desenho Verifica-se que: Existem problemas que ocorrem recorrentemente É possível identificar classes de soluções As soluções reflectem as forças em conflito Não existem soluções óptimas Desenho de Software 29 Padrões de Desenho Considere-se o jogo de xadrez. Para se ser um bom jogador de xadrez é necessário: Aprender os movimentos permitidos, como termina o jogo,... (primitivas) Saber que se deve ocupar centro do tabuleiro (princípios) Estudar os jogos dos grandes mestres (padrões) Desenho de Software 30 15