単にクラス図は不要であるといってしまうと、LyeeやT型と同一視されてしまうので、見解を述べておく（LyeeやT型の開発に携わったことがないので間違った認識かもしれないことをあらかじめ断っておく）。いろいろなところで講演したり、著述しているので、くどいと思うが、クラス図はER図から発展したという歴史的経緯も忘れてはならない。つまり、ER図では記述できなかった属性などを追記していった流派がオブジェクト指向プログラミングとの相性の良さからオブジェクト指向分析/設計と称した。当時はサブクラスによる継承が主流であったため、クラス図による関係の表記は有益であった。しかし、インタフェースによる継承を身上とする言語では、クラス図よりもシーケンス図の方が有益である（むろん、これはたぶんに好みの問題でもある）。
そして、もっとも重要な点は、SOAでは、モデルを業務ロジックとデータアクセスに分離していることである。業務ロジックとデータアクセスとの橋渡しをORマッピングツールに委譲するので、必要なのはクラス間の関係ではなく、メソッドに記述する「業務ロジック」とデータにアクセスするための「ルール」である(このあたりは後日詳述する)。データにアクセスするためには、クラスの属性よりもエンティティの方が扱いやすく、技法も確立されていることから、データアクセスに関しては、ER図が有益なのは議論の余地はない（あくまでRDBMSを前提とした場合）。
このあたりまでは、T型派にいわせれば、いまごろ気づいたのかと言うことになる。大事なことは、ER図を書く時期である。多くの人にとって、いきなりER図を書くことはいきなりクラス図を書くことと同様に難しい（歴史的ないきさつからクラス図が書ける人よりもER図が書ける人が多いため、ER図のほうが簡単と認識されている）。このため、ロバストネス分析のエンティティを論理設計の入力源として、ER図を書くことを提唱する。ロバストネス分析の出力を利用すると、シーケンス図とER図の整合性をチェックしやすくなる。より簡単にチェックする必要性があるならば、クラス図を作成してもよい。これは手間と品質とのトレードオフとの問題である。また、ER図が中心の開発では、動的な側面の設計に苦心していた。このためにも、ロバストネス分析を行い、シーケンス図を作成すべきである。
繰り返すが、ロバストネス分析は必須ではない。適切なER図が書けるならばこのような回り道をする必要はない。話が拡散するが、クラス図を書く前にシーケンス図を書くこと、シーケンス図を書く前にロバストネス分析を行うことを提唱しているのも同様の理由である。
ORマッピングツールを使うことによって、クラス図ベースの開発の方がよいという意見があるかもしれない。これに対しては、クラス図から(RDBMSの)データベース設計を行うのは困難であるからと反論しておく。
