Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Papyrus/Neon Work Description/NewFeature/Papyrus Refactoring Service"

(EMF Compare Integration)
(EMF Compare Integration)
Line 68: Line 68:
 
==Refactoring Resolution ==
 
==Refactoring Resolution ==
 
=== EMF Compare Integration ===
 
=== EMF Compare Integration ===
[[Papyrus_Refactor_Service_EMF_Compare_Integration.PNG|Integration of Model Resolver from EMF Compare]]
+
[[File:Papyrus_Refactor_Service_EMF_Compare_Integration.PNG|Integration of Model Resolver from EMF Compare]]
 
:[https://bugs.eclipse.org/bugs/show_bug.cgi?id=471024 471024]
 
:[https://bugs.eclipse.org/bugs/show_bug.cgi?id=471024 471024]
  

Revision as of 12:30, 30 June 2015

Papyrus Refactoring Service

Overview

An UML model can contain several files and it can reference external models. When user makes an action as rename a file, Papyrus must ensure that all references are always consistent at the end of execution.

Use Cases

Requirements

Index Description
REQ_001 Have a central mechanism to manage Refactor operation
REQ_002 Can choice the scope of the refactor resolution

Notions

Based on Control Mode mechanism and Element Type service, the mechanism uses three notions:

Notion Description
Request It contains all necessary information to execute correctly the refactor.
Service It is the entry point for the mechanism and it takes Request to deliver commands. It knows all participants.
Participant It registers on service to provide a command according to input request.
Command It contains refactor operation.
Scope It limits the refactor operation. It takes three values: None, Project, Workspace.

Components

The new mechanism adds a new plugin to contain all engines. This new plugin exposes an extension point.

Plugin

Refactor plugin and dependency

A new plugin will be created to contain the Refactor service. To declare the service, this plugin must depend of org.eclipse.papyrus.infra.core which exposes the extension point to declare a Papyrus service. The Refactor service plugin exposes itself an extension point, org.eclipse.papyrus.infra.services.refactorParticipant to register participants of Refactor.

Extension Point

It permits to add new Participant to a refactor. This class must implement the interface IRefactorParticipant. The participant returns a command according of input request. The role of participant has to be clearly defined to know which side effect of Refactor, it resolves. The participant is dependent of its scope resolution.

User Interface

Description

The service needs to know which is the refactor scope. The scope determines from where the refactor starts. The user interface lets to user to choice between three different scopes.

Scope Description
None It means that refactor doesn’t need to be executed.
Project It means that refactor uses all models present in Project to resolve broken references.
Workspace It means that refactor uses all model present in Workspace to resolve broken references.

Behaviour

Sequence diagram of Refactor scope definition through UI

Conception

The mechanism is similar as Control Mode or Element Type Edit service. From one request and the service, this one returns a command for the refactor.

Architecture

Architecture of Refactor service

Interaction

Sequence diagram of Refactor service

Refactoring Resolution

EMF Compare Integration

Integration of Model Resolver from EMF Compare

471024

Related Bugs

Back to the top