豆蔵ソフト工学ラボのモデリング記事のリンク

豆蔵ソフト工学ラボのモデリング記事がいつも参考になるので、リンクをメモ。
自分が考えていることをラフなメモ書き。

【参考1】
誤解しがちなモデリングの技：目次 | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技：第1回：コンポジションにまつわるアレコレ | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技：第2回：隠れた曖昧さ | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技：第3回：ステートマシン図（Ｉ） | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技：第4回：ステートマシン図 (II) | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技：第5回：ユースケース図にまつわるアレコレ | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技：第6回：初心者にありがちな間違い | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技：第7回：モデルの意味的な誤り(I) | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技：第8回：モデルの意味的な誤り(II) | 豆蔵ソフト工学ラボ

【参考2】
組込み開発のためのモデリングワンポイントレッスン：目次 | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン：第1回：対象を明確に | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン：第2回：デバイスのモデリング | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン：第3回：クラスとインスタンスの区別 | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン：第4回：ドメインと制御の区別(前編) | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン：第5回：ドメインと制御の区別(後編) | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン：第6回：状態って何？ | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン：第7回：イベントいろいろ | 豆蔵ソフト工学ラボ

組込み開発のためのモデリングワンポイントレッスン：第8回：状態遷移 | 豆蔵ソフト工学ラボ

【1】一つのシステム、一つの業務を分析する時、複数の観点でモデルを描いて、重要な箇所やキーとなる部分を把握したい時にUMLは役立つと思う。
但し、いくつかの注意点があると思う。

業務システム、業務の設計では、UMLの観点の分析は役立つが、ER図とDFDがやはり必要。
ER図で帳票の項目がどのように配置されるか分かるし、DFDで業務フローとデータの関連が一瞥できる。

個人的に注意している点は、エンティティがイベント・リソースだけでなく、サマリテーブルとして保持すべき部分はどこであるか、という所。
リアルタイムに表示したい時に時間がかかるならば、バッチ処理で集計したデータをサマリテーブルに生成し、そのデータを表示させるように設計する。
すると、その表示のタイミングによって、データは最新でないから、ユーザが戸惑う時がある。

また、業務システムのモデリングでも、組込システムと同様に、データのライフサイクルという観点で状態遷移図を考えたい時があるが、ER図・DFDではそれを表現しにくい。
いつもしっくりこない。

【2】組込システムのモデリングでは、UMLの観点の分析はすごく役立つと思う。
クラス図で必要な処理がオブジェクトに集約されるし、シーケンス図やアクティビティ図でオブジェクトの動的な処理をプログラムとほぼ一致させることもできる。

個人的に注意している点は、組込みシステムを状態遷移図として表現する時に、複雑な要件や仕様をどこまで状態遷移図で表現できるか、という所。
システムを状態遷移図に表現できれば、事実上、プログラムに自動生成することは可能。
だが、実際のシステムでは、イベントを待っていて発火する、とか、イベントの履歴を保持してどの状態に遷移させるべきか使用が決まっている、とか、色んなパターンがあって、状態遷移図に全ての仕様を盛り込むのも難しい。

UML2.xの状態遷移図の仕様を調べると、かなり複雑な仕様を表現する事はできる。
「H」のような履歴というモデル要素などを考えてみると、過去の人達が苦労して編み出した概念なんだな、とか分かる。

また、組込み開発のためのモデリングワンポイントレッスン：第4回：ドメインと制御の区別(前編) | 豆蔵ソフト工学ラボの記事のように、ドメインと制御の部分を区別して設計するのもかなりに熟練の業を必要とすると思う。
ユーザ側の観点ではドメインの要素しか見ないが、実際のシステム内部では、たくさんの制御装置があって、それら装置が連動して整合性が取れて初めて、システムが正常動作する。
ドメインと制御装置の依存関係、制御装置同士の関係を表現するのが難しいと思う。
どうしても、Controller部分が肥大化してしまうので、Mediatorパターンのように表現したくなるが、何となくいつもうまくいかない気がする。

【3】豆蔵さんの上記の記事はどれもとてもよく考えられている記事なので、astahでUMLをモデリングしていて、何となくしっくり来ない時に読み直している。
自分も、モデリングのパターンを整理してみたいと思う。