2005-12-30 diary: 大掃除 , ドキュメントコンパイラー

大掃除 , ドキュメントコンパイラー

自宅の部屋を大掃除しました。大きなホコリの塊がいくつもありました (苦笑)

大掃除

自宅の部屋を大掃除しました。大きなホコリの塊がいくつもありました (苦笑)まだまだ掃除しきれていません。

blanco Framework: ドキュメントコンパイラー

blanco Frameworkのメンバーは、かねてより ドキュメントコンパイラーという構想を持っています。これについてのメモです。前提条件としては、既存の blanco定義書を想定しています。もちろんドキュメントの入出力には blancoReportの存在が大きいと想定します。というか blancoReportが存在しているので、ベースとなる技術として不明な点はありません。(むろんOpenOffice.orgが どの程度正確にコンバートしてくれるかがカギです)

• 【定義ID】 最初にはドキュメントには定義IDのみを記載する。この例では 墨付きカッコ【】を 定義ID引き当てのためのタグとしている。

• 【定義ID (日本語説明)】 ドキュメントコンパイル時に定義書の引き当てに成功した場合には 丸括弧をともなった日本語説明が追加される。

• 【定義ID (変更後の日本語説明)】 ドキュメントコンパイル時に定義書を引き当て、かつ日本語説明が変更されている場合には、丸括弧の中には 変更後の日本語説明が自動的に記載される。

• 【定義ID (エラー文言)】 ドキュメントコンパイル時に定義書の引き当てに失敗した場合には 丸括弧をともなってエラーを表現する文言が追加される。そしてドキュメントコンパイルは中断する。

工程内での定義IDおよび名称の矛盾を解決できる期待が持てます。リレーショナルデータベースに履歴を持てば、仕様の追跡性が確保できると考えられます。構造化分析という観点での問題点や複雑さの定量化などにも期待が持てます。加えて工程間の定義IDの整合性のチェックなどにも応用も想定されます。

あとは納品物としての「見栄え」が課題になるであろうと考えられます。ファイナライズのような作業において、【定義ID (日本語説明)】 を 日本語説明(定義ID)に置き換えるような処理があっても良いのかも知れませぬ。

この日記について

• ホームページ更新者: 伊賀 敏樹 / Tosiki Iga
• Diary / Facebook / LinkedIn / GitHub / Qiita / Mastodon / X(Twitter) / Amazon / Share on Twitter / top / いがぴょんについて / Powered by Igapyonv3
• 本サイトの見解は、私 個人のものであり、株式会社レザボア・コンサルティング は当個人的見解に一切責任を持ちません。