412 lines
14 KiB
Markdown
412 lines
14 KiB
Markdown
file:: [SCICO-D-22-00337_reviewer_1676969327474_0.pdf](../assets/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 |