<< 実践 ドメインモデリング パッケージと画面の関係 | main | 実践 ICONIXプロセス ドメインモデルからユースケースへ >>

実践 ドメインモデリング 日本語と英語のマッピング

ICONIX プロセスでは「プロジェクトの用語集」から出発したドメインモデル(概念クラス図)をしだいに洗練し、詳細化し、最後は、実装クラスの自動生成という考え方。

「ユースケース駆動開発実践ガイド」の原著 "Use Case Driven Object Modeling with UML - Theory and Practice" では、最初に登場した "Book" が、Java で class Book { }まで落とし込まれていく。

日本ではどうなる?

「ユースケース駆動開発実践ガイド」では、ドメインモデリングは「書籍」で出発し、予備設計のロバストネス分析までは「書籍」。
実装設計のシーケンス図でこのオブジェクトが突然 "Book" にしている。

プロジェクトの関係者で問題領域の理解を共通にし、深めるためには、やはりモデリングは日本語でやるべきでしょう。 実装は、英語の名詞・動詞を使うことが多いと思う。Java やフレームワーク側が、クラス名もメソッド名を英語だし。

じゃあ開発プロセスのどこで日本語と英語のマッピングをするのが適切だろう。「ユースケース駆動開発実践ガイド」を翻訳した人たちも、議論があって、実装の前と後のところに線を引いたんだと思う。

でも、ラフなモデルから段階的にドメインモデル(クラス図)を成長させていく、ICONIX プロセスの考え方からすると、実装の直前で、大量の日英マッピング作業を発生させるのは実践的ではない。

最初は属性が無い状態からクラス図を書き始め、振る舞い分析(ユースケースモデリング)をしながら発見した属性を追加していく、ロバストネス分析の完了時には、75%程度の属性が定義済み、という ICONIX プロセスのガイドライン。

日英マッピングもこれと同じようなペースが良いと思う。
まず、最初の用語集(2時間で作るバージョン)は日本語だけでよい。
ここからスタートするときに、少しづつ、英語での表記を追加していく。例えば 書籍:Book のように。

英語へのマッピングは、負担が増えるけど、このマッピングをみんなでブレスト(おしゃべり)することで、モデルとみんなの理解を別の角度から検証という効果がありそう。

このやり方だと、ドメイン層のオブジェクトは、ソースコードレビューをユーザ自身ができてしまうような気がする。まあ、やる価値があるかどうかは別として。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
      1
2345678
9101112131415
16171819202122
23242526272829
3031     
<< July 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM