content/CP/T - Aula 2 - 19 Setembro.md

@@ -1,4 +1,3 @@
-#CP
 ## Conteúdo
 - cache em arquiteturas multicore
 - code profiling

content/MFES/MFES - UC Details.md

@@ -1,9 +1,7 @@
-11 Setembro 2023 - #MFES
-
 ## Programa
 
 1. Lógicas para especificação formal
-	1. [[MFES/T - Aula 2#Proposicional Logic (PL)| Lógica Proposicional (PL)]]
+	1. [[T - Aula 2 - 18 Setembro 2023#Proposicional Logic (PL)| Lógica Proposicional (PL)]]
 	2. Lógica de Primeira Ordem (FOL)
 	3. Lógica relacional (RL)
 	4. Lógica temporal linear (LTL)

content/MFES/T - Aula 2 - 18 Setembro 2023.md

@@ -1,10 +1,8 @@
-18 Setembro 2023 -  #MFES
-
 # Conteúdo
-1. [[MFES/T - Aula 2#1. Intro|Intro]]
-	1. [[MFES/T - Aula 2#1.1 SAT|SAT]]
-	2. [[MFES/T - Aula 2#1.2 Proposicional Logic (PL)|Lógica Proposicional]]
-3. [[MFES/T - Aula 2#SAT Solvers|SAT Solvers]]
+1. [[T - Aula 2 - 18 Setembro 2023#1. Intro|Intro]]
+	1. [[T - Aula 2 - 18 Setembro 2023#1.1 SAT|SAT]]
+	2. [[T - Aula 2 - 18 Setembro 2023#1.2 Proposicional Logic (PL)|Lógica Proposicional]]
+3. [[T - Aula 2 - 18 Setembro 2023#SAT Solvers|SAT Solvers]]
 
 # 1. Intro
 *Formal modeling* - formally represent the system and its properties in the syntactic conventions that the tool understands and can process. 

content/MFES/TP - Aula 1 - 18 Setembro.md

@@ -1,9 +1,7 @@
-18 Setembro 2023 -  #MFES
-
 ## Ficha 1
 
 > [!note]
-> As resoluções dos exercícios aqui contidos podem conter erros. Se detetares um problema (e se o souberes resolver) por favor contacta-nos.
+> As resoluções dos exercícios aqui contidos pode conter erros. Se detetares um problema (e se o souberes resolver) por favor contacta-nos.
 
 
 

content/RAS/T - Aula 1.md

@@ -1,34 +0,0 @@
-12 Setembro 2023 - #RAS 
-
-# Definition of Software Engineering
-Application of a systematic, disciplined and quantifiable approach to the analysis, design , implementation and exploitation of software systems, resorting to knowledge, principles, techniques and methods that originate from the empirical-scientific advances, in an ethical context to satisfy the necessities of human development.
-
-# Team
-- João M. Fernandes
-- André L. Ferreira    
-- Manuel Alves
-- Paulo Rafael Sousa
-
-# Evaluation
-
-- Test - January 02 
-	- Min grade: 8.00 
-- Exam - January 23
-- Project
-	- Min grade: 10.00
-	- **phase 1**: teams of five students;
-		- deadline: October 20
-	- **phase 2**: teams unite to create bigger teams project
-		- deadline: November 24
-	- **phase 3**: teams unite to create bigger teams project
-		- deadline: December 22
-	- **project presentation**: Jan 08–12
-	- project mark in each phase is affected by individual performance:
-		- individual variation (-2..+2) (provided by each team)
-		- sum of variations is 0 within the team
-	- project mark = (mark1 + mark3) /2
-	- project mark in 2022/23 can be reused this year (send email)
-- Final Mark = min(0.6×max(test, project)+0.4×min(test, project), test+2.5)
-
-
-[[RAS/T - Aula 2|Próxima aula]]

content/RAS/T - Aula 2 - 19 Setembro 2023.md

@@ -1,11 +1,9 @@
-19 Setembro 2023 - #RAS
-
 ## Contents
-1. [[RAS/T - Aula 2#Definition of Requirement|Definition of requirement]]
-2. [[RAS/T - Aula 2#Functional requirements|Functional requirements]]
-3. [[RAS/T - Aula 2#Non-functional requirements|Non-functional requirements]]
-4. [[RAS/T - Aula 2#4. User and system requirements|User and system requirements]]
-5. [[RAS/T - Aula 2#Recap|Recap]]
+1. [[T - Aula 2 - 19 Setembro 2023#Definition of Requirement|Definition of requirement]]
+2. [[T - Aula 2 - 19 Setembro 2023#Functional requirements|Functional requirements]]
+3. [[T - Aula 2 - 19 Setembro 2023#Non-functional requirements|Non-functional requirements]]
+4. [[T - Aula 2 - 19 Setembro 2023#4. User and system requirements|User and system requirements]]
+5. [[T - Aula 2 - 19 Setembro 2023#Recap|Recap]]
 
 ## 1. Definition of Requirement
 The requirements express the users necessities and restrictions that are
@@ -159,6 +157,3 @@ adopted for the user requirements.
 4. The requirements can be designated as either user or system requirements.
 5. User requirements are related to the problem domain and are usually expressed in a natural language.
 6. A system requirement is oriented towards the solution domain and is a detailed specification of a requirement, generally in the form of a formal model of the system.
-
-[[Próxima aula]]
-[[RAS/TP - Aula 1|Aula prática]]

content/RAS/TP - Aula 1.md

@@ -1,101 +0,0 @@
-20 Setembro 2023 - #RAS
-
-> [!note]
-> As resoluções dos exercícios aqui contidos podem conter erros. Se detetares um problema (e se o souberes resolver) por favor contacta-nos.
-
-
->[!help]+ Ex. 1
->Defina se os seguintes requisitos são funcionais ou não funcionais:
->1. Ter a possibilidade de exportar o ficheiro a que se refere a Portaria n. 321-A/2007, de 26 de março;
->2. Possuir um sistema que permita identificar a gravação do registo de faturas ou documentos equivalentes e talões de venda, através de um algoritmo de cifra assimétrica e de uma chave privada de conhecimento exclusivo do produtor do programa;
->3. Possuir um controlo de acesso ao sistema informática, obrigando a uma autenticação de cada utilizador;
->4. Não dispor de qualquer função que, no local, ou remotamente, permita alterar, direta ou indiretamente, a informação de natureza fiscal, sem gerar evidência agregada à informação geral.
->   
->   >[!hint]- Resolução
->   >1. requisito funcional: define uma feature do sistema
->   >2. *secção inicial* -> requisito funcional: garantir a integridade dos dados; *secção da encriptação simétrica* -> requisito não funcional : é um requisito tecnológico
->   >3. requisito funcional: defina uma feature do sistema; requisito não funcional :  é um requisito de segurança
->   >4. não requisito: não define uma feature (é uma "não-feature") e não se qualifica a requisito não-funcional
-
-
->[!help]+ Ex 3.1 (Naveda and Seidman, 2006, pp. 39–40)
-> Which is the type of elements less appropriate to be included in a requirements document?
->1. design restrictions
->2. product delievery constraints
->3. funcionalities to make available
->4. performance characteristics
->   
->>[!hint]- Resolução
->>Option 2 is the less appropriate.
->>
->>- Option 1 contains non-requirements but has to do with the development of the software, thus it's important to be included in the requirement phase.
->>- Option 2 has nothing to do with the development at all and contains restrictive directives.
->>- Option 3. is a functional requirement.
->>- Option 4. is a non-functional requirement.
-
-
->[!help]+ Ex. 3.2 (Naveda and Seidman, 2006, pp. 33–34)
->Which is the type of requirements that should not be included in a requirements document?
->
->1. functional requirements
->2. maintenance requirements
->3. project requirements
->4. performance requirements
->   
->>[!hint]- Resolução
->>Option 3. should not be included.
->>
->>- Option 1. is essential.
->>- Option 2. pertains to the directives that will define how the system will be maintained and managed in the future.
->>- Option 3. defines the circumstances around the project: it touches budget, the team members, other departments (than the development team), etc. It is too encompassing and it is not always about the development of the system. *The requirements document should be in the project documents*, not the other way around.
->>- Option 4. is a non-functional requirement, therefore  its inclusion is necessary.
-
-
->[!help]+ Ex. 3.3 (Naveda and Seidman, 2006, pp. 41–42)
->Which is the element that must be included in a requirements document?
->
->1. acceptance/validation procedures
->2. delivery plans
->3. quality attributes
->4. activities to guarantee the quality
->   
->>[!hint]- Resolução
->>Option 3. is a must.
->>
->>1. Option 1. pertains to the testing procedures.
->>2. Option 2. pertains to the expected plans of the delivery of the software (aka versions: version alpha, version beta,...).
->>3. Option 3. is a synonym for non-functional requirements.
->>4. Option 4. means the indicated protocol which regulates the quality of the product.
-
-
->[!help]+ Ex. 3.4 (Naveda and Seidman, 2006, pp. 57–58)
->Which of the following arguments is the most solid/strong to justify the specification of the non-functional requirements of a system?
->
->1. The non-functional requirements should only be considered in development contexts subject to tight restrictions (resources, budget, or deadlines).
->2. The non-functional requirements are only external characteristics of the system and can be obtained later.
->3. If a functionality is present in the system, the non-functional requirements determine how usable and useful it is.
->4. The non-functional requirements take less time to specify than the functional requirements.
->   
->>[!hint]- Resolução
->>Option 3. is the best justification.
->>
->>Non-functional requirements are, colloquially, an enumeration of restrictions to the functional requirements being defined by a developing system.
->>Non-functional requirements are the buffer of quality of the product - these cannot be defined later. Their determination may take even more time than the definition of functional requirements since, sometimes, they can be even more implicit than their counterpart. Their determination should also be independent of resources or budgets; otherwise, there can/will be consequences on the quality of the software.
-
-
->[!help]+ Ex. 3.5
->Consider the following requirement: *The system should be easy to use for trained persons.* 
->
->Classify this requirement with respect to its type. 
->1. Functional
->2. Non-functional
->
->Is this requirement verifiable? Justify.
->   
->>[!hint]- Resolução
->>Option 2., since it defines no feature.
->>
->>In terms of verifiability:
->>What is a trained person? That is debatable. Is it a person with 1h of experience, 3h, 5h? This needs to be defined. Also, what is easy? Is it defined by the number of errors this person commits (commit less than 3 errors in this determined feature - this is considered "easy")? Use correctly 80% of the software and it's "easy" and intuitive for the tester? This also needs defining.
->
-

content/index.md

@@ -4,7 +4,7 @@ Basicamente, isto é uma sopa de letras com alguma lógica por detrás (mas não
 ### Ano 1 (Mestrado)
 1. [[MFES - UC Details| (MFES) Métodos Formais de Engenharia de Software]]
 2. (ASCN) Aplicações e Serviços de Computação em Nuvem
-3. [[RAS/T - Aula 2|(RAS) Requisitos e Arquiteturas de Software]]
+3. (RAS) Requisitos e Arquiteturas de Software
 4. (CP) Computação Paralela
 5. (DAA) Dados e Aprendizagem Automática
 6. (ESR) Engenharia de Serviços em Rede