logseq/journals/2022_09_23.md

type:: meeting external-links:: 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]]
	- ![COLA-Supporting_the_model_based_safety_analysis_for_safety_critical_IoT_systems.pdf](../assets/COLA-Supporting_the_model_based_safety_analysis_for_safety_critical_IoT_systems_1663917284399_0.pdf)
- [[people/felicien]] fa una DEMO
	- ![image.png](../assets/image_1663918775774_0.png){:height 668, :width 766}
	- ![image.png](../assets/image_1663918795299_0.png)
	- ![image.png](../assets/image_1663918891519_0.png)
		- The final goal is analyze possible failures
	- ### Failure analysis
		- After the specification of the components, we can add annotations for failure analysis purposes
			- ![image.png](../assets/image_1663919079954_0.png)
			- ![image.png](../assets/image_1663919297747_0.png)
		- 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
					- ![image.png](../assets/image_1663920230021_0.png)
			-
	- ### System design
		- ![image.png](../assets/image_1663920775858_0.png)
		-
		-

• 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  (visualizzazione Web)
• Meeting EY