70 lines
3.8 KiB
Markdown
70 lines
3.8 KiB
Markdown
type:: [[meeting]]
|
||
external-links:: [meet.google.com/yos-jwti-zmv](http://meet.google.com/yos-jwti-zmv)
|
||
tags:: #PROJECTS/PRIN-EMELIOT
|
||
people:: [[people/mariani]] [[people/felicien]] [[people/danielamariani]] [[people/claudio]] [[people/juri]] [[people/riccardo]]
|
||
date:: [[23-09-2022]]
|
||
isconsortium:: false
|
||
|
||
- Avevamo condiviso i seguenti paper prima del meeting di oggi
|
||
- [[@MontiThings: Model-Driven Development and Deployment of Reliable IoT Applications]]
|
||
- 
|
||
- [[people/felicien]] fa una DEMO
|
||
- {:height 668, :width 766}
|
||
- 
|
||
- 
|
||
- The final goal is analyze possible failures
|
||
- ### Failure analysis
|
||
- After the specification of the components, we can add annotations for failure analysis purposes
|
||
- 
|
||
- 
|
||
- Questions from [[people/mariani]]
|
||
- No values can be not a problem, but if no values persist for a long time, then we can have a probalem. Does the language support this?
|
||
- The answer is no.
|
||
- How do you know that we are complete with respect to all the possible cases that need to specified
|
||
- We need a document of failures that can happen at the beginning of the process.
|
||
- In any case, we can also check the existing specification with respect to all the possible combinations that we could enumerate
|
||
- Do you have to enumerate all the possible failure combinations for each combination? Or can we specify the potential failures singularly, and then the system infers all the obvious combinations?
|
||
- Questions from [[people/danielamariani]]
|
||
- Do you have support correlation among faliures?
|
||
- The answer is yes, look at the example below
|
||
- 
|
||
-
|
||
- ### System design
|
||
- 
|
||
-
|
||
-
|
||
-
|
||
- type:: [[meeting]]
|
||
external-links::
|
||
tags::
|
||
people:: #people/imran #people/Vittorio_Cortellessa #people/riccardo #people/traini
|
||
tags::
|
||
date:: [[23-09-2022]] [[03-10-2022]]
|
||
- ### Tools to perform static analysis on source code
|
||
- SonarQube
|
||
- SonarGraph
|
||
- Understand by SciTools
|
||
- Different kinds of metrics at different level, like project, OO, etc.
|
||
- #people/imran focused on
|
||
- Cyclomatic
|
||
- CountInput
|
||
- FANIN
|
||
- CountOutput
|
||
- FANOUT
|
||
- scrML
|
||
- Maybe count for loops
|
||
- JDT
|
||
- ### Discussion
|
||
- Possibly perform a survey with tdevelopers of JMH #Ideas from #people/imran
|
||
- Suggesting new projects that have not been analyzed (from a performance point of view) and recommend what to analyze #Ideas from #people/Vittorio_Cortellessa
|
||
- Collect all the metrics for each method and check if there is a correlation with existing JMH benchmarks #Ideas
|
||
- In the case of functions that use other functions, we said to stop analyzing the first layer
|
||
-
|
||
-
|
||
-
|
||
-
|
||
-
|
||
- Esame Alessandro di Matteo e Giulia Scoccia
|
||
- [Appello 14/09/2022](onenote:[OneDrive](https://d.docs.live.net/a33324427a144a54/Documenti/Blocco%20appunti%20di%20Davide/Services/DIDATTICA/SEAS/SEAS%2021_22.one#Appello%2014/09/2022§ion-id={CFCF655E-E913-45C4-BE60-817E6B6F7CF9}&page-id={B29FADE0-095D-4DF5-B05D-17EE23D38D8B}&end)) ([visualizzazione Web](https://onedrive.live.com/view.aspx?resid=A33324427A144A54%21464&id=documents&wd=target%28Services%2FDIDATTICA%2FSEAS%2FSEAS%2021_22.one%7CCFCF655E-E913-45C4-BE60-817E6B6F7CF9%2FAppello%2014%5C%2F09%5C%2F2022%7CB29FADE0-095D-4DF5-B05D-17EE23D38D8B%2F%29))
|
||
- [[Meeting EY]]
|
||
- |