Microsoft Word - astah_tutorial.docx

1 / 153 使用バージョン:astah* 6.0, 6.1 2010/03/05 株式会社チェンジビジョン

目 次 このチュートリアルの概要 5 関連ドキュメント 5 基本操作ガイド 5 Tips（便利な使い方） 5 フィードバックについて 5 マインドマップを活用してみよう 6 マインドマップの紹介 6 マインドマップで要求分析してみよう 6 マインドマップと設計図がオールインワンでスムーズに連携できる 7 マインドマップで要求ヒアリングしよう 8 マインドマップ関連参考書籍 12 データモデリングしよう 13 ER 図を使ってみよう 14 IDEF1X、IE による ER 図を作成しよう 15 エンティティの種類について考えてみよう 16 マインドマップからエンティティへの変換をしてみよう 17 データモデリングのプロセスを使用してみよう 20 エンティティの表示レベルの設定をしてみよう 20 論理名と物理名を使ってみよう 22 ドメインを活用しよう 23 リレーションを張ってみよう 25 データ型を追加してみよう 30 エンティティ定義書を出力してみよう 31 SQL 出力（SQL-92 準拠）してみよう 34 DB リバースを使ってみよう（サンプル、サポート対象外） 38 ご利用の前に 38 予備知識 38 データベースの環境設定をしてみよう 38 astah* データベースリバースコンポーネントを使用してみよう 42 作成した asta ファイルを astah* professional で開いてみよう 45 astah* データベースリバースコンポーネントの改良について 48

CRUD を使ってみよう 49

CRUD の概要 49

SysML の概要を知ろう 78 SysML とは 78 誕生の背景 78 SysML の概要 78 SysML での各図 78 astah*での要求周りの機能の利用 80 要求 80 テストケース 80 要求テーブル 80 導出、コピー、満足、検証、洗練、トレース 81 導出<<deriveReqt>> 81 コピー<<copy>> 82 満足<<satisfy>> 82 検証<<verify>> 83 洗練<<refine>> 83 トレース<<trace>> 84 要求テーブルを使用しての要求モデリング[組み込み系サンプル]しよう 84 要求テーブルを使用しての要求モデリング[WEB 系サンプル]しよう 90 言語サポート機能を使ってみよう 98 Java 98 Java 基本機能 98 Java スケルトンコードを作成してみよう 101 Java ソースコードの読み込みをしてみよう 103 C++ 106 C++基本機能 106 C++スケルトンコードを作成をしてみよう 109 C++リバースをしてみよう（サンプル、サポート対象外） 113 C# 119 C#基本機能 119 C#スケルトンコードを作成してみよう 122

C#リバースをしてみよう（サンプル、サポート対象外） 125 構造化分析しよう 131 構造化分析とは 131 DFD(データフロー図) 132 DFD(データフロー図)を使ってみよう 133 フローチャートを使ってみよう 138 トレーサビリティマップを使ってみよう 142 納品資料としてのドキュメントを作成してみよう 144 RTF 出力してみよう 144 HTML 出力してみよう 146 便利な機能を使ってみよう 150 図上でマウスを使ってスクロール 150 編集を取り消す(UNDO) 150 モデルから図へのジャンプ 150 図からツリーへのジャンプ 151 API を使ってみよう 153 モデル参照 API 153 モデル編集 API 153 図要素参照 API 153 図要素編集 API 153 API のサンプル 153

各章は次の通りです。 y マインドマップを活用してみよう y データモデリングしよう y CRUD を使ってみよう y チーム開発してみよう y 要求を整理してみよう y 言語サポート機能を使ってみよう y 構造化分析しよう y フローチャートを使ってみよう y トレーサビリティマップを使ってみよう y 納品資料としてのドキュメントを作成してみよう y 便利な機能を使ってみよう y API を使ってみよう 関 連 ド キ ュ メ ン ト 基 本 操 作 ガ イ ド このチュートリアルと別に基本操作ガイドを用意してあります。astah*の画面構成、図やモデルの作成、図要素の 整列や色の設定など、astah*の基本的な操作を知りたい場合はそちらをご覧ください。

使用できるエディション： astah* professional、astah* UML、astah* community 日本語版:http://astah.change-vision.com/ja/tutorial/operation-guide.html

英語版: http://astah.change-vision.com/en/tutorial/operation-guide.html

TIPS

このチュートリアルと別に TIPS を用意しています。便利な使い方については、そちらを参考にしてください。 (旧 JUDE5.5 時点の Tips のため、最新の astah*とは異なる場合があります。)

使用できるエディション： astah* professional、astah* UML、astah* community http://astah.change-vision.com/ja/tutorial/tips.html

フ ィ ー ド バ ッ ク に つ い て

このドキュメントに関するフィードバックについては、下記 URL 記載のお問い合わせ先までお送りください。 http://astah.change-vision.com/ja/contact-support/contact-us.html

マ イ ン ド マ ッ プ を 活 用 し て み よ う

使用できるエディション： astah* professional、astah* UML、astah* think! astah*上でのマインドマップの活用方法、シーン、ユーザーは様々です。 ここでは、マインドマップを開発で活用する例をいくつか挙げていきます。 マ イ ン ド マ ッ プ の 紹 介

使用できるエディション： astah* professional、astah* UML、astah* think! デモ動画：http://astah.change-vision.com/ja/movie.html#mindmap キーワードを自由に入力し、枝を放射状に広げて作成するマインドマップは、アイディアを発散させ、思考を見え る化します。 会議の議事録作成やブレイン・ストーミング、プロジェクトのふりかえりなどは 職種に関わらず利 用することができ、ソフトウェア開発においては顧客要求の聞き取りやテストケースの洗い出しといった工程に合 わせた活用が可能です。 考えを整理する時、発想を生み出す時、思考を妨げることなくスムーズにグラフィカルな ノートを作成できます。 (*マインドマップは、英国 Buzan Organisation Ltd.の登録商標です。) マ イ ン ド マ ッ プ で 要 求 分 析 し て み よ う

使用できるエディション： astah* professional、astah* UML

マ イ ン ド マ ッ プ と 設 計 図 が オ ー ル イ ン ワ ン で ス ム ー ズ に 連 携 で き る astah*では、マインドマップと UML や ER 図などの設計用の図が１つのツールに入っていることより、互いの図要 素に簡単に変換でき、要求分析から設計までスムーズに移行できます。 マインドマップのトピックを、UML モデル（クラス、ユースケース、その他）に変換できます。 構造ツリーから UML 図へのドラッグ＆ドロップで変換でき、変換された UML クラスへはハイパーリンクを自動で追加することも 可能です。 UML モデルからマインドマップのトピックへの変換もドラッグにより可能です。

