I am looking for a toy example of the usage of a "create link object action" with at least one other link action in a UML activity diagram. I can find definitions of what this action does but no examples - so I only have a guess as to what it does.
For instance, "Executable UML: A Foundation for Model-Driven Architecture" suggests a "create link" action does the following "relate A to B across association." I imagine this example creates a look up table?
A link is the instance of an association, and a link object is the instance of an association class:
16.7.6: Link object Actions operate on link objects, which are instances of AssociationClasses.
We are far from system design, where the organisation of activities is specified in broad terms and the details are implemented in a programming language. Here we are in low-level actions that are meant for visual programming.
Looking at the definition of this action in the UML 2.5.1 specs:
A CreateLinkObjectAction is a specialized CreateLinkAction for creating a link object (an instance of an AssocationClass). A CreateLinkObjectAction has the same semantics for link creation as a CreateLinkAction, except that its endData must be for an AssociationClass and the new link is a link object that is placed on the result OutputPin. If a link object matching the given endData already exists, and all the Association ends are unique, then this is placed on the result OutputPin, and no new link object is created.
So in your toy example, you'd need to refer to a class diagram with an association class, for example:
In this case, your toy example would have a CreateLinkObjectAction called add product to order with two input pins: one for the PurchaseOrder, one for a selected Product, and an output pin for the newly created line. The output pin might feed another action such as determine quantity. As a source of inspiration, but to fine tune and complete, it could look like:
Related
I am currently studying an example from an online course to design a class diagram for a Library Management System.
However, I am confused with this example:
I can't really understand the purpose of creating two classes: Book and Book Item.
Couldn‘t I just insert attributes from Book Item class into the Book class and keep only a single class of the two?
This is an interesting example:
The Book refers to an book in the catalogue of the publisher or the library. It has an ISBN to uniquely identify it, a title, an author and so on.
The BookItem refers to a copy of that book that is owned by the the library and is lend to the users.
But this example requires improvements:
the model should prefer composition over inheritance., which in UML translates tonprefering a simple association over a specialization. Several BookItems may refer to the same Book, and the model does not capture this reality.
The boundaries between book and book items need to be reviewed. For example the BookFormat (only in item) may in reality influence the number of pages (in book). Moreover a publishing date seems not to be specific to a book item but general to the book. Printing date could change on each item.
I'm struggling at understanding UML component diagram.
I've just been through the "assembly connectors" and here's what I (think I) understood:
the circle represents an interface, which I understand as a set of functions that a component can offer to the others.
the half-circle... well, don't know how to call it, but it says something like "there's some functions I need in order to operate correctly". In the image, I guess that an order must have access to functions that return details of the Customer (e.g: methods GetName(), GetAddress(), etc.), that's why it has the assembly connection with the Customer Details interface, provided by Customer.
My question is: why is there a dependency relationship arrow from the interface which Account provides (AccountDetails) and the interface which Order requires (Payment)?
The link of this image doesn't explain it.
The assembly connector (two shown on top) is a kind of provisional concept. You know that there should be an interface used instead, but have not yet made up the details. This is a connector which looks like socket/lollipop. But it's a connector.
The separate lollipop/socket are concrete interface uses. These are real elements. The interface itself is not actually shown (you will have a separate diagram showing the details). But to make clear that the depending interface is related to the providing one you draw a dependency.
Simply spoken, the above is something in the middle of a design phase. Finally all assemlies should be replaced by provided/required interfaces.
I'm working on my graduation project which is an online quiz website. now i'm drawing the UML activity diagram but it gets too complex and i can't add more details because at the end it must be printed in the project documentation in A4 papers.
can i split the diagram into multiple diagrams?. and if i did this should i repeat the login/registration actions in the beginning of each diagram?
Use structured activities to form logical groups. You can instantiate these activities as call behavior actions where needed.
Assume you have an activity Login
(the lying 8 is an invention of Enterprise Architect to indicate an embedded diagram; not UML standard)
which looks inside like
(just very simplified).
Now you can instantiate that like
where the fork indicates the action is a call behavior.
Adding activity parameters it would even be possible to parametrize these. Just like you would do when calling a function in a programming language.
How do we represent in an Activity Diagram, which entities are to be accessed or updated? Is this is to be done as part of an activity diagram, or to be done separately?
You specify which Classes are accessed or updated using Pins on an Action or using an ActivityParameterNode on an Activity. Those Pins look like little squares on the periphery of the Action, or rectangles on the diagram frame of an Activity, and you connect OutputPins to InputPins using ObjectFlows (which unfortunately look just like the ControlFlows that connect Actions together). Here's an example from the UML 2.5 spec:
Now, to answer what I think you are really asking. I think you want to know how to navigate to instances of Classes in your model. To do that from an Activity, you use a ReadStructuralFeatureAction to read properties from the Class instance that owns the Activity you're specifying. The values flow out of an OutputPin. Using ReadStructuralFeatureActions you can navigate anywhere your instances allow. (Note that when a Property is owned by an Association rather than a Class, you use one of the ReadLink*Actions specializations of Action.)
Please see Part 4 of Conrad Bock's excellent series, UML 2 Activity and Action Models,
Part 4: Object Nodes for a better understanding.
You can use either
a dependency (dashed line) or
an object flow (solid line) to show that an action is interacting with an object or
an information flow (stereotyped with <<flow>>). This way you can specify one or more classes which control the information that is flowing (in the example it is FileTypeObject).
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.