I have a class (let's call it "CLASS") in two different EA diagrams.
CLASS is the same object in both diagrams.
I want to change the attributes order in one diagram without it automatically changed in the other diagram too.
Any ideas?
Thanks.
That depends on what you want. Do you want to show different aspects of the same element in the two diagrams then you can play with the Feature and Compartment Visibility (Ctrl-Shift-Y)
If you want to show different elements, but one starting as a copy of the other then you can Copy the element (Ctrl-C) and Paste as duplicate (Ctrl-Shift-V)
You can not do that. And it does not make much sense to hide single attributes or methods of a class in specific diagrams. Either all or nothing (to show just the class). EA has a way to hide single stereotyped element parts for a whole diagram. But that's not what you're looking for.
Maybe you can explain WHY you want to do that.
No, you can't do that. As you note, it is the same element (avoid using the term "object" here; object is actually a type of element in UML, just like class, component, use case, etc).
Attributes can either be sorted alphabetically (by default) or in some custom order which you set manually, but EA stores this order with the class, not with the diagram. In other words, the attributes of one particular class will always be displayed in the same order in all diagrams.
New users often find this type of issue confusing or even frustrating, until they realize that a diagram is only a visualization of the underlying model data -- it is not a drawing. This is why you don't do search-and-replace in models: you make a change to an element in one place and it is immediately reflected wherever else that element is shown.
The only way to show two different attribute sort orders is to make a copy of the class, but then of course it's not the same element anymore.
Related
I'm using the boundary-control-entity model for my sequence diagram, but in the alt fragment I'm confused about the interactions between the control and the entity in case the entity I'm adding contains duplicated fields.
shoudl I put select() before entering the alt fragment to show that the control is checking whether the informations are duplicated or no ?
My diagram:
5.Select() is the message I'm asking about
It's correct that way. The test condition is executed first. The alt fragment evaluates the existing conditions via the guards. These guards can contain anything and relate to something that happened any time (and not only directly) before.
Personal note: graphical programming is not really the silver bullet as it was praised in the 90s. SDs are fine to give an overview of collaborating objects. But when you try to go into details (like when using fragments) you soon recognize its shortcomings.
I'am creating an statechart diagram in StarUML and I want to show the name of choice elements in the diagram, but I don't know how to do it without adding a text annotation.
Do you know if it is possible?
Thanks!
(...)
Showing names of control nodes (including decision, merge, ...) diagram is not supported. It was never supported in previous versions, even in V1. Typically just show the guards of the control flows connected to the decision node, instead of showing the name of decision node. At this time, we recommend to use "Text" or "Note" annotation.
(...)
Thanks,
StarUML Team
This was the answer about the same question in this forum. Take a look.
Agree with #Victor, I just add Text Element inside the Choice Element.
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 have two components A and B. I want the model to show that they both <<include>> and <<use>> the third component. Which picture is correct, the top or bottom one?
Often, when you have two possibilities in UML, both are correct. But not here. I am afraid, both are bad.
According to the current standard 2.5 :
A Usage is a Dependency in which one NamedElement requires another
NamedElement (or set of NamedElements) for its full implementation or
operation. The Usage does not specify how the client uses the supplier
other than the fact that the supplier is used by the definition or
implementation of the client.
So, in UML <<use>> means "must have for some use". And notice, it is absolutely independent on the containment/inclusion relationship. The object we are depending on can be even contained, for it is not said we need it for creation of the dependent object.
We can use a component that belong to anywhere. But in the including (top) diagram we can't show the usage. So, it won't pass.
As for the second sort of relationship, including, there are greater problems here.
The standard UML component diagram has no "include" stereotype. But it is allowed to use elements of other diagrams.
But the component is not a class, it is an object. So, your component C simply cannot belong to both A and B. The other diagram fails, too. And if you want to have two different objects/components based on the same class or package, absolutely different diagram appears.
So, either A or B has its own instance of C and uses this instance. It is clean, without peeking into the other component.
If you use the tool that has not that containment connection, use the "include" association from the use case diagram.
I have also a strong suspicion that you could need not Component, but some different diagram, for your wish to put one box into different ones is unnatural.
I've taken the course Object Oriented System and Design at Stockholm University. I had to hand in an extra assignment where I had to create a UML Class Diagram reflecting a web site that sold cars (this is not a thread where I'm asking you to do my homework). This is what I handed in:
The teacher said that "this isn't how you use attributes" and seems reluctant to explaining what I should have done differently. It's all in Swedish but I think that the main points are clear regardless of language.
My question is: How should this have been modeled differently? I have aggregation for some objects, enums because the website had a limited amount of attributes for some classes.
Any help is greatly appreciated.
Kind regards,
Hugo
I see some problems in your diagram:
I believe you have some enumerations in your diagram that are not defined properly. An enumeration should look like this.
You define attributes in addition to aggregation (e.g. the Bil has a aggregation relation to this SäkerhetsTilägg, and additionally defines an attribute säkerhet. You should either use a relation or an attribute, see here.
While we are at this, the multiplicities are somewhat confusing. You say that Bil can have any number of SäkerhetsTilägg, while the attribute säkerhet holds exactly one SäkerhetsTilägg.
Afaik, you have to define the visibility of attributes and methods (like +, - etc).
It looks to me like you've got your Enumerations modeled as Classes. Even though visually an Enumeration looks like a Class with an <> stereotype, it's really a different thing altogether and it has EnumerationLiterals in the compartment when Attributes would be for a Class.
In ArgoUML you can create an Enumeration using the fourth button from the right on the toolbar. It's a dropdown menu which defaults to creating a new Datatype, but if you pull it down and select the green rectangle, it'll create an Enumeration. Create your Enumerations first and they'll be available for you to select as the type for your Attributes.
The final result should look like this: