BRON2 - What does it do for you?
BRON helps you to rapidly develop systems. The focus is primarily on design capture and programmer productivity.
BRON stands for "Binary Relationship Object Network". It is a way of describing a network of objects (a set of data structures) that are linked together with one of two basic types – One-to-One or One-to-Many – of relationship.
BRON deals with objects (which become C structures) with navigational links, data fields, and specific linkage and search behaviour. Many BRON objects contain linked lists, so the BRON package provides a high quality linked list library that supports singly linked lists and doubly linked circular lists.
BRON2C generates all of the code for the creation, linking, unlinking, destruction, searches, and state-event behaviour of an object; taking care of object memory management, object list management and managed references to other objects. This has two benefits:
The generated code is robust, with memory management taken care of for you. The programmer is freed to spend time developing and adding value, no need to write the "framework", BRON does that for you.
A BRON2 definition is sufficiently detailed enough to reproduce code from and therefore meets the criteria for a "pseudo-code" high level design.
BRON is unambiguous, clear, and succinct. This clarity and brevity give a considerable number of advantages over writing excess documentation and complex code. BRON provides:
Clear and concise high level design documentation Object manipulation code, automatically generated from the definitions A compact syntax leading to a reduced code size (that leads to the benefits above) Readable and maintainable resulting C code, even without the original BRON
The diagram below shows a simplified development flow.
Customer requirements are captured by whatever means matches your workflow, these are then expressed as a BRON model. This BRON model can be passed through the BRON Code Generator at any point in development to produce a BRON System Model (the C code that reflects your BRON Design Model).
The generated BRON System Model is targeted at the BRON OS abstraction layer, this provides the basic services that the BRON System Model requires to operate and provides a separation between the BRON System Model and the underlying platform.
BRON the concept, language, generator and run-time environment are self consistent and orthogonal. Concepts expressed in the language are compiled by the code generator such that they match the OS abstraction layer
Self consistent design, generation and runtime. OS abstraction layer runs on dev platform or target
BRON System Modeling Workflow
Define System Objects Define Object relationships Define Object Attributes ( the data ) Add Behavioural code augmentations ( for New, Free, Link, Unlink et al) Add Functional Augmentations (Methods) Define Signals and Timers Add Finite State Machines (FSMs) Define FSM behaviour and stateless event handlers Optimize Object Model, FSMs and FSM behaviour Produce Object testbenches Test Object behaviours Produce regression test suite Test System ( using traditional test plan/spec AND automated regression tests)
A simple example
You can express objects using whatever methodology notation you prefer, they all express essentially the same concepts. Many BRON developers don't bother with diagrams to represent the data, others produce diagrams for customer communication purposes. Taking the following simple 3 object example...
...the BRON equivalent of this is simply:
This code generates to 478 lines of C code and 96 lines of C header code that does the following:
Generated Header File Contents (View the generated .h file)
Protective #ifndef multiple inclusion protection typedef structs for the Objects struct declarations for the Objects, their data and Object lists/references List navigation macro definitions for all Object LISTs Function prototypes for each Object covering: Constructor functions (new<objectname>) Destructor functions (free<objectname>) Link functions (link<linkableobjectname> ) * Unlink functions (unlink<linkableobjectname>) * LinkNew functions UnlinkFree functions findFirst functions * findNext functions * matchAll functions *
Human readable comments are included, and with the 'g' option enabled even more comments are produced.
Generated C File Contents (View the generated .c file)
Protective #ifndef multiple inclusion protection header file inclusion For each Object Constructor function Destructor function Link function * Unlink function * LinkNew function * UnlinkFree function * findFirst functions * findNext functions * matchAll functions *
* = when required
For active objects there is an individual FSM function.
BRON definitions describe Objects, their data, their relationships and their behaviour.
In use you create Instances of these Objects, these Instances are data that is animated by the functions generated from the BRON definitions.
For example you could create three instances of the Object 'firstObject' :
firstobject1 = newFirstObject();
firstobject2 = newFirstObject();
firstobject3 = newFirstObject();
firstObject1 is a pointer to an instance of an OBJECT of type firstObject. You can access the Object data field anintegerfor this instance using firstObject1->aninteger
As soon as you start to get large collections of instances of one type it makes sense to manage them using another 'parent' object; you may reference these child objects using LIST or HASH to manage the 1 to many relationship. You may also name multiple 1 to many relationships differently to avoid confusion.
Enabling the OO concept of Object instances allows data driven systems with the minimum of enabling code, a powerful capability for 'C' targets.
'The Mythical Man Month' suggests that 10 lines of code per day can be expected.
From a 10 line BRON source file, that took about 2 minutes to design and type we produced:
478 (lines of .c) + 96 (lines of .h) = 574 lines of correct by construction generated C.
However, even though this shows BRON as highly productive we suggest that you don't think in terms of lines of code as a measure of completeness of a project. Instead we suggest that you think in terms of system requirements modelled and only consider code size in terms of size optimization against system requirements.
“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”
By focusing on producing a System Design Model the emphasis shifts from 'line of code produced' to 'elements of the system that have been modelled. This is much more useful and reliable in terms of project planning, it also relates more to the requirements than to 'implementation detail'.