Upload
others
View
5
Download
0
Embed Size (px)
Citation preview
1
Aula 17Decomposição sucessiva
Francisco DantasFrancisco DantasLES/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
Maio 2009 2 / 33Alessandro Garcia © LES/DI/PUC-Rio
• Referências complementares:– Capítulo 3 Qualidade de artefatos
– Capítulo 10 Especificação de módulos
2
Sumário
• Decomposição e integração
• Linguagens de representação
• Passo de projetop j
• Elementos de uma decomposição
• Critérios de avaliação de elementos
• Critérios de avaliação de interfaces
• Exemplo
Maio 2009 3 / 33Alessandro Garcia © LES/DI/PUC-Rio
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
Maio 2009 4 / 33Alessandro Garcia © LES/DI/PUC-Rio
concreto
desenvolvimento integração
tempo
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
é á
Maio 2009 5 / 33Alessandro Garcia © LES/DI/PUC-Rio
– Papéis de usuários humanos, exemplos:• especificadores
• desenvolvedores
• redatores de documentos
• controladores da qualidade
Linguagens de representação
Verificarpré requisitos
disciplina,matrículasolicitadas
disciplinasaceitas
disciplinas sempré requisito
Representação 1
Verificar
Representação 2
Históricoescolar
disciplinascursadas
pré requisito pré requisitos
Obterhistóricoescolar
Validar todasdisciplinassolicitadas
Validardisciplina
Históricoescolar
Representação 3
Representação 4
Maio 2009 6 / 33Alessandro Garcia © LES/DI/PUC-Rio
Semestre
Disciplinamatriculada
código nome professor
0..n
0..n
Representação 4
pHistorico = ObterHistorico( idAluno ) ;if ( pHistorico != NULL ){ for ( inxDisc = 0 ; … { ...
4
Níveis de abstração: recordação
Sistema
Programa
Arquivos, bases de dados,mensagens, plataformaalto
Módulos de definiçãoAPI - Aplication program
i t f
Interface típica
Componente
Módulo
Classe
Módulos de definiçãoheader files
interface
Elementos públicos(e protected)
Parâmetrosgeneralizados
Níveis deabstração
Maio 2009 7 / 33Alessandro Garcia © LES/DI/PUC-Rio
Linha de código
Bloco
FunçãoEscopo visível
Escopovisível
concreto
baixo
Processo de desenvolvimento: visão macro
Concepção
Especificaçãod i it
Auditoria física
Auditoria funcional
Base desoftware
Análise do domínio
de requisitos
Arquitetura
Projeto lógico
CQ do sistema
Integração e CQdos compostos
Teste funcional dosconstrutos
caso pouco se saibasobre os requisitos ouconstruções decomponentes/frameworks
Maio 2009 8 / 33Alessandro Garcia © LES/DI/PUC-Rio
Codificação
Projetofísico
dos compostos
Controle da qualidadedas unidades
Criação/manutenção Integração
não foi utilizadono trabalho
5
Generalizando: passo de projeto
Componente1
Projeto Detalhado
Componente2
ProjetoComponenteabstrato
Arquitetura
Maio 2009 9 / 33Alessandro Garcia © LES/DI/PUC-Rio
Componenten
Elaboração
Composição
Passo de projeto com controle da qualidade
Critérios e pa-drões de controle
da qualidade Histórico dealterações
Histórico dealterações
Especifi-cação
Artefatosantecedentes
Artefato
Artefatoconseqüente
Criação
Alteração
Controle da qualidade
Laudo Laudo
G ê i d
Maio 2009 10 / 33Alessandro Garcia © LES/DI/PUC-Rio
FAP
FAP
FAP
Outroartefato
Gerência da evolução
Avaliaçãoexterna
FAP : ficha de acompanhamento de problema
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
Maio 2009 11 / 33Alessandro Garcia © LES/DI/PUC-Rio
Elementos de uma decomposição
Maio 2009 12 / 33Alessandro Garcia © LES/DI/PUC-Rio
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 o de m i temou 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
t f d i ã d lt d d d l i t
Maio 2009 13 / 33Alessandro Garcia © LES/DI/PUC-Rio
– uma tarefa: descrição dos resultados de um desenvolvimento, junto com os critérios de avaliação da qualidade deles
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
Maio 2009 14 / 33Alessandro Garcia © LES/DI/PUC-Rio
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 odo o o p a abo dado ada u do
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
Maio 2009 15 / 33Alessandro Garcia © LES/DI/PUC-Rio
• 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
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 – é 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
Maio 2009 16 / 33Alessandro Garcia © LES/DI/PUC-Rio
• Integrabilidade– os elementos do conjunto de solução podem ser integrados sem
necessitarem de adaptações
• Vide aulas passadas...
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?d l l– modelo conceitual
– 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
• Como saber se a implementação está correta?– linguagem de teste
– scripts de teste
projeto lógico
projeto físico
Maio 2009 17 / 33Alessandro Garcia © LES/DI/PUC-Rio
p d
• 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
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?
Maio 2009 18 / 33Alessandro Garcia © LES/DI/PUC-Rio
– evitando que os passos de projeto levem a soluções erradas
– realizando controle da qualidade passo a passo
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
Maio 2009 19 / 33Alessandro Garcia © LES/DI/PUC-Rio
– boa organização interna
– encapsulamento
– coesão
– . . .
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
Maio 2009 20 / 33Alessandro Garcia © LES/DI/PUC-Rio
especificação
• projeto
• programação
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
Maio 2009 21 / 33Alessandro Garcia © LES/DI/PUC-Rio
• 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
Critérios de avaliação da interface dos elementos
A interface de um elemento é composta por itens da interface
• Tipo do itemdeve estar claramente definida a semântica do item e a escala – 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
Maio 2009 22 / 33Alessandro Garcia © LES/DI/PUC-Rio
• Suficiência de itens– o conjunto de todos os itens da interface permite corretamente
utilizar o elemento
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
Maio 2009 23 / 33Alessandro Garcia © LES/DI/PUC-Rio
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
Maio 2009 24 / 33Alessandro Garcia © LES/DI/PUC-Rio
– Dado um símbolo pode-se, recuperar, alterar e destruir o correspondente valor
• Essa especificação é boa? Usem os critérios da aula 7.
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
Maio 2009 25 / 33Alessandro Garcia © LES/DI/PUC-Rio
dicionário
– qual é o modelo de ancoragem do Valor?• indefinido
– pode-se destruir um elemento do Dicionário?• sim
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( pDic , Símbolo ) Valor , CondRet
Maio 2009 26 / 33Alessandro Garcia © LES/DI/PUC-Rio
( p , ) ,
– ExisteSímbolo( pDic , Símbolo ) boolean , CondRet
– DestróiPar( pDic , Símbolo ) Dicionário , CondRet
14
Biblioteca
1 1
Modelo da biblioteca
Indice Catalogo
BlocoProxBloco
1
1 1
Maio 2009 27 / 33Alessandro Garcia © LES/DI/PUC-Rio
Nome RefValor ProxValorValor EspacoLivre
DIM_BLOCO * 1
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
Maio 2009 28 / 33Alessandro Garcia © LES/DI/PUC-Rio
– ObterPValor( pDic , Símbolo ) pValor , CondRet
– DestruirSímbolo( pDic , Símbolo ) Dicionário , CondRet
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 */
Maio 2009 29 / 33Alessandro Garcia © LES/DI/PUC-Rio
• Esse código é bom?– o que acontece com o valor anterior ao substitui?
– para que procurar diversas vezes pelo símbolo, uma vez basta?
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 ) ;
Maio 2009 30 / 33Alessandro Garcia © LES/DI/PUC-Rio
InserirPValor( pDic , Símbolo , pValor ) ;} /* if */
• E agora?– precisa rever as especificações das funções
16
FIM
Maio 2009 31 / 33Alessandro Garcia © LES/DI/PUC-Rio