Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.
10

IMHO, there is actually no need to include any conditional or "loop" for the "wait" state at all: Any activity needs a certain time until it is completed. If a customer representative is available immediately, the time for the wait activity is zero, if not, the activity will just take some minutes or maybe hours. But the power of "zero" is it can be often ...


7

Problem Your diagram has several flaws. For instance, you'd need a join to synchronize the camera recording and the timer. But then, the semantic would mean that both activities must be finished before going on, so that in the end you would wait at least 2 minutes. Solution To solve this correctly, you must enclose the sequence of action that can be ...


5

Activity diagrams don't use the concept of objects, as they usually don't show who does what, but only which actions/decisions are taken. You could use partitions (also called swim lanes) to indicate who executes the actions, but if you have more than two or three objects interacting, this can become rather unreadable. For describing the interactions ...


4

Are your diagrams ok ? The guard on a decision node shall be placed on the tail of the line and not on the nodes (see UML 2.5 section 15.2.4). So [free customer representative available] on the top of the diamond shall be removed and the outgoing [yes] and [no] change to [customer representative available] and [customer representative not available]. ...


3

In short The activity diagram models flows of control and flows of objects. There is no initial or final state in such diagrams. But there are initial nodes that shows where the flow starts when the activity starts. There could be several, since activities allow concurrency. final nodes that end the flow. The confusion of initial/final activity nodes ...


3

An activity diagram is a specific UML diagram which can optionally contain swim lanes, but not mandatory. In this sense, an activity diagram can be a swimlane diagram. The term swimlane diagram is not an UML term. AFAIK it is older than those UML terms, it characterizes all kind of flow charts with swim lanes, from which the "activity diagram with swim ...


3

The Handling Input Method Visibility page in the Android developer docs has this to say about showing the input method on activity start: Although Android gives focus to the first text field in your layout when the activity starts, it does not show the input method. This behavior is appropriate because entering text might not be the primary task in the ...


3

The answer is Service + Thread. Don't put the socket in an Activity. The activity is for UI. It gets recreated when the user rotates the phone. You can run into problems when the user receives a phone call. Put your sockets in a Service. Your activity/activities can bind to the Service and use it's methods. Or you can use a Messenger to communicate between ...


2

I would include them when the exception affects the users actions. Ie. If the timeout causes the user to have to re-login. I think you have another underlying question though. "How detailed should my activity diagrams be?" Which is much harder to answer. On one hand you can virtualy write the code in UML and cover all the edge cases. But on the other, the ...


2

An activity is an ongoing nonatomic execution within a state machine. The ovals on an activity diagram are either action states or activity states. Action states are the atomic execution of an operation. Activity states are nonatomic and can be decomposed on another activity diagram. So, no, there does not have to one and only only activity per activity ...


2

For the data side of this. You'll have to decide whether to use a relational database? Some other database variants might be more suited. If you choose to use a relational database, you could use the following tables: A table that models the temporal dimension of the activity stream, E.g.: <activity_id, user_id, timestamp> A table containing ...


2

Strictly in UML a decision node has only 1 input and a merge node only has 1 output. So in order to model a point with several inputs and outputs, you would need to have a merge node and then a decision node. For example, at the top decision point of your diagram you would have a merge node to merge in the flows from the previous activity, and the repeat ...


2

While your question is a very specific one it actually winds down to a question how to represent a loop using an activity diagram. I strongly recommend checking this answer. In your case I guess the first approach from the answer is the most suitable.


2

I haven't seen anyone use an activity diagram (aka flow chart) for source code, professionally, for decades but if someone is insisting, it would look something like this:


2

By factoring out the duplicated code first, you can come to a completely different solution. If I take the first version (with switch) and refactor the duplicated code, you end up with something like public class EditTextActivity extends AppCompatActivity { public int callbackId; @Override protected void onCreate(Bundle savedInstanceState) { ...


2

The quote mentions not just rejected but rejected for traversal over the edge. This corresponds to the case that a token is not allowed to go through an edge, and not to the case where a target may not accept it. In which case is it rejected for traversal ? Unfortunately, unlike the terms offered and accepted which are well defined, the term rejected is ...


2

In short You have understood correctly. In long Analysis of the standard 15.3.3.3 says it very clearly: A ForkNode is a ControlNode that splits a flow into multiple concurrent flows. A ForkNode shall have exactly one incoming ActivityEdge, though it may have multiple outgoing ActivityEdges. The important thing here is that a ForkNode cannot ...


2

The «selection» introduces a semantic that allows to restricts the tokens of the ObjectFlow or change their order. So the specification shall be read, having both cases in mind. The standard shows in figure 15.16 an example in which «selection» is used to specify that Orders offered should be shipped by order of priority. Your first bullet is correct....


2

Activity diagrams can use partitions to group actions that share some characteristics. These partitions may graphically be represented as a swimlane (they can also be representend textually). If you cannot make a difference between a “swimlane” and an activity diagram, it may probably be because IT IS an activity diagram with swimlanes. Business Process ...


1

I think the problem with your picture is that you are trying to do something superficial. The edge b is absolutely superfluous. Actually what you would do is to directly join the tokens in one place: Tokens will wait in Action and the ones sending b1 and b2. You question is a sophism since the facts are wrong. Like The village barber shaves all men ...


1

What is it about ? The quote is from section 15.2.3.3, which explains that there are two kind of activity edges. More precisely, it is about ObjectFlow edges. These passes objects as tokens. One of the main differences, between an object flow and a normal control flow in the activity model, is that you may use object nodes (see section 15.4.3.1,). ...


1

I don't think there's a general answer to your question. You have to take the cases one-by-one, since the devil is in the details. This means that during execution data will be passed first to handler-1 and then to handler-2. It's not 100% clear what you mean, but I'll show you two ways to show this in UML with a sequence diagram: But configuration ...


1

If you use swim-lanes, I think you don't need any wait mechanism. It's implied that the Customer Representative has to be ready to do the task. Here's a suggestion done with PlantUML/PlantText: EDIT Here's another suggestion (source) with a more explicit wait semantic that allows for hanging up.


1

Having a "wait" state, or wait activity, is not implausible, and depending on the domain, not uncommon either. Mark it as such and defined how long the state will be active for (i.e. how long it it goes back to the decision point). If the decision point doesn't have to be explicitly exposed, you can roll the decision and wait state into a single activity ...


1

To keep the service always alive even the activity has been closed, you have the start the service as foreground. That leaves a notification on top. Now bind your service to your activity when the activity is visible and unbind on closing the activity. By this way, you will always have full control on your service. To start foreground @Override public void ...


1

Here you are speaking on one timeline only. But even in it there could be many end points - due to branching. And on the diagram you can have many timelines, each with its endpoints. On your timeline one endpoint will be enough, but we can say nothing about other timelines.


1

It makes sense to end the activity diagram at 1 point if the activity will return no value to caller or if it is returning the same object (or value) in all cases except a major error. If the activity may result in separate actions multiple end points would be valid. In your example, I would prefer a single end point. As an example of multiple end points ...


Only top voted, non community-wiki answers of a minimum length are eligible