マ イ ン ド マ ッ プ で 要 求 ヒ ア リ ン グ し よ う [収集] マインドマップは極めてシンプルなフォーマットから成り立っていますが、アイディアを発散することに長けてお り、議事録や要求の収集に向いていると言えます。顧客との打合せで会話しながら PC をおもむろに開き、astah* で要求をどんどんメモしておきましょう。このシーンでは、ラフで柔らかい、曖昧なアイデアを羅列しておくだけ にとどめます。特に、顧客の何気ないつぶやきや非機能要件など見落としがちな発言もどんどん書いていきましょ う。astah*では様々なマインドマップテンプレートも用意されており、このケースでは以下のテンプレートファイ ルを使うと良いでしょう。 astah* インストールフォルダ¥template¥mindmap¥UserRequirement.asta また、テンプレート自身を変更したい場合であれば、編集して自分用のテンプレートにすることもできます。 [整理・分析] 一方、開発用の各図(UML、ER 図など)の最終形モデルである実装モデルは、厳格でカチッとしており、要求から実 装モデルはこの段階では距離があります。したがってマインドマップで書かれた仕様を整理、分析し、モデリング の材料として利用してみると、モデリングの曖昧なところが見えてくるはずです。そのマインドマップを会議室に 持ち込みプロジェクタに映しながら、要求やモデルで曖昧な点を議論するのもよいでしょう。 こうすることでメンバー間のコミュニケーションの促進や待ち時間の削減に貢献できるでしょう。 [構築] 曖昧なところが明確になってくれば、それを分析モデル→設計モデル→実装モデルへと具体化してきましょう。

整理・分析・構築の例(マ イ ン ド マ ッ プ か ら ユ ー ス ケ ー ス 図 へ の 変 換 )

例えば、マインドマップで市の図書館システムの要求ヒアリングをし、それをユースケース図にする例を挙げます。 同様の内容を動画でも参照できます。

デモ動画：http://astah.change-vision.com/ja/movie.html#mindmap-to-usecase なぜ？誰が？どこで？について以下のようにヒアリングしました。

astah*の特徴としてマインドマップのトピックに UML などのアイコンを追加することができます。

ここでは、Who の項目に挙げた人に対して UML のアクターアイコン、When の項目に挙げた機能的要求に対して UML のユースケースアイコンを付加しました。こうすることで、ビジュアル面での恩恵を受けるだけでなく、構造 ツリーのトピックから他の図(たとえばユースケース図)へドラッグアンドドロップしたときに、変換したいモデル の種類がデフォルトで選択されるという利点があります。 さて、トピックからユースケース図を作ってみましょう。メニューから、空のユースケース図を作成します。 次にマインドマップのトピックからアクターを作成します。 構造ツリーでマインドマップの Who 配下のトピックを選択し、ユースケース図にドラッグアンドドロップします。 ダイアログで種類がアクターになっていることを確認して OK ボタンをクリックします。

次にトピックからユースケースを作成したいと思います。

構造ツリーでマインドマップの When 配下のトピックをユースケース図にドラッグアンドドロップします。 ダイアログで種類がユースケースになっていることを確認して OK ボタンをクリックします。

以下のようにユースケースができました。 後は、ユースケース図で関係を記述します。 このようにマインドマップを経由して設計するとコミュニケーションも活発になり、曖昧な点やモレがなくなり、 開発がスムーズに進むはずです。 マ イ ン ド マ ッ プ 関 連 参 考 書 籍 ソフトウェア開発におけるマインドマップの活用法について、次の書籍も参照ください。 「ソフトウェア開発に役立つマインドマップ」日経 BP 社 平鍋健児著 ブ ロ グ 記 事 : h t t p : / / b l o g s . i t m e d i a . c o . j p / h i r a n a b e / 2 0 0 7 / 0 5 / p o s t _ 8 9 3 a . h t m l

す 。 オ ブ ジ ェ ク ト 指 向 至 上 主 義 で も 、 デ ー タ モ デ リ ン グ 至 上 主 義 で も 、 現 実 の 開 発 は う ま く 行 き ま せ ん 。オ ブ ジ ェ ク ト 指 向 言 語 と 、リ レ ー シ ョ ナ ル デ ー タ ベ ー ス を つ な ぐ の は 、 D A O や H i b e r n a t e の よ う な パ タ ー ン や ツ ー ル を 使 う こ と も あ り ま す が 、 逆 に 、 こ れ ま で 蓄 え ら れ た 業 務 モ デ リ ン グ の 知 見 を 利 用 し な が ら オ ブ ジ ェ ク ト 指 向 設 計 を す る こ と も 可 能 で す。

クラス図（分析）

クラス図（設計）

物理データモデル

論理データモデル

オブジ

ェ

クト指向開発

デー

タ

モ

デ

リ

ング

ER 図 を 使 っ て み よ う 使用できる製品: astah* professional デモ動画：http://astah.change-vision.com/ja/movie.html#er-diagram ER 図の IDEF1X と IE の両記法をサポート。「リソース」、「イベント」、「サマリー」のエンティティカテゴリ や、 階層的な「ドメイン」の活用（エンティティにドラッグ＆ドロップできます）、論理・物理名の交換、SQL 出力などに対応しています。 マインドマップ、UML 図要素、データフロー図要素から ER エンティティへの変換、 又はその逆の連携も実現しています。 astah* の ER 図の主な機能は以下の通りです。 y IDEF1X、IE による ER 図の作成 y エンティティ定義書出力 y DB リバース（API 利用アプリケーションサンプル、サポート対象外） y マインドマップからエンティティへの変換 y SQL 出力（SQL-92 準拠） y ドメインの対応 y 表示レベル y 物理名の対応

エ ン テ ィ テ ィ の 種 類 に つ い て 考 え て み よ う 使用できる製品: astah* professional エンティティとは、システム(データベース)の管理対象となりうるもので人、モノ、イベント、履歴などがありま す。エンティティには、リソース系、イベント系、サマリー系などがあり、以下のように分類されます。 エンティティ種別 主な例 リソース系 会社、顧客、商品、製品、工場、カネなど。 イベント 会員登録・変更・削除、発注、出荷など。 サマリー系 購入履歴、出荷履歴など。 エンティティの抽出のコツがあり、以下の手順を踏むのもよいでしょう。 (1)エンティティ候補をヒト、モノなどのカテゴリーで抽出(マインドマップで行うのもよい。) ・そこから、リソース系エンティティの抽出 (2)業務フローを書く。(フローチャートや DFD、アクティビティ図で)行うのもよい。 ・そこから、イベント系エンティティの抽出 また、astah*ではエンティティのプロパティビューから、リソース系、イベント系、サマリー系の指定や、[シス テムプロパティ]-[新規 ER エンティティの型の色]で系統ごとに色の指定もできるので、ER 図を書いてモデリング するときに利用すると便利です。

マ イ ン ド マ ッ プ か ら エ ン テ ィ テ ィ へ の 変 換 を し て み よ う 使用できる製品: astah* professional

マインドマップでエンティティ抽出のために、以下のようなテンプレートを用意するのもよいでしょう。

また、エンティティ候補には ER エンティティのアイコンも付加してみました。

さて新規 ER 図を作成し、構造ツリーでこのマインドマップのトピックを図にドラッグアンドドロップしてみます。 事前に図の表示レベルをエンティティにしておくとよいでしょう。(詳しくは次の章で説明します。)

次にリソース系、イベント系、サマリー系を設定してみます。

