fix
This commit is contained in:
parent
d5ca6727b4
commit
14de295a1b
14 changed files with 0 additions and 851 deletions
|
|
@ -1,70 +0,0 @@
|
|||
🌫 11 Setembro 2023 - #ASCN
|
||||
|
||||
- ## Complex Structures: Challenges
|
||||
- ### 1. Deployment
|
||||
- Multiple components with specific requirements
|
||||
- Heterogeneous hardware, software and services (e.g., cloud computing services
|
||||
- ### 2. Management + Configuration
|
||||
- Specific to each software/hardware component
|
||||
- Optimal configurations will change over time...
|
||||
- ### 3. Monitoring + Benchmarking
|
||||
id:: 65120d55-d904-4ef5-bbbb-647bf02e05c9
|
||||
- Finding anomalies (performance, failures, ...) in complex applications and infrastructures
|
||||
- ## Agile Development
|
||||
**Quick reaction to frequent small changes!**
|
||||
- Rests on formal (versioned) source, binary and documentation repositories
|
||||
- Unambiguous current state
|
||||
- Ability to back track
|
||||
- Automated build and test
|
||||
- Fast feedback
|
||||
- Fast iterations
|
||||
- ## Operations
|
||||
- Manual provisioning and configuration
|
||||
- Informal communication between qualification and production stages
|
||||
- Consequences:
|
||||
- Not repeatable or reproducible
|
||||
- Configuration drift
|
||||
- “Snowflake” servers (don't even look at it…)
|
||||
- Subjective monitoring
|
||||
- ## Infrastructure as Code
|
||||
**Include infrastructure scripts in agile process!**
|
||||
- Hardware provisioning with scripts
|
||||
- In contrast to: physically unboxing and plugging
|
||||
- Software provisioning with scripts
|
||||
- In contrast to: clicking through setup wizards
|
||||
- Configuration with scripts
|
||||
- In contrast to: clicking through control panels
|
||||
- ## DevOps
|
||||
**Supports fast, frequent, small changes!**
|
||||
- Development and deployment are self-documenting and versioned
|
||||
- Deployment is reproducible and repeatable
|
||||
- Servers are disposable and consistent
|
||||
- ## Roadmap
|
||||
- Distributed systems architectures & deployment
|
||||
- Common distribution patterns
|
||||
- Reliability and scalability
|
||||
- Automatic provision and configuration
|
||||
- Cloud computing
|
||||
- Services and abstractions
|
||||
- Infrastructure management (virtualization, storage, ...)
|
||||
- Monitoring and evaluation
|
||||
- Monitoring frameworks and metrics
|
||||
- Benchmarking
|
||||
- ## Evaluation
|
||||
- **50%** - project
|
||||
- min: 10 values
|
||||
- checkpoint 1: 17/11/2023
|
||||
- checkpoint 2: 07/12/2023
|
||||
- final report: 19/12/2023
|
||||
- presentation: 08-12/01/2024 (week)
|
||||
- **50%** - written exam
|
||||
- min: 8 values
|
||||
- 12/12/2023
|
||||
- ## Team
|
||||
- João Paulo - jtpaulo@di.uminho.pt
|
||||
- Francisco Maia - fmaia@di.uminho.pt
|
||||
- Tânia Esteves - d12729@di.uminho.pt
|
||||
- Cláudia Brito – d13235@di.uminho.pt
|
||||
|
||||
|
||||
[[ASCN/T - Aula 2|Next class: T - Aula 2]]
|
||||
|
|
@ -1,83 +0,0 @@
|
|||
🌫 18 Setembro 2023 - #ASCN
|
||||
|
||||
- ## Why distributed systems?
|
||||
- Modularity, decoupling different concerns.
|
||||
- Performance.
|
||||
- Dependability
|
||||
- ## How to distribute?
|
||||
- ### 1. Monolythic system
|
||||
- Architecture: [[Monolithic system.excalidraw]]
|
||||
- Multiple services for multiple targets in the same server
|
||||
- ## 2. Distributed systems
|
||||
id:: 65120d55-6bed-47db-bd53-cc4f627c33dc
|
||||
- Main distribution concerns:
|
||||
1. Replication
|
||||
2. Partitioning
|
||||
3. Service-orientation
|
||||
- All of these address scaling out a service/application.
|
||||
- Not mutually exclusive, can be combined.
|
||||
- ### 2.1 Replication
|
||||
- Architecture: [[Replication.excalidraw]]
|
||||
- Multiple copies of the same data and functionality
|
||||
- Addresses resilience and scale-out
|
||||
- ### 2.2 Partitioning
|
||||
- Architecture: [[Partitioning.excalidraw]]
|
||||
- A server is split horizontally (Sharding).
|
||||
- Addresses scale-out.
|
||||
- Can be applied to computation, data, ...
|
||||
- ### 2.3 SOA - Service-Oriented Architecture
|
||||
- Architecture: [[SOA.excalidraw]]
|
||||
- Addresses scale-out and modularity.
|
||||
- Example: micro-services.
|
||||
- #### 2.3.1 Microservices
|
||||
- Each service implements specific functionality.
|
||||
- Services can scale independently.
|
||||
- Decomposition may be troublesome: how micro is micro?
|
||||
- Consistency.
|
||||
- Complex deployment and testing
|
||||
- ## Distributed architectures
|
||||
- ### 1. Client-server
|
||||
- Architecture: [[client-server.excalidraw]]
|
||||
- Functionality and data are in the server.
|
||||
- A stub runs embedded in the client.
|
||||
- The stub is part of the server software package
|
||||
- E.g., the Web (“protocol” is HTTP)
|
||||
- ### 2. Proxy Server
|
||||
- Architecture: [[proxy.excalidraw]]
|
||||
- Multiple servers can be used transparently.
|
||||
- The proxy is a performance and availability bottleneck.
|
||||
- E.g. MongoDB
|
||||
- ### 3. Master Server
|
||||
- Architecture: [[master.excalidraw]]
|
||||
- Scale out!
|
||||
- E.g. HDFS
|
||||
- ### 4. Server Group
|
||||
- Architecture: [[server-group.excalidraw]]
|
||||
- All servers can process requests.
|
||||
- Coordination may be necessary.
|
||||
- Resiliency!
|
||||
- E.g. ZooKeeper
|
||||
- ### 5. Bus
|
||||
- Architecture: [[bus.excalidraw]]
|
||||
- The bus routes messages.
|
||||
- Participants publish and consume messages to/from the bus.
|
||||
- Decouples producers from consumers.
|
||||
- **Flexibility!**
|
||||
- E.g. Kafka
|
||||
- ### 6. Multi-tier
|
||||
- Architecture: [[multi-tier.excalidraw]]
|
||||
- Each server acts as a client of the next tier.
|
||||
- Allows independent deployment and scaling of different functionality.
|
||||
- E.g. AS + DBMS:
|
||||
- “protocol A” == Web (e.g.)
|
||||
- “Stub B” == Database Driver!
|
||||
- “protocol B” uses SQL
|
||||
- #### 6.1 State in multi-tier
|
||||
- Persistent state is harder to replicate and shard.
|
||||
- Computation is easier to replicate and shard.
|
||||
- No state in upper tiers:
|
||||
- Web browser
|
||||
- Transient / cached state in middle tiers:
|
||||
- Application server
|
||||
- Persistent state at lower tiers:
|
||||
- Database
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
20 de Setembro 2023 - #CP
|
||||
|
||||
> [!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.
|
||||
|
||||
> [!note]
|
||||
> These resolutions are using the file ***mmult.c*** available and developed by the professors.
|
||||
## Ex. 1
|
||||
a)
|
||||
> [!help]- What is the complexity of the MM (i.e., in big O notation, where N is the problem size and NxN is the matrix size)?
|
||||
> O()
|
||||
|
||||
>[!hint]- Big O Notation Cheat Sheet
|
||||
>- Constant: O(1)
|
||||
>- Linear time: O(n)
|
||||
>- Logarithmic time: O(n log n)
|
||||
>- Quadratic time: O(n^2)
|
||||
>- Exponential time: O(2^n)
|
||||
>- Factorial time: O(n!)
|
||||
|
||||
>[!help]- What increase in execution time is expected when the N doubles?
|
||||
|
||||
>[!help]- Which component of the performance equation is affected (e.g., \#I, CPI or Tcc)?
|
||||
>
|
||||
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
#CP
|
||||
## Conteúdo
|
||||
- cache em arquiteturas multicore
|
||||
- code profiling
|
||||
- instruction-level paralelism
|
||||
- Data dependency
|
||||
- branch prediction
|
||||
-
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
21 Setembro 2023 - #DAA
|
||||
|
||||
##
|
||||
|
|
@ -1,76 +0,0 @@
|
|||
21 Setembro 2023 - #DAA
|
||||
|
||||
- ## Types of Data
|
||||
|
||||
-Numerical
|
||||
- Discrete Data ({1,2,3,...})
|
||||
- Continuous Data (\[1, +$\infty$])
|
||||
- *Categorical* (binary, languages, ...)
|
||||
- **Ordinal** (ratings of 1 to 5)
|
||||
|
||||
*not-scaled
|
||||
**scaled
|
||||
|
||||
#+BEGIN_EXAMPLE - Qual o tipo de dado que representa a quantidade de gasóleo?
|
||||
Numérico: continuous data
|
||||
#+END_EXAMPLE
|
||||
|
||||
>[!example]- Qual o tipo de dado que representa a quantidade de gasóleo?
|
||||
>Numérico: continuous data
|
||||
|
||||
>[!example]- Qual o tipo de dado que representa a nacionalidade?
|
||||
>Categórico
|
||||
|
||||
>[!example]- Qual o tipo de dado que representa a idade?
|
||||
>Numérico: discreto
|
||||
- ## Mean, Median & Mode
|
||||
- #+BEGIN_TIP
|
||||
A mean in math is the average of a data set, found by adding all numbers together and then dividing the sum of the numbers by the number of numbers
|
||||
#+END_TIP
|
||||
- >[!hint]+
|
||||
>A **mean** in math is the average of a data set, found by adding all numbers together and then dividing the sum of the numbers by the number of numbers.
|
||||
- ## Standard Deviation & Variance
|
||||
- ## Probability Density functions
|
||||
- ## Percentiles
|
||||
|
||||
There are 3 important percentiles:
|
||||
- 50% - median
|
||||
- 25% - 1st percentile
|
||||
- 75% - 3rd percentile
|
||||
|
||||
>[!note]+
|
||||
>These 3 percentiles allow the creation of box plot graphs. These specific graphs allow the discovery and presentation of outliers.
|
||||
- ## Covariance & Correlation
|
||||
|
||||
>[!hint]+
|
||||
>**Covariance** measures the direction of a relationship between two variables, while **correlation** measures the strength of that relationship.
|
||||
|
||||
Covariance is hard to interpret, thus correlation is used instead.
|
||||
In a dataset, correlations >0.5 are considerable.
|
||||
|
||||
>[!caution] Correlation does not mean causation!
|
||||
- ## Practical session of the class: miniconda
|
||||
IDEs: PyCharm, VS Code, (Jupyter - not recommended)
|
||||
|
||||
Depois de instalar o miniconda, correr os seguintes comandos:
|
||||
- conda create --name daaEnv python=3.10
|
||||
- conda activate daaEnv
|
||||
- python --version
|
||||
- conda install pandas
|
||||
- conda install xlrd
|
||||
- conda install xlwt
|
||||
- conda install matplotlib
|
||||
- conda install seaborn
|
||||
- conda install scikit-learn
|
||||
- conda install jupyterlab
|
||||
- conda list
|
||||
- ## Resource links
|
||||
- https://en.wikipedia.org/wiki/Average
|
||||
- https://en.wikipedia.org/wiki/Median
|
||||
- https://en.wikipedia.org/wiki/Mode_(statistics)
|
||||
- https://en.wikipedia.org/wiki/Standard_deviation
|
||||
- https://en.wikipedia.org/wiki/Variance
|
||||
- https://en.wikipedia.org/wiki/Probability_density_function
|
||||
- https://en.wikipedia.org/wiki/Percentile
|
||||
- https://en.wikipedia.org/wiki/Covariance
|
||||
- https://en.wikipedia.org/wiki/Correlation
|
||||
|
|
@ -1,42 +0,0 @@
|
|||
🌫 14 Setembro 2023 - #DAA
|
||||
|
||||
>[!note]+ Definition: Machine Learning
|
||||
>Machine learning refers to a system capable of the autonomous acquisition and integration of knowledge. This capacity to learn from experience, analytical observation, and other means, results in a system that can continuously self-improve and thereby offer increased efficiency and effectiveness.
|
||||
|
||||
>[!note]+ Tom Mitchell, Machine Learning (1997)
|
||||
>The field of machine learning is concerned with the question of how to construct computer programs that automatically improve with experience.
|
||||
|
||||
## Conteúdo
|
||||
1. Dados
|
||||
1. Dados, Informação e Conhecimento
|
||||
2. Dados Estruturados, Não Estruturados e Híbridos
|
||||
2. Extração de Conhecimento de Dados
|
||||
1. Caracterização do processo de extração de conhecimento
|
||||
2. Experimentação de casos de estudo e aplicação prática
|
||||
3. Resolucação de casos de estudo e aplicação prática
|
||||
3. Sistemas de Apendizagem
|
||||
4. Aprendizagem automática
|
||||
1. Aprendizagem supervisionada
|
||||
2. Aprendizagem não-supervisionada
|
||||
3. Aprendizagem por reforço
|
||||
4. Redes Neuronais
|
||||
5. Conjunto de Modelos
|
||||
6. Computação Natural (evolucionária, inteligência de enxames)
|
||||
|
||||
|
||||
## Team
|
||||
- Vitor Alves: valves@di.uminho.pt
|
||||
- César Analide: analide@di.uminho.pt
|
||||
- Filipa Ferraz: D7266@di.uminho.pt
|
||||
- Bruno Fernandes: bruno.fernandes@algoritmi.uminho.pt
|
||||
- Dalila Durães: dad@di.uminho.pt
|
||||
|
||||
## Avaliação
|
||||
- **40%** - Prova escrita
|
||||
- Prova: 14 de Dezembro
|
||||
- Recurso: 18 de Janeiro
|
||||
- **60%** - Trabalho de grupo
|
||||
- 1ª fase: 23 de Novembro
|
||||
- fase final: 11 de Janeiro
|
||||
- avaliação pelos pares: 27 de Janeiro 2023
|
||||
|
||||
|
|
@ -1,91 +0,0 @@
|
|||
🌫 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.
|
||||
|
||||
|
||||
|
||||
> [!help]+ Ex 1 (Configuração de produtos)
|
||||
> Certos produtos, como é o caso dos automóveis, são altamente personalizáveis, mas podem haver dependências entre as configurações. Os clientes podem não estar cientes de todas essas dependências, e poderão escolher opções de configuração inconsistentes.
|
||||
> Como são muitas configurações e muitas dependências, podemos usar um SAT solver para verificar se o cliente escolhe opções de configuração consistentes. Para isso, podemos seguir os seguintes passos:
|
||||
>
|
||||
> 1. Codificar as dependências entre configurações como uma formula proposicional $\psi$
|
||||
> 2. Codificar as opções selecionadas pelo cliente como uma fórmula proposicional $\phi$.
|
||||
> 3. Usar o SAT solver para verificar se $\psi \land \phi$ não é contraditório.
|
||||
>
|
||||
> Considere agora a seguinte dependência entre as configurações disponíveis para a personalização de um automóvel:
|
||||
>
|
||||
> *"O ar condicionado Thermotronic comfort requer uma bateria de alta capacidade, exceto quando combinado com motores a gasolina de 3,2 litros."*
|
||||
>
|
||||
> Será que um cliente pode escolher o ar condicionado Thermotronic comfort, uma bateria de pequena capacidade e não escolher o motor de 3,2 litros? Como poderia responder a esta pergunta com a ajuda de um SAT solver?
|
||||
>
|
||||
> > [!tip]- Resolução
|
||||
> > Legenda de variáveis utilizadas:
|
||||
> > A - ar condicionado
|
||||
> > B - bateria alta capacidade
|
||||
> > C - motor 3,2 L
|
||||
> >
|
||||
> >$A \land \neg B \implies G \equiv \neg (A \land \neg B) \lor G \equiv \neg A \lor B \lor G$
|
||||
> >
|
||||
> >$(\neg A \lor B \lor G) \land A \land \neg B \land \neg G$ ----- SAT?
|
||||
> >
|
||||
>
|
||||
|
||||
|
||||
> [!help]+ Ex 3 (Configuração de computadores)
|
||||
> Uma loja de eletrónica permite aos seus clientes personalizar o seu computador, escolhendo entre dois modelos de motherboards e dois modelos de monitor. Cada computador tem que ter obrigatoriamente uma única motherboard, um único CPU, uma única placa gráfica e uma única memória RAM. O computador poderá ou não ter um monitor. A personalização do computador deverá obedecer às regras:
|
||||
> 1. A motherboard MB1 quando combinada com a placa gráfica PG1, obriga à utilização da RAM1;
|
||||
> 2. A placa gráfica PG1 precisa do CPU1, exceto quando combinada com a memória RAM2;
|
||||
> 3. O CPU2 só pode estar instalado na motherboard MB2;
|
||||
> 4. O monitor MON1 para poder funcionar precisa da placa gráfca PG1 e da memória RAM2.
|
||||
>
|
||||
>Codifique este problema em lógica proposicional. Assinale claramente o que denota cada variável proposicional que introduzir e escreva um conjunto de fórmulas proposicionais adequado à sua modelação.
|
||||
>
|
||||
> > [!hint]- Resolução
|
||||
> > Legenda de variáveis utilizadas:
|
||||
> > $CPU_1; CPU_2; RAM_1; RAM_2; MB_1; MB_2; PG_1; PG_2; MON_1; MON_2$
|
||||
> >
|
||||
> > Problema modelado:
|
||||
> > 1. $CPU_1 \lor CPU_2$
|
||||
> > 2. $CPU_1 \implies \neg CPU_2$
|
||||
> > 3. $RAM_1 \lor RAM_2$
|
||||
> > 4. $RAM_1 \implies \neg RAM_2$
|
||||
> > 5. $MB_1 \lor MB_2$
|
||||
> > 6. $MB_1 \implies \neg MB_2$
|
||||
> > 7. $PG_1 \lor PG_2$
|
||||
> > 8. $PG_1 \implies \neg PG_2$
|
||||
> >
|
||||
> > 9. $MB_1 \land PG_1 \implies RAM_1$
|
||||
> > 10. $PG_1 \implies CPU_1 \lor RAM_2 \equiv PG_1 \land \neg RAM_2 \implies CPU_1$
|
||||
> > 11. $CPU_2 \implies MB_2$
|
||||
> > 12. $MON_1 \implies PG_1 \land RAM_2$
|
||||
>
|
||||
> Indique, apenas por palavras, como poderia usar um SAT solver para testar as consistências deste conjunto de regras.
|
||||
>
|
||||
> Indique, apenas por palavras, como usaria um SAT solver para se pronuncias quanto à velocidade das seguintes afirmações:
|
||||
> (a) O monitor MON1 só poderá ser usado com uma motherboard MB1.
|
||||
> > [!hint]- Resolução
|
||||
> > ??? $T \models MON_1 \implies MB_1$
|
||||
> > $T, \neg (MON_1 \implies MB_1) UNSAT$
|
||||
> > > [!info] $T \models F$ sse $T, \neg F UNSAT$
|
||||
>
|
||||
> (b) Um cliente pode personalizar o seu computador da seguinte forma: uma motherboard MB2, o CPU1, a placa gráfica PG2 e a memória RAM1.
|
||||
> >[!hint]- Resolução
|
||||
> >$T, MB_2 \land CPU_1 \land PG_2 \land RAM_1$ ---- SAT?
|
||||
|
||||
> [!help]+ Ex 2 (Distribuição de Gabinetes)
|
||||
> Considere que temos 3 gabinetes e queremos distribuir 4 pessoas (Ana=1, Nuno=2, Pedro=3 e Maria=4) por esses gabinetes. Para codificar este problema em lógica proposicional, , vamos ter um conjunto de variáveis proposicionais $x_{p,g}$ com a seguinte semântica:
|
||||
> $x_{p,g}$ é verdade sse a pessoa $p$ ocupa o gabinete $g$, com $p=1..4$ e $g=1..3$
|
||||
>
|
||||
> Considere que forem estipuladas as seguintes regras de ocupação de gabinetes:
|
||||
> 1. Cada pessoa ocupa um único gabinete.
|
||||
> 2. O Nuno e o Pedro não podem partilhar gabinete.
|
||||
> 3. Se a Ana ficar sozinha num gabinete, então o Pedro também terá que ficar sozinho num gabinete.
|
||||
> 4. Cada gabinete só pode acomodar, no máximo, 2 pessoas.
|
||||
>
|
||||
> Escreve um conjunto de fórumlas proposicionais adequado à modelação destas regras.
|
||||
>
|
||||
> >[!tip]- Resolução
|
||||
> > [[Ficha1_ex2.excalidraw]]
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
25 Setembro 2023 - #MFES
|
||||
|
||||
## Links de Resolução de Exercícios
|
||||
1. https://colab.research.google.com/drive/1hz-eUtQNTV_IeOh2mvOWvm0uG7ob5vGG?usp=sharing
|
||||
2. https://colab.research.google.com/drive/1GLws5mIyZhtMvVPQ5ZN4rnJnoccdJWGj?usp=sharing
|
||||
3.
|
||||
|
|
@ -1,123 +0,0 @@
|
|||
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. Intro
|
||||
*Formal modeling* - formally represent the system and its properties in the syntactic conventions that the tool understands and can process.
|
||||
|
||||
Formal Logic = logical language (logical symbols + non-logical symbols) + semantics +proof system
|
||||
|
||||
### 1.1 SAT
|
||||
<iframe title="Boolean Satisfiability Problem - Intro to Theoretical Computer Science" src="https://www.youtube.com/embed/uAdVzz1hKYY?feature=oembed" height="113" width="200" allowfullscreen="" allow="fullscreen" style="aspect-ratio: 1.76991 / 1; width: 100%; height: 100%;"></iframe>
|
||||
|
||||
The Boolean satisfiability (SAT) problem:
|
||||
|
||||
Find an assignment to the propositional variables of the formula such that the formula evaluates to TRUE, or prove that no such assignment exists.
|
||||
|
||||
|
||||
- SAT is an NP-complete decision problem.
|
||||
- SAT was the first problem to be shown NP-complete.
|
||||
- There are no known polynomial time algorithms for SAT.
|
||||
|
||||
|
||||
Usually SAT solvers deal with formulas in conjunctive normal form (CNF)
|
||||
- **literal**: propositional variable or its negation A, ¬A, B, ¬B, C, ¬C
|
||||
- **clause**: disjuntion of literals. (A _ ¬B _ C)
|
||||
- **conjunctive normal form**: conjuction of clauses. (A _ ¬B _ C) ^ (B _ ¬A) ^ ¬C
|
||||
|
||||
> [!info]+ Cook's theorem(1971)
|
||||
> SAT is NP-complete
|
||||
|
||||
|
||||
## 1.2 Proposicional Logic (PL)
|
||||
|
||||
>[!note] Nota
|
||||
>Esta secção basicamente só contém revisão de conceitos. Aconselha-se a ver a coisa rapidamente, porque é só a formalidade de lógica escrita por extenso.
|
||||
|
||||
Let $A$ be an assignment and let $F$ be a formula. If $A(F) = 1$, then we say **$F$ holds under assignment**, or **$A$ models $F$.**
|
||||
We write A $\models F$ iff $A(F)=1$, and $A \not \models F$ iff $A(F) = 0$.
|
||||
|
||||
|
||||
An assignment is a function $A$ : $V_{prop} \implies {0,1}$ , that assigns to every
|
||||
propositional variable a truth value. An assignment $A$ naturally extends to all formulas, $A$ : **Form** $\implies {0,1}$. The truth value of a formula is computed using **truth tables**:
|
||||
|
||||
| F | $A$ | $B$ | $\neg A$ | $A \land B$ | $A \lor B$ | $A \implies B$ | $A \iff B$ | $\bot$ | $\top$ |
|
||||
| --------- | --- | --- | -------- | ----------- | ---------- | -------------- | ---------- | ------ | ------ |
|
||||
| $A_1 (F)$ | 0 | 1 | 1 | 0 | 1 | 1 | 0 | 0 | 1 |
|
||||
| $A_2 (F)$ | 0 | 0 | 1 | 0 | 0 | 1 | 1 | 0 | 1 |
|
||||
| $A_3 (F)$ | 1 | 1 | 0 | 1 | 1 | 1 | 1 | 0 | 1 |
|
||||
| $A_4 (F)$ | 1 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 1 |
|
||||
|
||||
|
||||
|
||||
A formula $F$ is:
|
||||
1. **valid** iff it holds under every assignment. We write $\models F$. A valid formula is called a *tautology*.
|
||||
2. **satisfiable** iff it folds (true) under some assignment.
|
||||
3. **unsatisfiable** iff it holds under no assignment. An unsatisfiable formula is called a *contradiction*.
|
||||
4. **refutable** iff it is not valid.
|
||||
|
||||
> [!tip]+ Proposition
|
||||
> $F$ is **valid** iff $\neg F$ is **unsatisfiable**.
|
||||
|
||||
|
||||
- $F \models G$ iff for every assignment $A$, if $A \models F$ then $A \models G$. We say $G$ is a **consequence** of $F$.
|
||||
- $F \equiv G$ iff $F \models G$ and $G \models F$. We say $F$ and $G$ are **equivalent**.
|
||||
- Let $\Gamma = { F_1, F_2, F_3,... }$ be a set of formulas.
|
||||
- $A \models \Gamma$ iff $A \models F_i$ for each formula $F_i$ in $\Gamma$. We say $A$ models $\Gamma$.
|
||||
- $\Gamma \models G$ iff $A \models \Gamma$ implies $A \models G$ for every assignment $A$. We say $G$ is a **consequence** of $\Gamma$.
|
||||
|
||||
> [!tip]+ Proposition
|
||||
> - $F \models G$ iff $\models F \implies G$.
|
||||
> - $\Gamma \models G$ and $\Gamma$ finite iff $\models \land \Gamma \implies G$.
|
||||
>
|
||||
|
||||
- $\Gamma$ is *consistent* or *satisfiable* iff there is an assignment that models $\Gamma$.
|
||||
- We say that $\Gamma$ is inconsistent or unsatisfiable iff there is not consistent and denote this by $\Gamma \models \bot$.
|
||||
|
||||
> [!tip]+ Proposition
|
||||
> - {$F, \neg F$} $\models \bot$
|
||||
> - If $\Gamma \models \bot$ and $\Gamma \subseteq \Gamma '$, then $\Gamma ' \models \bot$
|
||||
> - $\Gamma \models F$ iff $\Gamma, \neg F \models \bot$
|
||||
|
||||
- Formula $G$ is a subformula of formula F if it occurs syntactically within F
|
||||
- Formula G is a strict subformula of F if G is a subformula of $F$ and $G \neg = F$
|
||||
|
||||
|
||||
**Basic Equivalences:**
|
||||
1. $\neg \neg A \equiv A$
|
||||
2. $A \lor A \equiv A$
|
||||
3. $A \land A \equiv A$
|
||||
4. $A \land \neg A \equiv \bot$
|
||||
5. $A \lor \neg A \equiv \top$
|
||||
6. $A \lor B \equiv B \lor A$
|
||||
7. $A \land B \equiv B \land A$
|
||||
8. $A \land \top \equiv A$
|
||||
9. $A \lor \top \equiv \top$
|
||||
10. $A \land \bot \equiv \bot$
|
||||
11. $A \lor \bot \equiv A$
|
||||
12. $A \land (B \lor A) \equiv A$
|
||||
13. $A \land (B \lor C) \equiv (A \land B) \lor (A \land C)$
|
||||
14. $A \lor (B \land C) \equiv (A \lor B) \land (A \lor C)$
|
||||
15. $\neg (A \lor B) \equiv \neg A \land \neg B$
|
||||
16. $\neg (A \land B) \equiv \neg A \lor \neg B$
|
||||
17. $A \implies B \equiv \neg A \lor B$
|
||||
18. $A \iff B \equiv (A \implies B) \land (B \implies A)$
|
||||
|
||||
|
||||
|
||||
|
||||
# 2. SAT Solvers
|
||||
- There are several techniques and algorithms for SAT solving.
|
||||
- Usually SAT solvers receive as input a formula in a specific syntatical format.
|
||||
- SAT solvers deal with formulas in **conjunctive normal form (CNF)**.
|
||||
|
||||
- Most current state-of-the-art SAT solvers are based on the **Davis-Putnam-Logemann-Loveland (DPLL) framework**.
|
||||
|
||||
## 2.1 DPLL Framework
|
||||
The idea is to **incrementally construct an assignment compatible with a CNF**, propagating the implications of the decisions made that are easy to detect and simplifying the clauses.
|
||||
|
||||
A CNF is satisfied by an assignment if all its clauses are satisfied. And a clause is satisfied if at least one of its literals is satisfied.
|
||||
|
|
@ -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.
|
||||
>
|
||||
|
||||
|
|
@ -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]]
|
||||
|
|
@ -1,164 +0,0 @@
|
|||
🌫 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. Definition of Requirement
|
||||
The requirements express the users necessities and restrictions that are
|
||||
placed on the system.
|
||||
|
||||
A **requirement** is a capacity that a system must possess, to satisfy the
|
||||
users necessities.
|
||||
|
||||
The IEEE 610.12-1990 standard definition divides requirements into
|
||||
two alternatives:
|
||||
1. user needs
|
||||
2. system capacities
|
||||
|
||||
Requirements can be divided into:
|
||||
1. functional requirements
|
||||
2. non-functional requirements
|
||||
|
||||
A r**equirement that for a stakeholder** can be perceived
|
||||
as being **functional**, can be considered as **non-functional**
|
||||
for **a different one**.
|
||||
|
||||
> [!info] A candidate requirement is a requirement that was identified by some elicitation technique.
|
||||
|
||||
|
||||
## 2. Functional requirements
|
||||
|
||||
> [!tip] Definition
|
||||
> A functional requirement describes a functionality to be made
|
||||
available to the users of the system.
|
||||
|
||||
- This type of requirements should not mention any technological issue.
|
||||
- Ideally, functional requirements must be independent of design and
|
||||
implementation aspects.
|
||||
|
||||
> [!note]- Note: Cohesion and Completion
|
||||
> Collectively, the set of functional requirements must be complete and
|
||||
coherent. The set is:
|
||||
> - *coherent*, if there are no contradictions among its elements;
|
||||
> - *complete*, if it considers all the necessities that the client wishes to see
|
||||
satisfied.
|
||||
>
|
||||
> Defining complete requirements is the most difficult attribute to
|
||||
achieve or evaluate.
|
||||
|
||||
> [!note]- Note: Implicit and Explicit Requirements
|
||||
> Implicit requirements are referred like that because the client may not be aware about these requirements.
|
||||
>
|
||||
> An **implicit requirement** is a requirement included by the development team, based on the domain knowledge that it possesses, in spite of not having been explicitly requested by the stakeholders.
|
||||
>
|
||||
> An **explicit requirement** refers to a requirement that was requested by the clients and that is represented in the documentation.
|
||||
|
||||
|
||||
## 3. Non-functional requirements
|
||||
|
||||
> [!tip] Definition
|
||||
> A non-functional requirement corresponds to a set of restrictions
|
||||
imposed on the system to be developed.
|
||||
|
||||
- Alternative terms: quality requirement or quality attribute
|
||||
- It establishes how attractive, fast, or reliable the system is.
|
||||
- It includes time constraints, restrictions in the development process, or
|
||||
adoption of standards.
|
||||
|
||||
> [!example]- Example: Technological restriction
|
||||
> The product must be developed in C++.
|
||||
|
||||
> [!info] **A non-functional requirement does not change the essence of the system functionalities.**
|
||||
|
||||
|
||||
- Non-functional requirements are applicable to the system as a whole
|
||||
and not just to some of its parts, as, generally, non-functional requirements **cannot be modularized**.
|
||||
|
||||
- The non-functional requirements are frequently **emergent properties** of the system at hand. *An emergent property of a system is a property that can be associated with the system as a whole, but not individually to each of its components.*
|
||||
- *Reliability* is a good example of an emergent property.
|
||||
|
||||
|
||||
> [!info] **Non-functional requirements are crucial to decide the system architecture.**
|
||||
|
||||
|
||||
|
||||
### 3.1 Classification of non-functional requirements
|
||||
|
||||
> [!tip]- Classification: Sommerville (2010)
|
||||
> - **product requirements**: characterise aspects of the behaviour of the system itself (*reliability, performance, efficiency, portability, usability, testability, and readability*).
|
||||
> - **organisational requirements**: come from strategies and procedures established in the context of the manufacturing process of the system or the client organisation (process standards and implementation requirements).
|
||||
> - **external requirements**: have origin in external factors to the system and the development process (interoperability, legal, and ethical requirements).
|
||||
|
||||
> [!tip]- Classification: Roberson and Roberson (2006)
|
||||
> - **appearance**: the aspect and the aesthetics of the system;
|
||||
> - **usability**: the easiness of utilization of the system and everything that permits a more friendly user experience;
|
||||
> - **performance**: aspects of speed, real-time, storage capacity, and execution correction;
|
||||
> - **operational**: characteristics about what the system must do to work correctly in the environment where it is inserted;
|
||||
> - **maintenance and support**: attributes that allow the system to be repaired or improved and new functionalities to be added;
|
||||
> - **security**: issues related to access, confidentiality, protection, and integrity of the data;
|
||||
> - **cultural and political**: factors related to the stakeholders culture and habits;
|
||||
> - **legal**: laws that apply to the system so that it can operate.
|
||||
|
||||
#### 3.1.1 Usability
|
||||
- **Ease of use** is related to the efficiency of utilizing a system and with the mechanisms that reduce the errors made by the users.
|
||||
- **Personalization** is associated with the capacity of adapting the system to the tastes of the users.
|
||||
- **Ease of learning** is concerned with the way users are trained to use the system.
|
||||
- **Accessibility** indicates how easy it is to use the system, for people who
|
||||
are somehow physically or mentally disabled.
|
||||
|
||||
> [!example]- Example: Usability requirements
|
||||
> 1. The product shall be easy to use for illiterate persons.
|
||||
> 2. The product shall be intuitive to use for children with 4 years old.
|
||||
> 3. The product shall be usable by visually impaired persons.
|
||||
|
||||
#### 3.1.2 Maintenance and support
|
||||
- System maintenance is divided into four types: preventive, corrective, perfective, and adaptive.
|
||||
- **Modifiability** is related to maintenance and is dependent on how easy it is to locate the components that must be changed.
|
||||
|
||||
> [!example]- Example: Maintenance and support requirements
|
||||
> 1. The source code of the product programs should contain comments.
|
||||
> 2. The product must be prepared to be translated to any language.
|
||||
|
||||
#### 3.1.3 Legal
|
||||
> [!example]- Example: Legal requirements
|
||||
> 1. The product shall be aligned with the PMBoK guide.
|
||||
> 2. The product shall be certified by the Taxing Authority.
|
||||
> 3. The product shall fulfil with the copyright.
|
||||
|
||||
|
||||
|
||||
## 4. User and system requirements
|
||||
|
||||
A **user requirement** represents:
|
||||
1. a functionality that the system is expected to provide to its users;
|
||||
2. a restriction that is applicable to the operation of that system.
|
||||
|
||||
- These requirements are related to the problem domain.
|
||||
- They are normally expressed without great mathematical rigour, using natural language and informal diagrams.
|
||||
|
||||
|
||||
A **system requirement** constitutes a more detailed specification of a requirement, being generally a formal model of the system. These requirements are oriented towards the solution domain, and are documented in a more technical language than the one
|
||||
adopted for the user requirements.
|
||||
|
||||
### 4.1 Problem domain
|
||||
- The requirements result from necessities that exist in the problem domain to be addressed.
|
||||
- User requirements should be described with the problem domain terminology.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
# Recap
|
||||
1. Requirements represent the necessities of the users and the constraints that are applied to a system and that must be considered throughout the development.
|
||||
2. The requirements can be classified, according to a first criterion, as either functional or non-functional.
|
||||
3. Non-functional requirements are divided in 8 different types: appearance, usability, performance, operational, maintenance and support, security, cultural and political, and legal.
|
||||
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/PL - Aula 1|Aula prática]]
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
{:blocks (
|
||||
{:block/content ""
|
||||
:block/format :markdown
|
||||
:block/left
|
||||
{:block/uuid #uuid "6512ac96-d3b5-4c76-a3ea-cdc9821a324e"}
|
||||
:block/parent
|
||||
{:block/uuid #uuid "6512ac96-d3b5-4c76-a3ea-cdc9821a324e"}
|
||||
:block/uuid #uuid "6512acea-36a2-48e7-8591-93a67acbf60e"})
|
||||
:pages (
|
||||
{:block/uuid #uuid "6512ac96-d3b5-4c76-a3ea-cdc9821a324e"
|
||||
:block/properties
|
||||
{:ls-type :whiteboard-page
|
||||
:logseq.tldraw.page
|
||||
{:id "6512ac96-d3b5-4c76-a3ea-cdc9821a324e"
|
||||
:name "6512ac96-d3b5-4c76-a3ea-cdc9821a324e"
|
||||
:bindings
|
||||
{}
|
||||
:nonce 1
|
||||
:assets []
|
||||
:shapes-index ()}}
|
||||
:block/updated-at 1695722866049
|
||||
:block/created-at 1695722646634
|
||||
:block/type "whiteboard"
|
||||
:block/name "6512ac96-d3b5-4c76-a3ea-cdc9821a324e"
|
||||
:block/original-name "6512ac96-d3b5-4c76-a3ea-cdc9821a324e"})}
|
||||
Loading…
Reference in a new issue