Good day, colleagues!
I've posted this question to Eclipse community forum of UML2Tools, but that forum is almost dead, so I post my question here:
How can I create several representations of the same class in the main window of UML2Tools?
I need this because if class has many connections with other classes(aggergations, associations, inheritance), diagram becomes very confusing.
So, in this case it's convenient to create "duplicate" of target class and make new connections on the "duplicate" class, assuming that target class has connections from both "original" and "duplicate" representation of the class.
In StarUML I can do such thing by just Copy+Paste. In UML2Tools Copy+Paste creates ANOTHER class with the same attributes. This is not what I want.
It is impossible to show different views of the same class inheritance, association and dependencies with UML2 tools.
Related
I am trying to generate a Doxygen documentation for my Python project.
It seems like Doxygen does not provide an overall class diagram of the project including Association. It shows only inheritance for a single file.
Is there is a way I can generate an overall class diagram in doxygen?
Thanks a lot!
Doxygen does not generate class diagrams that contain "association" arrows.
These are the diagram types and my experience with them (stemming from C++):
CLASS_DIAGRAMS: Seems to be an old Doxygen option, superseded by CLASS_GRAPH, which contains more information. CLASS_DIAGRAMS often just show the class without anything else in my output, which is superfluous.
CLASS_GRAPH: This is actually an inheritance diagram, not a full class diagram (internally, it even goes by the name "inherit graph"). It doesn't show a diagram at all if a class is not a derived class or base class.
COLLABORATION_GRAPH: Shows base class, membership and template relations. Doesn't show "inherited by" or "used by" relationships. For a leaf class, the inheritance diagram (CLASS_GRAPH) is just a part of the COLLABORATION_GRAPH.
TEMPLATE_RELATIONS: Shows template relations in a similar style as inheritance, which is helpful for code using template specialization instead of inheritance, e.g. CRTP.
As you have a python project, did you try out Sphinx? sphinx.ext.inheritance_diagram comes included with the sphinx-doc distribution but also does not show other types of relations than inheritance.
A web search turned out https://pypi.org/project/sphinx-pyreverse/ which might be what you're looking for. I did not try it out myself.
I've recently started programming in Scala, coming from Python and Java I was wondering what the correct way or the accepted way is when defining objects/classes in Scala. Scala supports, just like python, to add several class or object definitions in a single file.
So purely from an accepted structure perspective, does every object need to be defined in its own file or are you allowed to choose this yourself?
There is a chapter in the official Scala Style Guide on this. It's pretty clear in itself, but I'll just leave some quotes here.
The core idea is:
As a rule, files should contain a single logical compilation unit. By “logical” I mean a class, trait or object.
There is, of course, an exception for companion objects:
One exception to this guideline is for classes or traits which have companion objects. Companion objects should be grouped with their corresponding class or trait in the same file.
There is also the fact that sealed only works within the same file.
Despite what was said above, there are some important situations which warrant the inclusion of multiple compilation units within a single file. One common example is that of a sealed trait and several sub-classes. Because of the nature of sealed superclasses (and traits), all subtypes must be included in the same file.
Most of the time, case classes are just simple data containers and can be grouped together.
Another case is when multiple classes logically form a single, cohesive group, sharing concepts to the point where maintenance is greatly served by containing them within a single file.
Finally, there is a naming convention for exempted multi-unit Scala files:
All multi-unit files should be given camelCase names with a lower-case first letter.
So: put your Scala classes and objects in separate files, unless they fall into one of the three mentioned exceptions.
In Scala, it is perfectly valid to have multiple classes within a single file AS LONG AS they are tightly related.
But not all languages encourage this convention, and I think it is worth considering the reason.
I personally dislike it when people put multiple classes into a single file because it makes it harder to find a class definition. This is magnified in code reviews where I want to be able to review code as quickly as possible without digging around.
Cons
Code reviews require me to do more searching to find a class
I don't like having to grep to find a file
A consistent naming convention allows me to use my text editor or IDE tools to quickly open a file by the class name
Pros
As Jesper pointed out, certain scenarios require it
Support classes/traits are kept hidden to minimize file structure "noise"
Sometimes you have to put several traits, classes or objects in one source file, particularly when you are using sealed traits. A sealed trait can only be extended inside the same source file.
I've read that UML assumes by default that :
a class can inherit several others
an object is an instance of only one class
an object of a given class cannot change to another class
This leads me to the question : as there are 3 hypothesis, there are 2^3 possible combinations. Could you give me languages which would be examples of each of them ?
I mean for me Java is "false-true-true" and C++ is "true-true-true". What about the 6 others ? Or did I misinterpret the assumptions ?
Let's look at the UML 2.5 standard of the OMG, to have a definitive answer:
1.Class inheritance
The UML 2.5 standard clearly defines that a class can have none or several superclasses and, that conversely, a class can be superclass of none or several classes (see section 11.4.2 and 11.8.3.6).
So UML definitively allows multiple inheritance (as in C++ or Python). But you may as well restrict yourself and use only single inheritance and several interface implementations, like in Java and C#. You'd use a realization relationship to show the "inheritance" from an abstract interface (the inheritance arrow is then dotted).
2. Objects and classes
9.8.1: InstanceSpecifications represent instances of Classifiers in a modeled
system. They are often used to model example configurations of
instances.
FYI: the terms used in the standard are a little more general, but an object is an instance, and a class a classifier. This definition is then further refined in the semantcs in chapter 9.8.3 :
The InstanceSpecification may represent: • Classification of the
instance by one or more Classifiers, any of which may be abstract.
So UML allows objects to be an instantiation of several classes. I don't know languages that allow this, but if you do don't hesitate to comment ;-).
3. Changing class of object
I must admit that I can't answer this answer 100%. I don't think so, because, becoming an instance of another class would mean to re-insantiate a class, so it's not corresponding anymore to the definition of an instantiation.
Furthermore (see 9.8.3):
An InstanceSpecification may represent an instance at a point in time
(a snapshot). Changes to the instance may be modeled using multiple
InstanceSpecification, one for each snapshot.
This is somewhat ambiguous: a given object in a given diagram can't change classes. However, you can represent several times the object in different diagrams (snapshot) to show a change.
Conclusions
So your assumption 1 is true, 2 is false, and 3 true or false depending if you're reasoning at diagram or model level.
I have experience with StarUML and Jumli. At my current company we have a Professional license for EA 9.2.
When I design a program, I start with creating Use Cases. Then from every Use Case, I create a Sequence Diagram. And from the Sequence Diagrams, almost every Lifeline-object will become a class (and all messages will become a method). With StarUML and Jumli this wasn't a problem.
But I cannot find a way in EA to convert the Lifeline objects into classes.
I tried to read the help from Sparx, but to me it is not really helpful. Their 'tutorial' is not a tutorial, but actually just another help file with lots of blah blah.
Can anyone tell me how to do this? Or are there any really helpful links?
It IS possible, but only in one a bit hidden way. First I'll tell you about the alternative ways:
you have a conceptual error here. Timelines in Sequence diagram are not classes, but objects. So, they can't become classes.
Of course, a tool could have a function to create a class according to an object, as VP UML has. Obviously, EA has not such feature.
On the contrary, it is not a problem to drop a class on the sequence diagram to become a timeline. But EA has some conceptual problems with it, too. You have to make it an object here. Look also this.
On the other hand, there should be no problems to drop a timeline to the object diagram, but in EA it IS a problem - the object-timeline remains the timeline even on the Object diagram. That is obviously non-convenient and ununderstandable, but it is so. Obviously, it is one of these bugs that are called "features".
The same is behaviour of the timeline if we drop it on the Class Diagram. We even can't connect this object to a class by generalization - EA considers such connection as a rules breaking one.
And finally, how you CAN connect the timeline/object to a class. Right-click the timeline on the sequence diagram or its copy object on the class diagram. Go to Advanced. Choose Instance Classifier - the first menu item. There you can choose an existent class or even create a new one. And the object/timeline will belong to this very class.
You can't reach this feature from the Project Browser. It is obviously, another "feature" of the EA.
In a spec-adherent UML tool, one can assign classes (among other things) to a lifeline. I think that is why you are having difficulty converting lifelines into classes: they aren't the same kind of thing! Try creating classes first and assigning them to lifelines.
To transform sequence model into class model right-click on the package choose "Transform Current Package" => Check DDL => Select Transform
I hope this helps.
Regards,
Nabil
I was self-studying various UML diagrams and I understood most of them except for Class Diagram and Object Diagram.
I can not get my head around how they wil be converted into code.
The trick that I learnt is this: all nouns become classes and verbs become methods of the classes.
All good till there but after that, how is the diagram converted into code?
Have a look at a diagram here that I got from the internet:
So, assuming that the language is Java, how will you code a software based on this?
A UML diagram solely describes the internal architecture of a given piece of software.
The information contained in your UML diagram is therefore:
What classes are contained
What methods and properties do they contain
How do they relate to each other
Each block with a header ("Train" for instance ) represents a class, listing its properties and methods.
As such the UML diagram does not state anything about a GUI or how the user interacts with the software. It is up to you or a UI/UX designer to create an interface you can implement, that uses the functionality outlined in this UML diagram.
You can think of a UML diagram as a description of the architecture of a piece of software, that is very shallow but is well suited for an overview of the project.
It is not a recipe.
I hope this was useful to you.
When you have a class diagram, you have a representation of the classes (and its members) that you should have in code.
So, your noun/verb analysis (what you were talking about), has already been done when you have a class diagram.
A class diagram is just a visual representation of your classes, converting them to code is just easy if you know the syntax of the language that you want to use.