『第13回クリティカルソフトウェアワークショップ(13thWOCS2)』のパンフレット

来年の1月に開催される『第13回クリティカルソフトウェアワークショップ(13thWOCS2)』のパンフレットがたくさん送られてきました。

裏面は3日間イベントのプログラム表になっています。

SW Componentを体系的に知る本

25日が過ぎるとあれだけXmasで騒がしかった街もXmasなんてどっかに行ってしまい、すっかり年末ムード。　
 
今日は少しだけオフィスの整理で、整理するのは書類や本や不要物を破棄することがメイン。　
　
オフィスの本棚を整理すると、埋もれてどこに行ったのか探していた本を見つける事が多い。　
　
今日も書棚の端にあった『Component Software』を手にした。

　
この本はソフトウエアコンポーネントについての論文を読んだり書いたりするときに必ず文献に掲載される本の１つ。
　
絶対読まないといけない本とは思わない。
　
ただ、コンポーネントは色々な解釈があるので,学術的な議論や論文ではコンポーネントの定義や技術的な要素が体系的にまとめられているこの本を土台に議論をすることが多い。

プロセス代数とモデリングとアーキテクチャ分析・設計

分散並列・並行とリアルタイムが当たりまえに時代になりつつある現代では、モデルドリブン開発でアーキテクチャ分析・設計を行う時は、プロセス代数を使う事が必要条件になる。
　
もちろん、高専や大学や専門学校の時代から学ぶ必要がある。
ソフトウエア工学を学ぶとは理論や定理に基づいた科学的なアプローチを学ぶことである。
　
属人的な経験則、主観および根拠のない主張によるモデリングとアーキテクチャ分析・設計を否定し、可能な限り正当性や妥当性を持つ分析・設計にはプロセス代数を使うことは不可欠になっている。
　
結果的にそれが生産性や品質を高めることを加速する。
　
プロセス代数と支援ツールを用いて、アーキテクチャ分析・設計のモデリングを実施することはとても有用である。
　
工学的根拠や客観性で正当性や妥当性をもつ具体的なアプローチを使うことがメーカーやエンジニアの責任となる。

設計根拠を求められたとき、科学的(工学的)根拠に基づいて正当性や妥当性を示す必要がある。

モデラーとしてステップアップするために②～モデルドリブン開発におけるアーキテクチャ設計と例外処理設計

例外の設計はシステムの「アーキテクチャの土台と骨子」に大きな影響を与える最重要事項の１つである。

ソフトウエア言語として例外処理をサポートいていない場合は、関数やプロシージャの処理で想定外のことが発生した場合は、予め決めておいたフラグにエラーを意味する値をセットする。

あるいは返り値でエラーが分かる値を返す。
　
この方法は処理を呼びだしたクライアント側のコードが、毎回毎回フラグや返値を確認しなければならない。

　
基本的にはエラーが発生したときのみ、クライアント側は分かればいいので、この方式は無駄にコードサイズの圧迫につながる。
コードの修正の際にも面倒である。
　

クライアントがフラグや返値を確認するコードを書き忘れると大きなトラブルになりかねない。
つまり、良くないことが多い。

そこで、オブジェクト指向言語の多くは例外処理機能をサポートしている。
コンストラクタは返値を定義できないので、コンストラクタで予想外の事が起きた場合は例外処理を利用する。
　

例外処理は「リトライ」「エラーの回復」「クリーンアップ」「適切な対象処理のためのエラーの伝搬」など色々など便利である。

例外処理は、アーキテクチャに信頼性と耐故障性を与え、かつ、アーキテクチャをシンプルで分かり易い設計を可能にする。

ただし、例外は気を付けなければならない事もある。

継承関係にあるクラスにおいて、サブクラスはスーパークラスから継承した操作を再定義するときである。

多相(ポリモフィズム)を使う事を想定している継承階層(普通はそう)では：

●サブクラスはスーパークラスで定義している例外を勝手に増やせない(例外を発生させないように例外を減らすことは可能)
●サブクラスはスーパークラスで定義している例外の型と「同じ例外型」か「その部分型」でないいけない

この２つの規則はスーパークラスで定義していない例外が発生したらスーパークラスの操作を呼び出すクライアントは対応できないからである。

オブジェクト指向開発で例外処理を効果的・効率的に行うには例外階層の設計がポイントとなる。

例外階層の設計は単純でないし、アーキテクチャの土台と骨子となるからとても重要となる。

モデラーとしてステップアップするために①～オブジェクト指向開発と『契約による設計(Db)』

