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.
Related
I'm working on a component diagram of a system and due to the system's design quite a few dependency lines end up crossing, which makes the diagram hard to read and hard to follow.
One way to side-step this issue would be to use separate component diagrams to illustrate how a subset of the system's components depend on some component/interface. For example, the dependency on a data store would be represented in a component diagram which covers only the data stores and the components which directly access those datastores, omitting the remaining components. However, I'm not sure this is considered standard practice or even acceptable.
Does anyone know if it's ok to present multiple component diagrams of the same system? If not, what other alternatives are available to avoid cluttering the diagram?
Yes, that is the standard practice.
Only the most trivial systems are small enough to be represented in a single diagram.
Different views are a common way to simplify complexity in diagrams. However, the desire for multiple diagrams is possibly a bit of a smell that you have too much complexity in the system you are trying to model.
Consider moving up a level up from component diagrams to package diagrams in order to help lay out the bigger picture. This should help you to organize your system in to a set of well organized sub systems. For each sub-system you can then drill down back to the detailed component diagrams.
I built an application which is integrated in open source program( you just download the binary of the program, run it and then my integrated module will execute when you click on one single button called translate. That's all. )
What the application does is that when user builds some schema in the open-source project I mentioned above it generates C++ code for the schema. It's java program written in OOP style( classes, polymorphism, inheritance, encapsulation). There also runs some algorithms like top sort for finding topological sorting or bfs.
Since I study software engineering and will be presenting the application I would like to draw some UML diagrams or diagrams in general which would help me to better describe the application/ behavior of application itself.
Since it's not typical web-based project ( does not use any database etc... ) except for class diagram I don't know what what would be good to use.
Could anyone give me some diagram names which would help me to describe the behavior of my application better? I appreciate all the help.
You are looking for sequence diagrams, activity diagrams and/or state diagrams to describe behavior.
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.
How can i build an executable model in UML?
is it differ from UML model element used while drawing class,SD,...etc
By model element, I assume you mean some kind of UML notation like class, state, activity, etc. The graphical notation doesn't change that much when you use it in an executable context, but the underlying meanings (semantics) may change. To make the notation executable, you need a set of semantics that establish executable behavior on some subset of the UML notation. (Once you start thinking execution, you don't need everything). In the book Executable UML: A Foundation for Model Driven Architecture, Mellor/Balcer, Addison-Wesley 2002 (which I highly recommend), such a set of semantics is defined. If you want to see examples of Executable UML models and how they can be translated to code with open source tools check out Models to Code (with no mysterious gaps), Starr/Mangogna/Mellor, 2017. You may also want to take a look at executableuml.org and xtuml.org.
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 !!