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.
To solve this correctly, you must enclose the sequence of action that can be ...
The behaviors of a system are usually captured in UML with use case (requirements), sequence diagrams (interaction scenario between several classes), or activity diagrams (logical internal flow).
The activity diagram would best be used to model your narrative.
Association and Composition make sense for objects, as well as classes. An object may use another (Association), and an object may contain another (Composition).
But you can only Generalize a base class to create a derived class. It's not possible for one object to be a Generalization of another object. If the base class isn't abstract, it's possible to ...
Normally there is only a single active state. Fork creates more active states that can then propagate independently.
There is one thing you are missing with regard to join: you can only pass join when all inputs are incoming. That cannot be modeled simply by more incoming connections.
You can perfectly model the states between fork and join by doing a ...
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 ...
You have understood correctly.
Analysis of the standard
126.96.36.199 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 ...
An entity within the system that transforms data. Includes, for example, accounting clerks (persons), departments (places), and computers (things)
Source: Gelinas, Ulric J., et al. Business Processes and Information Technology. Orange Grove Texts Plus, 2008.
You only have one use case there, so only one blob. Add actors for everything that's mentioned there that isn't "the system" ("the user", "the billing system" and so on). Then join them up with lines. Job done.
She only reasons why you'd need multiple blobs i:
If you break out parts of a use case into sub-use cases, where there is common functionality, ...
Do you need to build both? Maybe. It depends. I'd say that if there is a 1:1 mapping between classes in a UML Class Diagram and components in a UML Component Diagram, you probably don't need both diagrams.
The intention of both diagrams is different, though. Class diagrams specifically show classes (and modules or packages), along with their attributes, ...
In UML (or any other type of practical design) you will never have to design every single possible combination of states, as you pointed out, that's impossible.
UML is meant to model something, and that's it. It doesn't force you you to come up with every single possible mix of states.
The designer or UX person will generally need to keep in mind 3 ...
The UML specification https://www.omg.org/cgi-bin/doc?formal/17-12-05.pdf states
As an ActivityNode may be the source for multiple ActivityEdges, the same token can be offered to multiple targets. However, the same token can only be accepted at one target at a time (unless it is copied, whereupon it is not the same token, see ForkNodes in sub clause 15.3 ...
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 ...
Since this question remains unanswered, I'd like to expand on my comments.
In a flow chart, you probably don't need to represent events at the level of detail that you are thinking. A flow chart is a representation of a workflow, process, or algorithm. At the most basic level, it contains terminals (a start condition or event and one or more stop conditions ...