astahによるモデリングのメモ

「ドメイン駆動設計」を読み直すようになってから、UMLによるモデリングをもう一度見直している。
アイデアをラフなメモ書き。

【参考】
オブジェクト指向設計の４つの流派からドメイン駆動設計へ: プログラマの思索

astah* professional 6.1の要求図: プログラマの思索

SysMLの要求図の書き方: プログラマの思索

シーケンス図とアクティビティ図と状態遷移図の関係: プログラマの思索

FP法で業務モデルを計測する: プログラマの思索

【1】僕は、UMLの各種ダイアグラムを、業務やプロセスやシステムの分析のラフなスケッチに使っている。
業務の流れ、プロセスの流れ、システムの振る舞い、システムの機能の関係を理解したい時、絵を描く方が、理解が早まる。

基本は手書きが多い。
でも、astahで描いておくと、後から何度でも修正変更できるし、ブラッシュアップできる。

UMLの利点は、1つのモデルを動的・静的な図など7種類以上の図を用いて、複数の観点で分析できることだ。
分析は、文章や表だけ書いても分からない。
文章よりも図の方が直観的で、イメージを共有しやすい。
一つのモデルをいろんな観点から徹底的に分析し、色んな性質や特徴をあげて、その整合性を見出す。

その試行錯誤が面白いし、モデルの本質が分かった時は、なるほどと思う。

【2】そのastahを使って、要求収集の工程から実装まで、一つの体系で一気通貫で設計できないか、考えている。

【参考】
実はastahを使って要求から画面作成までを一気通貫（＆自動生成）する方法の論文が無料で見れる - ウィリアムのいたずらの開発日記

組み込みソフトウェアの場合のＵＭＬ導入の問題とSysML - ウィリアムのいたずらの開発日記

ＵＭＬ以前の、システムの関連性（トレーサビリティ） - ウィリアムのいたずらの開発日記

astah*を使って、ICONIX風一気通貫システム開発　その１：概要 - ウィリアムのいたずらの開発日記

astah*を使って、ICONIX風一気通貫システム開発　その２：ユースケース - ウィリアムのいたずらの開発日記

astah*を使って、ICONIX風一気通貫システム開発　その３：ユースケースシナリオ - ウィリアムのいたずらの開発日記

astah*を使って、ICONIX風一気通貫システム開発　その４：ロバストネス分析 - ウィリアムのいたずらの開発日記

astah*を使って、ICONIX風一気通貫システム開発　その５：属性を埋める - ウィリアムのいたずらの開発日記

astah*を使って、ICONIX風一気通貫システム開発　その６：画面構成 - ウィリアムのいたずらの開発日記

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法（１） - ウィリアムのいたずらの開発日記

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法（２） - ウィリアムのいたずらの開発日記

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法（３） - ウィリアムのいたずらの開発日記

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法（４） - ウィリアムのいたずらの開発日記

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法（５） - ウィリアムのいたずらの開発日記

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法（６） - ウィリアムのいたずらの開発日記

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法（７） - ウィリアムのいたずらの開発日記

using astah for openthology modeling from Kenji Hiranabe

Astah UML/ER/mindmapping modeling tool Introduction from Kenji Hiranabe

設計手法は今までたくさん提唱されている。
構造化技法、データモデリング、プロセス指向分析(POA：別名は巻物分析)、オブジェクト指向モデリングなど。
データモデリングにも、TH法、T字形ER、渡辺式３要素分析法もあるし、オブジェクト指向モデリングにも、Rationa統一プロセス、ICONIX、アジャイルモデリングなどたくさんの流派がある。

今まで会ってきた日本のモデラーのお話を聞くと、彼らなりのモデリング技法というかスタイルを独自に持って、システムのあるべき姿を提示しようとしている。

個人的には、データモデリングも包含したオブジェクト指向モデリングができないか、探索している。
DOAもOOAもそれぞれに特徴がある。

DOAは、既存システムから仕様をリバース・エンジニアリングする時は最強の設計手法だ。
例えば、T字形ERがあげられるだろう。
既存の画面や帳票から、機能とテーブルを抽出し、CRUD図を作れば、既存システムの仕様がほぼ理解できる。
CRUD図があれば、元々の仕様を元に新たな設計書を作り出すことも可能だし、テスト仕様書にも応用できる。

OOAは、モデル間のトレーサビリティに特徴があると思う。
僕はアクティビティ図、ステートマシン図、クラス図を良く使うけれど、それらのUML図は、システムの一つの機能を複数の観点で表現したものと見なせる。
動的・静的な観点で表現する事で、モデルについてより深く考えることができる。

それら複数のUML図が一つのモデルを表現したものであるならば、それらのモデル間には相互に追跡できるということだ。
モデルのトレーサビリティがOOAではよく考えられていると思う。

【3】astahに可能性を感じるのは、複数のモデル間のトレーサビリティを補強する機能がチラホラあること。
astahでUMLの各種モデルを書いていると、ああ、こんな機能があるのか、と気付く時がある。
一つの使い方が、新たな設計手法を連想させる。

その辺りをまたまとめる。