logseq/pages/SANER2024_paper_127.md

type:: REVIEWS tags:: year:: 2024 venue:: SANER full-title:: SPViz: A DSL-Driven Approach for Software Project Visualization Tooling date-start:: 15-11-2023 - 22:39 date-submitted:: 10-12-2023 external-links:: status:: DONE deadline-submission:: 24-11-2023 file::

- ### [[Highlights]]
	- #+BEGIN_IMPORTANT
	  ((6564ffcd-3af3-4f3c-9797-52d383c9879b))
	  What does it mean with minimal effort?
	  #+END_IMPORTANT
	- ((6567bd5d-090d-4ff7-9823-d55542e7150c))
		- It seems to be very specific to PICTO
		- Moreover, MODISCO should be also considered in the related work section. Let's see....
	- ((6567bee1-9af7-42d9-ac8c-bbeefc15930a))
	- ((6567c0ac-0095-4010-9e77-4d4603735337))
		- This does not look good to me.
	- ((6567c16c-1b7c-466e-9d45-bd0b838f69d5))
		- How are these connected with the ((6567c185-408f-4c0e-83dd-cfcd615cbae3)) ? [[question]]
	- ((6567c1b8-9ffd-41e7-90e9-ca65c99118d2))
		- All of this is very confusing to me.
	- ((6567c269-4c2c-4b24-b818-111798d4f687))
		- Check what are the constructs in A3M.
		  id:: 6567c271-2f5a-4629-af01-b4a42519ec66
	- ((6567c2c2-56d6-4cc9-bcf2-a219abb787d0))
	  background-color:: green
		- Overall there is a confused use of models / metamodels / metametamodels
		  background-color:: green
	- ((65735fca-9fc8-4896-a1cd-882585b4dfd0))
		- Why is MVC only specific for OSGi? Potentially, it can be considered for different kinds of technologies..... [[question]]
	- ((657360d2-6296-4a55-acb4-78155dec7ea2))
		- So this paper is to show only the support for OSGi projects? Or here you pushing towards a generic approach? [[question]]
		- By reading
			- ((65736127-c00e-4730-829a-9e7f7ae2a278))
		- it seems to be OSGi specific and thus, it is necessary to clarify this early in the paper, even the title needs to changed accordingly.
	- ((6567bfd4-a9f2-4dc4-9244-00ffdfb071ac))
		- How to extract this project model? [[question]]
	- ![image.png](../assets/image_1702071897577_0.png){:height 543, :width 515}
	- ![image.png](../assets/image_1702072040375_0.png){:height 265, :width 774}
	- ((6573929a-5db6-4baf-bd17-8cbb014303ee))
		- How textual presentations (e.g., Fig. 7) are linked with graphical ones as shown e.g., in Fig. 1 [[question]]
		  background-color:: green
			- This question is also related to ((65739407-ddfa-4e36-a05d-8ece1d53303c))
			- Still not clear: ((6573945b-0222-4cd9-b248-c21a33dd6536))
- ((65749f02-578f-4f22-8b75-ed97a7bef133))
	- This part is obscure.
	- ((6574ffd5-23d1-4760-97e9-1c2ac28373b4))
		- Let's see that.
- ((65750014-5520-4748-a4b1-a9a453694d7f))
	- Indeed, that's true, but we are missing details
- ((657568ac-6059-480a-8a50-97519717938f))
	- It is not clear how this framework has been employed.
- ((657568f4-baba-4bbb-bdcf-e1fd0c2b26ef))
	- This sentence is not clear in the sense that the DSL does not have any constructs to specify how to parse configurations.
- ((65756934-0893-4f95-a17b-3028bf237c92))
	- It is necessary to give evidence of the benefit of this approach in comparison with existing ones (see work by Michele Lanza and co.)
- ((65756c5d-2f6f-44b7-a5a0-afbfb8f7b10d))
	- The whole paragraph is very verbose and does not add much at this stage.
- ((65756ca2-9f70-482f-a347-984b6364642d))
	- ((65756d1d-9694-4692-9232-07a8621c7247))
	- **Design questions**: ((65756d65-ea85-4f64-b164-1e70a9502f94))
	- Flexibility, usability, and effort reduction are the two aspects that have been assessed for the evaluation.
- ((65756e97-4603-4e10-a411-7a600f1fae87))
	- The development of such a crucial component is not presented earlier and it is not clear how it is developed in synergy with the model-based artifacts, including the specifications given with the different DSLs, presented earlier in the paper.