システムプロパティの色が設定されていることがわかりますね。

色付けすることにより、コミュニケーションも容易になり、より分かりやすくなります。 あとは続けて属性やリレーションシップの設計などを行い、設計をつめていくとよいでしょう。

デ ー タ モ デ リ ン グ の プ ロ セ ス を 使 用 し て み よ う データモデリングのプロセスの流れは、次の図のように、分析、設計、実装フェーズで、論理データモデルから物 理データモデルを作成するのが主流です。 出典：アーキテクタス 細川努 「UML による一気通貫 DB システム設計」 エ ン テ ィ テ ィ の 表 示 レ ベ ル の 設 定 を し て み よ う 使用できる製品: astah* professional astah*では、図の表示レベル(エンティティ、主キー、属性)を設定でき、これらのプロセスに則ったデータモデリン グが可能です。論理よりではエンティティレベルで、物理モデルに近づくにつれて主キーレベル、属性レベルで設 計するとよいでしょう。操作方法は、ER 図のプロパティビューから表示レベル(初期設定)で変更します。 ちなみにこの操作は対象の ER 図で新規作成 ER エンティティから表示設定が反映されます。既存の ER エンティ ティの表示レベルを変更したい場合は、ER エンティティのポップアップメニューから変更してください。 まず、エンティティレベルで設計してみます。エンティティとなりうるモデルを抽出するにとどめておきます。

続いて主キーレベルで設計します。リレーションを張っていってよいでしょう。

論 理 名 と 物 理 名 を 使 っ て み よ う 使用できる製品: astah* professional astah*ではエンティティや属性などに論理名と物理名の両方を設定でき、データモデリングのプロセスをサポート します。論理データモデリングでは、エンティティの論理名に”顧客”とつけ、物理データモデリングではテーブル 命名規則に則り、物理名を”CUSTOMER”にするようなことができます。 エンティティだけでなく属性にも物理名を設定できますし、SQL 出力では、論理名、物理名での出力が可能です。 論理モデル、物理モデルの切り替えは ER 図のプロパティビューのモデルタイプから行います。 まず、[論理モデル]で設計します。各エンティティや属性、リレーションについて概念を詰めていきます。

ド メ イ ン を 活 用 し よ う 使用できる製品: astah* professional ドメインとは、データの型や値／範囲を取り決めるディクショナリのことで、複数のエンティティの属性から設定 できます。ドメインを使用したデータモデリングは、システムの内のデータの不統一や不整合をなくすことができ、 データモデリングの中でも重要なプロセスです。例えば、クレジットカード番号にハイフンを含めるか含めないか で CHAR(12)に設計する人や CHAR(15)で設計する人が、ドメインを使用することでこのようなテーブル設計のミ スをなくすことが可能です。 また、ドメインを使用していることで、後から属性の長さを変更しても、参照先のエンティティに反映されるなど 仕様変更に強い設計になります。astah*では階層的なドメインの機能も兼ね備えています。構造ツリーのドメイン のポップアップメニューから追加できます。階層的に作成した場合、親の型や長さ等を引き継ぎますが、子側で型 や長さの変更も可能です。 ドメインのグルーピングの仕方は、その設計者の自由に取り決めていいですが、業務に依存しない共通的なドメイ ンは”共通”、業務に依存するドメインは”固有”や”業務”としておくのもいいでしょう。

下の例は、”共通”ドメインでいくつかドメインを設計した結果です。

また、作成したドメインを ER エンティティにドラッグアンドドロップすることもできます。

リ レ ー シ ョ ン を 張 っ て み よ う 使用できる製品: astah* professional 以下のようなモデルを作成してみましょう。 （例１） 【会社マスタ】 【会社階層】 会社コード(PK) 上位会社コード(FK) 会社名称 下位会社コード(FK) まず、２つの ER エンティティ” 会社マスタ”,”会社階層”を作成します。

ER エンティティ“会社マスタ”に、主キー”会社コード”、属性”会社名称”を追加します。

ER エンティティ“会社マスタ”から ER エンティティ”会社階層”に非依存型リレーションシップを引きます。

新しく引いた非依存型リレーションシップを選択し、プロパティビューの“キー”タブを開きます。

上位会社コード_0(new)を選択します。

これを“下位会社コード”にリネームします。

これでリレーションも含めたモデルを作成できましたね。

[リレーションシップ作成時のポイント]

親子間で複数のリレーションシップを張り、子エンティティ側の FK を異なる属性にしたい場合は、リレーシ ョンシップの“キー“タブを使用します。

デ ー タ 型 を 追 加 し て み よ う 使用できる製品: astah* professional astah*では、デフォルトでは以下のデータ型が定義されています。 ([ツール]-[ ER 図]-[ER データ型の設定]、 もしくは構造ツリー上の ER モデルのポップアップメニューから” ER データ型の設定”を選択。) この一覧にないデータ型も追加でき、長さや精度を設定できます。 [物理モデル作成時のポイント] 論理モデル作成後、物理モデル作成前に、固有の DB を使用し、astah*デフォルトのデータ型で不十分な場合、 先にデータ型を設定しておくと、物理モデルの属性の型を考慮するときにスムーズにモデリングできます。

[ツール]-[ER 図]-[エンティティ定義書のエクスポート]を選択します

出力ダイアログが表示されます。テンプレートはプロジェクト固有のテンプレートにも変更できます。 新しいテンプレートボタンをクリックしてみましょう。

以下のようにテンプレートを編集できます。 [ドメイン一覧] [エンティティ一覧] [エンティティ定義] 新しいテンプレートボタンをクリック後、了解ボタンクリックでテンプレートが作成されます。 そのファイルを開いてみましょう。

$each_domain など$から始まるものは、次のようにマッピングされます。 タブのドメイン一覧 - $each_domain タブのエンティティ一覧 - $each_entity タブのエンティティ名 - $each.entity.logical_name システム名 - $system.name No. - $each.row_number ドメイン名 - $each.domain.logical_name ドメインの物理名 - $each.domain.physical_name ドメインの別名１ - $each.domain.alias1 ドメインの別名２ - $each.domain.alias2 ドメインのデータ型 - $each.domain.type ドメインの長さ/精度 - $each.domain.length_precision ドメインの NotNull フラグ - $each.domain.notnull ドメインの親ドメイン - $each.domain.parent ドメインの定義 - $each.domain.definition エンティティの論理名 - $entity.logical_name エンティティの物理名 - $entity.physical_name エンティティの別名１ - $entity.alias1 エンティティの別名２ - $entity.alias2 エンティティの型 - $entity.kind

エンティティの定義 - $entity.definition エンティティのタグ付き値 - $entity.each.tagged_value.value 属性の論理名 - $each.entity.each.attribute.logical_name 属性の物理名 - $each.entity.each.attribute.physical_name 属性のドメイン名 - $each.entity.each.attribute.domain 属性の主キーフラグ - $each.entity.each.attribute.pk 属性の外部キーフラグ - $each.entity.each.attribute.fk 属性の NotNull フラグ - $each.entity.each.attribute.notnull 属性の参照先 - $each.entity.each.attribute.ref 属性のデータ型 - $each.entity.each.attribute.type 属性の長さ/精度 - $each.entity.each.attribute.length_precision 属性の初期値 - $each.entity.each.attribute.initial_value 属性の定義 - $each.attribute.definition 属性のタグ付き値 - $each.entity.each.attribute.each.taggedvalue 次にデフォルトのテンプレートで出力してみましょう。

