Aula 17 Revisão - PUC-Rioinf1301/docs/INF1301_Aula17_Revisao... · 2016. 3. 3. · Revisão...
Transcript of Aula 17 Revisão - PUC-Rioinf1301/docs/INF1301_Aula17_Revisao... · 2016. 3. 3. · Revisão...
1
Aula 17Revisão
Alessandro GarciaLES/DI/PUC-Rio
Abril 2010
Matéria da Prova
• Todo material dado até o dia de hoje
– capítulos correspondentes do livro são indicados no início de cada aula
– material referenciado ou usado em sala de aula
• Exemplo: catálogo de padrões de erros de programação em C
• Monografia sobre testes, arcabouço, etc…
• Exercícios– Todas respostas estão nos próprios slides
• etc…
Abril 2009 2 /38© LES/DI/PUC-Rio
2
Maio 2009 3 / 32Alessandro Garcia © LES/DI/PUC-Rio
Pontos a serem revisados
• Dúvidas e erros tipos cometidos em provas passadas (e/outrabalhos)
– Modelo conceitual vs. Modelo físico vs. Exemplo físico
• Diferenças entre os diferentes modelos, diagramas e notações
– Assertivas
• Como especificar: linguagem formal ou natural?
– Relacionamento entre faltas-erros-falhas e...
• Inspeção, Teste, e Assertivas
– Outras perguntas específicas
• Linguagens de scripts, porcentagem da prova sobre o trabalho, respostas em C++/Java, Acoplamento vs. Coesão vs. Encapsulamento, etc...
Maio 2009 4 / 32Alessandro Garcia © LES/DI/PUC-Rio
Definição dos modelos
• Modelo conceitual vs. Modelo físico vs. Exemplo físico
– Diferenças entre os diferentes modelos, diagramas e notações
– Trabalho: boa parte dos erros não foi na notação, mas sim onde deve ser descrito o que... Exemplos:
• inclusão de detalhes de implementação no modelo da arquitetura
• confusão: modelo físico vs. exemplo físico
• Então: segue algumas dicas de boas práticas...
3
Maio 2009 5 / 32Alessandro Garcia © LES/DI/PUC-Rio
Se for pedido modelo conceitual...
• ... da arquitetura (baseado em um conjunto de
requisitos)
– não esqueçam das interfaces!!!!
– exemplos:
• arquitetura do jogo Free Cell
células temporárias
notem que este modelojá permite inferir assertivas
estruturais
Maio 2009 6 / 32Alessandro Garcia © LES/DI/PUC-Rio
Modelo conceitual da arquitetura
• Modelo conceitual da arquitetura
– descreve um conceito sem se preocupar com a forma de sua implementação
– exemplo (trabalho): descrição conceitual da arquitetura (não provê certos detalhes de implementação)
– e.g. módulos que representam estruturas de dados
– e.g. funções internas/auxiliares
4
Maio 2009 7 / 32Alessandro Garcia © LES/DI/PUC-Rio
Modelo conceitual
• Modelo conceitual
– descreve um conceito sem se preocupar com a forma de sua implementação
– exemplos:
• modelo conceitual do problema Free Cell
um exemplo de assertiva que
não pode ser expressa aqui no
modelo?
uma instância de carta nunca pode
ocupar espaço em mais em um
tipo de célula
uma instância de carta deve ocupar
pelo menos um espaço em uma
das células
cada célula base é específica para um naipe e deve receber cartas em ordem crescente
células temporárias
notem que este modelojá permite inferir assertivas
estruturais
Maio 2009 8 / 32Alessandro Garcia © LES/DI/PUC-Rio
Especificaçãoconceitual dasinterfaces
funções
nos módulos sofrem
nenhuma influência da
estrutura de dados
(lista)
5
Maio 2009 9 / 32Alessandro Garcia © LES/DI/PUC-Rio
Exemplo de bom modelo arquitetural
• Propriedades de um bom modelo da arquitetura– simplicidade: principais módulos estão bem identificados e são derivados
geralmente dos requisitos (descrição do problema)
– notem que modelo arquitetural não requer conhecimento sobre implementação (não era precisa modelar lista neste modelo)
– relacionamentos e dependências entre módulos são capturados• alguns dos relacionamentos somente podem ser capturados quando você raciona sobre as
funções que devem estar disponíveis na interface
interface provida
para o usuário
Maio 2009 10 / 32Alessandro Garcia © LES/DI/PUC-Rio
Rastreabilidade
Note como os mesmostermos são utilizados Consistentemente nas duas descrições
Cuidado!!! (no outro modelo:
carta era um módulo)
Note as boas escolhas deprojeto modular: funçõesnos módulos sofrem nenhuma influência da estrutura de dados (lista)
6
Maio 2009 11 / 32Alessandro Garcia © LES/DI/PUC-Rio
Possíveis melhorias ou simplificações
• Idealmente: nomear relacionamentos
• Na prova: se necessário, usar texto auxiliar (linguagem natural) para descrever um conceito que não aparece explicitamente na descrição do problema
complicação desnecessáriaem um modelo arquitetural
desnecessário expressar relacionamentosjá conhecidos dos módulos de teste
Maio 2009 12 / 32Alessandro Garcia © LES/DI/PUC-Rio
Cuidados especiais....
• *.h no modelo da arquitetura?
• cuidado em criar confusões com elementos da notação (neste caso, herança/especialização)
7
Maio 2009 13 / 32Alessandro Garcia © LES/DI/PUC-Rio
Cuidado em confundir...
• Modelo físico com exemplo físico
- somente modela a lista principal
- ou seja, o exemplo não é uma
instância do modelo físico
- um exemplo físico é uma das
possíveis fotografias da estrutura
durante a execução do programa
conclusão:
este modelo físico não
é um exemplo físico (não contem
valores)
Maio 2009 14 / 32Alessandro Garcia © LES/DI/PUC-Rio
Bom modelo físico
poderia ter incluído uma
estrutura para cabeça da
lista principal
8
Maio 2009 15 / 32Alessandro Garcia © LES/DI/PUC-Rio
Bom exemplo físico
omitiu nome dos elementos
da estrutura, tornando-a de
difícil leitura
Maio 2009 16 / 32Alessandro Garcia © LES/DI/PUC-Rio
O que são assertivas?
• Assertivas são relações (expressões lógicas) envolvendo dados e estados manipulados
• São definidas em vários níveis de abstração
– programas
• devem estar satisfeitas para os dados persistentes (arquivos)
– módulos (ou classes)
• devem estar satisfeitas ao entrar e ao retornar de todas funções
• assertivas invariantes: – assertivas estruturais: corretude das instâncias de estruturas de dados
– também: certos limites inferiores e superiores associados com certos atributos de classes
– funções
• devem estar satisfeitas em determinados pontos do corpo da função
• usualmente assertivas de entrada e assertivas de saída– pré e pós condições
– na definição das pós-condições, assume-se que as pré-condições foram satisfeitas
• dificilmente são expressas em modelos físicos
9
Maio 2009 17 / 32Alessandro Garcia © LES/DI/PUC-Rio
Notação para assertivas?
• Em uma lista duplamente encadeada1. ∀∀∀∀ pElem ∈∈∈∈ lista : pElem->pAnt != NULL =>
pElem->pAnt->pProx == pElem
• note o uso da linguagem de programação com algumas extensões de notação
Outra redação: para todos os elementos elem pertencentes a uma lista duplamente encadeada, se elem possui um antecessor, então o sucessor deste é o próprio elem
• É dado um arquivo-A contendo n >= 0 registros– cada registro contém um campo chave– ∀∀∀∀ registros ri e rk : ri , rk ∈∈∈∈ arquivo-A :
se ri antecede rk então ri .chave < rk .chave
Outra redação: é dado um arquivo-A contendo n >= 0 registros– cada registro contém um campo chave– o arquivo é ordenado em ordem estritamente crescente segundo
chave
• estritamente: sem conter chave repetida
Maio 2009 18 / 32Alessandro Garcia © LES/DI/PUC-Rio
Assertivas – onde colocar?
– É comum que parte das assertivas possam ser alternativamente incluídas em vários pontos:
• Na definição do módulo, OU
• Na definição da estrutura de dados, OU
• Nas funções contidas no módulo, etc...
– Solução: para resolver esta ambigüidade de posição, procure incorporar a especificação no elemento menos abstrato
10
Maio 2009 19 / 32Alessandro Garcia © LES/DI/PUC-Rio
Relações entre: Falta, Erro, Falha, ...
• ... Assertivas, Teste, etc...
• Programas podem conter defeitos (ou faltas) que, quando exercitados, provocam erros de funcionamento. Quando observados estes erros passam a ser falhas.– defeito: código errado (falta: a mesma coisa que defeito)
• trecho que código onde é inserido um elemento à mais em um vetor de 10 elementos (estático)
– erro: estado diferente do esperado/desejado, ainda não observado• erro: no momento em que vetor fica com 11 elementos (dinâmico)
• ou seja, observada a violação da assertiva estrutural
– falha: estado diferente do esperado ou desejado, observado• quando o usuário percebe o erro interno do sistema (dinâmico)
Maio 2009 20 / 32Alessandro Garcia © LES/DI/PUC-Rio
Linguagem de script para testar um módulo
• É o conjunto de palavras-chave necessárias para definir os casos de teste em um arquivo/script de teste
== Excluir nó corrente de árvore contendo somente raiz
=excluirNo 0 0
=ehVazia 0 T
=irPai 0 5
=irFilho 0 5
=irEsquerda 0 5
=irDireita 0 5
=obterValor 0 # 5
11
Maio 2009 21 / 32Alessandro Garcia © LES/DI/PUC-Rio
... Palavras-chave para possíveis resultados tbém sãoparte da linguagem de script
. . .
== Criar árvore
=criar OK
=irdir ArvoreVazia
== Inserir à esquerda
=insdir CharA OK
== Obter o valor inserido
=obter CharA OK
== Ir para no pai, não tem
=irpai EhRaiz
== Inserir à esquerda
=insesq CharB OK
=obter CharB OK
== Ir para no pai, tem
=irpai OK
=obter CharA OK
. . .
Item de interface sendo testado resultado esperado
Maio 2009 22 / 32Alessandro Garcia © LES/DI/PUC-Rio
Logo...
• Altamente recomendado que vocês não ignorem tópicos do curso menos explorados (pelo menos, explicitamente) nos trabalhos
– inspeção de código
– imposição e conversão de tipos
– acoplamento, coesão, encapsulamento, etc...
• Revisem exercícios da sala de aula
12
Maio 2009 23 / 32Alessandro Garcia © LES/DI/PUC-Rio
Perguntas/dúvidas Específicas
• Questões de prova poderão ser respondidas em C++/Java?
– Somente respostas em C
• afinal, foi a linguagem utilizada nos trabalhos
– O objetivo deste curso não é um curso específico de uma linguagem de programação; portanto:
• em certas aulas, usamos exemplos em diferentes linguagens (p.e.C++/Java) para ilustrar que conceitos/princípios se aplicar a programas em qualquer linguagem
• raramente se pedirá para você escrever código na prova– logo, esta questão se torna praticamente irrelevante para provas
– Casos especiais:
• obviamente, certos padrões de organizações de módulos ou padrões de faltas discutidos no curso são específicos para C
– por exemplo, separação entre interface e implementação: *.h vs. *.c
– imposição de tipos em C
Maio 2009 24 / 32Alessandro Garcia © LES/DI/PUC-Rio
Questões sobre Modelos
• Evite “inventar” elementos da notação de modelagem
– Por exemplo, cada triângulo é uma interface...
• assim que lê sua especificação não sabe qual foi a intenção do modelador
– Na pior das hipóteses, crie uma legenda para comunicar a semântica de cada elemento da “sua notação”
• Caso você for usar diferentes estilos de setas para expressar diferentes de relacionamentos entre módulos, use legendas...
• Cuidado com uso errado da notação, por exemplo:
– referência ao invés de usar agregação
• Não esqueça de dar nomes aos elementos do modelo: nomes dos módulos, das interfaces, relacionamentos, etc...
13
Maio 2009 25 / 32Alessandro Garcia © LES/DI/PUC-Rio
Dicas gerais
• Se houverem questões do tipo: – “Dado o código/modelo abaixo, redija um texto sobre os
princípios de de modularidade seguidos ou violados.”
• Busque completude e coerência na sua resposta, mas escreva somente o necessário– Evite divagar sobre o assunto
– Não fantasie e escreva sobre o que você não tem certeza do que está falando
– Tamanho da resposta não é proporcional à nota
• Seja preciso e maximize o uso de terminologia básica da Programação Modular
– por exemplo, use: acoplamento, interface, encapsulamento, assertivas, padrão de programação, faltas, erros, falhas, etc...
– evite termos demasiadamente genéricos ou não definidos/relevantes neste curso, exemplo: coisa, elemento, classe, etc...
Maio 2009 26 / 32Alessandro Garcia © LES/DI/PUC-Rio
Dicas gerais
• Justifique suas respostas!
– Evite respostas vagas e sem evidências do tipo
• “Sim, a função X viola padrões de programação.”
• Prefira respostas com argumentação e precisão apropriada:– “A 5ª linha de código da função X viola o padrão de identificadores X
porque o prefixo do nome da variável Z....”
– “A expressão A na linha 3 exibe um padrão de falta clássico pois....”
– “O uso de malloc e sizeof na linha 7...”
14
Aula 17Revisão
Alessandro GarciaLES/DI/PUC-Rio
Abril 2010