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
Maio 2009
Alessandro Garcia © LES/DI/PUC-Rio
2 / 33
1
Sumário
• Decomposição e integração
• Linguagens de representação
p j
• Passo de projeto
• Elementos de uma decomposição
• Critérios de avaliação de elementos
• Critérios de avaliação de interfaces
• Exemplo
Alessandro Garcia © LES/DI/PUC-Rio
Maio 2009
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
Maio 2009
Alessandro Garcia © LES/DI/PUC-Rio
4 / 33
2
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
Alessandro Garcia © LES/DI/PUC-Rio
Maio 2009
5 / 33
Linguagens de representação
Representação 1
disciplina,
matrícula
solicitadas
disciplinas
aceitas
Verificar
pré requisitos
disciplinas
cursadas
Representação 2
disciplinas sem
pré requisito
Verificar
pré requisitos
Obter
histórico
escolar
Histórico
escolar
Validar todas
disciplinas
solicitadas
Validar
disciplina
Representação 3
Histórico
escolar
Representação 4
0..n
pHistorico = ObterHistorico( idAluno ) ;
if ( pHistorico != NULL )
{
for ( inxDisc = 0 ; …
{
...
Semestre
0..n
Disciplina
matriculada
código nome professor
Maio 2009
Alessandro Garcia © LES/DI/PUC-Rio
6 / 33
3
Níveis de abstração: recordação
Interface típica
Sistema
Arquivos, bases de dados,
mensagens, plataforma
alto
Programa
Módulos de definição
API - Aplication program
i t f
interface
Componente
Módulos de definição
header files
Módulo
Elementos públicos
(e protected)
Níveis de
abstração
Classe
Parâmetros
generalizados
Função
Escopo
visível
Bloco
baixo
concreto
Escopo
visível
Linha de código
Alessandro Garcia © LES/DI/PUC-Rio
Maio 2009
7 / 33
Processo de desenvolvimento: visão macro
Base de
software
Concepção
Auditoria física
Especificação
d requisitos
de
i it
Auditoria funcional
CQ do sistema
Análise do domínio
caso pouco se saiba
sobre os requisitos ou
construções de
componentes/frameworks
Teste funcional dos
construtos
Arquitetura
Integração e CQ
dos compostos
Projeto lógico
não foi utilizado
no trabalho
Projeto
físico
Controle da qualidade
das unidades
Codificação
Criação/manutenção
Maio 2009
Integração
Alessandro Garcia © LES/DI/PUC-Rio
8 / 33
4
Generalizando: passo de projeto
Projeto Detalhado
Componente
1
Arquitetura
Componente
2
Componente
abstrato
Projeto
Elaboração
Componente
n
Composição
Alessandro Garcia © LES/DI/PUC-Rio
Maio 2009
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
Artefato
conseqüente
Artefatos
antecedentes
Criação
Especificação
Artefato
Alteração
Laudo
Controle da
qualidade
Laudo
Gerência
G
ê i d
da
evolução
FAP
FAP
Outro
artefato
FAP : ficha de acompanhamento
de problema
Maio 2009
FAP
Alessandro Garcia © LES/DI/PUC-Rio
Avaliação
externa
10 / 33
5
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
Alessandro Garcia © LES/DI/PUC-Rio
11 / 33
Elementos de uma decomposição
Maio 2009
Alessandro Garcia © LES/DI/PUC-Rio
12 / 33
6
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 um
ou
m sistema
i tem
– 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:
t
f descrição
d
i ã dos
d resultados
lt d de
d um desenvolvimento,
d
l i
t
junto com os critérios de avaliação da qualidade deles
Alessandro Garcia © LES/DI/PUC-Rio
Maio 2009
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
Maio 2009
Alessandro Garcia © LES/DI/PUC-Rio
14 / 33
7
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
odo o
os critérios
o p
precisam
a ser abo
abordados
dado em cada
ada um
u dos
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
• 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
Alessandro Garcia © LES/DI/PUC-Rio
Maio 2009
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),
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...
Maio 2009
Alessandro Garcia © LES/DI/PUC-Rio
16 / 33
8
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
d l conceituall
– modelo físico, inclusive assertivas estruturais
projeto lógico
• 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
p d
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
Maio 2009
Alessandro Garcia © LES/DI/PUC-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
Maio 2009
Alessandro Garcia © LES/DI/PUC-Rio
18 / 33
9
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
– ...
Alessandro Garcia © LES/DI/PUC-Rio
Maio 2009
19 / 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
Maio 2009
Alessandro Garcia © LES/DI/PUC-Rio
20 / 33
10
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
Alessandro Garcia © LES/DI/PUC-Rio
Maio 2009
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
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
Maio 2009
Alessandro Garcia © LES/DI/PUC-Rio
22 / 33
11
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
Alessandro Garcia © LES/DI/PUC-Rio
Maio 2009
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,
pode se recuperar,
recuperar alterar e destruir o
correspondente valor
• Essa especificação é boa? Usem os critérios da aula 7.
Maio 2009
Alessandro Garcia © LES/DI/PUC-Rio
24 / 33
12
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
Maio 2009
Alessandro Garcia © LES/DI/PUC-Rio
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
Maio 2009
Alessandro Garcia © LES/DI/PUC-Rio
26 / 33
13
Modelo da biblioteca
Biblioteca
1
1
Indice
Catalogo
1
ProxBloco Bloco
DIM_BLOCO
Nome RefValor
1
*
Valor ProxValor
EspacoLivre
Alessandro Garcia © LES/DI/PUC-Rio
Maio 2009
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
Maio 2009
Alessandro Garcia © LES/DI/PUC-Rio
28 / 33
14
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?
Alessandro Garcia © LES/DI/PUC-Rio
Maio 2009
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
Maio 2009
Alessandro Garcia © LES/DI/PUC-Rio
30 / 33
15
FIM
Maio 2009
Alessandro Garcia © LES/DI/PUC-Rio
31 / 33
16