[ツール]-[ER 図]-[SQL 出力]を選択します。

次のようなオプションを設定できます。

DB リ バ ー ス を 使 っ て み よ う （ サ ン プ ル 、 サ ポ ー ト 対 象 外 ） 使用できる製品: astah* professional 本アプリケーションは astah* 編集 API のサンプルのため、サポート対象外です。不具合報告やお客様の実行環境 （DB、JDBC ドライバー等）に関連したご質問、各種お問い合わせには、対応できない場合がありますのでご了承 ください。 WEB サイトにも同じ内容の記事を掲載してあります。 http://astah.change-vision.com/ja/feature/db-reverse.html

astah* DB リバースツールは、ER 図に関連するモデルの編集 API のサンプルとして作成されました。DB リバース ツールを使うことで、DB に接続後、astah* モデルへ変換できます。

既存のデータベースにアクセスして、現状のテーブル設計を容易に見える化できます。

ご 利 用 の 前 に

astah* インストールフォルダ配下にある astah* API サンプルプログラム使用許諾契約 （ 「API_sample_program_license_agreement.txt」）を必ずお読みください。

予 備 知 識

astah* professional では、JDBC ドライバを利用してデータベースのテーブル定義を astah* プロジェクトへ変換 します。 JDBC ドライバは各データベースやサードパーティなどから提供されており、別途ダウンロードする必要 があります。 また、データベースの環境については各自で作成してくださいますようお願い致します。 デ ー タ ベ ー ス の 環 境 設 定 を し て み よ う ここでは確認用のデータベースを HSQLDB として、データベース環境を構築し、テーブルを作成する方法を解説 します。 既に存在しているデータベースから定義を読み込む場合は、この手順は不要です。 1. HSQLDB の ダ ウ ン ロ ー ド 次の URL から最新版の「hsqldb_1_8_0_9.zip」をダウンロードします。 http://hsqldb.org/ 2 .HSQLDB デ ー タ ベ ー スのイ ンス トール 事前に Java をインストールしてください。次に「hsqldb_1_8_0_9.zip」を解凍します。今回の例では、 「C:¥hsqldb_1_8_0_9」配下に解凍します。 3 .HSQLDB デ ー タ ベ ー ス の 起 動 コマンドプロンプトから以下を入力してください。 cd C:¥ hsqldb_1_8_0_9¥hsqldb¥data

java -cp ..¥lib¥hsqldb.jar org.hsqldb.Server -database TEST

4. HSQLDB DatabaseManager の起動

コマンドプロンプトから以下を入力してください。

cd C:¥ hsqldb_1_8_0_9¥hsqldb¥data java -cp ..¥lib¥hsqldb.jar org.hsqldb.util.DatabaseManager

次の画面で、Type を「HSQL Database Engine Server」に変更し、デフォルトの設定で「OK」を押下します。

5. HSQLDB DatabaseManager から SQL を実行

次の画面で右のテキストエリアに SQL 文を入力します。

DRO TABLE A IF EXISTS; DROP TABLE B IF EXISTS;

DROP TABLE C IF EXISTS;

CREATE TABLE A (

ID INT NOT NULL PRIMARY KEY, Name VARCHAR(10)

);

CREATE TABLE B (

ID INT NOT NULL PRIMARY KEY, Name VARCHAR(10),

FOREIGN KEY (ID) REFERENCES A (ID) );

CREATE TABLE C ( ID INT,

Name VARCHAR(10),

FOREIGN KEY (ID) REFERENCES A (ID) );

「Execute」ボタンを押下すると次のような表示になります。メニューの[View]-[Refresh Tree]を実行します。

テーブル A、B、C ができます

6. HSQLDB DatabaseManager の終了

ASTAH* デ ー タ ベ ー ス リ バ ー ス コ ン ポ ー ネ ン ト を 使 用 し て み よ う 1. astah* データベースリバースコンポーネントの起動 「astah インストールフォルダ\api\sample\db_reverse\run.bat」をダブルクリックします。 （例： C:\Program Files\astah-professional\api\sample\db_reverse\run.bat） 次のような画面が表示されます。 2. astah* データベースリバースコンポーネントの設定 HSQLDB の場合、次のように入力し、「Connect」ボタンを押下します。 [URL] jdbc:hsqldb:hsql://localhost [User] sa [Password] なし [JDBC Driver] org.hsqldb.jdbcDriver

[Driver path] C:¥ hsqldb_1_8_0_9¥hsqldb¥lib¥hsqldb.jar [Target Model] C:¥ result.asta

3. astah* データベースリバースコンポーネントでデータベースに接続 「Import」ボタンが有効になりますので押下します。

参考： 一部のエンティティのみを表示する ER 図を作成する場合は、新しい ER 図を作成後、構造ツリーで必 要なエンティティを選択して、ER 図にドラッグ＆ドロップします。

3. 型と長さを表示します

Ctrl＋A で図要素をすべて選択し、右クリックで表示されるポップアップメニューから [型と長さの表示]-[オン]を実行します。

4. 全図要素の自動レイアウトを実行します

astah* の上部メニュー、[整列]-[全図要素の自動レイアウト]を実行します。

5. 拡大表示します

A、B、C のテーブル、主キー、属性、依存型リレーションシップ、 非依存型リレーションシップが作成されていることが分かります

。

ASTAH* デ ー タ ベ ー ス リ バ ー ス コ ン ポ ー ネ ン ト の 改 良 に つ い て 1.【astah* API サンプルプログラム使用許諾契約】

お使いになる前に、astah インストールフォルダにある「API_sample_program_license_agreement.txt」を必ず お読みください。

2. ソースコードについて

次のフォルダに Java + astah* API で実装されたソースコードがあります。 astah インストールフォルダ\astah-professional\api\sample\db_reverse\*.java （例: C:\Program Files\astah-professional\api\sample\db_reverse\*.java ） 3. ソースコードの編集について 【astah* API サンプルプログラム使用許諾契約】に記載されているように、ソースコードを編集し機能を改良 して利用できます。ただし、astah* API サンプルプログラムの著作権や知的財産権は、株式会社チェンジビジョ ンに帰属します。 詳しくは【astah* API サンプルプログラム使用許諾契約】をご参照ください。 4. バッチによる簡単なコンパイルについて astah インストールフォルダ\astah-professional\api\sample\db_reverse\compile.bat （例:C:\Program Files\astah-professional\api\sample\db_reverse\compile.bat ） にてコンパイルできます。 5. Eclipse 等でのコンパイルについて

