I've been reading some -really- old slides about mozilla, and came across this diagram:
http://www.mozilla.org/newlayout/doc/gecko-overview_files/Slide0023.gif
but I never seen this sort of diagram before, it does not seem like a UML 2 diagram. Any ideas?
That's a very old fashioned class diagram. The little dots represent an interface.
Related
Is it bad practice for lines between different classes to cross in a UML diagram? Is it a design smell? Does it indicate that your classes are too tangled or independent or anything? Is it always/generally unavoidable? Or am I overthinking this?
Here is my current UML diagram if interested. You will see that I routed a couple lines all the way around to avoid overlapping....
Is it bad practice for lines between different classes to cross
Yes, because it can impede understanding of the graph/diagram.
Is it always/generally unavoidable
Not all graphs are planar (see planarity testing), so sometimes it is unavoidable.
But the problem is not as simple as "I will just route the line around". There are many rules and recommendations that constitute a good layout or contribute to good visual aesthetics; to name just a few:
lines crossing (you might have seen in some diagrams a small bridge when lines are crossing)
number of line bends
total line length
hierarchy (typically inheritance lines should be drawn upwards)
You can already see that some of the rules are competing; so layouting is always a balancing act. If you are interested in more detail I suggest googling around for "graph aesthetics" or "automatic (graph) layouting".
Unfortunately most research papers I have are behind paywall, so I cannot link to the pdfs, but some of it can be google-able; e.g. UML Diagram Layouting: the State of the Art or Aesthetics of Class Diagrams
In my opinion, line crossings may be unavoidable, but often, it happens when I am trying to show too many things with a single diagram. I see this as a "communication" smell rather than as a design smell.
I often found that explicitly writing down the question I am trying to answer helps spot the model elements that are not strictly necessary and that I should omit. Besides, several diagrams may better convey an idea/design than a single saturated one.
In your example, you could maybe break down your diagram following the colored areas you already identified.
When ever there are crossing lines, it is a good time to stop and think if the diagram has grown to be too complex.
I feel your diagram is trying to be abstract and concrete at the same time. I see it as being too complex. It is abstract in the sense that it provides an architectural overview, and concrete in that it shows structural detail related to implementation.
Personally, I might split your diagram into a component diagram; then express each component's structure using separate class diagrams.
In class diagrams I typically see something like ClassA extends ClassB where the arrow head points to ClassA. Example, here. This has always confused me. Why is the arrow head not pointing to ClassB?
UML is simply used wrong in those diagrams. The arrow head must be a triangle (not an open one) it must point into the other direction and it is called realizes not implements. So if I did not entirely misinterpret the diagrams the author (of the diagram or of the software which created them) simply did not know how to use UML correctly.
In this diagram (just found by googling) you can see a correct visualization of a class "SearchService" realizing (implementing) the interface "SiteSearch".
In the next diagram several classes are generalized by (specialize, extend) the class "Account".
On this site you can get an overview (looks correct on the first glance). If you want to be sure you should look into the specification (find pdf download there).
I think the confusion here crops up out of the variations in the way people relate to the subtleties of English grammar.
Some people may be inclined to complete the "inconvenient" but UML-standard token "extend" as "extends", while others will complete it as "extended" when viewing or designing a diagram. Hence the differences in interpretation.
I model a system as my school assignment. I use database and Hibernate. I have many persistent Serializable objects. But showing that on a diagram that has approximately 20 classes makes it illegible.
As far as I came up with a solution to split general diagram showing relationships between persistent classes and the one with interface realization. Is it the best solution or maybe there is yet better way?
20 classes does not make it illegible, just large. Splitting the diagram is fine. UML is a modeling language and diagrams are just views so that is not a problem. (However, some implementations are just views, or semi-models like Visio) I would split across data domains, show the path which is important all on one diagram. Focusing on showing the "use", interface, implementation all on one page. Unless the layers are the focus. Split on data domains, clusters of usage, and if it is all one-to-one your solution is fine. In the future a diagram example might help.
I would offer the suggestion of making use of packages and perhaps composite structure diagrams.
I have a few classes on my UML diagram which should not be used, but still available.
Is there any way to mark these classes as obsolete?
I've seen <> notation somewhere, but can not find how to use it in MS Visio 2003.
And another question. Should these classes be on UML diagram at all? I can imagine answer on this question would be on "per case" basis, but I'm interested in hearing general opinions. And if you put obsolete classes on your UML diagrams, why you did it? or why not?
Thanks!
It's not clear to me what you mean by " should not be used, but still available.". If they need to stay in the diagram but you want to visualize that they are now obsolete you can create a new stereotype <> and use it to annotate the obsolete classes.
If you don't really need them in the diagram then use a version control system for models as duffymo suggested. A list of version control tools for modeling elements can be founde here
I think if you're going to take the time to update the UML, the best idea is to remove it from the model. Leaving a bunch of "obsolete" diagram elements hanging around makes as much sense as keeping commented code in a version control system. Let the version control system manage the history.
I think that your model should include all your project and then you extract views from your model. If a class is not having any value in a specific view then this class should be removed from your class diagram view diagram but not from your model.
If you want to keep this class in your diagram then you can add a small comment (usually yellow square) or change the color of the class. I usually use green for class and then change the color to grey/green almost invisible but still visible color for non strategic classes.
Hope this help.
Today I got a diagram similar to this one. The diagram I got was produced using Visio which I don't have. I haven't seen such a diagram before and its symbols are not clear to me.
I tried to google it and find some explanations about this specific type of diagram, but to no avail.
Could you please tell me what type of diagram it is, and give me some links to sites about it?
Thanks in advance.
Looks like a Unified Modeling Language (UML) diagram, in particular, an Entity Relationship diagram
Looks like Entity relationship diagram
Entity-relationship modeling is a database modeling method, used to produce a type of conceptual schema, often a relational database, and its requirements in a top-down fashion. Diagrams created by this process are called entity-relationship diagrams.
This is a cardinality diagram, and the lines represent one-to-many relationships.
http://www.smartdraw.com/resources/tutorials/cardinality-notations/
it is an ER diagram and google provides enough links
Entity-Relationship Diagram
Thanks to everyone. Using your answers and hints, I finally found out that this specific notation system of ER diagrams is called Barker Notation -- that's the answer to my own question :-)
Yes it is entity relationship diagram. As you have mentioned you don’t have Visio, you can download FREE Visio trial for 60 day. I use Visio to create IT diagrams as it has many great features.