An example of artifact participant responsibility YAML definitions, lines 9+:
code: flow-activity: name: Code outputs: unit-test: target: unit-test document: target: document artifact-responsibilities: # Artifact responsibilities story: responsible: developer accountable: scrum-master consulted: [lead-developer, architect] informed: [product-owner, tester] description: |+2 Developer changes story status to "In progress" and adds comments about the progress or questions requiring clarifications. Other responsible subscribe to the story to receive notifications and provide clarifications. source: responsible: developer accountable: lead-developer consulted: [product-owner, architect] informed: [scrum-master, tester] description: |+2 Developer writes code and reaches out to the product owner and architect for clarifications. Informs the scrum master and the tester on the progress.
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.
Key of the responsibility artifact relative to the containing package
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
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.
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 responsible participants relative to the containing package
If true, suppresses inherited responsibility for this responsibility’s artifact.
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.