astah* データベースリバースコンポーネントは、astah* の API （astah-api.jar）を使用して作成されています。 そのため、以下を CLASSPATH に設定する必要があります。 インストールフォルダ\astah-professional\astah-api.jar （例:C:\Program Files\astah-professional\astah-api.jar ） 起動する場合は、astah の jar（astah-pro.jar）が必要なため、CLASSPATH に追加してください。 インストールフォルダ\astah-professional\astah-pro.jar （例:C:\Program Files\astah-professional\astah-pro.jar）

CRUD とはリレーショナルデータベース上で、どのデータに対して、どのプロセスが、生成(Create)、読み込み(Read)、 更新(Update)、削除(Delete)されるかを表す表形式のマトリックスです。 astah* の CRUD では、縦軸がプロセスで、ユースケース図(ユースケース)、アクティビティ図(アクション)、フロ ーチャート(フロー要素)、DFD(プロセス)を選択し、横軸がデータで、クラス図(クラス)、ER 図(ER エンティティ) を選択できます。それぞれ、縦軸、横軸を設定後、C、R、U、D の状態を記述し、分析することができます。 astah* の CRUD の主な機能は以下の通りです。 ・CRUD の生成、編集 ・CRUD に表示したい図を、構造ツリーからドラッグ&ドロップで追加 ・CRUD から構造ツリーの図やモデルへジャンプ ・CRUD のモデル軸、機能軸から図を開く ・図から CRUD へジャンプ ・CRUD の Excel 出力 ・全ての CRUD 統計レポートを Excel 出力 ・CRUD のテキストコピー CRUD 分 析 の 利 点 を 考 え よ う

データモデリングの世界では、CRUD 分析は大変重要かつ有効といわれています。 CRUD 分析は、テーブル設計段階の考慮モレや矛盾を早期に発見できる手立てとなりうるものです。 結合テスト段階での DB マイグレーション時のトラブル、マスタの登録処理抜け、スタブテストデータの削除忘れ、 データの二重登録、さらにはテーブル設計の問題により、特定のテーブルへの過剰な負荷による非機能要件である レスポンス問題、再度正規化やテーブル分割を余儀なくされるなどのリスクを軽減できます。 開発が大詰めの段階では、大量のビジネスロジックを抱えて、初期に引きずったテーブル設計を変更するのは容易 ではありません。CRUD 分析をプロジェクトに合わせた運用で適用して行くのもいいかもしれませんね。 CRUD 分 析 し て み よ う それでは astah*を実際につかって CRUD 分析してみましょう。 ここからは本のオンラインショッピングの例を示してみます。いつものようにマインドマップで軽い要求分析をし てみました。登場しうる簡単なモデルと機能を挙げています。 作成したマインドマップを利用し、 構造ツリーの User、Book、Cart トピックを新規作成したクラス図にドラッグアンドドロップします。

以下のようにクラスが作成されました。

このクラス図を ER 図に変換してみます。構造ツリーのクラス図のポップアップメニューから”ER 図に変換”を選択 します。

作成した ER 図にリレーションを張るなどして洗練させます。

作成したマインドマップを利用し、構造ツリーの Login、Adjustment、Put in cart、New Registration、Logout トピ ックを新規作成したユースケース図にドラッグアンドドロップします。

以下のようにユースケースが作成されました。

さて作成した ER 図、ユースケース図を利用して CRUD 分析できる材料がそろいました。 メニューから CRUD を作成します。

作成した ER 図、ユースケース図を設定してみます。

現段階で、考えられる C、R、U、D を設定します。

セルを直接選択し、C キー、R キー、U キー、D キーで ON/OFF を設定できます。

このように astah*では、UML、ER 図、業務フローを利用しながら、CRUD 分析の材料とすることができ、分析・ 設計間の考慮モレを CRUD 分析によって低減できると思います。

前章で作成した CRUD を Excel ファイルとして出力することも可能で、レビューや納品資料としても使用できます。 [ツール]-[CRUD]-[CRUD を Excel ファイルに出力]を選択します。

出力ダイアログが表示されます。

全 CRUD 統計リポートも出力できますから、全体を俯瞰してレビューしたい際に利用してみるのもよいでしょう。 （ [ツール]-[CRUD]-[全 CRUD 統計リポートを Excel ファイルに出力]）

チ ー ム 開 発 し て み よ う

モデリングにも今やチーム開発は必須の機能です。

astah*に用意されている二つのチーム開発の補助機能を紹介します。 マ ー ジ 機 能 っ て ど ん な 機 能 ？

使用できるエディション： astah* professional、astah* UML、astah* think! デモ動画：http://astah.change-vision.com/ja/movie.html#merge 他の人が作成したプロジェクトを、自分のプロジェクトにマージしたい時に使います。現在のプロジェクトに別の プロジェクトをマージできます。 簡単マージ、モデルごとに作業中・取込中のどちらを優先するか選択可能な詳 細マージ(pro,UML のみ)があります。 [用途] ・二つのプロジェクトファイルを一つにまとめる。 ・同一プロジェクトの編集 二人の人がそれぞれ編集した同一 astah*ファイルの変更点を合わせられる。 [使用イメージ]

以下のようなプロジェクトも新規作成してみます。

(新規作成することで base プロジェクトのモデルの内部 ID と同一になることがありません。) ファイル名は ref.asta です。

base.asta を開き、[ファイル]-[プロジェクトをマージ]を選択し、ref.asta を選択します。 以下のようなダイアログが表示されます。

“詳細”ボタンをクリックすると、差分が表示されます。 マージの結果を細かくカスタマイズしたい場合、この画面でどっちを優先させるか選択することができます。 まずは簡単マージするので、“キャンセル”ボタンで前の画面に戻ります。 ダイアログの説明に“一方に存在する要素は全てマージします。それ以外の要素は、以下のプロジェクトの要素を 優先してマージします。”とあります。この場合のマージでは、全て一方に存在する要素にあたりますので、“作 業中のプロジェクト”を選択しても、“取り込み中のプロジェクト”を優先しても全てマージされます。ひとまず “取り込み中のプロジェクト”を選択して“了解”ボタンをクリックします。

ref.asta のみに存在していた“ref クラス図”と“D”クラスが取り込まれましたね。 次は、コンフリクトがあるケースを説明していきます。

コンフリクト(内部 ID 衝突)あるケース

以下のようなプロジェクトを新規作成します。ファイル名は base.asta とします。

さらにこのプロジェクトの“”、“”、“”を削除し、“B”を“D”に名前変更します。

(この操作により、base プロジェクトの B クラスと ref プロジェクトの D と内部 ID が同一になります。)

base.asta 開き、[ファイル]-[プロジェクトをマージ]を選択し、ref2.asta を選択します。 以下のようなダイアログが表示されます。

