I have a .lib file containing internal C++ classes and a few C++ classes are interfaces to the functionality that software library provides.
How should I illustrate this with UML?
Using Enterprise Architect, I tried type 'Component' (pasted to the component diagram as simple link) and then dragged and dropped the internal classes of that library from the model tree to that component rectangle as element type Composite part, and the interface classes of that library as Port. Now the weird thing is what happened the model tree contains kind of object instances of that classes called Part1 and Port1 of UML type 'class', which is nonsense since a software library don't instantiate, it just provides its classes via .lib file, like a pool. I think UML element type 'component' is not the right thing here, is it?
The same happens if I use 'Package', also here parts and ports become things like object instances although classes in a library are not.
Following my comment to the O/P, I'd do something like the below. Please note that I'd probably not depict all of this on the same diagram, the class content of the package for example I might present on a separate diagram so that this is not so cluttered. But the logic is the same.
Update: Following commentary below I've added the this diagram which illustrates an alternative way of representing this. I think in some cases I've seen the delegation represented as a dependency rather than a reference association too. But hey ho. Internally, components are represented as interacting between each other via required/provided interfaces (though this is not shown as in the model below we only have one internal component illustrated).
It's not weird. You happened to drop a class as Part (in EA terms).
That's actually a Property. Just open its properties:
See UML 2.5 on p. 147:
9.9.17 Property [Class]
9.9.17.1 Description
A Property is a StructuralFeature. A Property related by ownedAttribute to a Classifier (other than an association) represents an attribute and might also represent an association end. ...
I'd probably just drop them as link to appear as class inside the enlarged component, YMMV
A class dropped as port will show as what the name said. So no confusion here. Anyway, I'd also drop it consistently as link to show just the contents. Further I'd probably stereotype the component itself with <<lib>> or the like. That's because you actually use a lib during compile time to extract the needed parts and it does not work as component by itself. A library though has an interface, namely to extract the compiled class modules it has inside.
Ah, and as #muszeo said: use ctrl-drag to show the above dialog.
Related
I'm working on a project where I'm using an SDK that provides things I need via some classes. I've named these ProviderProvider and Provider, that grant access to OneThing that is an IThing.
An example is shown here
.
My question is: What is the correct (or best) way to show that the Model provides the list of OneThings to the View through those classes?
Do you show this explicitly as in my example, by drawing a dependency arrow from Model to OneThing? That doesn't seem right to me and quickly becomes visually cluttered.
Do you not explicitly define that relationship, but is it simply implicitly defined through the other relationships?
Do you define that relationship semi-explicitly through attributes, notes or some other way?
What relations and attributes should I add/remove specifically and why?
You already have the implicit relationship since you use this class as a type of data returned by Model so you do not need to add that relationship explicitly.
It may be useful though, especially for classes that are core in the system, to add a diagram with dependencies only. Then you don't care about relationships between other classes, you only show on one diagram all classes that depend on the core one (it may be even more than one diagram).
One hint - in Case tool (like EA) even if you don't intend to show the relationship on the diagram since it is indicated implicitly it is still good to create the explicit dependency and just remove the arrow. This will support the traceability through tools like traceability matrix or dependency tree.
Please see the diagram below for this question...
I am trying to make a UML class diagram of an interface (IView) that has a method (abstract) that takes as a parameter a reference to a class (Card) in another package. I found a stackoverflow post that suggested that in UML, this should be expressed as "IView 'uses' Card" (Apologies, but I do not have the reference and I cannot re-locate it currently).
IView is implemented by two classes, and each of those concrete classes "uses" Card (of course). In the diagram, do I also need to express the "uses" relationship between the concrete classes and Card (not shown below)?
This isn't a too bad attempt. The top dependency is almost correct. You named the dependency Use but that's futile. You can just leave away that name. You could make it a use-dependency by adding the key word «use» but that's not needed. Just leave it a simple dependency.
Similarly the lower dependencies where the name Implements is futile. Anyhow, these should be realize relations. Use a closed triangle instead of the open arrow. And it's not necessary to name it either.
Finally you should just drag the attribute field into iView since it seems that this is a common attribute for the views (here I'm just guessing).
tl;dr
There is no need to draw a dependency from from the classes at the bottom to the top one.
Given I have two Java classes Foo and Bar, and Bar has a getFoos() method that returns a List<Foo>.
In Java, all classes extend the parent class Object. List is an interface that extends the interface Collection, which in turn extends Iterable. All of these are provided by the Java core and do not require programming. However, they have methods that can be used or overridden. Interface hierarchy may be necessary to be known, for example a method that takes an Iterable<Foo> will accept a List<Foo>.
When drawing a class diagram from these in UML, how do I do with the well-known classes (Object) and interfaces (List, and its super interfaces Collection and Iterable)? Do I have to draw them into the diagram as well? Can I skip them completely? Is there a special symbol for these (a cloud would feel great to me)? What about not-that-common classes that should be qualified (i.e. if it would be an java.awt.List and not a java.util.List)?
UML is not linked to any language, there is nothing in the norm about JDK classes.
A lot's of tools provide a profile with JDK classes already defined.
So you have to look in your tool if you get menu like "import profile" and look which profiles are available.
Two others solutions could be:
Define in your models the minimum set of JDK classes you need
Trying to write a java program to generate the XMI of JDK classes. Theoretically not so complicated, but the JDK includes JNI classes on which the introspection can not be used.
Your choice for how to deal with well-known classes will depend on how you plan on using your UML class diagram.
If the main purpose for creating a UML diagram is to communicate design details to a team, I would opt for not including well-know classes (not just from the JDK but also classes that are well-known in your context). The reason being that you want your message to be focused. Adding these well-known classes can quickly clutter your diagram while adding nothing to your message. For the same reason I typically exclude getters/setters and any information that is not essential to understanding the design. For classes that are not well-known I will include them because they communicate information that is not easily accessible to the team.
If your class diagram is going to be used in MDA, i.e. it will be used to generate a system implementation, then you have to include well-known classes.
In my previous question I was trying to achieve the idea of ordering the classes. Although the example I presented wasn't appropriate.
So here is the situation I want to ascribe by UML class diagram:
In ODT document I have something called figure. The figure is comprised of two atomic elements: image and title(of the image). The standard allows me to put the title, either on top of the image or bellow the it. Although In my application the title will always be beneath the image like this:
So in my case I want to submit the (more specific) information that the title must be beneath the image (although the standard does not obligate so). Thus I came up to the idea of making order in my class diagram (this is first, then this, then this, etc...). Because in my case that matters.
Here is my despaired attempt:
Is there any approach to present that information through a UML Class Diagram?
In the UML meta-model, there are meta-elements called Class and Property. An instance of a Class meta-element (e.g., called Figure) may own instances of a Property meta-element. Each instance of a Property meta-element has a type (e.g., Image and Figure). Both of the instances of the Property meta-element in your model are unnamed, which, unfortunately, makes it difficult to refer to them. Nonetheless, all of the instances of the Property meta-element that an instance of the Class meta-element owns are ordered. When you create a property in a UML tool, you generally add it to the end of an ordered list.
In your diagram there are two unnamed properties that are already ordered (implicitly, based on which you created first in the tool). This order can be seen and changed in a UML compliant tool. Here is an example UML model:
I strongly recommend you name all your properties, as I have done in my example model. For example, I named them title and image, starting with a lower-case letter. Among other benefits, that way you can see which is which more easily when you reorder them.
Here is a specification window in a professional tool called MagicDraw, where you can drag properties into the order you like:
You could change the order to say that the image comes before the title.
P.S., in an analysis model, if this ordering is a rule that's important in the problem domain, I would actually show an explicit association between Image and Title having association ends called something like comes before and comes after.
I am reverse engineering some Java code into a class diagram. Now I'm wondering how to model classes that are from a library that I didn't design. If I'm writing them down as classes, I should maybe also know what interfaces they implement, etc, and put that in the diagram. How far do I go with this? Is it better to write them down as attributes of my own classes?
Include whatever classes and interfaces your code uses in the diagram for your code.
Place the elements from the library into a package which represents the library's package.
Use whatever level of detail is sufficient for what the diagram represents.
If you only want to record that your code uses the library, a «uses» relationship to the package representing the library
If you have associations to elements in the library, model the elements you relate to but no detail in them.
If you or extend or implement classes or interfaces, model the attributes and operations of those elements.
If your code relies on a sequence of operations on elements in the library, you may model the operations, or may just use messages which are not directly linked to them, depending what your tool allows.
I found an interesting link which could help: http://www.ejb3.org/jar_file_reverse/jar_file_reverse.html
You can reverse your java project to show .java classes and then just drag and drop .class classes coming from the jar to your diagram. You can make a differentiation between them by adding the package name in the class name, or by changing the color of the class etc....