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:
Related
I have recently been studying UML and drawing simple diagrams with ordinary plain arrows between classes, but I know it's not enough. There are plenty of other arrows: generalization, realisation and etc. which have meaning to the diagram reader.
Is there a nice resource which could explain each arrow (ordinary, plain, dotted, diamond-filled, diamond)?
It would be the best if it will have some code examples for them.
Here's some explanations from the Visual Studio 2015 docs:
UML Class Diagrams: Reference: https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2015/modeling/uml-class-diagrams-reference
5: Association: A relationship between the members of two classifiers.
5a: Aggregation: An association representing a shared ownership relationship. The
Aggregation property of the owner role is set to Shared.
5b: Composition: An association representing a whole-part relationship. The Aggregation
property of the owner role is set to Composite.
9: Generalization: The specific classifier inherits part of its definition from the general
classifier. The general classifier is at the arrow end of the connector. Attributes, associations, and
operations are inherited by the specific classifier. Use the Inheritance tool to create a
generalization between two classifiers.
13: Import: A relationship between packages, indicating that one
package includes all the definitions of another.
14: Dependency: The definition or implementation of the dependent classifier might change if
the classifier at the arrowhead end is changed.
15: Realization: The class implements the operations and attributes defined by the interface.
Use the Inheritance tool to create a realization between a class and an interface.
16: Realization: An alternative presentation of the same relationship. The label on the
lollipop symbol identifies the interface.
UML Class Diagrams: Guidelines: http://msdn.microsoft.com/library/dd409416%28VS.140%29.aspx
Properties of an Association
Aggregation: This appears as a diamond shape at one end of the connector. You can use it to
indicate that instances at the aggregating role own or contain instances of the other.
Is Navigable: If true for only one role, an arrow appears in the navigable direction. You can use
this to indicate navigability of links and database relations in the software.
Generalization: Generalization means that the specializing or derived type inherits attributes,
operations, and associations of the general or base type. The general type appears at the arrowhead
end of the relationship.
Realization: Realization means that a class implements the attributes and operations specified by
the interface. The interface is at the arrow end of the connector.
Let me know if you have more questions.
I think these pictures are understandable.
A nice cheat sheet (http://loufranco.com/wp-content/uploads/2012/11/cheatsheet.pdf):
It covers:
Class Diagram
Sequence Diagram
Package Diagram
Object Diagram
Use Case Diagram
And provides a few samples.
My favourite UML "cheat sheet" is UML Distilled, by Martin Fowler. It's the only one of his books that I've read that I do recommend.
For quick reference along with clear concise examples, Allen Holub's UML Quick Reference is excellent:
http://www.holub.com/goodies/uml/
(There are quite a few specific examples of arrows and pointers in the first column of a table, with descriptions in the second column.)
The accepted answer being said, It is missing some explanations.
For example, what is the difference between a uni-directional and a bi-directional association? In the provided example, both do exist. ( Both '5's in the arrows)
If looking for a more complete answer and have more time, here is a thorough explanation.
A very easy to understand description is the documentation of yuml, with examples for class diagrams, use cases, and activities.
Aggregations and compositions are a little bit confusing. However, think like compositions are a stronger version of aggregation. What does that mean?
Let's take an example:
(Aggregation)
1. Take a classroom and students:
In this case, we try to analyze the relationship between them. A classroom has a relationship with students. That means classroom comprises of one or many students. Even if we remove the Classroom class, the Students class does not need to destroy, which means we can use Student class independently.
(Composition)
2. Take a look at pages and Book Class.
In this case, pages is a book, which means collections of pages makes the book. If we remove the book class, the whole Page class will be destroyed. That means we cannot use the class of the page independently.
If you are still unclear about this topic, watch out this short wonderful video, which has explained the aggregation more clearly.
https://www.youtube.com/watch?v=d5ecYmyFZW0
If you are more of a MOOC person, one free course that I'd recommend that teaches you all the in and outs of most UML diagrams is this one from Udacity: https://www.udacity.com/course/software-architecture-design--ud821
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 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.
How do I create an abstract use case in enterprise architect 10?
Edit:
Here is an example:
How do I achieve this in Enterprise Architect?
Stereotyping the use case as "abstract" does not change the font face.
I'm not asking how to change the font manually. I was expecting that if a use case is stereotyped as "abstract" then its title font face would automatically be changed to italic. But that does not seem to be the case.
Go to the properties window (not the dialog that pops up when you double click on the element, the windows default posion is in the lower-left corner).
In the "Advanced" section set "Abstract" to "True".
Regardless of the type of element, "abstractness" is not expressed as a stereotype in EA, so that wouldn't work for classes either. Instead, there is an "abstract" checkbox in the element's Properties dialog. You'll find it on the Details page if you open the dialog for a class.
The same dialog for a use case, however, does not include the "abstract" checkbox. However, the underlying data model allows any element to be abstract, including use cases.
Leaving aside the correctness or otherwise of modelling abstract use cases in favor of answering the actual question, there are two ways to achieve an abstract use case in EA. Both are "proper" in that they result in use cases with the appropriate "abstract" property set, as opposed to making purely cosmetic changes in the font or similar.
Use cases made abstract in either of these ways will be displayed with an italic font automatically, they can be distinguished in searches and generated reports, etc.
Method 1: element properties window
In the Element Properties Window (not the dialog but the one you open in Element menu), you can set the "abstract" property under the Advanced branch.
Method 2: use a script
Here's a VB script snippet which makes a single use case abstract.
if (theElement.Type = "UseCase") then
theElement.Abstract = 1
theElement.Update()
end if
If you place that in a diagram or object browser script you can easily make a use case abstract. You'll probably want to modify it to make it a toggle rather than one-way, but you get the idea.
This can be useful if you've already created a number of concrete use cases and want to make them abstract.
It is possible, but useless, and and style both in UML and OOP
If your client insists on the structure, you can show variations of some behaviour by extends and include stereotypes. And some of the variations can have a note that says, that this variation will be never really realized. This is semantically equivalent to your abstract use case. ...And the uselessness of the thing is obvious, too.
You can set Abstrect property directly, as is shown in a neighbouring answer. But it doesn't add to usefullness.
More reasons not to use "abstract" :
What does being abstract means? It means, that this very structure will be never realized by itself, and will only provide some common features to other, concrete structures. I.e., it is setting the way of REALIZATION, the inner construction of your system. And you should NOT solve problems of realization on UC diagrams, they are merely formal way of setting the task you are solving. You should not mix setting the task and solving it.
In technical way, being abstract is a structural piece of information. Use case diagram is a behavioral diagram. You CAN use structural elements borrowed from other diagrams in it, though. For example, abstract classes. But it is for exceptional use, not standard one. For example, you are solving the task and (alas!) you have already some SW/HW rigidly set due to licenses or politics. It is not good, but it can happen. But use case itself if pure behavioral element and you can't simply say it is abstract.
"abstract" is a word used in some languages, but not in all OOP languages. You shouldn't set the language in the UC diagram.
Use case shows behaviour, and will be realized first rather by interface than by class. And all interfaces already are abstract.
Like you can see from the diagram it has three objects. Object_1 has a variable-sized ordered array with references to objects 2 and 3 in that order which is exactly the thing I want to say with the diagram. My problem is that I didn't see anything in the UML standard specifications when I browsed them through for a notation to do something like this.
How do I fix this diagram so that it would be a valid object diagram according to the UML standard? Or is it even possible? Does UML specify a way to say something like this?
There is no specification of what an object diagram (what you show) is (see a full explanation here). So whatever you do will be right (or wrong :-))