I have an enum that has two dependencies. These two are in different projects (Im coding in Java). I want to show this dependency ina UML diagram but how can I show what projects these classes are from? (I know for packages you can put it like this: Package :: pkgName).
Any ideas would be helpful. Thanks
What tool are you using?
In Rational Rose, if you this structure:
Folder1
|___Class1
Folder2
|___ClassDiagramX
and the ClassDiagramX shows Class1 then you'll see a small "stereotype" like note indicating "from Folder1" in the box representing Class1.
That should be sufficient.
There are other options using fancy-colorful-notes, but I don't care so much for them.
--edit--
Without knowing the tool I can't really say what you can and can not do. From UML pov, I don't know of any defined convention, so whatever conveys what you wan to can be used. Class diagram is a representation and does not affect the meta-data of the class (e.g. which project it belongs to). So as long as the "class" is in the correct package, it's doesn't matter how it's "shown" in the class diagram.
E.g. in the class-diagram you can put up 2 big squares in the background showing / grouping classes from each project and dependency arrows running across these groups.
OR
"add the line" if that's possible in your tool.
If you use Eclipse and java then you have a feature which allow to join two different projects. I mean open the package explorer and click on the project name then select join, or merge with I don't really remember the exact title of the menu but it is easy to find.
Once your both projects have been joined your can create a class diagram and just drag drop inside the same diagram two classifiers coming from different projects.
Project in the sense of "a set of planned activities and deliverables, with common goal" can not be reasonably encoded in UML.
Project in the sense of "a set of related files and metadata that allows an IDE to compile and run a program" is out of scope for UML, as this is a development environment artifact and not application design artifact.
For example, you can decide to use multiple projects for each module of your app or a single project for all modules. This will not change your design, only the instructions for the IDE - it's even possible that different team members have different project configurations, especially if some use Eclipse, others IntelliJ IDEA and some EMACS.
On the other hand, if you still want to denote logical sets of classes, you do have options - the formal way would be to use tagged values. Alternatively, I often use colors (for example, green for public API, yellow for extension points/SPI and red for implementation classes; or blue for low-latency multicast component, green for guaranteed messaging components).
You may also use a separate component diagram, showing which class belongs to which component (remember not to build uber-diagrams, but instead aim for simplicity and showing only the relevant facets of the design)
This was a generic advice, but the answer you need is very context-specific. I can get more concrete if you can describe in more detail what are the classes in question, what are the projects (how do you delineate between them) and the overall architecture of the system.
Related
first of all - I am not sure if cucumber support this, but is it possible to define features in different module than in one that contains feature files?
Given real life example:
Let's say I want to have module called 'carcore',
Then let's say I want to have module called 'Volkswagen',
and other one called 'Ford'.
Is it possible that I will put feature deffinition files for common features in 'carcore' module but keep feature diffinition files specific for vokswagen or ford in their own modules?
I am using gradle to sew this modules together. It is more or less simple. Though when Cucumber annotations are introduced, it is not that easy. Cucumber is not able to find feature definitions in other modules. I was not able to find any relevant and useful reading, so if anyone can help me or point me into right direction I would be very glad.
Cucumber is designed so that you have one World for your features, and in that world each thing you talk about should have a unique name and a single definition. It deliberately chooses to not have any kind of name-spacing. The rationale behind this is that Cucumber is a tool for describing business behaviour not for programming.
What you are doing with your modules is programming, and what you seem to reflecting is HOW your program is implemented, but HOW has no place in Cucumber scenarios; they should be written way before you think about HOW to do things. Scenarios should only be about WHAT the business wants and WHY they want this.
What you can do with your modules idea is push it down your stack, into the step definitions or better yet modules that define calls that your step definitions can use. Now because you are in a programming language you have the power to program in whatever way you need.
Finally Ford and Volkswagen are brands of Car. Whilst you might use the names as examples having a module for an individual brand seems wrong at any level.
It is done automatically as with any other classes.
Cucumber will pick up automatically any feature definition files that are in defined dependencies.
My IDE didn't picked up the relation between feature definition file and feature itself, so it got me confused.
I'm working on source code that is split across several projects with a specifically defined build order. I want to see the projects sorted by the build order so I can always tell which classes can be used in which projects. Does anyone know how to do this in Eclipse Kepler?
If you are not already using working sets in Eclipse, they provide a good way to organize your projects. The organization is single-level, rather than hierarchical, but you can group projects and then quicly select in the project explorer view settings whether you want the working sets to be shown or not. A potentially useful detail is that a project may be contained in multiple working sets, so that you can have multiple grouping criteria at the same time.
In your case, you could define a working set for each phase of your build, prefixing its name with a letter or number that would ensure its presentation in a specific order. Or you could define a working set for each set of projects with the same dependencies.
Alternatively, you might be able to just rename your projects appropriately. In many cases the project name itself is mostly cosmetic, although it is often used as a default in generated files.
In my opinion, however, the easiest way to "tell which classes can be used" is to just configure your project build paths correctly and let the editor do the rest. For me it is more natural not to use a class because it is not proposed for auto-completion or because any such use results in a compiler error, rather than explicitly checking the dependencies each and every time...
IMHO there is no such feature in eclipse. But you can use Resource Tagger plugin or Resource decorator plugin and filter the resources based on different conditions.
Is there some sort of tool that you can point at a set of Java classes, and it produces output showing the transitive imports of each class?
I understand that imports are not "transitive" from the point of view of the language itself - i.e. if com.acme.X imports com.acme.Y, and com.acme.Y imports com.acme.Z, that does not mean that you can refer to com.acme.Z within com.acme.X. But that's not what I mean:
Rather, I mean that com.acme.X nonetheless depends upon com.acme.Z (at least under the current implementations of X and Y), and I want to know that fact. In fact I want to know it for a large number of classes, and so I'm hoping that there's a tool do determine it automatically.
Either a standalone tool or an Eclipse plugin or feature would be great.
Thanks in advance.
EDIT to hopefully show what I want this for:
I have a huge monolithic jar that contains many features that are (essentially) completely unrelated. I'd like to break it apart into several smaller, more manageable, and more self-coherent jars.
Unfortunately, I can't do it simply by breaking it up based on packages, because many of the packages themselves are not self-coherent either. That is, for example, there's a "com.acme.utils" package. Two things in that package are probably have nothing in common except for the fact that they're both, in some sense, "utilities". One may be a utility for some particular business function, another may be TCP/IP utilities, another may be a set of string utilities, another may be some completely unrelated business function.
And there are a bunch of packages like this. So when you look at the transitivity of imports from the point of view of packages, they snowball without limit, and so more or less everything in the monolithic jar depends on everything else in the monolithic jar.
So I'd like to start by considering transitivity of imports from the class point of view, rather than the package point of view. That way I should be able to more easily determine what classes need to be reorganized from what existing packages into new, more coherent packages, and then after that I can break the monolithic jar apart by packages / sets of packages.
we're using sonar for software metrics. http://www.sonarsource.org/
For a student project I need to extend a Java project.
The problem is that this project doesn't have a lot of comments and it's hard to analyze it.
I'm searching for something to generate a class diagram and, if possible, a sequence diagram.
I have already tried umbrello (but there are some bugs with big classes) and agilej but the project has a lot of packages and sub-packages and I did not find how to generate the diagram recursively.
Are there other tools to do this?
Thank you in advance.
In Eclipse you have the option to set the package presentation to Flat or Hierarchical. In the flat mode you see the fully qualified name of each package under the src/ folder, and in the hierarchical mode you have to expand to see src/com/mypackage etc. In AgileJ when you are in flat mode (the default mode for Eclipse) then whatever you drag from the package explorer, be it a project, folder, library, Java source file, class or whatever, it will recurse down through the ownership tree and add the classes which it finds as you would expect it to do.
The anomaly you describe in you question - not recursing through the sub-packages - happens when you have the package explorer in hierarchy mode. In this case what happens is that the class diagram just receives notification of a drop of a package - but it has no way of knowing the package presentation mode of the package explorer or even if the drag originated from the package explorer.
So if you really want to recurse down through a hierarchy of packages, and for some reason don't want to multiple select them with the package explorer in flat mode, then the easiest thing to do is switch to the Resource perspective and in the Navigator view find the folder which is the parent of all the packages you want to include then drag that onto the class diagram. That will kick off a recursive search for classes down through the sub-packages.
Please note that if you drag in a large enough number of classes (the exact threshold is configurable) then it will offer to filter them down - for example you might want to filter out unit tests or generated classes. If you try to add a really large number of classes (again, it is configurable, but by default it is 200) then you'll be blocked - but what is the point of a single class diagram with 200 classes on it, it will only result in an unreadable class diagram.
Another eclipse plugin is called 'metrics', which you can find on sourceforge. It can provide a bunch of information about a Java project, both in textual and graphical form.
Not to keep all my classes in a single src -> 'package_name' folder I'm creating different sub-packages in order to separate my classes by groups like - utilities, models, activities themselves, etc. I'm not sure if it is a good practice and people do the same in real projects.
Yes, it's definitely standard practice to separate your classes into packages. It's good to establish a convention for how they are separated, to make it easier to find things later. Two common approaches:
Put things into packages based on what they are: model, service, data access (DAO), etc.
Put things into packages based on what function they support (for example, java.io, java.security, etc.
I've used both and keep coming back to the former because it's less subjective (it's always clear whether a class is a model or a service, but not always clear whether it supports one function or another function).
Doing it by class type the way you describe is one way that I've seen in real projects. I don't care for it as much as I used to because when I need to make a change or add a feature I tend to need to have several packages expanded in my IDE. I prefer (when I have the choice) to group classes by feature instead. That way I know where to look for all classes that support that feature.
The convention I prefer is to group classes first by module, then by functionality. For example, you could have the following structure:
com.example.modulea - modulea specific code that doesn't have any real need of a different package
com.example.modulea.dao - data access for module a
com.example.modulea.print - printing for module a
...
com.example.moduleb - moduleb specific code that doesn't have any real need of a different package
com.example.moduleb.dao - data access for module b
com.example.moduleb.print - printing for module b
In this fashion, code is clearer by package.
In the other style, of grouping by pure functionality, the package size tends to be quite large. If your project contains 15 modules, and each module has one or more elements per package, that's at least 15 classes per package. I much prefer clearly separated packages than packages that simply group things because "oh here are some printing utilities that are used for every module but only one module actually uses one of them from this package" - it just gets confusing.