今日と明日は明後日のための資料作り。

　
ソフトウエア開発においてきわめて重要なものに『契約による設計(Db)』がある。
　
「契約による設計(Db)」を学ぶには色々な書籍があるけれど、酒匂さん翻訳された書籍『オブジェクト指向入門』が良い。

「契約による設計(Db)」はオブジェクト指向極めて重要で、信頼の高いシステム拡張性・保守性及び再利用を実現する上で不可欠である。

「契約による設計(Db)」を理解して活用するとモデルドリブン開発で大きな武器となるので、是非マスターしよう！
　

クラス定義にはクラスのインスタンスが絶対保障しなければならい「(クラス)不変条件」を明示的に示す必要がある。
　

これはクラス定義の中に「クラス不変条件」として明治的に設計者が記述しなければ第3者には基本的には分からない。
　

●「クラス不変条件」==>クラスの属性や関連が満たさなければならない値、状態、制約を定義したもの。クラスが持つ全ての操作には下記の定義が不可欠で、この３つを定義しないクラスは著しく信頼性が無い。
　
「事前条件」==>操作処理を問題無く行う為に操作の呼び出し側が満足しなければならない条件
　　

●「事後条件」==>操作の呼び出し側が「事前条件」を満足して操作を呼びだした場合に、操作が保証する処理結果
　　
●「例外定義」==>操作が例外を発生する際の例外の種類・型情報。定義してない例外をクラスの操作は絶対に発生させてはいけない

「クラス不変条件」と操作の「事前条件」「事後条件」「例外定義」はソースコードの中に実装されるから、単に分析や設計のための技法ではない。
　

「クラス不変条件」と操作の「事前条件」「事後条件」「例外定義」を明示的にクラスに定義することで、レビュー(インスペクション)やテストも加速する。

　
さらに、開発したシステムの拡張性・保守性及び再利用では、クラスの「クラス不変条件」と操作の「事前条件」「事後条件」「例外定義」を常に意識しなければ安全な拡張や再利用はできない。
　

システムに修正を入れる場合は、クラスの「クラス不変条件」と操作の「事前条件」「事後条件」「例外定義」を守る様に修正を入れなければいけない。
　

そのために、必要に応じて『開放閉鎖原則』を併用することが多い(『開放閉鎖原則』も書籍『オブジェクト指向入門』に詳しく説明してある)。
　
なお「例外定義」の定義は特に注意が必要である。

　
クラスの中の各操作が例外を定義を明示的にしてない場合は、その操作は絶対に発生させてはいけない。
　

JavaやEiffelでは操作が例外定義をしていないと例外を発生させられないが、C++では可能(モラル的には良くない)なので、クラスの中の各操作が例外を定義を明示的にしてない場合はしばしば大きなトラブルの原因になる。

『契約による設計(Db)』を用いると、クラスに関する情報が一か所に定義できるので、情報が分散しないメリットも大きい。
　

『契約による設計(Db)』を理解することは、オブジェクト指向開発の常識と主張する専門家も多いので、是非理解して活用しよう。

『第13回クリティカルソフトウェアワークショップ(13thWOCS2)』での講演のご案内

『第13回クリティカルソフトウェアワークショップ(13thWOCS2)』での講演することになりました。

日時：平成28年1月20日
場所：コングレスクエア日本橋

『第13回クリティカルソフトウェアワークショップ(13thWOCS2)』は、平成28年1月19日～21日の3日間開催され専門家による魅力ある講演や技術セミナーおよびコンテストが開催されます。

詳しくは下記をご覧ください。

http://www.keiso-comm.com/13wocs2/program.html

状態マシンのコード生成をする『3階層ステートアーキテクチャ』

ロバート・マーチン氏が紹介している『3階層ステートアーキテクチャ』を制約を効果的に設計・実装できるように拡張の検討している。　

これって「ステートパターン」ではなく、自由に状態マシンのコードを生成する『状態マシンコンパイラー』と呼ばれている。

まだまだ作業は続く。

『アーキテクチャの設計効果&効率』のメトリクス2

メトリクスを表形式とコンポーネントあるいはサブシステムの中に表示する両方で対応。

『アーキテクチャの設計効果&効率』専用のグラフによる表示を行う。
グラフで示すと視覚的効果でアーキテクチャの性質が一目瞭然になる。
　
アーキテクチャの分析と設計を行いながら、動的にメトリクスを計算してアーキテクチャの効果を判定することが可能。