Diagram - Activity Profiles
Model event actions, structured ownership, independent partitions, notes and exception handlers.
#Usage
Start with Activity basics for module setup, actions, flows and pins. The profiles below add descriptive event and ownership rules through the same store, semantic root, copied form and history.
Use the Activity setup with the module installed in the store. Keep the matching semantic root and copied inspector under Diagram.Root. The examples below include their complete model and controls.
#Describe send and accept actions
Select Dispatch to edit its signal and target description. It accepts input argument pins only. Receive order and Wait each own one result output. Stock ready is a change acceptance with no result pin. Change timer trigger changes the unconnected Wait result to a result-free Change trigger; Undo restores both profile and pin. Try removing connected result rejects the same conversion on Receive order until its result ObjectFlow is repaired.
| Profile | Required descriptive values and pin contract |
|---|---|
sendSignal | name, ordered pins, signal, target; input pins only. Target is text, not a delivery address or inferred graph binding. |
acceptEvent with Signal | trigger: { kind: 'signal', signal }, unmarshall: false; exactly one output result and no inputs. |
acceptEvent with Time | trigger: { kind: 'time', expression, relative }, unmarshall: false; exactly one output result and no inputs. relative is a required boolean. |
acceptEvent with Change | trigger: { kind: 'change', expression }, unmarshall: false; no input/result pins. |
updateEvent creates or removes a result pin in the same transaction as changing the
trigger. There is one inert trigger per acceptance. Signal definitions, unmarshalling,
call acceptance, event queues and execution are not modeled. Signal names are at most
128 characters; target/time/change text at most 256.
#Own a structured Activity
Fulfill is a fixed StructuredActivityNode with explicit inner ownership. Its input
boundary exposes two distinct physical IDs. The outer portId is input in the
parent scope; the innerPortId is output in Fulfill's scope. Output boundary pins
reverse those directions. This permits a supported crossing through a boundary pin
without treating an ordinary flow as cross-scope.
Audit and Record are drawn within the frame but initially belong to the Activity. The owner readout makes that distinction visible. Choose Move pair into Fulfill to transfer both actions and their connecting flow while retaining world positions. Try moving Audit alone rejects while the pair belongs to the Activity because the flow would span owners. After the pair transfers, that rejection specimen is disabled. Undo restores the prior owner and makes both actions available again. Toggle Fulfill collapse changes presentation while retaining semantic contents. Use Fit selected for the scope when the full model is dense.
moveContents(ids, scopeId) transfers executable/object/control/Note roots within one
Activity, retaining world placement and updating owned descendants/relations in one
transaction. Pins move with their owner. A scope cannot move into itself or a
descendant. Ordinary reparenting or metadata-only scope changes cannot bypass matching
visual and semantic ownership. Converting an action with owned pins/children to an
incompatible kind rejects until those dependencies are removed.
#Keep partitions separate from ownership
Operations is a root visual partition. Its members explicitly include Review, Ship
and their ControlFlow; those records retain Activity scope and their existing parents.
Toggle partition orientation changes the frame, not the semantic owner. The note
uses an annotation to Ship. Try annotating partition rejects an unsupported target.
| Data | Supported contract |
|---|---|
partition | name, ownership at the Activity root, distinct members IDs (up to 512), orientation: 'horizontal' | 'vertical', required isDimension, optional parentPartitionId. Root visual frame with no actual parent. |
| Members | Existing executable/object/control nodes or control/object flows in the same Activity. Pins, Notes and partition frames are excluded. Membership is independent of enclosure and may cross structured scopes within that Activity. |
| Hierarchy | Explicit parent partition belongs to the same Activity; cycles reject. A dimension partition is a top-level catalog without direct members or parent partition. |
note | name, ownership, text up to 1024 characters. It is not a token-flow endpoint. |
annotation | Ownership and optional name; Note body source to executable/object/control body target in the same scope. Pins, partitions and Notes are excluded targets. |
#Describe an exception handler
Charge card is protected by Recover. The handler relation names both nodes and Recover's single untyped exception input. Choose Describe handler to change its name/type descriptions, then Undo. Try ordinary handler flow rejects a regular ControlFlow into the handler body. Select Recovery to edit the relation through the copied form.
A handler has kind: 'exceptionHandler', ownership, protectedNodeId, handlerBodyId,
exceptionInputId, distinct nonblank exceptionTypes (1–32, at most 128 characters
per name), and optional name. The protected node is an executable pin owner; the
handler is a distinct ordinary or structured action in the same scope. Its one input
is the handler-owned exception pin, with no datatype or connection tag. Exception
names do not infer subtyping.
The handler body and its external pins have no ordinary ActivityEdges. Structured handler interior flows may use the reversed inner boundary ports. When the protected node has output pins, handler outputs match their relative order/count and explicit datatype/tag descriptions. The handler connector binds the protected body to the exception pin's actual outer port; the factory derives its distinct relation artwork. No exception is raised, dispatched or recovered at runtime.
#Profile editing reference
| API/model action | Purpose and defaults |
|---|---|
DiagramActivityEditor.updateEvent(id, trigger) | Atomic trigger/result-pin change; connected or locked result removal rejects. |
moveContents(ids, scopeId) | Explicit ownership transfer to the Activity or a StructuredActivityNode; descendants and compatible related geometry move together under current policy. |
connectHandler, updateHandler | Create or describe a typed handler relation through the connection controller. |
annotate, updateAnnotation | Create or describe a Note relationship with explicit Note/target IDs. |
createDiagramActivityRelation, activityRelationText, activityRelationAppearance, validateActivityProfiles | Construct/inspect relation presentation and profile constraints. Factories are not commits. |
| Copied form actions | signalDetails, eventDetails, partitionDetails, noteText, moveScope, handlerDetails, annotationDetails; shared selected data, choices, drafts and disabled/status state come from DiagramActivityInspectorModel. |
These actions use the same installed uml-activity version-1 module as basic flows.
Copied PrimeOne and Tailwind forms keep their own established visible controls;
showcase controls use PrimeVue in both previews. Selection and navigation remain
available in read-only mode; writes, dependent port placement, approval and history
recheck current permissions. Pending is distinct from committed. Generic
graph reuse retains/remaps complete ownership
and relation dependencies through the module; copying an incomplete dependency set
must be repaired rather than silently rebound.
ExpansionRegion, interruptible regions, token execution, CallBehavior/CallOperation resolution, executable expressions and a general UML type system are outside this profile. Keep these diagrams descriptive when integrating them with other tools.