From 83a61595154affeb0085144c21df270f0923e705 Mon Sep 17 00:00:00 2001 From: Maged Elaasar Date: Wed, 4 Apr 2018 16:16:09 -0700 Subject: Bug 532101: [AFViewpoints] Make AF editor faster Bug 532104: [AFViewpoints] Transform your Workspace reference to platform reference - Simplified the AF model wizard by defaulting the root to be Architecture Domain. - Extended the Load Resource action in the AF editor to allow loading AF models from the running platfom. - Added a Resolve All action that can be used on any object in the editor to quickly resolve related references. This can be used on a loaded AF model (from workspace or running platform) to also load its dependencies like elementtypeconfigurtion and palleteconfiguration files. - Made the architecture, elementtypesetconfigurtion, nattableconfiguration, and paletteconfiguration resources extend of a common base class that supports default load/save options. This base class also makes the cross references persist using platform:/platform URIs but upon load, they may resolve to platform:/resource if the resource is available in the workspace. - Refactored uml.architecture, all the elementtypeconfiguration, all palletteconfiguration, and all nattableconfiguration models by changing their cross references to platform:/plugin URI format. - Fixed PasteEObjectConfigurationItemProvider to make the containment reference axisIdentifier show in the editor/property sheet as a containment reference (was necessary to convert its cross references properly) Change-Id: I69b82f53670cbb81e9117ce82c61d7c898080c93 Signed-off-by: Maged Elaasar --- .../resources/architecture.mediawiki | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) (limited to 'plugins/doc') diff --git a/plugins/doc/org.eclipse.papyrus.infra.architecture.doc/resources/architecture.mediawiki b/plugins/doc/org.eclipse.papyrus.infra.architecture.doc/resources/architecture.mediawiki index a49efca82b9..93ca91a8e7a 100644 --- a/plugins/doc/org.eclipse.papyrus.infra.architecture.doc/resources/architecture.mediawiki +++ b/plugins/doc/org.eclipse.papyrus.infra.architecture.doc/resources/architecture.mediawiki @@ -78,7 +78,7 @@ The architecture metamodel in Papyrus is implemented as a realization and an ext ==Walkthrough== -The definition of an architecture model in Papyrus starts with the selection of the ''Architecture Model'' option in the Eclipse ''New'' creation wizard under the ''Papyrus'' category. The top element of the file should be a ''Architecture Domain'' element. +The definition of an architecture model in Papyrus starts with the selection of the ''Architecture Model'' option in the Eclipse ''New'' creation wizard under the ''Papyrus'' category and clicking Finish. Step 1: Specify the ''Name'' and ''Description'' of the ''Architecture Domain'' (the root element). @@ -86,16 +86,18 @@ The definition of an architecture model in Papyrus starts with the selection of Step 3: Right click on the domain to add one or more ''Stakeholders''. In the properties view, specify the following for each stakeholder: a ''Name'', a ''Description'', and one or more references to ''Concerns''. -Step 4: Right click on the domain to add one or more ''Architecture Description Languages''. In the properties view, specify for each language: a ''Name'', a ''Description'', a unique ''Id'' (e.g., org.eclipse.uml2.UML), an ''Extension Prefix'' if desired (e.g., profile), an ''Icon'' using a platform URI (e.g., platform:/plugin/project/icons/xxx.png), a ''Metamodel'' as a reference to an ''EPackage'' (load the Ecore model first), one or more ''Profiles'' as references to ''EPackages'' (load the Ecore models first), one or more ''Element Types'' as references to ''ElementTypeSetConfigurations'' (load the *.elementtypesetconfiguration models first), a creation command using a fully qualified of a Java class implementing the IModelCreationCommand interface, and an optional conversion command using a fully qualified of a Java class implementing the IModelConversionCommand interface. +Step 4: Right click on the domain to add one or more ''Architecture Description Languages''. In the properties view, specify for each language: a ''Name'', a ''Description'', a unique ''Id'' (e.g., org.eclipse.uml2.UML), an ''Extension Prefix'' if desired (e.g., profile), an ''Icon'' using a platform plugin URI (e.g., platform:/plugin/project/icons/xxx.png), a ''Metamodel'' as a reference to an ''EPackage'' (load the Ecore model first), one or more ''Profiles'' as references to ''EPackages'' (load the Ecore models first), one or more ''Element Types'' as references to ''ElementTypeSetConfigurations'' (load the *.elementtypesetconfiguration models first), a creation command using a fully qualified of a Java class implementing the IModelCreationCommand interface, and an optional conversion command using a fully qualified of a Java class implementing the IModelConversionCommand interface. Step 4A: Right click on the description language to add one or more representation kinds, i.e., ''Papyrus Diagram'', ''Papyrus Table'' or ''Papyrus Sync Table'' (see details below). -Step 5: Right click on the domain to add one or more ''Architecture Framework''. In the properties view, specify for each framework: a ''Name'', a ''Description'', a unique ''Id'' (e.g., org.eclipse.dodaf), an ''Extension Prefix'' if desired (e.g., profile), an ''Icon'' using a platform URI (e.g., platform:/plugin/project/icons/xxx.png), and one or more ''Element Types'' as references to ''ElementTypeSetConfigurations'' (load the *.elementtypesetconfiguration models first). +Step 5: Right click on the domain to add one or more ''Architecture Framework''. In the properties view, specify for each framework: a ''Name'', a ''Description'', a unique ''Id'' (e.g., org.eclipse.dodaf), an ''Extension Prefix'' if desired (e.g., profile), an ''Icon'' using a platform plugin URI (e.g., platform:/plugin/project/icons/xxx.png), and one or more ''Element Types'' as references to ''ElementTypeSetConfigurations'' (load the *.elementtypesetconfiguration models first). Step 6: Right click on the description language (step 4) or framework (step 5) to add one or more ''Architecture Viewpoints''. In the properties view, specify for each viewpoint: a ''Name'', a ''Description'', a unique ''Id'' (e.g., org.eclipse.uml.design), one ore more references to ''Concerns'', and one or more references to ''Representation Kinds''. Step 7: Deploy the model. The new architecture file can be deployed in an Eclipse plugin and registered through an extension point. The extension point to use is org.eclipse.papyrus.infra.architecture.models. Alternatively, the model can be deployed using the ''Other Architecture Model'' button in the ''Architecture Contexts'' preference page. +Note: If the Architecture Model you are developing is considered an extension of another model that is available in the target platform, and you want to reference some of its dependencies (like elementtypeconfigurations and palleteconfiguration, etc.) you first need to load the plugin that contains the model in your workspace. Then, using the Architecture Model editor, load the other Architecture Model using the ''Load Resource->Browse Workspace'' context menu action). This will import it using its "platform:/resource" URI. On the other hand, if the extended architecture model is rather deployed in the current platform, then use the ''Loaded Resource->Browse Registered Architectures'' context menu action. This will load the model using its "platform:/plugin" URI. Once the extended model is loaded in the editor, you can invoke the context menu action ''Resolve All'' to load all its related resources. + ==Papyrus Diagram Specification== Once a ''Papyrus Diagram'' is created, in the properties view, specify for it: @@ -104,7 +106,7 @@ Once a ''Papyrus Diagram'' is created, in the properties view, specify for it: * An ''Implementation ID'' (required) which selects the physical (hard-coded) diagram in Papyrus that will be used as a base. The possible values for this property are summarized in the following table. * An optional ''Parent'' that specifies a parent viewpoint-defined diagram to inherit from. Essentially, the inheriting diagram will defer to its parent�s rules (see below) when its own are not sufficient to take a decision. * An optional ''Custom Style'' as an URI of the form platform:/plugin/.... It must point to a CSS file that will then be automatically applied to the diagram. -* An optional ''Custom Palette'' as an URI of the form platform:/plugin/.... It must point a palette definition in XML that will be automatically applied to the diagram. +* An optional ''Palette'' as an URI. It must point a palette definition in XML that will be automatically applied to the diagram. * Other attributes are inherited from the ISO 42010 implementation and are currently not used in Papyrus. {| border="solid 1px grey" -- cgit v1.2.3