チーム開発してみよう
チーム開発してみよう
モデリングにも今やチーム開発は必須の機能です。
astah*に用意されているチーム開発補助機能を 2 つ紹介します。

マージ機能ってどんな機能？
他の人が作成したプロジェクトを、自分のプロジェクトにマージしたい時に使います。現在のプロジェクトに別のプロジェクトをマージできます。簡単マージと、モデル毎に作業中・取込中のどちらを優先するか選択可能な詳細マージの 2 種類があります。
デモ動画：https://www.youtube.com/watch?v=EVgmuCVB3PE&feature=youtu.be[用途]•

2 つのプロジェクトファイルを 1 つにまとめる。

•同一プロジェクトの編集

2 人がそれぞれ編集した同一astah*ファイルの変更点を合わせられる。

[使用イメージ]1まず簡単マージを使ってみよう
以下のようなプロジェクトを新規作成します。ファイル名はbase.asta とします。

次に、下のようなプロジェクトを新規作成します。ファイル名を「ref.asta」とします。

base.asta を開き、[ファイル]-[プロジェクトをマージ]を選択して ref.asta を選択すると、

2

以下のようなダイアログが表示されます。

[詳細]ボタンをクリックすると、差分を表示されます。ここで、どちらのモデルを優先するかなどを細かくカスタマイズしながらマージを実行できます。

今回は、シンプルな[簡単マージ]を試しましょう。[キャンセル]ボタンを押して、前のダイアログに戻ります。

今回の例では、いずれのモデルも一方のファイルにしか存在しないため、どちらを選択しても結果は同じです。
デフォルトでは[取込中のプロジェクト]が選択されています。この選択状態のまま[了解]ボタンを押しましょう。

3ref.asta から、[ref クラス図]と[D]クラスが取り込まれましたね。

コンフリクト(衝突)の定義
astah*では、コンフリクトを下記のように定義します。
両方のプロジェクトの同じ名前空間(パッケージ)内に、同一の名前か同一 ID のモデルが存在し、変更されているケース。

astah*で作成したモデルは、全て内部的に ID を持ちます。この ID は、モデルの作成時に自動で割り振られるもので、プロジェクトファイル上では表示されません。astah*のマージ機能は、モデルの名前と、この内部 ID を基準に実行します。
従って、名前が異なるモデルであっても、内部 ID が同一の場合はコンフリクトが発生します。このケースは、ある既存ファイルを複製して作業した場合に多く見られます。このように意図しないコンフリクトを避けるには、既存のファイルを複製後、[ツール] – [モデル補正] – [全てのモデルの ID のリセット]から、全モデルの ID をリセットした上で、作業してください。

4参照プロジェクト管理って、どんな機能？
デモ動画：https://www.youtube.com/watch?v=J4kGKPJp8cI&feature=youtu.be「参照プロジェクト管理」機能は、 他プロジェクトを「読み取り専用」でインポートする機能です。これにより、インポート先のプロジェクトにおいて、変更されないことが保証された状態でインポートしたモデルを利用することができます。また、インポート元のプロジェクトでモデルが更新された場合には、その旨を検知し、インポート先のプロジェクトに反映することができます。

[使用イメージ][詳細イメージ]
参照プロジェクト機能を利用したチームモデリングの一案をPDF で公開しています。
日本語版：http://astah.change-vision.com/ja/files/astah-ref-project.pdf
英 語版：http://astah.change-vision.com/en/files/astah-ref-project-en.pdf
この参照プロジェクト機能の活用シーンは、ブログ記事もご参照ください。
https://ja.astahblog.com/2017/01/16/utilize_referene_project_more/

参照プロジェクト管理機能を使ってみよう
例えば、A さん、B さん、C さんの 3 人で共通のモデルを作成し、チーム開発する場合は、当機能を次のように使えます。
1. 共通部分のモデルを早めに確定し、「共通」というパッケージに退避し、[共通]というパッケージを持つファイルを「common.asta」として保存します。

2. ここから、3 人で共通部分を使用した開発をします
A さんが機能 A、B さんが機能 B、C さんが機能 C を担当するとします。
A さんは、a.asta を作成し、common.asta を参照する設定をします。プロジェクトに[機能A]パッケージを作成し、読み取り専用の[共通]モデルを使用しながら、モデリングします。
B さんは、b.asta を作成し、common.asta を参照する設定をします。プロジェクトに[機能B]パッケージを作成し、読み取り専用の[共通]モデルを使用しながら、モデリングします。
C さんは、c.asta を作成し、common.asta を参照する設定をします。プロジェクトに[機能 C]パッケージを作成し、読み取り専用の[共通モデルを使用しながら、モデリングします。
1. まず[ファイル] – [参照プロジェクト管理]を選択します。

2. [追加]ボタンを押します3. Common.asta を選択して[了解]を押すと、[共通]フォルダが読み取り専用として追加されます。追加されたモデルは編集できませんが、構造ツリーからドラッグ＆ドロップすることで、図上に表示できます。

この機能は、場合によっては、CVS、SVN、VSS などの構成管理ツールと組み合わせると良いかもしれません。
注意点は、構成管理ツールでチェックアウトした後のファイルのタイムスタンプは、チェックアウト時のタイムスタンプとなりますが、astah*の参照プロジェクト管理では、ファイルのタイムスタンプが変更されると更新を促されます。こういったケースのために、astah*でファイルを保存した時のタイムスタンプをasta ファイルの中に埋め込み、参照プロジェクトでモデルのタイムスタンプを使用できる機構も用意しています。モデルのタイムスタンプを使う場合は、[ツール] – [システムプロパティ]– [参照プロジェクト] – [参照プロジェクト更新時にファイルのタイムスタンプでなく、モデルのタイムスタンプを使う]のオプシ
ョンを有効にします。

モデルのタイムスタンプは、プロジェクトのプロパティビュー[バージョン履歴] – [モデルのタイムスタンプ]で確認できます。

また、コミットするときのコメントに、プロジェクトの簡易比較で出力されるテキストのモデルの DIFF を張り付けてもいいかもしれませんね。
メンバ内で作業中に共通部分に編集が必要になった場合は、common.asta を変更し、保存します。編集が終われば、メンバに通知し、それぞれのファイルを開き、common.asta を更新します。[参照プロジェクト]が更新されると、下記のようなメッセージが表示されます。

OK を押すと、参照プロジェクトの状態が[要更新]として表示されるので、[更新]ボタンを押して更新します。

A さん、B さん、C さんのそれぞれのパートのモデルが完成したら、各自のファイルから参照モデルを解除します。

その後、3 つのファイルを、取込み中プロジェクト優先でマージをして、最後に、このファイルにcommon.asta を追加して、[共通]パッケージを読み込みます。 これで、 FIX した共通モデルを使いながら、各自の担当するパートのモデルを効率的に分担して作業できました。

「参照プロジェクトを使用する上でのポイント」
・共通化にするモデルのスコープや担当を明確にし、早期に共通モデルを FIXすることが重要です。
・構成管理ツールを使用する場合は、モデルのタイムスタンプを使用しましょう。(システムプロパティで設定)