要素が異なる理由が“名前が異なっています”になっていて、作業中の要素が“B”、取込む要素が“D”になって います。これはどういうことでしょうか？ “簡単マージ“ダイアログの説明に“一方に存在する要素は全てマージします。それ以外の要素は、以下のプロジ ェクトの要素を優先してマージします。”とあります。このケースは、作業中プロジェクト、取込み中プロジェク トの両方に同じモデルがあり、どちらかを優先させるか決めなければならないコンフリクト（変更の衝突）です。 astah*では各モデルに内部 ID を保持しており、コンフリクトの定義は、内部 ID が同じか同じ名前空間で名前が同 じものが変更されたことを意味しています。 コンフリクトの定義： 両方のプロジェクトに同じ名前空間(パッケージ)で同じ名前か同じ内部 ID のものが存在し、変更されているケース。 このケースでは同じ内部 ID のコンフリクトと言えます。内部 ID は、モデルの新規作成時、例えばクラスを作成し たときに割り振られます。また、astah＊がもつ内部の ID は衝突がないことを前提としています。そのため、ID の 生成も注意して衝突しないようにしています。内部 ID は複数の人が複数のパソコンで同時に編集したモデルであっ ても、別々になるように生成されます。 では、“簡単マージ“ダイアログで”取込み中プロジェクト”を優先でマージします。 クラス“B”が“D”になっていますね。

[マージ機能のポイント] このようにマージする際は、内部の ID と名前の衝突するコンフリクトに気をつけモデリングすることで、複 雑なマージをよりスムーズにすることができます。 では、“簡単マージ“ダイアログで” 作業中プロジェクト”を優先でマージします。 クラス“B”はそのままですね。 コンフリクト(名前衝突)があるケース 以下のようなプロジェクトを新規作成します。ファイル名は base.asta とします。

以下のようなプロジェクトも新規作成します。

(新規作成することで base プロジェクトのモデルの内部 ID と同一になることがありません。) ファイル名は ref3.asta です。

base.asta を開き、[ファイル]-[プロジェクトをマージ]を選択し、ref3.asta を選択します。 以下のようなダイアログが表示されます。

“詳細”ボタンをクリックします。コンフリクト(内部 ID 衝突)があるケースと異なる結果が表示されています。 要素が異なる理由が“名前が同じですが異なるモデルです”になっていて、作業中の要素が“C”、取込む要素が “C”になっています。コンフリクト(内部 ID 衝突)のあるケースと異なり、名前が同じだが内容が異なるケースで す。(内部 ID も異なる。)つまり、同じ名前空間(パッケージ)で同じ名前のコンフリクトと言えます。 では、“簡単マージ“ダイアログで”取込み中プロジェクト”を優先でマージします。 クラス“C”が取込み中の“C”になっていますね。(ref3.asth の C クラスの定義に ref が入っています。)

コンフリクト(内部 ID 衝突)あるケースと同様に、内部の ID と名前の衝突するコンフリクトに注意してモデリング することで、複雑なマージをより簡単にできます。 図のマージでの注意点を押さえておこう astah*のマージでは、図に対して完全にマージする図と、図を”取込み中プロジェクト”もしくは” 作業中プロジェク ト”から選び、一方の内容に置き換えられる図がありますので、このルールを理解したうえでマージされると上手に マージできるでしょう。 図名 マージルール クラス図 マージ ユースケース図 マージ ステートマシン図 作業中、取込み中の一方に置換 アクティビティ図 作業中、取込み中の一方に置換 シーケンス図 作業中、取込み中の一方に置換 コミュニケーション図 作業中、取込み中の一方に置換 コンポーネント図 マージ 配置図 マージ 合成構造図 マージ フローチャート 作業中、取込み中の一方に置換 データフロー図(DFD) 作業中、取込み中の一方に置換 ER 図 マージ CRUD 作業中、取込み中の一方に置換 マインドマップ 作業中、取込み中の一方に置換

要求テーブル 作業中、取込み中の一方に置換

トレーサビリティマップ 作業中、取込み中の一方に置換

にあるモデルを読み取り専用のモデルにする機構です。 参照先のファイルのタイムスタンプかモデルのタイムスタンプが変更されれば、参照元から更新ができます。 (タイムスタンプの設定については、[ツール]-[システムプロパティ]-[プロジェクトのマージ]-[参照プロジェクト更新 時にファイルのタイムスタンプでなく、モデルのタイムスタンプを使う] (デフォルトは OFF) で設定が選択できます。) 参照されているファイルを編集後保存すると、参照元ファイルを開いた時に、更新を促される MSG が表示された り、[ファイル]-[参照プロジェクト管理]で表示されるダイアログで、対象のファイルが”要更新”となります。 [使用イメージ] [詳細イメージ] 参照プロジェクト機能を利用したチームモデリングの一案を PDF で公開しています。 日本語版 http://astah.change-vision.com/ja/files/astah-ref-project.pdf 英語版 http://astah.change-vision.com/en/files/astah-ref-project-en.pdf 参 照 プ ロ ジ ェ ク ト 管 理 を 使 っ て み よ う

例えば、以下の手順でプロジェクト分割すると、スムーズにマージすることができます。 (A さん、B さん、C さんの 3 人で共通のモデルを作成し、チーム開発する例) 1. 共通部分のモデルを早めに確定し、“共通”などとするパッケージに退避する。これを common.asta とする。 (例えば、クラスと属性、操作、ER ドメインと、ER エンティティと属性) 2. ここから、3 人で共通部分を使用した開発をします A さんが、機能 A、B さんが機能 B、C さんが機能 C を担当するとします。

A さんは、a.asth を作成し、common.asta を参照する設定をします。プロジェクトに”機能 A”パッケージを作成 し、読み取り専用の”共通”モデルを使用しながら、モデリングします。

B さんは、b.asth を作成し、common.asta を参照する設定をします。プロジェクトに”機能 B”パッケージを作成 し、読み取り専用の”共通”モデルを使用しながら、モデリングします。

C さんは、c.asth を作成し、common.asta を参照する設定をします。プロジェクトに”機能 C”パッケージを作 成し、読み取り専用の”共通”モデルを使用しながら、モデリングします。

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

[ツール]-[システムプロパティ]-[プロジェクトのマージ]-[参照プロジェクト更新時にファイルのタイムスタンプ でなく、モデルのタイムスタンプを使う](デフォルトは OFF) モデルのタイムスタンプは、プロジェクトのプロパティビュー”バージョン履歴“の”モデルのタイムスタンプ” で確認できます。 また、コミットするときのコメントに、プロジェクトの簡易比較で出力されるテキストのモデルの DIFF を張 り付けてもいいかもしれませんね。 4. メンバ内で作業中に共通部分に編集が必要になった場合は、common.asta を変更し、保存します。 編集が終われば、メンバに通知し、それぞれのファイルを開き、common.asta を更新します。

5. 最後に A さん、B さん、C さんのモデリングが確定したら、参照モデルを解除し、それぞれを a2.asta、b2.asta、 c2.asta として保存します。

最終成果物として a2.asta を fixed.asta として保存します。b2.asta、c2.asta を取込み中プロジェクト優先で簡 単マージします。

最後に、fixed.asta から common.asta を参照します。“共通“パッケージ配下が読み取り専用のアイコンが表 示されています。

要 求 を 整 理 し て み よ う SYSML の 概 要 を 知 ろ う

SYSML と は

