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).
Related
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.
Considering the following class diagram:
The class System is active and its behaviour is to continuously
call filter on PressureSensorFilter passing
PressureSensor.Pressure as argument
call Display.show passing the output param of
PressureSensorFilter.filter as argument
I would like to model the behaviour of System through an ActivityDiagram.
The main challenge in doing this is accessing the property PressureSensor of System.
After reading the UML 2.5 specification, I believe that the only way to do this is to use ReadSelfAction(pag 457 UML 2.5 spec) and ReadStructuralFeatureAction (pag 466 UML 2.5 spec) as depicted by the following Activity diagram:
where
ReadSelfAction gives as output a current Instance of System.
ReadPressureSensorFe.. is a REadStructuralFeatureAction that reads the property PressureSensor of the object give at its input pin which in this case is the current Instance of System.
CallBesselFilter.filter Action and CallDisplay.show Action are two CallOperationAction(s) that call PressureSensorFilter.filter and Display.show respectively.
The issue with this is that is very convoluted and unclear.
Is there any less convoluted and more clear way to describe the behaviour of System through an Activity diagram?
The ReadSelfAction as extra action is superfluous. You can reduce the control flow like this:
The pressure is read by the filter from the Pressure class' property. The filtered output is sent to Display and looping....
You should look into SysML. It's designed to cope with exactly that kind of problems you deal with.
It all depends on what detail you would like to provide in your activity diagram. The diagram you provide is correct. By the way, its level of details could be directly used to generate code. If you would like to describe behavior more abstract, do not use actions like read structural feature etc. But in your example, it is very good and precised way of description.
My requirement : I want to come up with a suitable UML diagram based on the case which is described below. I need to know which UML will best suit this condition.
The case : Two object A and B in the form of "Application Forms" interacts with each other.Certain event in object A triggers a state change of object B.Both object interacts with each other for a Use Case.
I tried using State Diagram but it fails as here 2 object interact with each other to change the state of one object, whereas State diagram is suitable to depict state change of one object only without showing interaction with another object which is causing state change.
My requirement is to show both interaction and state change together in the same diagram.Is it possible?
Any suggestion on this which UML diagram is suitable for this?
UML uses two different diagrams for each behavior, one for State (State Machine Diagram) and one for Interaction (could be the communication diagram or the sequence diagram).
Since the Interface of a class doesn't change when it's state changes (by applying the State Pattern for example), the interaction should not really change from the perspective of the caller, sure, internally all kinds of things might be going on, but that should not really matter.
The way I'd model this is to describe which states your objects are in and which scenario will play out. That will result in a few interactions and possibly state changes. Then pick a new scenario, either using the end-state of the previous one as a starting point, or describing a new starting state.
That way each scenario is clearly defined, the interaction diagram shows how the objects interact, and multiple State Diagrams with the active state highlighted can show the changes in state and thus behavior of the different objects.
There is no diagram that gracefully combines both, since one (the state machine) is a static diagram, showing all possible options, while the other describes the interaction.
Sure you could play around with creative naming, as suggested (ObjectA/State) as your different objects in the interaction type diagrams, but it would not result in a very clear picture. What you're trying to describe here is a story, a sequence of events and how those events impact the different states of the objects. So your scenario's are the story on a high level, the communication diagrams the stories on a much more detailed level and the state machine diagram the snapshots of specific situations.
Model your states in the state diagram as such: (Object / ObjectState).
For example:
States (A/uninitialized) , (A/initialized), ...
Should work then.
State diagram, sequence diagram, communication diagram and the whole answer by #jessehouwing is fine, but I think there is an easier and more natural way:
(1) http://agilemodeling.com/style/activityDiagram.htm, Figure 3. Submitting expenses
Note that this is UML 1.4 activity diagram. Current UML notation is slightly diferent. Dashed lines represent Object flow : Chapter 3.90.2.2 Object flow ...Objects that are input to or output from an action may be shown as object symbols. A
dashed arrow is drawn from an action state to an output object, and a dashed arrow is drawn from an input object to an action state. The same object may be (and usually is) the output of one action and the input of one or more subsequent actions...
and (2) http://www.uml-diagrams.org/document-management-uml-activity-diagram-example.html
show an examples of how you can combine object states and UML activity diagram. The pictures are activity diagrams and the orange rectangles highlight points where objects with states (the part in [some state]) are shown. The purple rectangles show authors who were robbed.
I am trying to draw an activity diagram in UML 2. I have an action called "splitter" which takes an object and split it into two groups of objects called A and B. These new objects undergo two different flows in the activity diagrams in parallel. I am wondering if UML2 supports taking multiple output from an action. How can I emphasize on the parallelism without using a fork symbol?
Your action can have two outgoing data flows - either using pins or connecting the two outgoing links to different object nodes. After this from either the pins or the nodes you can start two different flows. There is no need to use fork.
The activity diagram provides two kinds of flows: control flow and object flow. The "fork" is used for control flow only.
According you question it looks like you are talking about object flow. There is no any kind of "parallelism" in UML notation for object flow.