Saltar para:
Logótipo
This page in english Ajuda Autenticar-se
Projecto da Casa da U. Porto
Você está em: Início > EIC0039
Autenticação




Mapa das Instalações
Edifício A (Administração) Edifício B (Aulas) - Bloco I Edifício B (Aulas) - Bloco II Edifício B (Aulas) - Bloco III Edifício B (Aulas) - Bloco IV Edifício C (Biblioteca) Edifício D (CICA) Edifício E (Química) Edifício F (Minas e Metalurgia) Edifício F (Minas e Metalurgia) Edifício G (Civil) Edifício H (Civil) Edifício I (Electrotecnia) Edifício J (Electrotecnia) Edifício K (Pavilhão FCNAUP) Edifício L (Mecânica) Edifício M (Mecânica) Edifício N (Garagem) Edifício O (Cafetaria) Edifício P (Cantina) Edifício Q (Central de Gases) Edifício R (Laboratório de Engenharia do Ambiente) Edifício S (INESC) Edifício T (Torre do INEGI) Edifício U (Nave do INEGI) Edifício X (Associação de Estudantes)

Métodos Formais em Engenharia de Software

Código: EIC0039     Sigla: MFES

Áreas Científicas
Classificação Área Científica
OFICIAL Engenharia de Software

Ocorrência: 2011/2012 - 1S

Ativa? Sim
Página Web: http://paginas.fe.up.pt/~apaiva/teach/1112/MFES.htm
Página e-learning: http://moodle.fe.up.pt/
Unidade Responsável: Departamento de Engenharia Informática
Curso/CE Responsável: Mestrado Integrado em Engenharia Informática e Computação

Ciclos de Estudo/Cursos

Sigla Nº de Estudantes Plano de Estudos Anos Curriculares Créditos UCN Créditos ECTS Horas de Contacto Horas Totais
MIEEC 0 Plano de estudos oficial 4 - 6 56 162
5
MIEIC 117 Plano de estudos a partir de 2009/10 4 - 6 56 162

Docência - Responsabilidades

Docente Responsabilidade
Ana Cristina Ramada Paiva Regente

Docência - Horas

Teóricas: 2,00
Teórico-Práticas: 2,00
Tipo Docente Turmas Horas
Teóricas Totais 1 2,00
Ana Cristina Ramada Paiva 2,00
Teórico-Práticas Totais 5 10,00
Ana Cristina Ramada Paiva 4,00
Rui Filipe Lima Maranhão de Abreu 6,00

Língua de trabalho

Português - Suitable for English-speaking students

Objetivos

1-CONHECIMENTOS ÚTEIS
Conhecimentos de engenharia de software (nomeadamente, processos de desenvolvimento e modelação de software) e conhecimentos de teoria de computação.
2-OBJETIVOS ESPECÍFICOS
Desenvolver as capacidades de abstração de forma a descrever o que o sistema deve fazer e não a maneira de o fazer. Estar familiarizados com os métodos formais e forma como eles podem contribuir para aumentar a qualidade dos sistemas de software.
3-CONHECIMENTO PRÉVIO
É útil frequência anterior em Engenharia de software, Teoria de computação e Conceção e análise de algoritmos.
4-DISTRIBUIÇÂO PERCENTUAL
Componente científica = 75%
Componente tecnológica = 25%
5-RESULTADO DA APRENDIZAGEM
No final da unidade curricular os estudantes devem ser capazes de:
- aplicar métodos formais de especificação (baseado em modelos; baseado em propriedades; baseado em comportamento) e verificação ("Model-checking", provas formais e teste) no desenvolvimento de sistemas de software.
- identificar os métodos formais existentes e saber quando devem ser aplicados e quais são mais adequados em cada caso.

Programa

1. Introdução
1.1 O que são métodos formais.
1.2 Importância e aplicabilidade dos métodos formais no desenvolvimento de software.
1.3 Modelos de ciclo de vida e processos de desenvolvimento de software incorporando métodos formais.
1.4 Especificação, refinamento, implementação, verificação e validação.
1.5 Classificação de métodos formais.
1.6 Modelos explícitos vs implícitos, executáveis vs não executáveis.
1.7 Técnicas de verificação formal.

2. "Alloy Constraint Analyzer", para modelação e análise semântica
2.1 Modelação declarativa.
2.2 Diferenças relativas a "model checking".
2.3 Comandos Alloy.
2.4 Funções; Predicados; Factos; Asserções e Verificações ("Checks").
2.5 Modelação estática vs dinâmica.
2.6 Simular a execução de uma operação.
2.7 Verificar propriedades "safety".
2.8 A ferramenta Alloy analyzer.

3. Lógica e "Model Checking"
3.1 Lógica proposicional, de predicados, temporal linear (LTL), temporal ramificada (CTL).
3.2 Representação de estados.
3.3 "Model Checking":
3.3.1 Propriedades: "Safety"; "Fairness"; "Liveness"; Universalidade; Inevitabilidade; Possibilidade; Ausência; Resposta; Precedência.
3.3.2 Problema de Explosão de estados (técnicas existentes para minorar este problema): Estado Simbólico; "Bounds"; "On-the-fly"; "Partial Order Reduction (POR)"; Abstracção.

4. Especificação baseada em modelos
4.1 As linguagens VDM-SL e VDM++.
4.2 Representação de dados com base em estruturas matemáticas (conjuntos, sequências e funções finitas).
4.3 Especificação com estado e sem estado.
4.4 Definição de tipos, valores e funções.
4.5 Definição de classes, variáveis de instância e operações.
4.6 Expressões e instruções.
4.7 Design-by-contract: definição de invariantes, pré-condições e pós-condições.
4.8 Descrição de algoritmos, especificações executáveis.
4.9 Análise de consistência da especificação: obrigações de prova e teste.
4.10 Ligação do VDM++ ao UML.
4.11 Geração de código a partir de uma especificação formal.
4.12 A ferramenta VDMTools.