Systems Modeling Language の略で OMG（Object Management Group）によって策定されたハードウェアも含め たシステム全体を記述するためのモデリング言語です。 誕 生 の 背 景 特に組み込み分野でのハードウェアも含めたモデリングにおいて、従来のモデリング手法では問題点を抱えたまま でした。特に、分析・設計において有効とされていた UML においても、仕様策定時には想定していなかった領域 での問題や仕様の曖昧さ、表現力の不足といった問題が指摘されるようになりました。また、UML はあくまでソフ トウェアを分析・設計する表記法で、ハードウェアなどは対象外でした。UML の配置図など一部ハードウェアを表 現可能なものもありますが、ソフトウェアからの観点であり、ハードウェアそのものを表現できず、表現力の拡張 が望まれていました。それを打破するべく OMG により SysML が策定され今日に至り、最新の仕様書は 1.1 です。 (2009 年 10 月 29 日現在) SYSML の 概 要 SysML は、図のように UML 2 を拡張した仕様になっています。

SysML は、UML2 の全ての仕様を包含しているのではなく、一部は SysML 独自の仕様となっています。

引用：OMG SysML1.1 仕様書 P7

http://www.omg.org/spec/SysML/1.1/changebar/PDF/

引用：OMG SysML1.1 仕様書 P11

ASTAH*で の 要 求 周 り の 機 能 の 利 用

astah* professional では SysML の要求に関連した部分をソフトウェア開発の現場で汎用的に使用できるよう実現 しました。要求およびテストケースの階層・派生関係の設定、要求テーブルを用いた管理を容易にし、工程間のギ ャップを減らします。 要 求 使用できるエディション： astah* professional システムの要求を記述するモデルです。名前、ID、テキスト等を設定でき、階層をツリーとして表現します。また、 導出、コピー、満足、検証、洗練、トレースといった派生関係を設定できます。その他の機能として、要求からユ ースケースやマインドマップのトピックへの変換もサポートしています。 テ ス ト ケ ー ス 使用できるエディション： astah* professional システムのテストケースを記述するモデルです。名前、ID、定義等を設定でき、階層をツリーとして表現します。 また、満足、検証、洗練といったテストケースからの派生関係も設定可能です。テストケースからユースケースや マインドマップのトピックへの変換もサポートしています。 要 求 テ ー ブ ル 使用できるエディション： astah* professional デモ動画：http://astah.change-vision.com/ja/movie.html#requirement-table 表形式で要求を編集したり、階層を指定して要求の ID、名前、テキストを表示したりできます。Excel への入出力 も可能です。 要 求 図 使用できるエディション： astah* professional

導 出 、 コ ピ ー 、 満 足 、 検 証 、 洗 練 、 ト レ ー ス 使用できるエディション： astah* professional 導 出 <<DERIVEREQT>> 引用：OMG SysML1.1 仕様書 P144 http://www.omg.org/spec/SysML/1.1/changebar/PDF/ 導出は、クライアント要求がサプライヤ要求に導き出される二つの要求間の依存関係です。 例えば、システム要求はビジネス要求に由来するかもしれません。あるいは、より低レベルの要求はシステム要求 に由来するかもしれません。他の依存関係と同様に、矢方向はクライアント要求からそれが導き出されるサプライ ヤ要求まで指します。 astah*では、要求から要求に引くことができます。 要求のプロパティビューの”依存元”タブ、”依存先” タブ、もしくは、要求テーブルの要求のポップアップメニュー ”依存元の設定”、”依存先の設定”から追加できます。

A DeriveReqt relationship is a dependency between two requirements in which a client requirement can be derived from the supplier requirement. For example, a system requirement may be derived from a business need, or lower-level requirements may be derived from a system requirement. As with other dependencies, the arrow direction points from the derived (client) requirement to the (supplier) requirement from which it is derived. 引用：OMG SysML1.1 仕様書 P149

コ ピ ー <<COPY>> 引用：OMG SysML1.1 仕様書 P144 http://www.omg.org/spec/SysML/1.1/changebar/PDF/ コピーは、クライアント要求とサプライヤ要求間の依存関係で、クライアント要求のテキストがサプライヤ要求の 読み取りコピーであることを示しています。異なる状況で再利用する目的で、クライアント/サプライヤ関係を維持 します。クライアント要求は、コピーの矢印の先のサプライヤ要求の読み取り専用コピーです。 astah*では、要求から要求に引くことができます。 要求のプロパティビューの”依存元”タブ、”依存先” タブ、もしくは、要求テーブルの要求のポップアップメニュー ”依存元の設定”、”依存先の設定”から追加できます。

A Copy relationship is a dependency between a supplier requirement and a client requirement that specifies that the text of the client requirement is a read-only copy of the text of the supplier requirement. A Copy dependency created between two requirements maintains a master/slave relationship between the two elements for the purpose of requirements re-use in different contexts. When a Copy dependency exists between two requirements, the requirement text of the client requirement is a read-only copy of the requirement text of the requirement at the supplier end of the dependency.

引用：OMG SysML1.1 仕様書 P149 http://www.omg.org/spec/SysML/1.1/changebar/PDF/ 満 足 <<SATISFY>> 引用：OMG SysML1.1 仕様書 P144 http://www.omg.org/spec/SysML/1.1/changebar/PDF/ 満足は、要求とその要求を満足させるモデル間の依存関係です。 他の依存関係と同様に、矢方向はクライアントモデルからそれを満たすサプライヤ要求まで指します。 astah*では、モデル※から要求に引くことができます。 モデル※とは以下を示します。 パッケージ 、モデル 、サブシステム 、クラス 、関連クラス、 インターフェース、

引用：OMG SysML1.1 仕様書 P151 http://www.omg.org/spec/SysML/1.1/changebar/PDF/ 検 証 <<VERIFY>> 引用：OMG SysML1.1 仕様書 P145 http://www.omg.org/spec/SysML/1.1/changebar/PDF/ 検証は、要求とシステムが要求を満たすかどうかを検証するテストケースの依存関係です。他の依存関係と同様に、 矢方向は、クライアントテストケースからそれが導き出されるサプライヤ要求まで指します。 astah*では、テストケースから要求に引くことができます。 要求のプロパティビューの”依存元”タブ、”依存先” タブ、テストケースのプロパティビューの”依存先” タブ、もし くは、要求テーブルの要求のポップアップメニュー”依存元の設定”、”依存先の設定”から追加できます。

A Verify relationship is a dependency between a requirement and a test case or other model element that can determine whether a system fulfills the requirement. As with other dependencies, the arrow direction points from the (client) element to the (supplier) requirement.

引用：OMG SysML1.1 仕様書 P152

http://www.omg.org/spec/SysML/1.1/changebar/PDF/

洗 練 <<REFINE>>

引用：OMG SysML1.1 仕様書 P145

