logseq/pages/hls__SCICO-D-22-00337_reviewer_1676969327474_0.md

file:: SCICO-D-22-00337_reviewer_1676969327474_0.pdf file-path:: ../assets/SCICO-D-22-00337_reviewer_1676969327474_0.pdf

• Modelling of architectural design ls-type:: annotation hl-page:: 3 hl-color:: green id:: 63f4858e-1ab5-46e2-9850-c3deade329c2
• Formal verification as a fitness functio ls-type:: annotation hl-page:: 3 hl-color:: green id:: 63f48595-ddbe-48b7-af9d-62c8c2c01c7f
• evolution path ls-type:: annotation hl-page:: 3 hl-color:: green id:: 63f48598-edaa-4070-8876-891c90e9c9e0
• Software Evolutionary Architecture ls-type:: annotation hl-page:: 4 hl-color:: green id:: 63f737dc-be8f-468a-a32d-ccf67f52b382
• evolve over tim ls-type:: annotation hl-page:: 4 hl-color:: green id:: 63fb6ec8-a99f-4a1c-9829-5bcc429362dd
• changes in user requirements ls-type:: annotation hl-page:: 4 hl-color:: green id:: 63fb6ed4-8a06-4703-971d-7016b73e732a
• Evolutionary architecture is a design principle that helps to support making frequent changes ls-type:: annotation hl-page:: 4 hl-color:: purple id:: 63fb71da-f941-476e-97c2-97a6120eb2db
• fitness function ls-type:: annotation hl-page:: 4 hl-color:: purple id:: 63fb71f2-5a95-4ee9-896c-3c5503d26561
• planning the evolution of architectural design in incremental steps remains a challenge ls-type:: annotation hl-page:: 4 hl-color:: purple id:: 63fb7250-4fef-4618-84c4-58622cc151c7
• automatically generating evolution plans to refactor the architectural design aimed at supporting new functionalitie ls-type:: annotation hl-page:: 4 hl-color:: yellow id:: 63fb72b0-e7d2-4eeb-9113-60b8c7efb996 hl-stamp:: 1677423289628
• rigorousness and effectiveness of the evolution plan ls-type:: annotation hl-page:: 4 hl-color:: yellow id:: 63fb73c2-a79e-4d2d-b5c7-be4bba84174b
• most suitable planning strateg ls-type:: annotation hl-page:: 4 hl-color:: yellow id:: 63fb748b-5b7c-41a2-9f3a-50df27e6d455
• user requirements, runtime environment, development libraries and programming languages ls-type:: annotation hl-page:: 5 hl-color:: green id:: 63fb756b-4fd8-4fb9-998c-e9767abe819a
• Evolutionary architecture ls-type:: annotation hl-page:: 5 hl-color:: green id:: 63fb75f5-4825-45b9-9e96-f61f9e62bd8c
• evolutionary architecture is making frequent small changes over time in agile manner through continuous deliver ls-type:: annotation hl-page:: 5 hl-color:: blue id:: 63fb7916-7c63-469b-b8f4-8c10a68d27e1
• d it is still lacks of tool to support planning. ls-type:: annotation hl-page:: 5 hl-color:: blue id:: 63fb7944-022a-4074-939d-74e9e26ef2e5
• they fail to take the functional properties into consideration ls-type:: annotation hl-page:: 5 hl-color:: purple id:: 63fb7983-5d61-4222-89d5-bfd798929dfe
• using ls-type:: annotation hl-page:: 6 hl-color:: red id:: 63fb7a66-800d-4555-a474-d115f1fd6e32 hl-stamp:: 1677425257445
• ”An evolutionary architecture supports guided, incremental change across multiple dimensions”. ls-type:: annotation hl-page:: 7 hl-color:: blue id:: 63fb7aaa-4c36-4b36-8015-e4cb8aba65c9 hl-stamp:: 1677425323913
• Ford et al.[2] ls-type:: annotation hl-page:: 7 hl-color:: blue id:: 63fb7ac2-2f35-418f-88f5-74d37ce4a9ea
• itness functions determine the candidate solution to achieve the goals ls-type:: annotation hl-page:: 7 hl-color:: green id:: 63fb7b4c-8b6f-476b-9363-256ff5a19c9b hl-stamp:: 1677425486871
• A Survey of Fitness Approximation Methods Applied in Evolutionary Algorithms, ls-type:: annotation hl-page:: 41 hl-color:: green id:: 63fb7b57-8360-4137-9ea1-eb54c1d53dd7
• itness functions are usually implemented as unit tests that verify the correct output of defined test cases ls-type:: annotation hl-page:: 8 hl-color:: purple id:: 63fb7bbb-8b17-494f-8232-a894ba5ae3a0 hl-stamp:: 1677425597798
• 2.2. Challenges of Evolutionary Architecture ls-type:: annotation hl-page:: 8 hl-color:: green id:: 63fb7c02-2a97-444b-bc5a-e14499361fc3 hl-stamp:: 1677425668884
• planning the refactoring and deployment remains challenging ls-type:: annotation hl-page:: 8 hl-color:: green id:: 63fb7cbf-5ee1-4a88-acc4-dcd4ba50ecfa
• hard to determine when the old configuration can be safely cut off from the rest of the system, which evolution steps need to be performed carefully, or when the new functionality is ready ls-type:: annotation hl-page:: 9 hl-color:: green id:: 63fb7cd5-071a-470f-994a-a8a21c4733a8
• To plan the evolution, architects need to reason about system behaviour at each step of the evolution process [29]. As the planning is usually performed manually, there is a high risk of mistakes being introduced, which causes system failures during the evolution. ls-type:: annotation hl-page:: 9 hl-color:: yellow id:: 63fb7d18-10d5-4e57-8fe8-f185d7e7366c hl-stamp:: 1677425946333
• structural and behavioural aspects of an architectural design ls-type:: annotation hl-page:: 9 hl-color:: green id:: 63fb7dd1-408f-46d2-90ad-5b31ce0d09de hl-stamp:: 1677426131869
• an additional model is created to describe the sequence of changes that need to take place ls-type:: annotation hl-page:: 9 hl-color:: green id:: 63fb919f-3648-4616-9a01-fedf096ebcbe
• A component has one or more ports that serve as interfaces to other components ls-type:: annotation hl-page:: 9 hl-color:: green id:: 63fb91e4-e836-4fe2-8cde-325ef1461144
• software architectural pattern recognition and reasonin ls-type:: annotation hl-page:: 42 hl-color:: green id:: 63fb9218-8369-4d35-96fa-ac632b3a5e28
• ?? ls-type:: annotation hl-page:: 10 hl-color:: red id:: 63fb9236-0ffe-43a0-a2a9-94d97d9c95f1 hl-stamp:: 1677431352602
• description logic based ontology languag ls-type:: annotation hl-page:: 42 hl-color:: green id:: 63fb9431-8ca5-4e4f-8af1-27dbba56f257 hl-stamp:: 1677431859940
• With the definition of behaviour in place, the model can be verified to prove whether the desired behaviour can be achieved ls-type:: annotation hl-page:: 12 hl-color:: green id:: 63fb982c-ec3c-430f-9cfc-341ffe011095
• E1 – When the emergency is requested, the request is acknowledged, and the wristband’s status is switched to alert mode. ls-type:: annotation hl-page:: 12 hl-color:: green id:: 63fb987f-3d3c-4f99-ac6d-dbad870bd139
• 2 – After the emergency request is dispatched for processing, the request is acknowledged by the system. ls-type:: annotation hl-page:: 12 hl-color:: green id:: 63fb9888-7a9e-41d8-91f6-987a5e10a8ca
• E3 – After the request is dispatched to process, the system must find the emergency centre in the proximity of the patient location ls-type:: annotation hl-page:: 12 hl-color:: green id:: 63fb98a3-ffb3-40b7-ba17-212289a6b150
• 4 – After the emergency staff acknowledges the emergency request (through the Liferescue application), the patient record can be fetched and verified. ls-type:: annotation hl-page:: 12 hl-color:: green id:: 63fb98ae-b909-49c7-8073-9ae5aff6d912
• E5 – After the caregiver acknowledges the emergency request (through the Lifecare application), the patient record can be fetched and verified. ls-type:: annotation hl-page:: 12 hl-color:: green id:: 63fb98b9-7617-4afc-94b1-3f0a6d44e094
• design encoded in the model supports the required functionalities ls-type:: annotation hl-page:: 13 hl-color:: yellow id:: 63fb9901-2250-4385-81cb-a760909aea0d hl-stamp:: 1677433096367
• The model checker only gives one possible state trace that shows how the system satisfies the property. ls-type:: annotation hl-page:: 13 hl-color:: green id:: 63fb997f-39ed-4e56-bf5f-fa7af0092ec2 hl-stamp:: 1677433218015
• .M ls-type:: annotation hl-page:: 13 hl-color:: red id:: 63fb99d3-6347-44de-be08-dadc8905b40a hl-stamp:: 1677433301731
• he reference model includes details that are not specific to any system, so it can be reused when the same function needs to be incorporated in other systems ls-type:: annotation hl-page:: 14 hl-color:: green id:: 63fb9e2d-69bb-4606-bf53-1896cfd40772 hl-stamp:: 1677434416515
• a) is a reference model for the payment gateway to be integrated with Lifefriend according to Change#2 ls-type:: annotation hl-page:: 14 hl-color:: green id:: 63fb9f0b-9837-45be-9143-db4a192cbd0b
• preprocessed ls-type:: annotation hl-page:: 15 hl-color:: green id:: 63fb9f5a-c0ca-4f58-a7fb-e8c69b52b2a6
• Change#2: The payment is preprocessed on lifefriend before the payment gateway checks it. ls-type:: annotation hl-page:: 15 hl-color:: green id:: 63fb9f5f-0b33-4e8b-8f28-cde998df3767
• he changes should be made to the software system through short iterations ls-type:: annotation hl-page:: 15 hl-color:: green id:: 63fb9f84-ab38-4dbc-bb3b-1c1c9328e7cf
• PDDL4J ls-type:: annotation hl-page:: 15 hl-color:: green id:: 63fb9fcd-995d-4a02-ba00-d7067d41a67f
• where the configuration of the refactored design supports new functional properties ls-type:: annotation hl-page:: 15 hl-color:: green id:: 63fba009-5ef7-4b77-b61d-e4cfa59ae9ea
• generate a state trace that describes how system responses are made in order to achieve the properties. ls-type:: annotation hl-page:: 16 hl-color:: green id:: 63fba046-18cc-48a5-86f7-b6ef3f6b4a16
• create a problem description in the PDDL ls-type:: annotation hl-page:: 16 hl-color:: green id:: 63fba058-c157-4138-8274-dea6ca045eb8
• It consists of the steps to apply structural changes to the architectural design ls-type:: annotation hl-page:: 16 hl-color:: green id:: 63fba0a0-0180-4f97-98e7-18bd8debfc51
• we verify the set of functional properties against the interim models to determine a safe evolution path ls-type:: annotation hl-page:: 16 hl-color:: green id:: 63fba0b6-397d-42d5-8928-69a5a58a32b5
• AI planner parses the domain description and the problem description. T ls-type:: annotation hl-page:: 18 hl-color:: green id:: 63fba135-52de-4e06-ba0c-78de239c3c65
• efactoring via Referencing ls-type:: annotation hl-page:: 18 hl-color:: blue id:: 63fba140-ffa6-4d50-916f-daea604a7784 hl-stamp:: 1677435206234
• I planning [40] is a common technique to explore the state space using a specified strategy and find the sequence of actions to achieve a defined goal. ls-type:: annotation hl-page:: 15 hl-color:: blue id:: 63fc8b72-9668-4a19-b189-2415015e1ce0
• goal ls-type:: annotation hl-page:: 15 hl-color:: yellow id:: 63fc8b7c-19da-4da3-94cc-a489a7a41ac8 hl-stamp:: 1677495166491
• object types, predicates, and actions ls-type:: annotation hl-page:: 16 hl-color:: green id:: 63fc8d25-e479-46be-bf4a-b57551c17702 hl-stamp:: 1677495591882
• users do not need to recreate it to plan the evolution of a specific software system ls-type:: annotation hl-page:: 16 hl-color:: green id:: 63fc8d7a-5354-4454-a5d6-c21062b620a3
• rchitectural refactoring domain ls-type:: annotation hl-page:: 17 hl-color:: green id:: 63fc8dc9-ce9f-46ed-8435-bc800e1409ab
• Listing 4: Domain Description of Refactoring ls-type:: annotation hl-page:: 17 hl-color:: yellow id:: 63fc8e19-a132-4ddc-b1a2-061798bc9e9b hl-stamp:: 1677495837725
• Listing 5: Actions in Domain Description ls-type:: annotation hl-page:: 17 hl-color:: green id:: 63fc8e31-c0f9-48b7-bccb-a1aa767050df hl-stamp:: 1677495859100
• problem description ls-type:: annotation hl-page:: 18 hl-color:: yellow id:: 63fc8ec1-beb9-43d3-bdcb-07a5d77abd49 hl-stamp:: 1677496003214
• onfiguration obsoletion ls-type:: annotation hl-page:: 18 hl-color:: blue id:: 63fc8ef0-01fd-400a-a78b-d4d85082965a
• extension ls-type:: annotation hl-page:: 18 hl-color:: blue id:: 63fc8ef6-a4c0-4f1e-bf1d-a8b075ae32f7
• substitution ls-type:: annotation hl-page:: 18 hl-color:: blue id:: 63fc8eff-cc65-4f7b-8abc-5ee501a8d8c7
• Each refactoring part requires the reference model to be defined ls-type:: annotation hl-page:: 18 hl-color:: blue id:: 63fc8f12-9189-4a7a-8218-d21d4ec6101e
• [:span] ls-type:: annotation hl-page:: 18 hl-color:: blue id:: 63fc8f3a-1f47-40b6-ac05-a5a592de464f hl-type:: area hl-stamp:: 1677496122373
• goals represent the changed design configurations that need to be made on the current design ls-type:: annotation hl-page:: 18 hl-color:: blue id:: 63fc8f86-6bec-43f2-8dd1-bd4c673e7d9f
• problem descriptio ls-type:: annotation hl-page:: 18 hl-color:: blue id:: 63fc8fa9-97e4-4d5c-bc6d-57a6543c40d4
• e have developed algorithms to create the problem description ls-type:: annotation hl-page:: 18 hl-color:: yellow id:: 63fc8fb2-13fc-4986-8e50-da0ba3971ec1 hl-stamp:: 1677496257093
• The state trace indicates the sequence of how components and connectors interact to serve the new functions, so it guides how the design should be refactored. ls-type:: annotation hl-page:: 18 hl-color:: green id:: 63fc9629-fa98-404f-8cdd-77658bd7812c hl-stamp:: 1677498012297
• Change# 3 of LifeNet, a payment gateway will be inserted into the system to handle customers’ payment function ls-type:: annotation hl-page:: 19 hl-color:: green id:: 63fc96de-1f2e-464e-9d5b-8d678249412e
• Algorithm 1 Generating problem description for configuration extension ls-type:: annotation hl-page:: 19 hl-color:: green id:: 63fc971d-1af7-4549-8711-d8d1769c2196
• After the problem description is generated ls-type:: annotation hl-page:: 23 hl-color:: green id:: 63fc97a1-234c-4cb1-9c93-383db1fb25e6
• evolution plan ls-type:: annotation hl-page:: 23 hl-color:: green id:: 63fc99a1-2742-42c1-b778-2062049574e7
• efactor the architectural design for evolutionary architecture. ls-type:: annotation hl-page:: 3 hl-color:: green id:: 63f4858a-11a0-4924-90e0-4447cb1edfb0