I was reading this Wikipedia page on UML 2 package diagrams. This page mentions a relationship of merge between 2 packages.
Quoting the article:
"A package merge is "a directed relationship between two packages, that indicates that the contents of the two packages are to be combined. It is very similar to Generalization in the sense that the source element conceptually adds the characteristics of the target element to its own characteristics resulting in an element that combines the characteristics of both"
Somehow I just cannot grok this concept of package merging.
Has anyone used this in their modeling? Can anyone give me a real example of where and why you would use package merge.
The wiki quote is right from the OMG spec, as the reference indicates. Two things. The OMG spec goes on to say:
This mechanism should be used when elements defined in different packages have the same name and are intended to
represent the same concept. Most often it is used to provide different definitions of a given concept for different purposes,
starting from a common base definition. A given base concept is extended in increments, with each increment defined in a
separate merged package. By selecting which increments to merge, it is possible to obtain a custom definition of a concept for
a specific end. Package merge is particularly useful in meta-modeling and is extensively used in the definition of the UML metamodel.
Secondly the entire OMG UML spec infrastructure and superstructure is broken into many packages, which are often merged. This is useful when you want to do your own meta modeling and add functionality or exclude it, I have myself. UML is their own best example. Many UML implementations have followed this package merging scheme successfully for inclusion and exclusion to a solution.
The merge package is a kind of dependency link. I never use it because this concept is not needed with my favorite tool EclipseUML Omondo. I mean that my modeling is made at project level which includes packages, inners packages etc....
Many tools are talking about package merge because they have never implemented the project level and still just model at package level :-) If you reverse a multiple packages java project then export the xmi of RSA, EA or any other tool then you will see what I mean. You don't for example see an interface and a class inheritance because not placed in the same package. How can you imagine that I would place all my interfaces and classes in the same package ?
This is what is recommended by tool vendors because they can't manage project level and this is for me bad project architecture !!
Related
When using UML/SysML, what would be the best diagram type to represent a software strategy/structure using Git Submodules?
I am a Git novice, but it seems to me that the UML Package Diagram type is the most appropriate at the GIT level, because “GIT Submodules” sounds to me like a way of organizing your physical code files and file groups (and versions), and so it is a “logical organizational” thing.
And then the individual components should be UML components. And down at the unit level, they should be classes.
What do you all say?
Thanks
The package diagram is a way to structure the modelling space. It is not meant to represent the repository structure (despite the folder-like visualisation).
But of course both are not incompatible: you may structure your model elements in packages that have some sililarities with the component boundaries, and use the same logic for your organizing the repos.
Another approach would be to use a diagram showing the artifacts (source file, library, executable) and their dependency. Nothing prevents you from adding a stereotype for repositories.
I found this sentence in article about XMI on wikipedia:
At the moment there are several incompatibilities between different
modeling tool vendor implementations of XMI, even between interchange
of abstract model data.
I wondered how it is possible that, despite using a well-documented standard, tools are not compatible. After looking through documentations of UML and XMI and through other people's questions I found out that there is no XML scheama or DTD for UML models saved as XMI.
According to the best answer to this question -https://stackoverflow.com/a/36885550/9329778 -the correct approach to check if XMI is well formed should be to validate/process it through a conforming UML model.
I also found this in XMI 2.5.1 documentation in section "7.3.2 Model Class Representation":
By default, XMI allows you to serialize features using either XML
elements or XML attributes; however, XMI allows you to specify how to
serialize them if you wish.
This looks to me like a source of the problem.
My questions are:
Is there an official guide that strictly describes how to save UML model using XMI? I don't mean the UML syntax meatamodel (which can be downloaded from OMG website).
If the answer to the first question is "no" - does it mean that different modeling tools can perform serialization of the same UML model differently even if they use the same version of XMI?
the reference is this current document by OMG
Though there is a "standard" the people which defined it are from different vendors under the hat of OMG. Of course every vendor tries to keep his sheep dry and warm (and likely if possible leave those of others in the rain - well). This simply lead to a standard which is open to anyone. While OMG ("trying" to holding its hand over such standards) allowed the addition of vendor individual extensions to pass, each vendor took advantage and used this addendum to his own favor. And that's what we see in different fora: why can't I import my model (completely/at all) from vendor A's tool into vendor B's tool. It's a cross.
Note: regarding 1: No. You can not take this document and create XMI from a model. It's not written that way. What I did was to create a simple model, export it (from my favorite tool) and see what had been created. Then I tried to import that into another tool (finding to where it fails). Or even export and import in the same tool to find what was missing afterwards.
Please I need help in understanding this two approaches in the uml world. I am a programmer who is new to uml. I just started learning uml lately but kept getting this phrase asked all the time. - Are you modelling or drawing?. An explanation is needed with clear examples.
This link hinted just a little but I am stil confused -- http://modeling-languages.com/drawing-tools-vs-modeling-tools/
UML is a modeling language, which has a graphical notation. Its semantic is precisely specified by UML 2.5 standard of the OMG and also the international standards ISO 19505-1:2012 and 19505-2:2012 (although the latter corresponds to UML 2.4.1).
THere are two different approaches to UML diagramming. And it's heavily influenced by the tools you use:
Drawing tools generally offer UML shapes to be used in drawings. But there is no deeper meaning behind the shapes. It's only pictures. These tools would allow you to mix a use case with a class or an actor in a deployment diagram. The advantage is that you can do what you want. The inconvenience is that what you want may not be compliant.
Real modeling tools let you combine only valid UML elements together and ensure consistency of what you draw with the deeper meaning of the UML language. And they build a true and comprehensive model behind the scene by combining all the facets of the different diagrams.
Modeling tools can do smarter things. They can relate for example a class to their object instantiations in sequence diagram. They can help you to find all the other models in which a specific class is used. If you rename a class or add a property in one diagram, it'll be automatically reflected in all the others.
Modeling requires more discipline, but it's more powerful in the end. Some modelling tools can even use their understanding of UML to generate code out of the model.
You can use UML diagrams in very free way and you can use them up to the specifications. There are even different UML tools - some support only free style diagrams/drafts, some check dependencies and correctness and thus create models. There are some tools in between (MS Visio is one of them)
Nothing is ideal and fitting for everything. For example, some strict tools (VP and EA) forbid to make number-named classes, but according to UML specification you MUST use number names for anonymous classes. But -sigh- we have what we have.
Use of UML as such is not strictly predefined. So, you can use it for freehand drafts, later work on them more thoroughly and make them models. Or do only drafts. Or only models. But at any moment you should know how strictly are you keeping up to specifications. Or at least, trying to keep up. But even very free draft can help you greatly to understand the task or to think in a more productive way.
There is a large project on Golang which divided into many packages. I want to visualize the relationship between its entities to better understand the structure of the project. The first thing that comes to mind - the dependency graph classes. How to build it?
PS:
And I want find all unused method's / structures
The tool closest to what you search (but without the diagram feature though) would be go oracle
It can be embedded in:
Atom with atom.io go-oracle package
SublimeText with the waigani/GoOracle plugin
I also like to use test cases in order to compute a code coverage, which also helps to pinpoint unused methods.
I have designed UML diagrams in different tools (StarUML, BoUML, Papyrus, Omondo, Rational Rose, etc.) depending on the project and the date (rose was first, after Omondo, then starUMl, ..., now papyrus). However, I see that I cannot open my old UML diagrams because the tool is obsolete.
I would like to know if there is a standard format for UML diagrams. Probably not in production, but at least to know if there is proposal of standard format.
Probably, Eclipse is doing something like that with the M2 project, but do the other tools (not eclipse based) are interested in reading this format.?
Each UML tool uses its own format, but I think the era of proprietary format is over, and open format for diagrams like this should exist.
I have two answers to this:
In theory the standard exchange format for UML models is XMI but it´s true that each vendor implements a slightly different version so interchange is not a reality. Nevertheless, most tools are converging to at least support the Eclipse MDT-UML2 XMI implementation which in my opinion is becoming de facto XMI standard.
The OMG is working on a new standard : Diagram Definition that is supposed to fix the problems with the current XMI one (they are working a lot with many of the top vendors to make sure that this time they all go in the same direction) and, also important, it will allow to interchange not only the data (i.e. the info about the model elements) but also the layout and graphical representation so that after the import you get a model exactly as the same you exported in the first place
Have you heard of XMI?
#JordiCabot here adds some interesting details about it.
Besides Jordi's reference to the Diagram Definition standardization activity, please note that there is another action ongoing from OMG:
a request for comments has been issued in June 2011 for a CANONICAL XMI format, which is basically a subset and a set of additional rules for writing XMI documents that should limit the possibility of creating different XMI dialects, or at least should allow tools to understand a common dialect (the canonical one).