洗練とは、モデルから要求に詳細化する依存関係です。他の依存関係と同様に、矢方向は、クライアントモデルか らサプライヤ要求の方向を示します。 astah*では、モデル※から要求に引くことができます。 モデル※とは以下を示します。 パッケージ 、モデル 、サブシステム 、クラス 、関連クラス、 インターフェース、 エンティティ 、コントロール 、バウンダリ 、アクター、 ユースケース コンポーネント 、成果物 、ノード 、要求 、テストケース 要求のプロパティビューの”依存元”タブ、”依存先” タブ、テストケースのプロパティビューの”依存先” タブ、もし くは、要求テーブルの要求のポップアップメニュー”依存元の設定”、”依存先の設定”から追加できます。 ト レ ー ス <<TRACE>> 引用：OMG SysML1.1 仕様書 P146 http://www.omg.org/spec/SysML/1.1/changebar/PDF/ トレースとは、要求間の抽象的なつながりを表す依存関係です。 astah*では、要求から要求に引くことができます。 要求のプロパティビューの”依存元”タブ、”依存先” タブ、もしくは、要求テーブルの要求のポップアップメニュー ”依存元の設定”、”依存先の設定”から追加できます。 要 求 図 と 要 求 テ ー ブ ル を 使 用 し て 要 求 を モ デ リ ン グ [組 み 込 み 系 サ ン プ ル ]し よ う 使用できるエディション： astah* professional 以下は、OMG から提供されている SysML1.1 仕様書の要求図のサンプルです。 [組み込み系サンプル]で自動車の舗道摩擦まわりの要求を表したものです。 引用：OMG SysML1.1 仕様書 P152 http://www.omg.org/spec/SysML/1.1/changebar/PDF/

エディタのボタンから“要求”作成ボタンをクリックし、図上に要求を作成します。要求名、要求の ID を入力しま す。Text の項目には、その要求の説明を入力します。（astah*では、ID と Text の順序が例と異なります）

同様に他の要求についても作成します。次に、要求間の関係を作成してみましょう。 要求間の導出関係とネスト関係を、それぞれ、ツールバーのボタンを押して、作成します。

ネスト関係については、作成時に、親子関係が変わることを、構造ツリーで確認できると思います。 ここまでで、例の要求図が完成しました。図だと要求間の関係を一目で把握できますね。

要求図を書く時に作成されたモデルから、次のような要求テーブルが作成されます。要求テーブルは、ネームスペ ース毎に一つ作成可能で、その配下に存在する要求が自動的にリストに表示されるようになっています。 要求図と要求テーブルでは同一のモデルが利用されますので、一方で変更すればもう一方にも反映されます。また、 それぞれのポップアップメニューから、図やテーブルに相互にジャンプ可能になっています。 さて、同等のモデルをはじめから要求テーブルを使用して作成する場合を見てみましょう。次のような手順になり ます。 まず、図メニューから”要求テーブル”を選択し、要求テーブルを作成します。 要求テーブルを右クリックしてポップアップメニューから”要求の追加”で

Adhesion utilization, Vehicle conditions, Test and procedure conditions, Pavement friction, ASTM R1337-90 の要求を追加していきます。

・子要求の追加 ・兄弟要求の追加 ・依存元の設定

・ユースケースへの変換

Vehicle conditions は Adhesion utilization とネスト関係がありますので、ポップアップメニューから”子要求の追加” から追加します。Test and procedure conditions も同様です。

また、Test and procedure conditions から Pavement friction、Pavement friction から ASTM R1337-90 へ導出 <<deriveRept>>でつながっていますので、ポップアップメニューから”依存先の設定”から追加します。(“依存元の 設定”でも可能です。) ちなみに、導出<<deriveRept>>とは、要件から別の要件が導き出される関係のことです。

以下が作成したモデルです。 要求テーブルと要求図の両方を使って、それぞれの利点を活かすといいですね。 要 求 図 と 要 求 テ ー ブ ル を 使 用 し て 要 求 を モ デ リ ン グ [WEB 系 サ ン プ ル ]し よ う 使用できるエディション： astah* professional ここでは、ストーリー仕立てで要求モデリングしていきたいと思います。 プロジェクトマネージャーである A さんは、営業 X さんと取引先に新案件の打ち合わせに行きました。 A さんは、いつものように PC を起動しマインドマップでヒアリングを開始しました。 「登場人物」 プロジェクトマネージャー A さん 営業 X さん 開発リーダー B さん 要求開発リーダー R さん

その後、プロジェクトマネージャーA さんはヒアリングした要求を機能要件、非機能要件もまとめて、要求の機能 をまとめてみることにしました。頭のなかに浮かんだのは以下のモデルです。

次に要求間の依存関係を設定していきます。 先ほど軽く、ユースケース分析をしていました。ユースケースの"ログインする"の詳細は、要求の"ログインボタン "にあたります。このように機能要件のユースケースから機能要件の要求に対して詳細化するという意味合いの洗練 <<refine>>を引くことができます。このように既存の UML のダイアグラムと関連し合っているため、この様に可 視化することにより、仕様の共有化に一役買うことにもなるでしょう。操作方法は、要求テーブル上で依存を張り たい要求を選択し、ポップアップメニューから”依存先の設定”から追加します。(“依存元の設定”でも可能です。) また、プロジェクトマネージャーA さんは顧客からログイン時のレスポンスやセキュリティの要求に注意するよう に言われていたのを思い出しました。非機能要件を満たせないと顧客から信頼をなくしかねません。 機能要件の要求"ログインボタン"は、非機能要件の要求"レスポンス要求"、"セキュリティ要求"を導き出しています。 同様に機能要件の要求"正常遷移"から機能要件の要求" XX 画面要求"へも同様です。 このように、導出<<deriveRept>>とは、要件から別の要件が導き出される関係のことを表します。 操作方法は、要求テーブル上で依存を張りたい要求を選択し、ポップアップメニューから”依存先の設定”から追加 します。(“依存元の設定”でも可能です。) 次にテストケースについて考えています。 テストケースは、astah*内でもモデルとして生成できます。実際のそのテストケースの内容ですが、自動テストに するか EXCEL でテスト仕様書を書くのか現段階では決まっていませんが、ここは顧客・メンバと話し合うため、 成果物は何にするかは、懸案事項として置いておくとします。

ただ、自動テストならソースや結果のドキュメント、テスト仕様書なら、ドキュメントへ、シナリオならフローチ ャートやアクティビティ図へのハイパーリンクを張るのか、またはテストケースの定義に書くのかなど、事前にプ ロジェクトで話し合ってよりよい合意をとったほうがよさそうです。 プロジェクトマネージャーA さんは、この点をメモしておき、開発リーダーB さんにテストケースの設計を指示し ました。開発リーダーB さんは、まずネスト関係に注意しながら、テストケースを設計し始めました。 また、テストケースと要求間では、検証<<verify>>といって要求を満たすことをテストケースで検証するための依 存関係をはることができます。開発リーダーB さんは、プロジェクトマネージャーA さんが作ったモデルを自分の モデルにマージし、検証関係を張っていきました。出来上がったモデルは、以下でした。

その後は、プロジェクトマネージャーA さんは要求開発リーダーの R さんに要求の詳細化を依頼しました。 要求開発リーダーR さんは、自身を中心に、要求開発グループで展開させるために、要求テーブルを EXCEL で出 力してチーム内の共有を開始しました。[ツール]-[要求]-[要求テーブルを Excel ファイルに出力]で出力できます。