Métodos Formais em Engenharia de Software |
---|
Cálculo de Sistemas de Informação |
Programação Ciber-física |
Verificação Formal |
Calendário | Sumários |
Anos anteriores |
Alumni |
(This page in English)
Slides de apresentação do perfil.
Bem vindo à página da edição de 2023/24 do perfil de Métodos Formais de Programação (MFP), que continua a unidade curricular obrigatória de Métodos Formais em Engenharia de Software (MFES).
Este perfil de especialização do MEI é lecionado por docentes do Grupo de Lógica e Métodos Formais com tradição na investigação e ensino de métodos formais aplicados ao desenvolvimento de software. Todos fazem também parte do centro de investigação HASLab (High-Assurance Software Laboratory) da Universidade do Minho e do INESC TEC, em que se vem consolidando ‘know-how’ em métodos formais desde há mais de 30 anos.
As unidades curriculares que actualmente fazem parte do perfil MFP são as seguintes:
1ºS | MFES | ||
2ºS | CSI | VF | PCF |
Nos seu conjunto, estas UCs ensinam as principais competências de que depende o projecto de aplicações fiáveis, à escala industrial. Na sua componente teórica, a visão é a de abordar problemas de software segundo uma autêntica perspectiva de engenharia, que permite - através da modelos sobre os quais é possível raciocinar e calcular - prever o comportamento dos programas antes de serem executados. Uma vez escritos, MFP ensina como fazer a sua verificação, um ingrediente essencial à qualidade do software.
Historial: o perfil de MFP foi criado em 2007/08, segundo as orientações do Processo de Bolonha. Designava-se então MFES. Todo o seu historial pode ser consultado nos anos anteriores.
Os 20 ECTSs deste perfil e da unidade curricular de MFES estão distribuídos pelas seguintes área de conhecimento, segundo as IEEE/ACM Curriculum Guidelines for Software Engineering:
In my career in software, I’ve seen many good languages, tools and methods adopted. But none had the impact we’d hoped for. I came to realize that there’s one thing that makes for great software: conceptual clarity in the design.
Daniel Jackson about his new book The Essence of Software
In late 1967 the Study Group recommended the holding of a working conference on Software Engineering. The phrase “software engineering” was deliberately chosen as being provocative, in implying the need for software manufacture to be based on the types of theoretical foundations and practical disciplines, that are traditional in the established branches of engineering.
Garmisch NATO conference report, 1968
There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies.
It is easier to write an incorrect program than understand a correct one.
Program testing can be used to show the presence of bugs, but never to show their absence!
Simplicity does not precede complexity, but follows it.
Software Development: A Rigorous Approach by C.B. Jones