I went through the pain of generating a .uml model from java source in Eclipse.
I am using Papyrus for drawing diagrams, but it seems that the only way of displaying my model is manually dragging elements. Every class/method/field/association needs to be manually moved over.
This is quite a tedious task. I would think that a 'batch loading' of elements would be available, so is it? If there isn't, do you know of a tool that is able to use the same .uml format and has this functionality?
I'd rather move everything and weed out unneccesary stuff rather than spend hours DNDing.
Thanks!
I know it's been five years, but the current version of Papyrus does allow for drag and drop of many elements on a diagram, and you can multi-select to and bring up a context menu for commands to display information about the internal structure of the classes (for example).
Since the Neon release, Papyrus also has a much improved and tailorable layout mechanism that may meet your needs.
However, a ".uml" file typically does not contain any information with regards to diagrams, so there would be nothing to build on for diagram except for the layout tools.
Related
I have an e4 RCP which needs all the screen real estate. I have developed a second RCP that is in effect a relatively simple single-function plug-in, with currently only one part. I want the user to be able to launch the second from the first, then terminate it, all on demand.
As I understand it, I have 3 options:
Launch a new workbench for the second, written as a plug-in. I assume this uses more resources and also has the problem that I need to track and distinguish events which will go to both.
Write the second as a model fragment plug-in that extends the first. This has the advantage that I can keep on adding to the second plug-in by declaration in the model editor. However, I believe this requires attaching to an existing container in the main model. I could add a new container to the main model and write code to flip containers in and out but it is all done in the model editor currently, and more importantly the functions carried out by the second plug-in are quite different from those of the first (main) RCP, so I fear the user will find the UI change confusing.
Use EModelService and write code to create a new TrimmedWindow and then child PartStack, and Part, and all the Handlers. I have not yet found enough documentation to fully understand the implications, advantages and disadvantages of this - aside from the obvious ones that the former declarations now have to be programmed and coupling is tighter.
It looks to me like Eclipse itself uses approach 1 for two of its menu items:
Help Contents
Eclipse Marketplace
From the UI perspective, the kind of UI separation of functions that I want to achieve is very much like these two items. Hence I am leaning to option 1.
Any corrections or alternatives?
You could possibly use a PerspectiveStack with two perspectives containing the windows for your two apps. The second app can be in model fragment.
You can then just use EPartService.switchPerspective to switch between them.
Our team has been using Rhapsody for developing UML models and c++ code for 10+ years, and we would like to switch to Eclipse and use Papyrus for UML modeling.
We have compatibility concerns: would the UML models (all class diagrams, state machines etc) created in Rhapsody be all portable to Papyrus/Eclipse easily? Rhapsody can export UML models into XMI files (UML 2.1, 2.2, 2.3 standards). My questions is: is Papyrus able to reconstruct diagrams from XMI files
If not, are there better alternative UML plugins that work in Eclipse?
The XMI file exported by Rhapsody contains only meta data of the models. Is there a quick way to port the entire project from Rhapsody into Eclipse? Anybody experienced the similar?
Your answers will be much appreciated.
First, I must mention that I am directly involved with Papyrus, especially with the brand new Papyrus for Real Time project, at Eclipse.
First to set expectations... Moving diagrams between modeling tools has always been an exercise in frustration... There have been "standards" over the years (e.g., OMG's XMI-DI), but none seem to have been fully successful and all have necessitated a manual review. Note that I have not tried with the latest version of UML (2.5).
Now the model semantics, however, have a tendency to be more portable, especially with more recent versions of UML. I am not sure which version Rhapsody pretends to support, so it would be difficult to comment further.
With the version of Papyrus that is currently in development (with a scheduled June 2015 release), the notion of "canonical" diagram has been added. This provides for automatic creation and update of some diagrams under certain condition. for example, many behaviour diagrams, such sequence diagrams and some structure diagram, such as composite structure, can be canonical and generated from the semantic model. However, layout would still need to be adjusted. Other diagrams, such as class diagrams, would have to be manually re-created.
As was mentioned in the comment to your question, trying it out would give you the best indication of how much work is involved.
I am interested in this topic and I did a simple research on it: in fact a connector between RSA and Ppayrus is already open source https://www.eclipse.org/forums/index.php/t/835114/ it could be usefull to take a look at it and implement the same for Rhapsody.
I know that the Rhapsody XMI export did not export the graphical elements, you should probably then export them in a serialized format and mapping htem to papyrus diagram element.
other interested work but seems not to be free : modelbus https://www.modelbus.org/en/rhapsody.html which implement connectors with Papyrus EA and Rhapsody : could be also interesting to look at.
I am interested in your feedback if you did not let it down and do achive the mapping :)
This is a relatively open ended question so I wouldn't just mind being pointed in the right direction.
I have a product that uses the Eclipse workbench to allow users to program in a custom language. For this product, I will also have some minor UI and internal changes for a lighter version to be exported. For example, a full version of the product contains some extra views and menus, and behaves slightly differently (like when creating a new file) where as the ligher version does not contain a lot of view and has a couple of different more simplified ones.
I do not want to make a copy of my workspace and then have 2 separate workspaces for a full version and a lighter version as that will be difficult to maintain in the long run especially when there are changes in code relevant to both. I want to be able to export both, full and light versions of a product from a common workspace.
How can I go about this? Or where can I start looking?
The product is a collection of features and uses the Eclipse workbench as its base application.
I would like to clarify that I am asking how I could hide a view for the full or light version, as an example. I know in C#, we have options like #if. I have seen a lot of questions which refer to having 2 different versions of the same code, but nothing about how they could have 2 different versions of the same code.
You want the Eclipse RCP book it really fully explains how to do this. And to do it you need a solid understanding of the concepts of Eclipse plugin, feature, product, fragment and a few other things.
Essentially you can segment your application in to multiple plugins (have a base plugin for example, and then another that provides additional functionality). Then you organize those plugins into features that are the collection of the functionality to be installed. The notion of a "product" in Eclipse has to do with the branding, so you would probably have two products, a lite and a full one. The products could have a branding plugin (where the product is actually declared).
This should get you started.
I am currently working on a project in Eclipse but the problem is that this project is very big (a lot of codes, classes, packages, etc) and undocumented. Since, the project is written in Java, my idea was to make a reverse enineering of the project to see his architecture in UML. Do you know an eclipse plugin who can complete this task very easily? Thanks for your answer !!
I think MoDisco is what you are looking for ( here for a short intro)
It seems that the question is dealing with Eclipse plugin therefore Modisco and StartUML are not a possible choice because they are either not a graphical class diagram viewwer or an Eclipse plugin.
The tools that I have evaluated and selected are:
Topcased can reverse a project and gives an UML view. The reverse is good even if not recursive. I mean that you can detect only object having their own information such as class, interface, package, method and attributes but you can not detect calls between classes because this require a recursive reverse.
eUML will give you a visual class diagrams and the possibility to navigate but no model only EMF tags inserted inside your own code. I like the visual representation of the class diagram but having EMF tags in my code is too intrusive !!
You can try RSA which is a pretty good reverse having a real UML model but you will also get EMF tag in your code
The best for me and with no doubt is EclipseUML Omondo with no tag in the code and a high quality UML model but it is really too expensive !!
I'd advise StarUML or StavrUML, the unofficial fork. It reverse engineers code compliant with Java versions before 1.6 or something. Yes, the project was abandoned years ago, but the UML editor remains incredibly strong and powerful.
However, I'd avoid using reverse engineering a UML diagram. You'll probably get an unreadable mess out if it. Just get stuck in and make it manually :)
I'm sure you can find a suitable tool for your needs if you check these.
I'm evaluating the possibility of developing an Eclipse plugin to modify the source code of some Java files.
The Eclipse plugin should:
add one menu option or context menu option to launch the modification process.
add a key binding
only alter the UI in that way when an editor has been open on a Java file.
the modification process would not open a dialog, or maybe, a very simple one.
the modification process would traverse the AST of the Java file and would modify it.
Considering that we have no experience with Eclipse plugins and we need spend time in reading docs, how much time do you estimate in developing that plugin?
Thanks in advance.
It's really not that difficult at all... I had students in my design patterns class doing it for an assignment (adding/removing javabean getters and setters)
See http://help.eclipse.org/ganymede/topic/org.eclipse.jdt.doc.isv/guide/jdt_api_manip.htm
[EDIT: added the following article reference]
And a great article on it at http://www.eclipse.org/articles/article.php?file=Article-JavaCodeManipulation_AST/index.html (from 2006 -- there may be a few API changes since)
Yes, writing plugins takes a little getting used to, but so does any API.
And you can modify the AST -- see the page I reference above.
(I should note that the above link is from the eclipse help, which can also be accessed via Help->Help Contents inside Eclipse -- there's a lot of good info in there, but it's just a starting point)
You'll probably spend quite some time cursing the complexity of the eclipse plugin system. There are some example plugin development projects that can be very helpful if they cover the area you're working in.
I'd say you're looking at 2-4 days of work, spent mainly getting familiar with the platform - someone with a lot of experience writing eclipse plugins would probably take no more than an hour.
However, your step 5 could be tricky. I don't know how easy it is to access and change the Java AST; my experience is based on developing an editor plugin for an exotic file format rather than Java code.
Well, the four first points are easy to achieve, even by monkey coders that look at the eclipse PDE documentation shipped with Eclipse. These can be achieve in 1 day of work, maybe 2.
The hardest point is really the fifth one and the kind of modification you expect to do. Acting directly on the editor content is simple, accessing the editor internal AST and modifying it is really a bigger challenge and I doubt that it could be achieve in less than a week by unexperimented people (it can take longer, depending of what kind of modification you want to apply).