So much for not-posting on my vacation… But I couldn’t think of reaching such new areas. Although most of the credit goes to my wife who just happens to be practicing Information Management and/or Record Keeping professional.
On the very beginning of my vacation when I summarized our “IT-developer-world” experiences on playing with design level information (now that we have it fully available) my wife pointed out, that its just standard metadata.
And I had to agree. Just standard metadata. None of which was structurally enough available prior of “abstractions”.
For the teaser of what’s coming, I posted few images. DesignInfo type is summarized as:
Design level information.
This information includes the references to specification and requirements.
This information is effectively used to generate the documentation and reports to communicate with stakeholders and other interest parties, such as testers and requirement analysts.
And includes section for Requirements; in particular performance requirement specification that contains pure raw numbers defining the requirements for the abstracted block:
Performance specific requirement.
The structured data is used to generate diagnostic time constraints either injected in the executing code itself or to provide performance profiler input automatically.
Connected to an architectural event it looks like this in the abstraction:
Why design against specification time requirements only, when one can design against design time requirements that are enforced to be in sync with the implementation.
I’ll follow up with complete example of generated documentation and modified code generator(s) to support requirement enforcement.
Won’t promise a day though, still on vacation 😉