Is there a way to hide or remove the various base_Class properties that appear together with the properties defined for a stereotype? I am close to deploy a profile and I am pretty sure this will generate some confusion among the users.
Actually you really don't want to remove the 'base_*' properties as these indicate the meta class that your stereotypes extend. When a user goes to apply your profile, the meta class extension allows the UML editor e.g. Papyrus to display appropriate stereotypes for the target UML element. So if a user wants to apply your profile to a UML Class element, without the 'base_Class' property, nothing will show up. These extensions are linked to other elements within your profile so just removing them will cause your profile to "break" elsewhere. Other typical meta class extensions might be Property i.e. a 'base_Property' will show up. There are many others.
Oh ok cool. So when your users apply the profile to a model this takes place, as you know, primarily under the Profile->Applied stereotypes area of the Properties editor. The meta class extension properties are definitely not visible there, at least on my Papyrus version. Using Modeling Luna 4.4.0
Related
We use elements with composite diagrams in our models. Usually if such a composite diagram exists, then the element shows a link icon to indicate a double click will open/show the diagram.
But with ArchiMate elements the link icon is not shown unless using the rectangle notation. Is there some workarround or configuration to allways show the icon?
This screenshot illustrates the problem:
Out of the box, there is nothing you can do. There is no setting or configuration that will show the composite diagram indicator on the Archimate elements.
The reason is that the shapescript used for these elements simply doesn't include this indicator.
There are a few options to get this done anyway
1 Send a feature request to Sparx
You can use this link: https://www.sparxsystems.com/support/forms/feature_request.html to send an official feature request to Sparx Systems. They might one day implement this, but there are no guarantees at all.
2 Override the standard the ArchiMate MDG
Steps include
Create your own stereotypes in a profile, redefining the existing ArchiMate stereotypes. See the manual for more details
Include your profile into an MDG
Add your MDG to your model or environment
Set your MDG to Active to actually make the redefines happen.
This might be interesting if you want to add additional properties (tagged values) to the standard ArchiMate stereotypes as well. I'm not so sure if it's worth the trouble just to add the composite indicator.
3 Hack the existing Archimate MDG file
The Archimate MDG is defined in the file C:\Program Files (x86)\Sparx Systems\EA\MDGTechnologies\ArchiMate3.xml. This is an XML file that you can open with any text editor. The shapescripts are included in binary form like this
<Image type="EAShapeScript 1.0" xmlns:dt="urn:schemas-microsoft-com:datatypes" dt:dt="bin.base64">
UEsDBBQAAAAIAGaEbU+CvMH4PQIAADAKAAAHABEAc3RyLmRhdFVUDQAH1zDMXdcwzF3XMMxd
zVVJTsNAEOyrkfhDFC6OlAP7IsSRF/AAlMSJY5FNjgMKiL9T1Z3B9tiJAxKLLI9nqamumV68
lLH0ZCFDackUvURmcigH8qZtIBPMrWUuK8nwrBV5J23pYy6VCKMUo9sNeobZpTJG6L0AmWF9
BZRDWJvISELFLcGYAkveVC2E4EsxGmDUA2MMDUNl5jjD3jlGbeniPcbbwWOsTnOgukbgTuQV
vVDO5AL4K+A7n0oCrJORVhfKPAayuD6E5Qk4FkCS5RT7u/pea3vm8VFltIVrBB6y8USRWuap
n7CnHj/F6jNWM3xDqK+zR20zD+OfsYw5UQzbMqrO2m6mm72YzB75mpjKmPfNlx7g3Tf51zh8
xdUoChWXK687AWOXHlohxi2WGZuMSnqKa1QfbyKQkbjf7hn6U/Rt30AYLZlY/hQZ3Dff3fIs
O0R+H4FmEe+EfOxF2D0EPsY3Qx4ydnMb7n7rrTmldXbG8ohVejAGjpWgfJLcRqA1YgIl1Srg
FPM8md7O0afVI+8+nFb7Wsu3qJh51RdGC1ec3u32GVOMPiqIVQU1LFGx6B2LEafBdvx0xdrv
Nvw7YB4M9By5nRb6VMLZ4m3Yac1XOZoeZC7mnvuN8zbl91crMyuj+Y01oCvnXk7vqszfq8W+
hf9fi+3vtbsW23+trhY3xRxnprg//v8TYTUgtjn2HuS+EHt/G3VN1hPMV89pFl2FKdotV04/
Zl0UufbS80x1BxEO7f5f1V1lr1tm+F73/W5Z46PqKu8HUEsBAhcLFAAAAAgAZoRtT4K8wfg9
AgAAMAoAAAcACQAAAAAAAAAAAACAAAAAAHN0ci5kYXRVVAUAB9cwzF1QSwUGAAAAAAEAAQA+
AAAAcwIAAAAA
</Image>
If you replace that section with a shapescript of your own, it will happily accept that. You can create this format by creating your own profile in EA and then exporting the package as a UML profile. EA will then convert your shapescript into this binary format.
I one published the shapescript for most of the MDG's, including ArchiMate3 on github. That might give you a head start when developing your own.
is there a way to have prefilled attributes notes in enterprise architect?
It should be something like this scenario:
1) I create new attribute
2) Enterprise architect prefill note of attribute with predefined text
Something like template for attributes.
Thank you for any advice
I know this won't help directly this question.
Anyways you can achieve it through an external addin.
All you need to do is handle the EA_OnPreNewAttribute and EA_OnPostNewAttribute broadcast events .
This isn't quite what you're after but it is possible to create an Attribute stereotype in a Profile and add to this a Tag with an initial value set to what ever you want. When you create an attribute with this stereotype, this means your predefined text would appear in a tag-value for the attribute rather than the note. Not ideal, but might work for you.
You could also have a go at writing some JavaScript to do this as well (under Scripting in EA). You'd have to use the JS to navigate the repository structure, find the attributes in question, and update their note. I don't believe you can attach a script to a UI event, so I think you'd be stuck running this post-hoc rather than having the note auto-populate on attribute creation.
I am working on an eclipse plugin in which I have used decorators to decorate my resources with different text as a prefix. Now I want to search these resources with the text which I have used while decorating the resources.
What I exactly want is to extend eclipse's open resource dialogue so that I can enter the text which I have used to decorate resources to find them.
So how could I achieve this...
Many thanks..
The Open Resource dialog is not really customizable.
The dialog class is org.eclipse.ui.internal.ide.dialogs.OpenResourceDialog. This extends FilteredResourcesSelectionDialog which contains most of the label providers and the like which you would have to change. However this class is not designed to be modified and would be hard to change.
FilteredResourcesSelectionDialog in turn is derived from FilteredItemsSelectionDialog which can be extended more easily, but you would have to duplicate a lot of code from OpenResourceDialog and FilteredResourcesSelectionDialog.
Is it possible to add attributes to a Visio (in my case 2007) UML diagram Interface object? It shows operations in its properties dialog, but alas no Attributes section. I am really hoping someone has thought of a way around this (without looking at third-party apps).
It is possible to achieve the same visual Effect: An interface is represented like a class with a stereotype <<interface>>. So you can go to UML/Stereotypes/New and enter "interface" as Stereotype name, then select Class as base. Now you can Create a new Class, edit it and select the new interface stereotype. After doing so you have a visual representation of an interface which can hold attributes.
Maybe this suites your needs. Still the internal representation of these models is not UML 2 compliant (but Visio has other flaws regarding that either way).
I'm building a Zend-based Web app that will permit third-party extensions.
Essentially, this application's database will have a generic "content store." Extensions are added to render different pieces of content in different ways.
Think of a rich mail store: When the user asks for a "Calendar" item, I instantiate a Calendar class (or something) and ask it to render the item's content. The same database might contain "Mail" items, which are rendered by a different class (or whatever). So I'm basically defining a base class with the needed methods to handle content items, and then add-ins are written which inherit from that to deal with specific item types.
Each of these add-ins may need to access its own View files, since each of them will obviously have a different visual layout.
I can't foresee all the content renderers that might be used; new ones will be "installed" (in some fashion) so that my application knows "when I see content with a database type column of XYZ, I'll call the XYZ thing to render that."
Likely, what will happen is this: User will visit a URL for the application, thus triggering an action within a Controller. That Controller will use a Model method, telling it which specific content item was requested.
From there, either the Model or the Controller (which?) needs to call something (what?) that gets the item from the database (okay, the Model clearly does that) and renders it using some predetermined View. This would be PART of a larger page that might well include several rendered items (as in, a list of content items).
So two questions:
What's the best way to architect this in Zend Framework? I do want these add-ins to inherit from a base renderer class that I provide, because very simple renderers may simply need to call functionality from that base class, rather than having any of their own code (e.g., a "Note" and a "Memo" might well use the simplified rendering functionality from the base renderer class).
What's the best way to "register" these add-ins with my application? An .ini file, perhaps a database table? The goal is simplified installation steps for whoever is operating the application - e.g., editing an .ini file is often easier than manually querying a database, although I could also provide an admin back-end UI for new content renderers to be registered in.
I'd implement the Visitor Pattern for this.
Each third-party extension should implement an interface that you define, so that you know you can call a specific method, say render() on any object that is an instanceof that interface.
Each extension then implements its own rendering. Perhaps it utilizes a View partial in the Zend Framework architecture. Or else perhaps it uses some totally different code to render itself as a PDF or something (maybe each extension needs to be able to override content-type headers?).
As for how to register it, check out the Zend_Application framework for defining resource plugins.