Aula 17 Decomposição sucessiva

Transcrição

1 Aula 17 Decomposição sucessiva Francisco Dantas LES/DI/PUC-Rio Agosto 2008 Especificação Objetivos dessa aula Apresentar o método de desenvolvimento baseado em decomposição sucessiva Apresentar uma técnica de controle da qualidade passo a passo baseada em revisões dirigidas por critérios definidos Referência básica: Capítulo 11 Referências complementares: Capítulo 3 Qualidade de artefatos Capítulo 10 Especificação de módulos 2/ 33 1

2 Sumário Decomposição e integração Linguagens de representação Passo de projeto Elementos de uma decomposição Critérios de avaliação de elementos Critérios de avaliação de interfaces Exemplo 3/ 33 Qual é o problema? Desenvolvemos software a partir de um nível elevado de abstração até chegarmos ao nível concreto decomposição sucessiva Compomos a solução a integrando elementos menos concretos formando elementos concretos correspondentes a um nível mais alto de abstração integração sucessiva abstrato tempo desenvolvimento integração concreto 4/ 33 2

3 Pontos de vista Além do nível de abstração, elementos são observados a partir de pontos de vista Construção estático estruturas de dados modelos conceitual e físico dinâmico comportamento no tempo protocolos, seqüências de eventos processos e implantação Papéis de usuários humanos, exemplos: especificadores desenvolvedores redatores de documentos controladores da qualidade 5/ 33 Linguagens de representação Representação 1 disciplina, matrícula solicitadas Verificar pré requisitos disciplinas cursadas disciplinas aceitas disciplinas sem pré requisito Representação 2 Verificar pré requisitos Histórico escolar Obter histórico escolar Validar todas disciplinas solicitadas Representação 3 Validar disciplina Histórico escolar 0..n Semestre 0..n Disciplina matriculada Representação 4 phistorico = ObterHistorico( idaluno ) ; if ( phistorico!= NULL ) { for ( inxdisc = 0 ; {... código nome professor 6/ 33 3

4 Níveis de abstração: recordação alto Sistema Interface típica Arquivos, bases de dados, mensagens, plataforma Programa Módulos de definição API - Aplication program interface Componente Módulos de definição header files Módulo Níveis de abstração Classe Elementos públicos (e protected) Parâmetros generalizados Função Escopo visível baixo concreto Bloco Linha de código Escopo visível 7/ 33 Processo de desenvolvimento: visão macro Concepção Especificação de requisitos it Análise do domínio Base de software Auditoria física Auditoria funcional CQ do sistema caso pouco se saiba sobre os requisitos ou construções de componentes/frameworks não foi utilizado no trabalho Arquitetura Projeto lógico Projeto físico Teste funcional dos construtos Integração e CQ dos compostos Controle da qualidade das unidades Codificação Criação/manutenção Integração 8/ 33 4

5 Generalizando: passo de projeto Projeto Detalhado Componente 1 Arquitetura Componente abstrato Projeto Componente 2 Elaboração Composição Componente n 9/ 33 Passo de projeto com controle da qualidade Histórico de alterações Critérios e padrões de controle da qualidade Histórico de alterações Artefatos antecedentes Especificação Criação Alteração Artefato conseqüente Artefato Laudo Controle da qualidade Laudo FAP Gerência da evolução FAP FAP : ficha de acompanhamento de problema Outro artefato FAP Avaliação externa 10 / 33 5

6 Evitar passos de projeto errados Controle da qualidade passo a passo a cada passo de projeto deve-se controlar a qualidade durante o desenvolvimento de módulos, se o trabalho realizado em passos de projeto anteriores for a causa, os defeitos encontrados devem ser corrigidos reorganização (refatoração, refactoring) manutenção preventiva negociação da correção corrige-se ou adaptam-se os artefatos de modo que o todo se torne consistente 11 / 33 Elementos de uma decomposição 12 / 33 6

7 Elementos de uma decomposição Uma abstração raiz é qualquer coisa definida. Exemplos um modelo conceitual: define a organização conceitual (independente da implementação) de uma estrutura de dados ou de um sistema uma especificação de um módulo um tipo abstrato de dados uma especificação de uma função uma pseudo-instrução um tipo de dados implementado por um struct uma tarefa: descrição dos resultados de um desenvolvimento, junto com os critérios de avaliação da qualidade deles 13 / 33 Elementos de uma decomposição O conjunto de solução é uma solução exata da abstração raiz não faz mais nem faz menos do que o que foi especificado Alguns elementos do conjunto de solução poderão estar no nível concreto Outros estarão em um nível de abstração mais baixo do que a raiz, mas ainda não concreto Podem existir misturas de concreto e abstrato 14 / 33 7

8 Critérios de avaliação dos elementos do conjunto Especificação dos requisitos do elemento avaliada segundo os critérios apresentados na Aula 7 Especificação de requisitos (Capítulo 10) nem todos os critérios precisam ser abordados em cada um dos elementos. Ressaltamos os seguintes: Definição deve estar claramente definida a intenção do elemento Adequação compatibilidade entre o serviço prestado pelo elemento e as necessidades (precisa) e expectativas (deseja) do usuário Nivelamento todos os elementos do conjunto de solução estão no mesmo nível de abstração Viabilidade o elemento ou já é uma solução concreta, ou admite uma solução satisfatória 15 / 33 Critérios de avaliação dos elementos do conjunto Completeza de interface a especificação da interface do elemento está completa e em conformidade com os requisitos do elemento é na realidade um fator de qualidade (um conjunto de critérios), a ser visto mais adiante Necessidade cada elemento do conjunto de solução efetivamente contribui para a sua solução Suficiência o conjunto solução resolve completamente a abstração raiz Integrabilidade os elementos do conjunto de solução podem ser integrados sem necessitarem de adaptações Vide aulas passadas / 33 8

9 Como desenvolver uma tabela de símbolos? O que é uma tabela de símbolos? especificação de requisitos do módulo tabela de símbolos Qual seria a organização da tabela de símbolos? modelo conceitual projeto lógico modelo físico, inclusive assertivas estruturais Quais seriam as funções da tabela de símbolos especificação conceitual e física das funções projeto físico Como saber se a implementação está correta? linguagem de teste scripts de teste Implementar e testar parte do módulo de teste específico parte do módulo tabela de símbolos continuar até concluir Corrigir e revisar tudo sempre que necessário 17 / 33 Requisitos para a seqüência de passos Queremos evitar retrabalho inútil causa retrabalho inútil: refazer coisas para corrigir erros de decomposição Queremos assegurar que a decomposição esteja (idealmente) correta por construção evitar passos de decomposição errados na decomposição: o que é estar correto? Como assegurar isso? evitando que os passos de projeto levem a soluções erradas realizando controle da qualidade passo a passo 18 / 33 9

10 O que é estar correto? Um módulo bem projetado deve possuir qualidade: testabilidade detectabilidade baixo custo de reteste manutenibilidade fácil localizar o que deve ser alterado: a causa diagnosticabilidade fácil efetuar alterações sem que novos defeitos sejam introduzidos depurabilidade evolutibilidade boa organização interna encapsulamento coesão / 33 Evitar passos de projeto errados Como é feito o controle da qualidade? revisar o passo de projeto, baseando-se em um conjunto de critérios verificar a observância dos padrões de especificação projeto programação verificar, sempre que possível, a observância das recomendações de especificação projeto programação 20 / 33 10

11 Critérios de avaliação dos elementos do conjunto Integrabilidade os elementos do conjunto de solução podem ser integrados sem necessitarem de adaptações Minimalidade não existe subconjunto do conjunto de solução que por si só represente um conceito bem definido Ortogonalidade cada elemento resolve uma parte da abstração raiz que não é resolvida por qualquer outro elemento Flexibilidade o elemento pode ser utilizado em diferentes contextos através da seleção de parâmetros existentes na interface a flexibilidade deve ser a mínima necessária 21 / 33 Critérios de avaliação da interface dos elementos A interface de um elemento é composta por itens da interface Tipo do item deve estar claramente definida a semântica do item, e a escala de medição, ex. velocidade em m/s símbolo sob a forma de um string ASCII Necessidade do item o item da interface é necessário para poder corretamente utilizar o elemento Suficiência de itens o conjunto de todos os itens da interface permite corretamente utilizar o elemento 22 / 33 11

12 Critérios de avaliação da interface dos elementos Minimalidade de itens não existe um subconjunto do conjunto de itens e que represente um conceito bem definido, i.e. um item composto Ortogonalidade de itens cada item se refere a um requisito do elemento que nenhum outro item considera Encapsulamento são tornadas visíveis na interface física somente as propriedades de implementação efetivamente necessárias 23 / 33 Exemplo: dicionário genérico e persistente Requisitos Um dicionário persistente genérico armazena 0 ou mais pares <símbolo, valor> em alguma memória persistente Cada símbolo aparece uma única vez no dicionário Uma vez no dicionário, símbolos não podem ser alterados Ao inserir um par <símbolo, valor>, caso o símbolo ainda não exista no dicionário, o par é acrescido ao dicionário Dado um símbolo pode-se verificar se este já existe no dicionário Dado um símbolo pode-se, recuperar, alterar e destruir o correspondente valor Essa especificação é boa? Usem os critérios da aula / 33 12

13 Dicionário genérico: avaliação Explicitude o que é um Símbolo? Símbolo é um string de 0 ou mais bytes quem ancora Símbolos? Para assegurar imutabilidade, os Símbolos são copiados para dentro do dicionário o que é um Valor? Valor é uma seqüência de bytes possuindo semântica e tamanho indefinidos pode possuir uma estrutura complexa mas não conhecida pelo dicionário qual é o modelo de ancoragem do Valor? indefinido pode-se destruir um elemento do Dicionário? sim 25 / 33 Dicionário genérico: operações Operações sobre dicionários como um todo CriarDicionário( NomeDicionário ) Dicionário, CondRet DestruirDicionário( NomeDicionário ) CondRet Operações sobre acesso a dicionários AbrirDicionário( NomeDicionário ) pdic, CondRet FecharDicionário( pdic ) CondRet Operações sobre conteúdo de dicionário InserirPar( pdic, Símbolo, Valor ) Dicionário, CondRet ObterValor( (p pdic, Símbolo ) Valor, CondRet ExisteSímbolo( pdic, Símbolo ) boolean, CondRet DestróiPar( pdic, Símbolo ) Dicionário, CondRet 26 / 33 13

14 Modelo da biblioteca Biblioteca 1 1 Indice Catalogo 1 ProxBloco Bloco DIM_BLOCO * 1 Nome RefValor Valor ProxValor EspacoLivre 27 / 33 Operações sobre conteúdo do dicionário Sobre Catálogo InserirValor( pdic, Valor ) pvalor, CondRet ExtrairValor( pdic, pvalor ) Valor, CondRet DestruirValor( pdic, pvalor ) Dicionário, CondRet Sobre Índice ExisteSímbolo( pdic, Símbolo ) boolean, CondRet InserirPValor( pdic, Símbolo, pvalor ) Dicionário, CondRet SubstituirPValor( pdic, Símbolo, pvalor ) Dicionário, CondRet ObterPValor( pdic, Símbolo ) pvalor, CondRet DestruirSímbolo( pdic, Símbolo ) Dicionário, CondRet 28 / 33 14

15 Implementação de InserirPar pvalor = InserirValor( pdic, Valor ) ; if ( ExisteSímbolo( pdic, Símbolo )) { SubstituirPValor( pdic, Símbolo, pvalor ) ; } else { InserirPValor( pdic, Símbolo, pvalor ) ; } /* if */ Esse código é bom? o que acontece com o valor anterior ao substitui? para que procurar diversas vezes pelo símbolo, uma vez basta? 29 / 33 Implementação de InserirPar pvalor = InserirValor( pdic, Valor ) ; pinx = ExisteSímbolo( pdic, Símbolo ) ; if ( pinx!= NULL_INX ) { pval = ObterPValor( pdic, pinx ) ; SubstituirPValor( pdic, pinx, pvalor ) ; DestruirValor( pdic, pval ) ; } else { InserirPValor( pdic, Símbolo, pvalor ) ; } /* if */ E agora? precisa rever as especificações das funções 30 / 33 15

16 FIM 31 / 33 16