446 lines
19 KiB
Markdown
446 lines
19 KiB
Markdown
file:: [Cicchetti et al_2012_Managing the evolution of data-intensive Web applications by model-driven.pdf](file://C:/Users/david/Zotero/storage/L26Q4DJX/Cicchetti et al_2012_Managing the evolution of data-intensive Web applications by model-driven.pdf)
|
||
file-path:: file://C:/Users/david/Zotero/storage/L26Q4DJX/Cicchetti et al_2012_Managing the evolution of data-intensive Web applications by model-driven.pdf
|
||
|
||
- design evolutions
|
||
ls-type:: annotation
|
||
hl-page:: 1
|
||
hl-color:: green
|
||
id:: 651bb3da-8ca6-4a9d-986d-b236d69df892
|
||
- interconnected artifacts, notably to existing portions of the application which should be co-evolved accordingl
|
||
ls-type:: annotation
|
||
hl-page:: 1
|
||
hl-color:: green
|
||
id:: 651bb3f4-3190-4efa-9334-24819d0280d5
|
||
- hand-code the necessary modifications, that is a tedious and error-prone activity
|
||
ls-type:: annotation
|
||
hl-page:: 1
|
||
hl-color:: green
|
||
id:: 651bb459-a0f0-4f62-b8f0-bcbd2c1654a2
|
||
- holding back the software evolution operations [42].
|
||
ls-type:: annotation
|
||
hl-page:: 1
|
||
hl-color:: blue
|
||
id:: 651bb467-29d7-4946-be24-195674913ffc
|
||
- text-based approaches cannot deal with the level of abstraction of models in a profitable way
|
||
ls-type:: annotation
|
||
hl-page:: 2
|
||
hl-color:: green
|
||
id:: 651bb4fb-12e8-4342-a684-03834a4ee25b
|
||
- enhance file-oriented or line-oriented versioning techniques towards more structural recording of change
|
||
ls-type:: annotation
|
||
hl-page:: 2
|
||
hl-color:: blue
|
||
id:: 651bb506-4dbe-445e-abc9-52fdbf7a40e3
|
||
hl-stamp:: 1696314635518
|
||
- Contributions
|
||
ls-type:: annotation
|
||
hl-page:: 2
|
||
hl-color:: green
|
||
id:: 651bc663-edb2-4c8a-83f9-cb934ec9ba88
|
||
- evolution of Web applications which consists of the following stages
|
||
ls-type:: annotation
|
||
hl-page:: 2
|
||
hl-color:: green
|
||
id:: 651bc668-de31-489e-a8f2-6db61bf2201c
|
||
- (a) detection of changes operated on the models of a given Web application by means of model differencing approach
|
||
ls-type:: annotation
|
||
hl-page:: 2
|
||
hl-color:: blue
|
||
id:: 651bc66f-8b80-40c3-8719-7b2a1319e50b
|
||
- (b) model-based representation of the detected changes in order to enable,
|
||
ls-type:: annotation
|
||
hl-page:: 2
|
||
hl-color:: blue
|
||
id:: 651bc679-fed9-4207-9f52-f3e1fb8308e8
|
||
- (c) the automated generation of migration tools by means of model transformations.
|
||
ls-type:: annotation
|
||
hl-page:: 2
|
||
hl-color:: blue
|
||
id:: 651bc680-0ea9-4f8b-ba70-8bea958644ba
|
||
- Subsequent versions of a beContent model are compared to detect the occurred modifications and bring forth adaptations capable of migrating also those aspects which are not directly derivable from the model
|
||
ls-type:: annotation
|
||
hl-page:: 2
|
||
hl-color:: purple
|
||
id:: 651bc6a2-7ed0-4c6c-bf39-004af671c5a3
|
||
- do not embody layout templates or the data which are inserted in the system after the deployment of the generated application and persistently stored in a database.
|
||
ls-type:: annotation
|
||
hl-page:: 2
|
||
hl-color:: purple
|
||
id:: 651bc6b4-959c-47d7-8632-43ce921b0fdf
|
||
- “external” artifacts should be supported.
|
||
ls-type:: annotation
|
||
hl-page:: 2
|
||
hl-color:: purple
|
||
id:: 651bc6bd-948d-4031-9598-2b6c406bbc43
|
||
- the proposed process is also applied to manage the evolution of systems which have been developed with WebML, a modeling language which has been employed on full scale projects and is widely used in commercial enterprises
|
||
ls-type:: annotation
|
||
hl-page:: 2
|
||
hl-color:: purple
|
||
id:: 651bc6d1-463c-470b-b642-44ec3e431c0a
|
||
- model differencing,
|
||
ls-type:: annotation
|
||
hl-page:: 2
|
||
hl-color:: blue
|
||
id:: 651bc6ef-65ee-459e-bf94-cb3f435222ec
|
||
- data schema evolution
|
||
ls-type:: annotation
|
||
hl-page:: 2
|
||
hl-color:: blue
|
||
id:: 651bc6f4-5bdd-4301-9db7-0da8c421ef1a
|
||
- coupled evolution
|
||
ls-type:: annotation
|
||
hl-page:: 2
|
||
hl-color:: blue
|
||
id:: 651bc6f9-446b-40e9-b747-cf305045113b
|
||
- even though each phase of the proposed process relies on techniques already available in other application domains, their integration and adaptation in a comprehensive modelbased approach to support Web application evolutions represents the main novelty of the paper
|
||
ls-type:: annotation
|
||
hl-page:: 2
|
||
hl-color:: purple
|
||
id:: 651bc71b-9f18-4b26-88a6-c1944ff330b8
|
||
- (e.g., Hera [13], OO-H [15], UWE [19], WebDSL [43], WebML [5] and Webile [11] to mention a few)
|
||
ls-type:: annotation
|
||
hl-page:: 2
|
||
hl-color:: purple
|
||
id:: 651bc7a8-41ca-4a42-8f0d-7e2e77611acd
|
||
- several assets might not be directly reflected in the models, such as the content stored in persistent back-ends and those artifacts which are obtained via manual customizations (as outlined by the gray boxes in Fig. 1b).
|
||
ls-type:: annotation
|
||
hl-page:: 2
|
||
hl-color:: purple
|
||
id:: 651bc859-5c2d-48d8-889d-dfabebf4e5bb
|
||
- modifying a model might require additional adaptations in order to keep the overall system valid.
|
||
ls-type:: annotation
|
||
hl-page:: 2
|
||
hl-color:: purple
|
||
id:: 651bc868-33f0-4487-adb2-7ff7f2620088
|
||
- the more such interdependencies are formally defined, the better the adaptation process can be automatized
|
||
ls-type:: annotation
|
||
hl-page:: 2
|
||
hl-color:: purple
|
||
id:: 651bd412-788e-4cc8-864b-8beaa1cbafa5
|
||
- conformance relation between the data and their schema
|
||
ls-type:: annotation
|
||
hl-page:: 3
|
||
hl-color:: purple
|
||
id:: 651bd42f-f2d0-4bb9-b203-d2170fa63f7f
|
||
- (a) the detection of model changes by means of model comparison techniques,
|
||
ls-type:: annotation
|
||
hl-page:: 3
|
||
hl-color:: blue
|
||
id:: 651bd459-3230-4f01-bbb7-f1248c330a87
|
||
- b) their model-based representation
|
||
ls-type:: annotation
|
||
hl-page:: 3
|
||
hl-color:: blue
|
||
id:: 651bd461-3754-4858-b993-97356bf8d08b
|
||
- (c) the automated generation of migration tools by means of model transformations.
|
||
ls-type:: annotation
|
||
hl-page:: 3
|
||
hl-color:: blue
|
||
id:: 651bd467-5af9-46cd-bee6-c9155c61e137
|
||
- differences are based on the considered metamode
|
||
ls-type:: annotation
|
||
hl-page:: 3
|
||
hl-color:: purple
|
||
id:: 651bd475-2a3c-441f-b677-eae40bc99fec
|
||
- adaptation must necessarily consider the technological assets and the architecture of the final system that cannot be generalized.
|
||
ls-type:: annotation
|
||
hl-page:: 3
|
||
hl-color:: purple
|
||
id:: 651bd47e-61a7-4901-9f58-885db34c4867
|
||
- calculation, representation, and visualization (the interested reader can refer to [4] for an extended discussion).
|
||
ls-type:: annotation
|
||
hl-page:: 3
|
||
hl-color:: purple
|
||
id:: 651bd4a6-7cd3-48ab-a7e4-f836782dadf8
|
||
- model matching
|
||
ls-type:: annotation
|
||
hl-page:: 3
|
||
hl-color:: purple
|
||
id:: 651bd4d7-2369-4678-8103-9475b1eed6b0
|
||
- it relies on a metamodel independent matching algorithm and can be used for differencing models conforming to any modeling language.
|
||
ls-type:: annotation
|
||
hl-page:: 4
|
||
hl-color:: blue
|
||
id:: 651bd52f-cbfc-4b65-87d3-c5c84563d0e7
|
||
- In this respect, the Epsilon Comparison Language [22] (ECL) significantly simplify the customization of the matching algorithm and permits the definition of domain-specific heuristics for the modeling language at use
|
||
ls-type:: annotation
|
||
hl-page:: 4
|
||
hl-color:: purple
|
||
id:: 651bd542-a5ce-4338-845a-30d9ba928ff4
|
||
- the metaclasses AddedWebPage, DeletedWebPage and ChangedWebPage are derived and permit the specification of additions, deletions, and changes of WebPage instances, respectively.
|
||
ls-type:: annotation
|
||
hl-page:: 4
|
||
hl-color:: green
|
||
id:: 651bd585-56a8-4518-977d-ef45bde44e46
|
||
- on-breaking changes: modifications which do not invalidate the existing systems with the corresponding models;– breaking and resolvable changes: modifications which invalidate the existing systems even though they can be automatically co-adapted;– breaking and unresolvable changes: modifications which invalidate the existing applications and cannot automatically co-evolved and the user intervention is required
|
||
ls-type:: annotation
|
||
hl-page:: 5
|
||
hl-color:: blue
|
||
id:: 651bd5bf-621c-4061-9b9c-0ac6a0c54aaf
|
||
- adapting customized source code requires the ability to extract and query the corresponding abstract syntaxes in order to refactor it
|
||
ls-type:: annotation
|
||
hl-page:: 5
|
||
hl-color:: blue
|
||
id:: 651bd5fa-5205-4342-b9de-59bfb63c9e78
|
||
- WebML enables the specification of navigation concerns which cannot be expressed by beConten
|
||
ls-type:: annotation
|
||
hl-page:: 5
|
||
hl-color:: purple
|
||
id:: 651bd697-80f0-4a50-987d-fc5641916dbf
|
||
- outlining its application on WebML models.
|
||
ls-type:: annotation
|
||
hl-page:: 5
|
||
hl-color:: blue
|
||
id:: 651bd6a4-2aae-43f7-88b9-13ee6072572f
|
||
- structure, composition, and data entry
|
||
ls-type:: annotation
|
||
hl-page:: 5
|
||
hl-color:: purple
|
||
id:: 651bd6ca-1451-410b-af83-43c47669e7f8
|
||
- for instance a textual content can be edited by means of text fields, text areas, or richtext editors.
|
||
ls-type:: annotation
|
||
hl-page:: 6
|
||
hl-color:: purple
|
||
id:: 651bd6e9-8da7-4ccd-a701-fe2244bef3aa
|
||
- CustomEntity is the metaclass used by modelers to specify the data entities of the application being developed.
|
||
ls-type:: annotation
|
||
hl-page:: 6
|
||
hl-color:: blue
|
||
id:: 651bd8b5-9bad-42ae-9de4-b35edb36011b
|
||
- The beContent metamodel provides also a built-in support for RSS (Really Simple Syndication): the metaclass Channel is provided to define RSS channels and for each of them to specify the corresponding data source
|
||
ls-type:: annotation
|
||
hl-page:: 6
|
||
hl-color:: blue
|
||
id:: 651bd8db-d3ec-463c-80a6-26ea10859340
|
||
- . For instance, the metaclass Editor is used to edit the content of textual attributes by means of a rich-text editor. The management of files and images to be uploaded or deleted is completely transparent to the users which can use the specific File, FileToFolder, and Image metaclasses
|
||
ls-type:: annotation
|
||
hl-page:: 7
|
||
hl-color:: green
|
||
id:: 651bd917-1301-441e-a58f-f541dd639035
|
||
- Handlers consist of a number of Content each related to the entity which contains data to be retrieved and collected together.
|
||
ls-type:: annotation
|
||
hl-page:: 7
|
||
hl-color:: green
|
||
id:: 651bd96f-dc26-41b5-a988-720a18a1ba15
|
||
- they are entities containing graphical directives which are then merged with the retrieved dat
|
||
ls-type:: annotation
|
||
hl-page:: 7
|
||
hl-color:: blue
|
||
id:: 651bd97f-285d-487b-9baa-a05091e5cf80
|
||
- Employer home page handler is specified to gather data from the Employer entity and publish its content in a Web page.
|
||
ls-type:: annotation
|
||
hl-page:: 7
|
||
hl-color:: purple
|
||
id:: 651bd9d4-c6f8-4032-8ca1-14833afd091b
|
||
- Whenever data entry models are modified, new SQL code is generated and the previous implementation of the CRUD operations is simply substituted.
|
||
ls-type:: annotation
|
||
hl-page:: 10
|
||
hl-color:: green
|
||
id:: 651bda36-8d7f-4b3a-b557-2177e1559357
|
||
- Table 1 Fragment of the change classification of beContent models
|
||
ls-type:: annotation
|
||
hl-page:: 11
|
||
hl-color:: green
|
||
id:: 651bda4d-4d42-4e8d-9172-17803ec717e1
|
||
- additive, subtractive, and updative
|
||
ls-type:: annotation
|
||
hl-page:: 10
|
||
hl-color:: purple
|
||
id:: 651bda72-16fc-475b-b53b-bc78986e47de
|
||
- (a) keeping the system in a consistent state
|
||
ls-type:: annotation
|
||
hl-page:: 10
|
||
hl-color:: green
|
||
id:: 651bda97-5a45-47ef-a275-2eb0230c3a9d
|
||
- (b) assisting the designer in managing the coupled evolution of certain components by prescribing their possible adaptations.
|
||
ls-type:: annotation
|
||
hl-page:: 10
|
||
hl-color:: green
|
||
id:: 651bda9e-be2f-495a-9d66-4f5951f2da5a
|
||
- Adding and removing a data entity,
|
||
ls-type:: annotation
|
||
hl-page:: 10
|
||
hl-color:: green
|
||
id:: 651bdae4-4bad-4a85-9f79-a21a4365ad85
|
||
- Fig. 13a by removing the table Picture and consequently all its data
|
||
ls-type:: annotation
|
||
hl-page:: 10
|
||
hl-color:: green
|
||
id:: 651bdb62-6b5c-464a-9a30-ca464eef50a9
|
||
- Changing properties of a data entity,
|
||
ls-type:: annotation
|
||
hl-page:: 10
|
||
hl-color:: purple
|
||
id:: 651bdb93-2850-4774-8102-c3ad65c53219
|
||
hl-stamp:: 1696324592939
|
||
- Changing the name of a data entity requires to alter the name of the corresponding table
|
||
ls-type:: annotation
|
||
hl-page:: 11
|
||
hl-color:: green
|
||
id:: 651bdbb0-4c5a-4637-8d9b-77e731898b22
|
||
- Merging or splitting data entities
|
||
ls-type:: annotation
|
||
hl-page:: 11
|
||
hl-color:: purple
|
||
id:: 651bdbb4-be0b-4bfb-ac60-4970ab79345b
|
||
hl-stamp:: 1696324588967
|
||
- This kind of operation requires to split also the stored data and this can be done by considering the value of the attribute type in the existing data set
|
||
ls-type:: annotation
|
||
hl-page:: 11
|
||
hl-color:: purple
|
||
id:: 651bdbe3-4eb4-432e-9e85-5937bda208a3
|
||
- Adding or removing entity fields
|
||
ls-type:: annotation
|
||
hl-page:: 11
|
||
hl-color:: purple
|
||
id:: 651bdbe9-afb2-4e49-bbf2-09fbfe4fae21
|
||
- corresponding table must be altered in order to accommodate the new column.
|
||
ls-type:: annotation
|
||
hl-page:: 11
|
||
hl-color:: blue
|
||
id:: 651bdc06-d72a-4710-b10a-df0151e4e0cd
|
||
- mandatory attributes, default values or specific policies have to be provided
|
||
ls-type:: annotation
|
||
hl-page:: 11
|
||
hl-color:: blue
|
||
id:: 651bdc0f-90f0-4332-b239-c0af1b541c34
|
||
- Changing properties of an entity field,
|
||
ls-type:: annotation
|
||
hl-page:: 11
|
||
hl-color:: purple
|
||
id:: 651bdc14-78f0-42a5-9a1c-fb664f6b4679
|
||
- Changing a referredEntity from a current entity to a new one, entails to properly alter the corresponding column by changing its type to that of the primary key of the new referred entity
|
||
ls-type:: annotation
|
||
hl-page:: 11
|
||
hl-color:: purple
|
||
id:: 651bdd5f-3ebd-4d69-83fb-8c6796eb6424
|
||
- Adding and removing a handler
|
||
ls-type:: annotation
|
||
hl-page:: 12
|
||
hl-color:: purple
|
||
id:: 651bdd72-8558-4075-9e71-547aa993b865
|
||
- Changing properties of a handle
|
||
ls-type:: annotation
|
||
hl-page:: 12
|
||
hl-color:: purple
|
||
id:: 651bdd79-01ef-4ca2-8700-7a771f4cada2
|
||
- Both operations do not require particular adaptations even though handler removals might invalidate the navigation.
|
||
ls-type:: annotation
|
||
hl-page:: 12
|
||
hl-color:: blue
|
||
id:: 651bdd8d-c5d1-4118-96af-caa5f667ec85
|
||
- Modifying this reference means adding or removing new contents in the handler and might require the template to be consistently adapted, i.e., to include or remove the correct tags which are depending on the data to be presented.
|
||
ls-type:: annotation
|
||
hl-page:: 12
|
||
hl-color:: blue
|
||
id:: 651bddae-4c35-4973-b892-04751844c509
|
||
- Adding and removing a content
|
||
ls-type:: annotation
|
||
hl-page:: 13
|
||
hl-color:: purple
|
||
id:: 651bddd7-b57a-419c-9c4c-47e222528b4b
|
||
- Changing properties of a content,
|
||
ls-type:: annotation
|
||
hl-page:: 13
|
||
hl-color:: purple
|
||
id:: 651bddf1-a355-49e7-a136-8f3cdcdc7985
|
||
- So far, we have described the different ways a beContent model can be modified and discussed the countermeasures necessary to adapt the system accordingly.
|
||
ls-type:: annotation
|
||
hl-page:: 14
|
||
hl-color:: purple
|
||
id:: 651bde0d-1013-45be-b2c9-84175a64b0b9
|
||
- EMF Compare and customizing its matching algorithm with ECL
|
||
ls-type:: annotation
|
||
hl-page:: 14
|
||
hl-color:: purple
|
||
id:: 651bde22-fab9-41cf-acf6-c41debe9c54b
|
||
- Even though such detected differences are correct from a structural point of view, very likely they do not reflect the intentions of the modeler.
|
||
ls-type:: annotation
|
||
hl-page:: 14
|
||
hl-color:: blue
|
||
id:: 651bde80-fb41-430a-882c-be29ca2cf53a
|
||
- state-based differencing approaches detect evolutions by comparing two snapshots of application models at selected development times.
|
||
ls-type:: annotation
|
||
hl-page:: 14
|
||
hl-color:: purple
|
||
id:: 651bde8f-ca3a-4c76-8d74-236d6f224b48
|
||
- According to this rule, two custom entities match when they are similarly named or when they are involved in a split operation.
|
||
ls-type:: annotation
|
||
hl-page:: 14
|
||
hl-color:: purple
|
||
id:: 651bdeb2-e581-4b86-8fc4-322cfd69795d
|
||
- In the following, the generation of the adaptations will be illustrated for both data and graphical templates for the LAMP platform.
|
||
ls-type:: annotation
|
||
hl-page:: 17
|
||
hl-color:: purple
|
||
id:: 651bdf71-1009-403a-a6af-93823dd2d5cb
|
||
- Whenever the structure part of a model is modified, the adaptation must account for the evolution of the schema and the migration of the existing data.
|
||
ls-type:: annotation
|
||
hl-page:: 17
|
||
hl-color:: purple
|
||
id:: 651be00d-b48b-4368-b6f3-dc5d58c2d445
|
||
- different SQL queries must be generated to consistently manage this operation according to the data change classification summarized in the upper part of Table 1.
|
||
ls-type:: annotation
|
||
hl-page:: 17
|
||
hl-color:: green
|
||
id:: 651be01d-6d6e-465d-bb6c-f0c2f99b37e8
|
||
- structure model changes imply the generation of SQL queries to update the database schema, and to migrate the already stored data
|
||
ls-type:: annotation
|
||
hl-page:: 17
|
||
hl-color:: blue
|
||
id:: 651be156-1ab7-4d4b-bb6c-d1986e5e64af
|
||
- the deletion of data entities is managed by the lines 1–15 in Listing 3: it produces the SQL queries in the lines 1–5 in Listing 4 to deal with the deletion of the data entity Picture, as represented in the difference model in Fig. 18 by the DeletedCustomEntity element
|
||
ls-type:: annotation
|
||
hl-page:: 17
|
||
hl-color:: green
|
||
id:: 651be199-85aa-4f0a-ab32-ac3460ab4a7f
|
||
- employer table since it has a column which refers to tuples of the table picture.
|
||
ls-type:: annotation
|
||
hl-page:: 17
|
||
hl-color:: green
|
||
id:: 651be1a3-8be0-454a-a7cb-7922e2665c72
|
||
- The existing queries to retrieve the appropriate data for page contents are generated as relying on the structure model definition in a beContent model. Therefore, whenever the structure concern is manipulated, the corresponding queries are automatically and consistently updated.
|
||
ls-type:: annotation
|
||
hl-page:: 18
|
||
hl-color:: green
|
||
id:: 651be216-8e18-4482-b931-b898758a68c3
|
||
- tate-based techniques are adopted as in our case, which required an additional tuning by means of ECL
|
||
ls-type:: annotation
|
||
hl-page:: 18
|
||
hl-color:: purple
|
||
id:: 651be220-bcd0-4d5b-b47d-38ce8c88c0de
|
||
- Unfortunately, it cannot be as accurate as in the previous case since the adaptation has to be manually performed by the designer. Nevertheless, interesting documents can be generated to describe the kind of operations which the designer might consider during the management of the migration stage, as the fragment in Listing 5 which is directly generated from the difference model in Fig
|
||
ls-type:: annotation
|
||
hl-page:: 19
|
||
hl-color:: purple
|
||
id:: 651be23f-80cd-4f9b-a988-3c865bb04055
|
||
- In order to keep the system in a valid and consistent state, regenerating it does not suffice because of a variety of aspects which are either subject to customization or are referring to information which has been created after deployment.
|
||
ls-type:: annotation
|
||
hl-page:: 28
|
||
hl-color:: purple
|
||
id:: 651be2bb-f9dc-425b-9f75-13c127b56a23
|
||
- from automated tools to prescriptions which can help the designer to consistently evolve the affected assets.
|
||
ls-type:: annotation
|
||
hl-page:: 28
|
||
hl-color:: purple
|
||
id:: 651be2ca-b9b3-4bda-8462-500277326b19
|
||
- differencing, data schema evolution, and coupled evolution
|
||
ls-type:: annotation
|
||
hl-page:: 28
|
||
hl-color:: purple
|
||
id:: 651be2d7-0b61-4323-93f9-cf2266144634
|
||
- The techniques presented here have been validated using the beContent metamodel which permits the declarative specification of Web applications generated by means of automated transformations.
|
||
ls-type:: annotation
|
||
hl-page:: 29
|
||
hl-color:: purple
|
||
id:: 651be2e7-505a-46bc-a0bb-8d90068b955e
|
||
- By differencing beContent models, migration routines are obtained through model-to-code transformations whenever exact adaptations were possible, otherwise in order to re-establish the system consistency a migration recipe is proposed
|
||
ls-type:: annotation
|
||
hl-page:: 29
|
||
hl-color:: blue
|
||
id:: 651be331-4e19-457e-b4c3-ae2dd0feee58
|
||
- to better clarify the generality of the proposed technique an outline is provided of the needed steps to implement the same evolution support for WebML-based applications
|
||
ls-type:: annotation
|
||
hl-page:: 29
|
||
hl-color:: blue
|
||
id:: 651be33c-0252-4f35-83e1-f915d6317853 |