Documentation

From Definition to Code

A complete system definition in Specify gives you a structured path from specification to implementation. The more complete and accurate the definition, the more directly it maps to code.

The path

The route from definition to implementation follows three stages:

  1. Define - describe all features, use cases, and requirements in Specify
  2. Verify - review the specification for completeness and accuracy
  3. Implement - write code (or generate code frameworks) from the specification
The specification doesn't tell developers how to implement the system. It tells them what the system must do, under what conditions, with what constraints. The implementation choices - language, framework, architecture patterns - remain with the engineering team.

Feature dialogues

Feature dialogues define all the interactions between users (or protocols) and the system. Each dialogue describes the complete sequence from the start to the finish of a feature activation.

In the Reference Project, "Cancel Baking Session" under User Features is a feature dialogue. It defines every step of the interaction: the user triggers cancel, the system checks the current state, the heating stops, the display updates. Feature dialogues also apply to protocol interactions - the features offered by a Bluetooth API, for example, would each be a dialogue.

A well-defined set of feature dialogues means the user-facing and protocol-facing behaviour of the system is fully specified. Nothing is left to interpretation during implementation.

Event processing

Beyond feature dialogues, many features involve event processing - scheduled or triggered events that the system handles in the background.

The Oven Project has two patterns for this:

Frequency-scheduled events - actions that run at a fixed interval. A diagnostic check every hour, a sensor reading every 100ms. These translate to frequency-scheduled virtual state machines in implementation.

Time/date-scheduled events - actions that run at a specific time. A daily backup at midnight, a weekly calibration check. These translate to event-scheduled virtual state machines.

The event processing features create a bridge between the system definition and the implementation. They define what events exist, when they fire, and what happens in response.

From specification to implementation

If you describe all features - including feature dialogues and event sequence process dialogues - you end up with a complete system definition from which you can code or auto-generate code frameworks.

For hand-coded implementations, the specification provides:

  • A clear list of every behaviour that needs to be coded
  • Requirements that define the acceptance criteria for each behaviour
  • Use cases that define the test scenarios
  • Feature set boundaries that suggest component boundaries
For auto-generated code frameworks, the specification provides the structured data that code generators consume. Feature dialogues translate to interaction handlers. Event processing features translate to state machines. Requirements translate to assertions and constraints.

Traceability to testing

All the features in a system definition are used to tag and uniquely identify every code statement and code path. This creates direct traceability from specification through implementation to testing:

  • Unit tests validate feature APIs
  • Integration tests validate use case flows
  • Acceptance tests validate complete feature requirements and behaviour
When a test fails, you trace back to the feature and requirement it validates. When a requirement changes, you know which tests and code paths are affected.

Solaros Construct

Solaros Construct, a separate product in the Solaros ecosystem, can generate embedded code frameworks from finalised feature sets in Specify. The two products work together - Specify defines the system, Construct generates the implementation scaffolding.

Related