SWIM Supporting Material
SWIM-SERV-220 Service behaviour
Requirement
Title | Service behaviour |
Identifier | SWIM-SERV-220 |
Requirement | A service description shall include or refer to information about the typical behaviour of the service. |
Rationale | This requirement facilitates the understanding of the service behaviour to support operational processes. |
Verification | Completeness: Verify that the behaviour information is included and covers the errors handling as well. Consistency: Verify that the names of the interfaces, service operations and exchanged information are consistent with the interface definitions. Correctness: Not Applicable. |
Examples/Notes | It is best practice for the overview of the service behaviour to describe the typical workflow, e.g., that operation x needs to be called before operation y can be used. Note: More details on the service behaviour can be provided as part of the model view in SWIM-SERV-330. Examples of what to include in the more detailed service behaviour:
|
Level of Implementation | Mandatory |
Guidance
Service behaviour
The behaviour is for the service as a whole. The behaviour of the operations is not covered by this requirement. Instead, it is captured in the description of the operations (SWIM-SERV-270 Service operations).
This requirement covers the typical behaviour of the service. This tends to be easy to document under normal conditions as the service is working as hoped.
The service behaviour can be captured
- using a formal modelling notation such as the Unified Modeling Language (UML) (which allows e.g. sequence diagrams), and/or
- expressed as textual description in plain language.
The SWIM-SERV-330 Model view can be used to make reference to the model.
The specification gives examples of what can be included in the model view. The examples cover the non-nominal (error handling) behaviour e.g. the behaviour of the service with incorrect input data or incorrect authentication. This can be affected by the chosen implementation of the service. See Documenting the use of standardised implementations for more examples.
Verification Support
Completeness | Check that: [ ] The service description includes or refers to information about the typical behaviour of the service. [ ] The service description includes or refers to information about error handling during the typical behaviour of the service. |
Consistency | Check that: [ ] The names of the interfaces, service operations and exchanged information are consistent with the interface definitions. |
Examples
The following example shows the content as a table.
service behaviour | typical behaviour | The service consumer uses the setTOBT operation to upload a Target Off-Block Time for a specific flight and receives a response on the validity of the request. The service consumer uses the deleteTOBT operation to delete the Target Off-Block Time for a specific flight and receives a response on the validity of the request. Each operation of the interface can be called independently. The operations are detailed in a model view. |
---|
The following example shows an extract of the content of a JSON file that conforms to the Service Metadata Schema
"technicalDescription": { "behaviour": [{ "name": "TYPICAL", "description": "The service consumer uses the setTOBT operation to upload a Target Off-Block Time for a specific flight and receives a response on the validity of the request. The service consumer uses the deleteTOBT operation to delete the Target Off-Block Time for a specific flight and receives a response on the validity of the request. Each operation of the interface can be called independently. The operations are detailed in a model view." }] }
Complete examples are available at Example service description.
Related content
Status: Living Material