An example of an activity YAML definition:
flow-activity: name: Create a story description: Product Owner creates a new story in the issue tracker. participants: product-owner resources: issue-tracker output-artifacts: story modifiers: final responsible: product-owner accountable: product-owner consulted: lead-developer informed: [developer, tester] representations: flow: hide-empty-description: true vertical: false context: 1 outputs: groom: target: groom payload: story
Keys of accountable participants relative to the containing package
If this reference is not set then EObjectActionProvider creates a new Action using AppFactory in newAction() method. If this reference is set and is Action then a copy of the action is created and returned. Otherwise the reference value it is adapted to ActionProvider which is used to create an action. This allows to merge actions and chain action generation. E.g. generate Ecore model documentation and merge it into the Engineering documentation.
Artifact responsibility assignments if different from the flow element responsibility assignments. E.g. a person responsible for an activity may delegate responsibility for some artifact to another participant. In this case another participant becomes responsible and the participant responsible for the activity becomes accounable for the artifact.
Keys of consulted participants relative to the containing package
Element documentation. Documentation elements are adapted to
SupplierFactory<InputStream> during generation. Exec content classes such as Markdown and Interpolator can be used as documentation elements.
documentation: content-text: Single line documentation
documentation: content-text: |+2 Multi-line documentation, line 1 Line 2.
documentation: content-resource: doc.txt
documentation: content-markdown: style: true source: content-text: Single ``line`` documentation
documentation: content-markdown: style: true source: content-text: |+2 Line 1. **Line 2**.
documentation: content-markdown: style: true source: content-resource: doc.md
Keys of informed participants relative to the containing package
Keys of input artifacts resolved relative to the containing package
A collection of boolean flags:
abstract- Specifies that this package element is abstract. For packages and flows it means that they contain abstract elements and must be extended to become concrete. If a package or a flow contains abstract elements and does not have abstract modifier, it is diagnosed as an error. If concrete packages and flows extend abstract ones they must override (implement) all abstract elements.
explicit-end- Applies to flows. Specifies that the end pseudo-state shall not be inferred by finding flow elements with no outputs. End will either be explicitly specified or the diagram will not have an end pseudo-state.
explicit-start- Applies to flows. Specifies that the start pseudo-state shall not be inferred by finding flow elements with no inputs. Start will either be explicitly specified or the diagram will not have a start pseudo-state.
final- Specifies that this flow element cannot be overridden in flows extending this flow. Overriding a final elemen will be diagnosed as an error. For example, in an organization some processes can be defined as flows at higher levels of the orgnization and extended at lower levels.
finalmodifier allows to specify what can be extended and what cannot. Specifying a top-level flow as final indicates that it cannot have extensions.
optional- Specifies that this element is optional. Optional elements have different apperance on diagrams.
extension- Specifies that this element is an extension for an element in one of extended packages/flows. If this modifier is present and
extendsreference is empty, then it results in a diagnostic error.
partition- Applies to flows and specifies that a flow shall be rendered as a partition (e.g. a composite state) on a diagram.
Keys of output artifacts resolved relative to the containing package
Keys of participants resolved relative to the containing package
Properties can be used to customize the documentation generation process, e.g. provide configuration for generation of representation diagram elements.
The below snippet shows how to use properties to customize diagram element shape for draw.io diagrams:
service-catalog: name: AWS Service Catalog properties: representation: drawio: width: 150 height: 200 style: shape: mxgraph.aws3d.cloudfront
Properties under the
representation are copied to the representation diagram element. Then, properties under the
drawio key are used during generation of draw.io diagrams. The following properties are supported by drawio diagram elements:
style- string or map
Properties with other keys become user object attributes.
Mapping of representation names to values - Diagrams which serve as templates for generating diagram content from the package element.
The below code snippet defines two representations:
test: flow-flow: name: Test representations: flow: hide-empty-description: true vertical: false generated: type: drawio:./test.drawio name: Drawio description: Generated diagram
In the second case a diagram file
test.drawio is generated if it doesn’t exist. This file can be edited after generation using an online editor or a desktop application which can be downloaded from https://www.diagrams.net/.
./ prefix indicates that the diagram file location shall be resolved relative to the marker location, i.e. the location of the YAML file with representation definition. If there is no prefix, or if there is no marker, i.g. if the definition was loaded from XMI and not from YAML, then diagram file location is resolved relative to the model resource location, which may be different from the location of the YAML file.
Keys of resources resolved relative to the containing package
Keys of responsible participants relative to the containing package
During documentation generation flow elements in the flow are sorted in the order of dependency and then alphabetically. I.e. if there is a transition from “Plan” to “Execute” then “Plan” will appear in the list of flow elements before “Execute”. Sort groups can be used to customize the default sorting behavior by scoping sorting to a particular group of elements. Groups themselves are sorted alphabetically. Elements without sort group appear before elements with an assigned sort group. For full control of sorting assign a different sort group for each flow element.
If element’s URI is not set then its default value is derived from the container URI and containment reference. This is a logical URI and it can be used for cross-referencing of elements in a resource-independent fashion.