logseq/pages/Software Evolutionary Architecture%3A Automated Planning for Functional Changes.md

type:: REVIEWS tags:: EvolutionaryArchitecture year:: 2023 venue:: SCP full-title:: Software Evolutionary Architecture: Automated Planning for Functional Changes date:: 21-02-2023 - 09:48 external-links:: file:: title:: Software Evolutionary Architecture: Automated Planning for Functional Changes status:: DONE

- ## [[Highlights]]
	- ((63fb72b0-e7d2-4eeb-9113-60b8c7efb996))
		- Refactor concerning what? Why and who trigger the refactoring operation?
	- ((63fb73c2-a79e-4d2d-b5c7-be4bba84174b))
		- Check if the evaluation has been done concerning such properties
	- ((63fb748b-5b7c-41a2-9f3a-50df27e6d455))
		- Again, most suitable with respect to what?
	- ((63fb756b-4fd8-4fb9-998c-e9767abe819a))
		- Ecosystem of software products
	- **Changes in functional requirements are the main cause of software changes**
	- ==DEFINITION OF EVOLUTIONARY ARCHITECTURE==
		- ((63fb7916-7c63-469b-b8f4-8c10a68d27e1))
		- ((63fb7aaa-4c36-4b36-8015-e4cb8aba65c9))
			- ((63fb7ac2-2f35-418f-88f5-74d37ce4a9ea))
	- ==LIMITATIONS OF EXISTING APPROACHES FOR SUPPORTING EVOLUTIONARY ARCHITECTURE==
		- ((63fb7983-5d61-4222-89d5-bfd798929dfe))
	- ==HOW ARE FITNESS FUNCTIONS IMPLEMENTED?==
		- ((63fb7bbb-8b17-494f-8232-a894ba5ae3a0))
	- ((63fb7d18-10d5-4e57-8fe8-f185d7e7366c))
		- To make the motivation stronger, it is necessary a concrete example that authors can use through the paper / section to improve the presentation of the problem and support the presented challenges.
	- ((63fb9901-2250-4385-81cb-a760909aea0d))
		- So that the components support the semantics specified in LTL?
		- In other words I guess that the components and their relations have to support the functionalities specified in LTL
	- ((63fc8b7c-19da-4da3-94cc-a489a7a41ac8))
		- How is this specified by the developer?
	- ((63fc8e19-a132-4ddc-b1a2-061798bc9e9b))
		- The role of this is not clear to me.
	- ((63fc8e31-c0f9-48b7-bccb-a1aa767050df))
		- This is a kind of delta language to specify changes to be operated on this initial specification.
	- ((63fc8ec1-beb9-43d3-bdcb-07a5d77abd49))
		- Where is the problem description?
			- ((63fc8fb2-13fc-4986-8e50-da0ba3971ec1))
				- ?????
- ## [[Comments]]
  id:: 645a0b36-8aee-420f-bece-b1e69b98c266
	- The paper presents an approach to support the evolution of software architectures. The proposed system can automatically generate evolution plans to refactor architectural designs with respect to defined fitness functions ensuring that the operated changes meet the wanted goals. Evolution plans are automatically generated and consist of sequential refactoring steps. The interim models that are produced by such refactoring steps are formally verified to identify steps that can potentially disrupt the system under analysis.
	- The paper is about an interesting and relevant topic. My main concerns about the paper are related to the following issues:
		- The paper is sometimes unnecessarily verbose and consequently, it is not always focused. In particular, I would improve section 4 with a particular emphasis on the three types of refactorings. I would make them more clear by improving the presentation of the running example. Even the description of the challenges of evolutionary architecture should be made more clear by referring to some concrete examples.
		- The proposed approach works and reasons at the level of architectural models. Thus, it is not clear how the identified and operated architectural changes are actually operated in the real system.
		- By following my previous point, it is necessary to add early in the paper an overview of the approach showing all the involved stakeholders and all the steps involving both models and related source code. The paper currently presents details related to the evolution of architectural models and neglects how models are linked to source code, which should be consistently changed according to the identified evolution plans. The use case shown in Fig. 7 does not refer at all to the real system. I'm missing how the process shown in Fig. 7 can be contextualized in practice in some DevOps process
		- Another comment is related to newly defined properties as shown on page 12. In particular, what if some of the wanted changes have to refine existing properties and not add completely new ones? Moreover, how to check if the new properties do not invalidate existing ones?
	- Overall, I like the general idea of the proposed approach. However, I'm missing links with concrete development processes and practices. The techniques to support evolutionary architecture should be connected with the problems that stand at the code/deployment level, otherwise, the reader is missing the point of how the proposed approach can be used in practice.