Skip to content

Latest commit

 

History

History
132 lines (80 loc) · 6.5 KB

SpecifyingApplications.md

File metadata and controls

132 lines (80 loc) · 6.5 KB

Specifying Applications

Automated code generation and testing requires the applications being specified in syntactically well defined way.
Any specification, which shall be published for implementation, has to comprise OpenApiSpecification, CONFIGfile and TestCases.
A couple of additional documents have to be elaborated to ease creation of the three main documents.
In general the following sequence of activities is recommended:

Workflow for Specifying Applications

Purpose of the Application

The Purpose of the application shall be expressed in a single sentence. It must be most comprehensive and precise.

Name of the Application

The ApplicationName is treated as an identifier (means e.g. that it must be invariant).
Right after starting the specification and implementation process, resources will be referenced by ApplicationName and also during later operation, important processes will reference the ApplicationName (and ReleaseNumber).
Guidance can be found in Structure of ApplicationNames.

Repository

Every Application needs an own repository, which will exist in parallel to the Application over its entire lifespan.
Initial specification, but also implementation and later bug fixing and potential expansion of the Application will be organized through this repository.

Concepts

Step-by-Step Guidelines

ServiceList

The ServiceList must represent all services, which are either provided or consumed by the application.
The ServiceList is a compact notation for designing the service names and allocating the UUIDs.
It provides full focus on composing a complete and well-structured set of services before adding parameter and body details in the OpenApiSpecification.

Concepts

Step-by-Step Guidelines

Sequence Diagrams

The sequence diagrams are a visualization of interaction chains between operation servers and operation clients and the basis for the individual forwardings in the forwardingList.

Concepts

Step-by-Step Guidelines

ProfileList and ProfileInstanceList

The ProfileList and the ProfileInstanceList must represent all Profiles, which are used inside the application.
Profiles are used for storing configuration information, which is not directly related to a specific interface.
The ProfileList describes the Profiles as classes and supports creating the OpenApiSpecification.
The ProfileInstanceList lists all objects created from the Profile classes; it supports creating the CONFIGfile.

Concepts

Step-by-Step Guidelines

ForwardingList

The ForwardingList must describe all relationships between events and reactions that need to be documented and configurable at the application.

Concepts

Step-by-Step Guidelines

OpenApiSpecification

The OpenApiSpecification (OAS) represents the detailed specification of the REST API of the application.

Concepts

Step-by-Step Guidelines

CONFIGfile

The CONFIGfile describes the data structure inside the application and on the disk. The defined values represent the initial state of the application directly after instantiation.

Step-by-Step Guidelines

TestCaseCollection

Concepts

Step-by-Step Guidelines

Documentation

Publishing

After finishing specification work on a release, files have to be published for initiating next steps.

Concepts

<- Back to Preparing - - - Up to Main - - - Ahead to TinyApplicationController ->