Specification Driven Development Demo


Summary

  • Subject: Formal methods in Application Management
  • Idea: Generate API trace for a Formal Model and distribute it to developers for extracting API Steps and running Units Tests on the Implementation. Interpret aggregate result of executing individual Unit Tests as executing a "Virtual System Test"".
  • Gain: Get design right, write better code. Managing Units Tests separately is cheaper than managing Systems Test as a single unit. Formal Model and Implementation conform each other.
  • See also: Amazon finds formal method useful in real world context. It scales up.

Need for Specification Driven Development?

In the future IT environment, 

Given  Technology trend such as 'micro services'
And    Technology trend such as 'block chain'
And    Technology trend such as 'IOT'
And    Business environment trend  'increased openess of IT systems'
And    Business environment trend  'need for new innovations'
When   In the future 'implementations become more complex'
And    In the future 'having more interfaces open for malicious attacks'
# Then   Risk of Unfortunate IT failures

companies need to manage their IT on-line openess carefully to avoid the Risk of Unfortunate IT failures.

Specification Driven Development, with adequate development architecture and development process, could help companies in managing their IT on-line openess. As the result, expect better systems due to understanding the problem better, getting the design right, and being able to write better code. Particulary, in the context of this demo, expect savings in test management, when using formal model to generate API traces, which represent end-to-end scenarios executing across system services in the formal model, and using these API traces to create unit tests on implementation. Savings in test management are realized, when, after executing each of the individual unit tests, the aggregate result can be interpreted as an execution of a "virtual" system test on the composite system - considerably easier than managing the execution a system test as a single unit.

Objective of the Specification Driven Development Demo

This Specification Driven Development Demo presents a realization of a development architecture to help in managing IT on-line openness.

Particularly, it

  • aims at pointing out, how Specification Driven Development can be integrated with an existing legacy implementation
  • puts forward design artifacts and how these artifacts are transferred from design step to another
  • explains, how to setup development architecture supporting Specification Driven Development

The demo uses an existing application (timeoff-management) as a target implementation. Only one simple interface (/registerCompany(post)) is specified to keep focus on the factors enabling Specification Driven Development.

Overview of Specification Driven Development Demo

The diagram below shows main architectural elemets corresponding Specification Driven Development design steps:

The diagram depicts also, how timeoff-management -application, used in this Specification Driven Development Demo, is retrived from a GitHub repository.

Finally, the diagram presents directory ../stage/, which is used to transfer design artifacts between design steps.

  • timeoff-swagger.yaml: specification of interface /registerCompany(post) created in Schema and API Design
  • API Trace: Formal model execution traces created in Formal Modeling deployed in the the form of self extracting archive files to the staging directory

00-dev-overview.jpg

Code

Demo is avaibale in a GitHub repository with MIT licence.

Comment and Feedback

You can comment or give feeback on reddit or directly sending gmail to the account name of this GitHub -page.

subscribe via RSS