5. Provas Formais
5.1 Aplicação de lógica de Hoare à prova de correcção de algoritmos.
5.2 Linguagem de especificação Gallina: tipos e expressões; proposições e provas; tipos de dados indutivos; tácticas de prova e automação; predicados indutivos.
5.3 Prova de correcção de programas.
5.4 A ferramenta Jape.

Bibliografia Obrigatória

Daniel Jackson; Software Abstractions, MIT Press, 2006. ISBN: 0-262-10114-9
Fitzgerald, John; Validated designs for object-oriented systems. ISBN: 1-85233-881-4
Richard Bornat; Proof and Disproof in Formal Logic, Oxford University Press, 2005. ISBN: 0-19-8530269
B. Bérard; M. Bidoit; A. Finkel; F. Laroussinie; A. Petit; L. Petrucci; Ph. Schnoebelen; P. McKenzie; Systems and Software Verification - Model Checking Techniques and Tools, Springer, 2001. ISBN: 3-540-41523-8

Bibliografia Complementar

Clarke, Jr., Edmund M.; Model checking. ISBN: 0-262-03270-8
Fitzgerald, John; Modelling systems. ISBN: 0-521-62605-6
Alagar, V. S.; Specification of software systems. ISBN: 0-387-98430-5

Métodos de ensino e atividades de aprendizagem

As aulas teóricas serão usadas para exposição e estudo dos conteúdos programáticos, bem como, realização de exercícios práticos.
As aulas práticas serão usadas para realização de exercícios, para contactar com a diversas ferramentas e para a realização de trabalhos práticos.

Software

Alloy Analyzer
VDMTools
JAPE

Palavras Chave

Ciências Tecnológicas > Engenharia > Engenharia de computadores
Ciências Tecnológicas > Tecnologia > Tecnologia de computadores > Tecnologia de software

Tipo de avaliação

Avaliação distribuída com exame final

Componentes de Avaliação

Descrição Tipo Tempo (Horas) Peso (%) Data Conclusão
Participação presencial (estimativa) Participação presencial 56,00
Mini teste e exame final Exame 6,00 2012-02-10
Estudo para realização do trabalho prático Trabalho laboratorial 20,00 2011-12-20
Trabalho prático Trabalho laboratorial 40,00 2011-12-20
Total: - 0,00

Componentes de Ocupação

Descrição Tipo Tempo (Horas) Data Conclusão
Estudo individal e acompanhamento das aulas Estudo autónomo 40 2011-12-20
Total: 40,00

Obtenção de frequência

Nota mínima de 45% na classificação do trabalho prático.
A presença nas aulas teórico-práticas é registada e obrigatória conforme legislação em vigor.

Fórmula de cálculo da classificação final

Avaliação distribuída com exame final, com as seguintes componentes:
(A) mini teste de Alloy, com consulta, duração de 1h, peso 40%, nota mínima de 45%.
(B) trabalho prático de VDM++, peso 25%, nota mínima de 45%.
(C) exame final com consulta, duração 1h30, peso 35%, nota mínima de 45%.

Classificação Final = (A)*40% + (B)*25% + (C)*35%

Nota: em todo o caso, a classificação final não pode exceder em mais de 3 valores a classificação do exame arredondada para o inteiro mais próximo.
Os alunos que não obtiverem aprovação no mini teste de Alloy poderão fazer um módulo de avaliação adicional no exame final da unidade curricular.
Oa melhoria da componente de Alloy só poderá ser melhorada no exame de recurso.

Provas e trabalhos especiais

Mini teste de Alloy na aula teórica do dia 19 de outubro.

Trabalho prático de VDM++:
- entrega até às 23h do dia 25 de novembro;
- defesa do trabalho prático durante as aulas práticas da semana de 28 novembro a 2 de dezembro.

A defesa dos trabalhos práticos é obrigatória para TODOS os alunos.

Avaliação especial (TE, DA, ...)

Os trabalhos são obrigatórios para todos os alunos, mesmo para os alunos dispensados de frequência às aulas.

Os alunos dispensados de frequência às aulas devem contactar o docente para sessões especiais de acompanhamento dos trabalhos.

A defesa dos trabalhos práticos é obrigatória para TODOS os estudantes.

Melhoria de classificação

- A classificação do mini teste só poderá ser melhorada em exame de recurso.
- Os alunos que não obtiverem aprovação no mini teste poderão fazer um módulo adicional de 1h no exame final.
- As classificações obtidas no trabalho prático podem ser melhoradas na edição seguinte
da disciplina
- A classificação do exame pode ser melhorada em exame de recurso.

Observações

Os alunos com frequência à disciplina do ano anterior terão que fazer exame de 2h30 (com a componente de Alloy e VDM). A classificação no módulo de Alloy será usada como classificação da componente do mini teste desta edição. A classificação obtida no trabalho de VDM++ do ano anterior será usada como classificação do trabalho de VDM++ desta edição.
Recomendar Página Voltar ao Topo
Copyright 1996-2019 © Faculdade de Engenharia da Universidade do Porto  I Termos e Condições  I Acessibilidade  I Índice A-Z  I Livro de Visitas
Página gerada em: 2019-04-26 às 17:31:57 | Política de Utilização Aceitável | Política de Proteção de Dados Pessoais