- ((65756ef8-4a40-4581-9e6e-4ce81c5030af))
	- The details of this phase would have been of interest for the venue. Instead they are just mentioned here.
- ((65756f32-af92-4a01-bbd4-b89d68bded8a))
	- What are the difficulties of such a scenario? What are the limitations of existing technologies that could not make possible their adoption on this specific scenario?
	  background-color:: green
	- The comparison done on the LoC is not strong in my opinion
	  background-color:: green
- ((65757240-df44-4a44-8229-2606bf6a2924))
	- The goal of such documentation should be more clear.
- All the considered scenarios are essentially the same, i.e., showing dependencies among different elements. If this is the goal of the proposed methodology, then this should be make clear early in the paper, even the title has to be refined. Otherwise, the tool should be compared with existing approaches including code visualizations tools.
  background-color:: green
- ((65757383-bf9d-456c-aa94-f5c67b430ce0))
	- It is necesarry to do such a discussion a rigorous manner. What are the limitations of the other tools? What are the requirements that industrial partners were looking for?
	- ((6575749b-d197-4a4d-be76-b3cceb37906f))
		- Even such an explanation is not enough.
- ((65757684-ebce-4c3f-8983-3990806afe33))
	- How do you compare with existing works? [[question]]
	- ((6575cb1a-e1e4-4960-b474-d0bd54c54cf4))
		- This needs to be discussed / clarified
	-

• • REVIEWS/Notes
    • SOViz employes two DSLs
      • A DSL for describing the architectural elements and their relationships
        • So it is a kind of meta-metamodel (check why not EMF or alike)
          • Yes, exactly, as it is written at ((65738fb6-7ac9-45b6-90b3-19b1fec27031))
      • A DSL to specify the concrete syntax of these elements, i.e., how they should be visualized.
    • Given specifications in these two DSLs, the approach can automatically generate a project-specific visualization tool
      • Why project specific and not language/technology/architecture specific? question
    • It is necessary to check how the "parsing" part is done. In case of OSGi for instance, it is necessary to instruct the system to parse MANIFEST files.
    • VCM is the view context model
    • PM is the project model, which contain data extracted from the a concrete project

  • ❓️Questions

    • {{query (and question SANER2024_paper_127)question) }} query-table:: true query-properties:: [:block]

  • Comments

    • The paper introduces SPViz, a novel approach for generating visualization tools for software systems through the use of two domain-specific languages (DSLs). One DSL is designed for articulating architectural elements and their relationships, while the other focuses on specifying the concrete syntax for visual representation. By leveraging these specifications, SPViz automates the creation of project-specific visualization tools, demonstrating its applicability across various technologies such as OSGi, Maven and Spring DI, and Gradle.
    • While the paper is about an interesting topic and maintains a well-organized structure, there are notable areas where further clarification and refinement are warranted:
      • The paper frequently references visualizations in Figs. 2 and 3 as potential outputs of the proposed approach. However, there is a lack of clarity regarding how these graphical representations correlate with the textual specifications provided by the DSLs. Specifically, the connection between textual instructions (Fig. 7) and graphical outputs (Fig. 1) requires elucidation.
      • The paper discusses experimental scenarios centered around a common problem i.e., identifying objects and their dependencies based on a specific notion of dependency. A more comprehensive exploration of the limitations of existing technologies that hindered their application to real-world examples is necessary for a thorough understanding.
      • The claim that industrial partners found existing technologies unsatisfactory and subsequently adopted SPViz needs more substantiation. A compelling argument should be presented, outlining the deficiencies of existing tools that SPViz successfully addresses. Furthermore, the authors mention that the presented approach enhances a previous work from the authors by making it more generic and appliable on technologies that are different than OSGi. However, the authors could consider the work done e.g., by M. Lanza et al. on software visualization.
      • The reliance on Lines of Code (LOC) as a metric for evaluation is critiqued as unconvincing, especially when manually written code is more complex than automatically generated code.
      • The pivotal PM generator component is briefly mentioned without adequate discussion on its development, particularly its integration with DSL specifications. For example, insights into the development of parsers for OSGi information could enhance the paper's technical depth.
      • The usage of terminology, particularly concepts such as models, metamodels, and meta-metamodels, requires refinement for a more accurate representation of the proposed approach.
      • Certain verbose paragraphs could be streamlined to focus on technical details and comparisons with existing technologies. For instance, the paragraph discussing architect dissatisfaction with other tools lacks specificity; a more rigorous analysis of tool limitations and the specific requirements sought by industrial partners is necessary for a robust discussion.
• {{embed SANER2024-REVIEW-INSTRUCTIONS}}