組込ソフトウェア開発のための3部作「構造化モデリング」「オブジェクト指向モデリング」「リバースモデリング」を読んでいて楽しい

組込ソフトウェア開発のための3部作「構造化モデリング」「オブジェクト指向モデリング」「リバースモデリング」を読んでいて、面白いのでメモ。
10年以上も前にかおるんさんは既に読破されているので参考にしている。

【参考】
読了・組み込みソフトウェア開発のためのオブジェクト指向モデリング - ブログ@kaorun55

読了・組込みソフトウェア開発のための 構造化モデリング - ブログ@kaorun55

【1】上記のブログでは、「組み込みとしては、やはりこちら（構造化）の方がしっくりくる。なんとなくオブジェクト指向の方は無理をしている気がしてならない。」という感想がある。
「オブジェクト指向モデリング」よりも「構造化モデリング」の方がしっくり来るらしい。

一方、僕は、構造化設計の技法は、データフローダイアグラムとかSTS分割のような古い技法に違和感があって、むしろ、オブジェクト指向設計の方針でクラス図、シーケンス図、状態遷移図からモデルを作り出す方がしっくり来る。
だから、「構造化モデリング」よりも、「オブジェクト指向モデリング」の方が、読みやすく感じた。
なぜなら、オブジェクトで考える方がレイヤ化設計、状態遷移図などのモデルを自然に組み立てられる気がするから。

【2】たとえば、組込みSW開発の経験はゼロだが、組込みSWのモデルをユーザ視点の業務ロジック層と、物理法則やセンサーから検知した情報の制御を含む制御層の2つに大きく分けてモデルを組み立てる方針の場合、オブジェクト指向設計の方がパッケージでソフトェアを分割してレイヤ化しやすい利点があると思う。

以前、astah関西で、高井さんがSysMLを使う利点として、熱力学など自然科学の専門家、自動車や家電機器などの業務の専門家、ハードウェアの専門家、そして組込みSWを開発するプログラマの4種類の人達が、SysMLを通じてコミュニケーションできるようになった、という話もあった。

第2回astah関西の感想　#astahkansai: プログラマの思索

また、状態遷移図とは、一つのオブジェクトに着目してその状態が遷移した過程を表すので、クラス図で洗い出したオブジェクトから自然に状態遷移図で考えるように仕向けられる。

組み込みソフトウェアの根本問題～対象物の状態遷移を記述できれば、制御が可能だ: プログラマの思索

【3】興味深いのは、組込みSW開発の要件定義で重要な成果物として、ユーザ視点のユースケース分析だけでなく、イベントリストも挙げられている点だ。
たとえば、「構造化モデリング」「オブジェクト指向モデリング」の例では、電気ポットのソフトウェア要件定義で、ユーザがお湯を沸かすときのイベントだけでなく、ポットの水位やポットのお湯の温度の変化がトリガーとなるイベントも洗い出されている。
考えてみれば当たり前だが、アクターとして、ポットの購入者という利用者だけでなく、ポットという機械を構成するセンサー部品（水位の検知、温度の検知）もアクターになるわけだ。
つまり、組込みSW開発では、アクターの種類が多いので、コンテキスト図を最初に描くのが割と重要と気づいた。

【4】もう一つの「リバースモデリング」は読みかけだが、よくある事例な気がして、興味深く読んでる。
レガシーな業務システムと同じく、組み込みソフトウェアもレガシーになると、設計書はなくなっていて、動くソースコードが仕様そのものになっている。
しかし、数千行、数万行、数十万行のソースコードから本来の設計思想を汲み取って開発するのは至難の業だ。
たとえば、工場の生産ラインとか、長年使われている機械部品とか、そういう例があるのだろう。

「リバースモデリング」では、レガシーと化したソースコードからリバースして、モデルを抽出し、本来のあるべきモデルを描き出し、そこから仕様変更や改修を手がけていく、というストーリー。
なかなかうまく行かないだろうが、色んな技法を駆使して、リバースしたモデルを洗練させていくのは面白い。
今なら、XDDPと組合せてやるだろうか？

【5】残念なことに、組込ソフトウェア開発のための3部作「構造化モデリング」「オブジェクト指向モデリング」「リバースモデリング」は、「構造化モデリング」以外は絶版になっている。
3部作全てが復刊されるといいなと思う。