astah* チュートリアル

astah* チュートリアル
[最も⾝近なソフトウェア開発設計⽀援ツール]
使用バージョン:astah* 6.0, 6.1
2010/03/05
株式会社チェンジビジョン
1 / 153
astah* チュートリアル
目次
このチュートリアルの概要
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
CRUD 分析の利点を考えよう
49
CRUD 分析してみよう
50
2 / 153
astah* チュートリアル
CRUD をドキュメント出力してみよう
チーム開発してみよう
マージ機能ってどんな機能？
まず簡単マージを使ってみよう
57
60
60
60
参照プロジェクト管理ってどんな機能？
71
参照プロジェクト管理を使ってみよう
71
要求の機能を使ってみよう
78
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
言語サポート機能を使ってみよう
Java
Java 基本機能
98
98
98
Java スケルトンコードを作成してみよう
101
Java ソースコードの読み込みをしてみよう
103
C++
106
C++基本機能
106
C++スケルトンコードを作成をしてみよう
109
C++リバースをしてみよう（サンプル、サポート対象外）
113
C#
119
C#基本機能
119
C#スケルトンコードを作成してみよう
122
3 / 153
astah* チュートリアル
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
4 / 153
astah* チュートリアル
このチュートリアルの概要
この資料は、astah*のいくつかの機能とその活用方法を理解してもらうことを目的として、astah*の使用方法や活
用例を紹介します。特に UML 版や professional 版に含まれる主な機能に関連した astah*の利用例です。
次の方々を対象としています。
y
astah*をこれから評価される方
y
今まで astah*を使ったことがない方
y
すでに astah*のユーザーの方
各章は次の通りです。
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
5 / 153
astah* チュートリアル
マインドマップを活用してみよう
使用できるエディション： 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*を使ってマインドマップで要求分析を行ってみましょう。
6 / 153
astah* チュートリアル
マインドマップと設計図がオールインワンでスムーズに連携できる
astah*では、マインドマップと UML や ER 図などの設計用の図が１つのツールに入っていることより、互いの図要
素に簡単に変換でき、要求分析から設計までスムーズに移行できます。
マインドマップのトピックを、UML モデル（クラス、ユースケース、その他）に変換できます。構造ツリーから
UML 図へのドラッグ＆ドロップで変換でき、変換された UML クラスへはハイパーリンクを自動で追加することも
可能です。 UML モデルからマインドマップのトピックへの変換もドラッグにより可能です。
7 / 153
astah* チュートリアル
マインドマップで要求ヒアリングしよう
[収集]
マインドマップは極めてシンプルなフォーマットから成り立っていますが、アイディアを発散することに長けてお
り、議事録や要求の収集に向いていると言えます。顧客との打合せで会話しながら PC をおもむろに開き、astah*
で要求をどんどんメモしておきましょう。このシーンでは、ラフで柔らかい、曖昧なアイデアを羅列しておくだけ
にとどめます。特に、顧客の何気ないつぶやきや非機能要件など見落としがちな発言もどんどん書いていきましょ
う。astah*では様々なマインドマップテンプレートも用意されており、このケースでは以下のテンプレートファイ
ルを使うと良いでしょう。
astah* インストールフォルダ¥template¥mindmap¥UserRequirement.asta
また、テンプレート自身を変更したい場合であれば、編集して自分用のテンプレートにすることもできます。
[整理・分析]
一方、開発用の各図(UML、ER 図など)の最終形モデルである実装モデルは、厳格でカチッとしており、要求から実
装モデルはこの段階では距離があります。したがってマインドマップで書かれた仕様を整理、分析し、モデリング
の材料として利用してみると、モデリングの曖昧なところが見えてくるはずです。そのマインドマップを会議室に
持ち込みプロジェクタに映しながら、要求やモデルで曖昧な点を議論するのもよいでしょう。
こうすることでメンバー間のコミュニケーションの促進や待ち時間の削減に貢献できるでしょう。
[構築]
曖昧なところが明確になってくれば、それを分析モデル→設計モデル→実装モデルへと具体化してきましょう。
8 / 153
astah* チュートリアル
整理・分析・構築の例(マインドマップからユースケース図への変換 )
例えば、マインドマップで市の図書館システムの要求ヒアリングをし、それをユースケース図にする例を挙げます。
同様の内容を動画でも参照できます。
デモ動画：http://astah.change-vision.com/ja/movie.html#mindmap-to-usecase
なぜ？誰が？どこで？について以下のようにヒアリングしました。
9 / 153
astah* チュートリアル
astah*の特徴としてマインドマップのトピックに UML などのアイコンを追加することができます。
ここでは、Who の項目に挙げた人に対して UML のアクターアイコン、When の項目に挙げた機能的要求に対して
UML のユースケースアイコンを付加しました。こうすることで、ビジュアル面での恩恵を受けるだけでなく、構造
ツリーのトピックから他の図(たとえばユースケース図)へドラッグアンドドロップしたときに、変換したいモデル
の種類がデフォルトで選択されるという利点があります。
さて、トピックからユースケース図を作ってみましょう。メニューから、空のユースケース図を作成します。
次にマインドマップのトピックからアクターを作成します。
構造ツリーでマインドマップの Who 配下のトピックを選択し、ユースケース図にドラッグアンドドロップします。
ダイアログで種類がアクターになっていることを確認して OK ボタンをクリックします。
10 / 153
astah* チュートリアル
以下のようにアクターができました。
次にトピックからユースケースを作成したいと思います。
構造ツリーでマインドマップの When 配下のトピックをユースケース図にドラッグアンドドロップします。
ダイアログで種類がユースケースになっていることを確認して OK ボタンをクリックします。
11 / 153
astah* チュートリアル
以下のようにユースケースができました。
後は、ユースケース図で関係を記述します。
このようにマインドマップを経由して設計するとコミュニケーションも活発になり、曖昧な点やモレがなくなり、
開発がスムーズに進むはずです。
マインドマップ関連参考書籍
ソフトウェア開発におけるマインドマップの活用法について、次の書籍も参照ください。
「ソフトウェア開発に役立つマインドマップ」日経 BP 社
平鍋健児著
ブログ記事 : http://blogs.itmedia.co.jp/hiranabe/2007/05/post_893a.html
Amazon： http://www.amazon.co.jp/ASIN/dp/4822283143/xpjp-22
12 / 153
astah* チュートリアル
データモデリングしよう
オブジェクト指向分析設計がかなり現場でも使われるようになってきましたが、それで
も、データモデリングは重要です。オブジェクト指向は、プログラミング言語から来た
概念を、設計に援用しようとしています。データモデリングは、アプリケーションを超
えた寿命を持つデータをモデリングしようとしています。
両者は補い合って、ひとつの「意味論」の中で協調して使われても「よい」ものなので
す。オブジェクト指向至上主義でも、データモデリング至上主義でも、現実の開発はう
まく行きません。オブジェクト指向言語と、リレーショナルデータベースをつなぐのは、
DAO や Hibernate のようなパターンやツールを使うこともありますが、逆に、これまで
蓄えられた業務モデリングの知見を利用しながらオブジェクト指向設計をすることも
可能です。
オブジェクト指向開発
クラス図（分析）
データモデリング
論理データモデル
クラス図（設計）
物理データモデル
13 / 153
astah* チュートリアル
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
物理名の対応
14 / 153
astah* チュートリアル
IDEF1X、 IE による ER 図を作成しよう
使用できる製品: astah* professional
astah*の ER 図は二つの表記法に対応しており、すぐに切り替えられます。
[IDEF1X 表記]
[IDEF1X 表記]
15 / 153
astah* チュートリアル
エンティティの種類について考えてみよう
使用できる製品: astah* professional
エンティティとは、システム(データベース)の管理対象となりうるもので人、モノ、イベント、履歴などがありま
す。エンティティには、リソース系、イベント系、サマリー系などがあり、以下のように分類されます。
エンティティ種別
主な例
リソース系
会社、顧客、商品、製品、工場、カネなど。
イベント
会員登録・変更・削除、発注、出荷など。
サマリー系
購入履歴、出荷履歴など。
エンティティの抽出のコツがあり、以下の手順を踏むのもよいでしょう。
(1)エンティティ候補をヒト、モノなどのカテゴリーで抽出(マインドマップで行うのもよい。)
・そこから、リソース系エンティティの抽出
(2)業務フローを書く。(フローチャートや DFD、アクティビティ図で)行うのもよい。
・そこから、イベント系エンティティの抽出
また、astah*ではエンティティのプロパティビューから、リソース系、イベント系、サマリー系の指定や、[シス
テムプロパティ]-[新規 ER エンティティの型の色]で系統ごとに色の指定もできるので、ER 図を書いてモデリング
するときに利用すると便利です。
16 / 153
astah* チュートリアル
マインドマップからエンティティへの変換をしてみよう
使用できる製品: astah* professional
マインドマップでエンティティ抽出のために、以下のようなテンプレートを用意するのもよいでしょう。
ショッピングサイト構築という想定でエンティティを挙げてみました。
17 / 153
astah* チュートリアル
また、エンティティ候補には ER エンティティのアイコンも付加してみました。
さて新規 ER 図を作成し、構造ツリーでこのマインドマップのトピックを図にドラッグアンドドロップしてみます。
事前に図の表示レベルをエンティティにしておくとよいでしょう。(詳しくは次の章で説明します。)
以下のように ER エンティティが作成されました。
18 / 153
astah* チュートリアル
次にリソース系、イベント系、サマリー系を設定してみます。
システムプロパティの色が設定されていることがわかりますね。
色付けすることにより、コミュニケーションも容易になり、より分かりやすくなります。
あとは続けて属性やリレーションシップの設計などを行い、設計をつめていくとよいでしょう。
19 / 153
astah* チュートリアル
データモデリングのプロセスを使用してみよう
データモデリングのプロセスの流れは、次の図のように、分析、設計、実装フェーズで、論理データモデルから物
理データモデルを作成するのが主流です。
出典：アーキテクタス細川努「UML による一気通貫 DB システム設計」
エンティティの表示レベルの設定をしてみよう
使用できる製品: astah* professional
astah*では、図の表示レベル(エンティティ、主キー、属性)を設定でき、これらのプロセスに則ったデータモデリン
グが可能です。論理よりではエンティティレベルで、物理モデルに近づくにつれて主キーレベル、属性レベルで設
計するとよいでしょう。操作方法は、ER 図のプロパティビューから表示レベル(初期設定)で変更します。
ちなみにこの操作は対象の ER 図で新規作成 ER エンティティから表示設定が反映されます。既存の ER エンティ
ティの表示レベルを変更したい場合は、ER エンティティのポップアップメニューから変更してください。
まず、エンティティレベルで設計してみます。エンティティとなりうるモデルを抽出するにとどめておきます。
20 / 153
astah* チュートリアル
続いて主キーレベルで設計します。リレーションを張っていってよいでしょう。
最後に属性レベルで設計します。詳細な属性項目を設計していきます。
21 / 153
astah* チュートリアル
論理名と物理名を使ってみよう
使用できる製品: astah* professional
astah*ではエンティティや属性などに論理名と物理名の両方を設定でき、データモデリングのプロセスをサポート
します。論理データモデリングでは、エンティティの論理名に”顧客”とつけ、物理データモデリングではテーブル
命名規則に則り、物理名を”CUSTOMER”にするようなことができます。
エンティティだけでなく属性にも物理名を設定できますし、SQL 出力では、論理名、物理名での出力が可能です。
論理モデル、物理モデルの切り替えは ER 図のプロパティビューのモデルタイプから行います。
まず、[論理モデル]で設計します。各エンティティや属性、リレーションについて概念を詰めていきます。
22 / 153
astah* チュートリアル
次に[物理モデル]で設計します。データベース自体を想定しながらモデリングしていきます。
ドメインを活用しよう
使用できる製品: astah* professional
ドメインとは、データの型や値／範囲を取り決めるディクショナリのことで、複数のエンティティの属性から設定
できます。ドメインを使用したデータモデリングは、システムの内のデータの不統一や不整合をなくすことができ、
データモデリングの中でも重要なプロセスです。例えば、クレジットカード番号にハイフンを含めるか含めないか
で CHAR(12)に設計する人や CHAR(15)で設計する人が、ドメインを使用することでこのようなテーブル設計のミ
スをなくすことが可能です。
また、ドメインを使用していることで、後から属性の長さを変更しても、参照先のエンティティに反映されるなど
仕様変更に強い設計になります。astah*では階層的なドメインの機能も兼ね備えています。構造ツリーのドメイン
のポップアップメニューから追加できます。階層的に作成した場合、親の型や長さ等を引き継ぎますが、子側で型
や長さの変更も可能です。
ドメインのグルーピングの仕方は、その設計者の自由に取り決めていいですが、業務に依存しない共通的なドメイ
ンは”共通”、業務に依存するドメインは”固有”や”業務”としておくのもいいでしょう。
23 / 153
astah* チュートリアル
下の例は、”共通”ドメインでいくつかドメインを設計した結果です。
また、作成したドメインを ER エンティティにドラッグアンドドロップすることもできます。
以下のようにドメインを使用した属性が追加されましたね。
24 / 153
astah* チュートリアル
また、属性のプロパティビューからドメインを変更することもできます。
リレーションを張ってみよう
使用できる製品: astah* professional
以下のようなモデルを作成してみましょう。
（例１）
【会社マスタ】
【会社階層】
会社コード(PK)
上位会社コード(FK)
会社名称
下位会社コード(FK)
まず、２つの ER エンティティ” 会社マスタ”,”会社階層”を作成します。
25 / 153
astah* チュートリアル
ER エンティティ“会社マスタ”に、主キー”会社コード”、属性”会社名称”を追加します。
ER エンティティ“会社マスタ”から ER エンティティ”会社階層”に非依存型リレーションシップを引きます。
ER エンティティ”会社階層“から属性”会社コード“を”上位会社コード”に名前変更します。
26 / 153
astah* チュートリアル
再度、ER エンティティ“会社マスタ”から ER エンティティ”会社階層”に非依存型リレーションシップを引きます。
27 / 153
astah* チュートリアル
新しく引いた非依存型リレーションシップを選択し、プロパティビューの“キー”タブを開きます。
上位会社コード_0(new)を選択します。
ER エンティティ”会社階層“に新しい属性” 上位会社コード_0“ができました。
28 / 153
astah* チュートリアル
これを“下位会社コード”にリネームします。
これでリレーションも含めたモデルを作成できましたね。
[リレーションシップ作成時のポイント]
親子間で複数のリレーションシップを張り、子エンティティ側の FK を異なる属性にしたい場合は、リレーシ
ョンシップの“キー“タブを使用します。
29 / 153
astah* チュートリアル
データ型を追加してみよう
使用できる製品: astah* professional
astah*では、デフォルトでは以下のデータ型が定義されています。
([ツール]-[ ER 図]-[ER データ型の設定]、
もしくは構造ツリー上の ER モデルのポップアップメニューから” ER データ型の設定”を選択。)
この一覧にないデータ型も追加でき、長さや精度を設定できます。
[物理モデル作成時のポイント]
論理モデル作成後、物理モデル作成前に、固有の DB を使用し、astah*デフォルトのデータ型で不十分な場合、
先にデータ型を設定しておくと、物理モデルの属性の型を考慮するときにスムーズにモデリングできます。
30 / 153
astah* チュートリアル
エンティティ定義書を出力してみよう
使用できる製品: astah* professional
デモ動画：http://astah.change-vision.com/ja/movie.html#entity-definition
astah*では、テンプレートを指定して、ER 図のエンティティ定義を EXCEL 形式で出力できます。
設計したエンティティをドキュメントに出力して、納品資料として利用したり、チームでレビューしたりするのも
よいでしょう。
[ツール]-[ER 図]-[エンティティ定義書のエクスポート]を選択します
出力ダイアログが表示されます。テンプレートはプロジェクト固有のテンプレートにも変更できます。
新しいテンプレートボタンをクリックしてみましょう。
31 / 153
astah* チュートリアル
以下のようにテンプレートを編集できます。
[ドメイン一覧]
[エンティティ一覧]
[エンティティ定義]
新しいテンプレートボタンをクリック後、了解ボタンクリックでテンプレートが作成されます。
そのファイルを開いてみましょう。
32 / 153
astah* チュートリアル
$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
33 / 153
astah* チュートリアル
エンティティの定義 - $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
次にデフォルトのテンプレートで出力してみましょう。
SQL 出力（ SQL-92 準拠）してみよう
34 / 153
astah* チュートリアル
使用できる製品: astah* professional
デモ動画：http://astah.change-vision.com/ja/movie.html#sql-export
SQL-92 相当の DDL を出力できます。以下のモデルで SQL を出力してみましょう。
[ツール]-[ER 図]-[SQL 出力]を選択します。
以下のダイアログが表示されますので、オプションボタンを押下します。
35 / 153
astah* チュートリアル
次のようなオプションを設定できます。
出力した結果のサンプルです。
36 / 153
astah* チュートリアル
37 / 153
astah* チュートリアル
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
起動に成功すると次のような画面が表示されます。
38 / 153
astah* チュートリアル
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;
39 / 153
astah* チュートリアル
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 ができます
40 / 153
astah* チュートリアル
6. HSQLDB DatabaseManager の終了
HSQLDB DatabaseManager の画面を閉じます。
41 / 153
astah* チュートリアル
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
42 / 153
astah* チュートリアル
3. astah* データベースリバースコンポーネントでデータベースに接続
「Import」ボタンが有効になりますので押下します。
4. astah* データベースリバースコンポーネントでインポート
43 / 153
astah* チュートリアル
「Import Successfully」がコンソールに出力され、astah* プロジェクトの作成が完了します。
44 / 153
astah* チュートリアル
作成した ASTA ファイルを ASTAH* PROFESSIONAL で開いてみよう
1. 作成したファイルを astah* professional で開きます
2. ER 図を自動作成します
構造ツリーの ER モデルを選択し、右クリックで表示されるポップアップメニューから[ER 図を自動作成する]
を実行します。
参考：一部のエンティティのみを表示する ER 図を作成する場合は、新しい ER 図を作成後、構造ツリーで必
要なエンティティを選択して、ER 図にドラッグ＆ドロップします。
3. 型と長さを表示します
Ctrl＋A で図要素をすべて選択し、右クリックで表示されるポップアップメニューから
[型と長さの表示]-[オン]を実行します。
45 / 153
astah* チュートリアル
4. 全図要素の自動レイアウトを実行します
astah* の上部メニュー、[整列]-[全図要素の自動レイアウト]を実行します。
5. 拡大表示します
A、B、C のテーブル、主キー、属性、依存型リレーションシップ、
非依存型リレーションシップが作成されていることが分かります。
46 / 153
astah* チュートリアル
47 / 153
astah* チュートリアル
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）
48 / 153
astah* チュートリアル
CRUD を使ってみよう
使用できるエディション： astah* professional
デモ動画：http://astah.change-vision.com/ja/movie.html#crud
CRUD の概要
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 分析の利点を考えよう
49 / 153
astah* チュートリアル
データモデリングの世界では、CRUD 分析は大変重要かつ有効といわれています。
CRUD 分析は、テーブル設計段階の考慮モレや矛盾を早期に発見できる手立てとなりうるものです。
結合テスト段階での DB マイグレーション時のトラブル、マスタの登録処理抜け、スタブテストデータの削除忘れ、
データの二重登録、さらにはテーブル設計の問題により、特定のテーブルへの過剰な負荷による非機能要件である
レスポンス問題、再度正規化やテーブル分割を余儀なくされるなどのリスクを軽減できます。
開発が大詰めの段階では、大量のビジネスロジックを抱えて、初期に引きずったテーブル設計を変更するのは容易
ではありません。CRUD 分析をプロジェクトに合わせた運用で適用して行くのもいいかもしれませんね。
CRUD 分析してみよう
それでは astah*を実際につかって CRUD 分析してみましょう。
ここからは本のオンラインショッピングの例を示してみます。いつものようにマインドマップで軽い要求分析をし
てみました。登場しうる簡単なモデルと機能を挙げています。
作成したマインドマップを利用し、
構造ツリーの User、Book、Cart トピックを新規作成したクラス図にドラッグアンドドロップします。
50 / 153
astah* チュートリアル
以下のようにクラスが作成されました。
クラス図を詳細化してみます。
51 / 153
astah* チュートリアル
このクラス図を ER 図に変換してみます。構造ツリーのクラス図のポップアップメニューから”ER 図に変換”を選択
します。
以下の MSG が表示されます。ここでは”はい”を選択します。
以下のように ER 図が作成されました。
52 / 153
astah* チュートリアル
作成した ER 図にリレーションを張るなどして洗練させます。
作成したマインドマップを利用し、構造ツリーの Login、Adjustment、Put in cart、New Registration、Logout トピ
ックを新規作成したユースケース図にドラッグアンドドロップします。
53 / 153
astah* チュートリアル
以下のようにユースケースが作成されました。
ユースケース図を洗練させます。
54 / 153
astah* チュートリアル
さて作成した ER 図、ユースケース図を利用して CRUD 分析できる材料がそろいました。
メニューから CRUD を作成します。
以下のようなダイアログが表示されます。
55 / 153
astah* チュートリアル
作成した ER 図、ユースケース図を設定してみます。
空の CRUD が作成されました。
56 / 153
astah* チュートリアル
現段階で、考えられる C、R、U、D を設定します。
セルを直接選択し、C キー、R キー、U キー、D キーで ON/OFF を設定できます。
このように astah*では、UML、ER 図、業務フローを利用しながら、CRUD 分析の材料とすることができ、分析・
設計間の考慮モレを CRUD 分析によって低減できると思います。
CRUD をドキュメント出力してみよう
57 / 153
astah* チュートリアル
前章で作成した CRUD を Excel ファイルとして出力することも可能で、レビューや納品資料としても使用できます。
[ツール]-[CRUD]-[CRUD を Excel ファイルに出力]を選択します。
出力ダイアログが表示されます。
出力結果は以下の通りです。
58 / 153
astah* チュートリアル
全 CRUD 統計リポートも出力できますから、全体を俯瞰してレビューしたい際に利用してみるのもよいでしょう。
（ [ツール]-[CRUD]-[全 CRUD 統計リポートを Excel ファイルに出力]）
59 / 153
astah* チュートリアル
チーム開発してみよう
モデリングにも今やチーム開発は必須の機能です。
astah*に用意されている二つのチーム開発の補助機能を紹介します。
マージ機能ってどんな機能？
使用できるエディション： astah* professional、astah* UML、astah* think!
デモ動画：http://astah.change-vision.com/ja/movie.html#merge
他の人が作成したプロジェクトを、自分のプロジェクトにマージしたい時に使います。現在のプロジェクトに別の
プロジェクトをマージできます。簡単マージ、モデルごとに作業中・取込中のどちらを優先するか選択可能な詳
細マージ(pro,UML のみ)があります。
[用途]
・二つのプロジェクトファイルを一つにまとめる。
・同一プロジェクトの編集
二人の人がそれぞれ編集した同一 astah*ファイルの変更点を合わせられる。
[使用イメージ]
まず簡単マージを使ってみよう
60 / 153
astah* チュートリアル
コンフリクトがないケース
以下のようなプロジェクトを新規作成してみます。ファイル名は base.asta とします。
以下のようなプロジェクトも新規作成してみます。
(新規作成することで base プロジェクトのモデルの内部 ID と同一になることがありません。)
ファイル名は ref.asta です。
base.asta を開き、[ファイル]-[プロジェクトをマージ]を選択し、ref.asta を選択します。
以下のようなダイアログが表示されます。
61 / 153
astah* チュートリアル
“詳細”ボタンをクリックすると、差分が表示されます。
マージの結果を細かくカスタマイズしたい場合、この画面でどっちを優先させるか選択することができます。
まずは簡単マージするので、“キャンセル”ボタンで前の画面に戻ります。
ダイアログの説明に“一方に存在する要素は全てマージします。それ以外の要素は、以下のプロジェクトの要素を
優先してマージします。”とあります。この場合のマージでは、全て一方に存在する要素にあたりますので、“作
業中のプロジェクト”を選択しても、“取り込み中のプロジェクト”を優先しても全てマージされます。ひとまず
“取り込み中のプロジェクト”を選択して“了解”ボタンをクリックします。
62 / 153
astah* チュートリアル
ref.asta のみに存在していた“ref クラス図”と“D”クラスが取り込まれましたね。
次は、コンフリクトがあるケースを説明していきます。
コンフリクト(内部 ID 衝突)あるケース
以下のようなプロジェクトを新規作成します。ファイル名は base.asta とします。
このプロジェクトを ref2.asta として保存します。
63 / 153
astah* チュートリアル
さらにこのプロジェクトの“”、“”、“”を削除し、“B”を“D”に名前変更します。
(この操作により、base プロジェクトの B クラスと ref プロジェクトの D と内部 ID が同一になります。)
base.asta 開き、[ファイル]-[プロジェクトをマージ]を選択し、ref2.asta を選択します。
以下のようなダイアログが表示されます。
“詳細”ボタンをクリックします。コンフリクトがないケースの詳細ダイアログの結果と少し異なります。
64 / 153
astah* チュートリアル
要素が異なる理由が“名前が異なっています”になっていて、作業中の要素が“B”、取込む要素が“D”になって
います。これはどういうことでしょうか？
“簡単マージ“ダイアログの説明に“一方に存在する要素は全てマージします。それ以外の要素は、以下のプロジ
ェクトの要素を優先してマージします。”とあります。このケースは、作業中プロジェクト、取込み中プロジェク
トの両方に同じモデルがあり、どちらかを優先させるか決めなければならないコンフリクト（変更の衝突）です。
astah*では各モデルに内部 ID を保持しており、コンフリクトの定義は、内部 ID が同じか同じ名前空間で名前が同
じものが変更されたことを意味しています。
コンフリクトの定義：
両方のプロジェクトに同じ名前空間(パッケージ)で同じ名前か同じ内部 ID のものが存在し、変更されているケース。
このケースでは同じ内部 ID のコンフリクトと言えます。内部 ID は、モデルの新規作成時、例えばクラスを作成し
たときに割り振られます。また、astah＊がもつ内部の ID は衝突がないことを前提としています。そのため、ID の
生成も注意して衝突しないようにしています。内部 ID は複数の人が複数のパソコンで同時に編集したモデルであっ
ても、別々になるように生成されます。
では、“簡単マージ“ダイアログで”取込み中プロジェクト”を優先でマージします。
クラス“B”が“D”になっていますね。
65 / 153
astah* チュートリアル
[マージ機能のポイント]
このようにマージする際は、内部の ID と名前の衝突するコンフリクトに気をつけモデリングすることで、複
雑なマージをよりスムーズにすることができます。
では、“簡単マージ“ダイアログで” 作業中プロジェクト”を優先でマージします。
クラス“B”はそのままですね。
コンフリクト(名前衝突)があるケース
以下のようなプロジェクトを新規作成します。ファイル名は base.asta とします。
66 / 153
astah* チュートリアル
以下のようなプロジェクトも新規作成します。
(新規作成することで base プロジェクトのモデルの内部 ID と同一になることがありません。)
ファイル名は ref3.asta です。
base.asta を開き、[ファイル]-[プロジェクトをマージ]を選択し、ref3.asta を選択します。
以下のようなダイアログが表示されます。
67 / 153
astah* チュートリアル
“詳細”ボタンをクリックします。コンフリクト(内部 ID 衝突)があるケースと異なる結果が表示されています。
要素が異なる理由が“名前が同じですが異なるモデルです”になっていて、作業中の要素が“C”、取込む要素が
“C”になっています。コンフリクト(内部 ID 衝突)のあるケースと異なり、名前が同じだが内容が異なるケースで
す。(内部 ID も異なる。)つまり、同じ名前空間(パッケージ)で同じ名前のコンフリクトと言えます。
では、“簡単マージ“ダイアログで”取込み中プロジェクト”を優先でマージします。
クラス“C”が取込み中の“C”になっていますね。(ref3.asth の C クラスの定義に ref が入っています。)
では、“簡単マージ“ダイアログで” 作業中プロジェクト”を優先でマージします。
68 / 153
astah* チュートリアル
クラス“C”はそのままですね。
コンフリクト(内部 ID 衝突)あるケースと同様に、内部の ID と名前の衝突するコンフリクトに注意してモデリング
することで、複雑なマージをより簡単にできます。
図のマージでの注意点を押さえておこう
astah*のマージでは、図に対して完全にマージする図と、図を”取込み中プロジェクト”もしくは” 作業中プロジェク
ト”から選び、一方の内容に置き換えられる図がありますので、このルールを理解したうえでマージされると上手に
マージできるでしょう。
図名
マージルール
クラス図
マージ
ユースケース図
マージ
ステートマシン図
作業中、取込み中の一方に置換
アクティビティ図
作業中、取込み中の一方に置換
シーケンス図
作業中、取込み中の一方に置換
コミュニケーション図
作業中、取込み中の一方に置換
コンポーネント図
マージ
配置図
マージ
合成構造図
マージ
フローチャート
作業中、取込み中の一方に置換
データフロー図(DFD)
作業中、取込み中の一方に置換
ER 図
マージ
CRUD
作業中、取込み中の一方に置換
マインドマップ
作業中、取込み中の一方に置換
69 / 153
astah* チュートリアル
要求テーブル
作業中、取込み中の一方に置換
トレーサビリティマップ
作業中、取込み中の一方に置換
マージ時には図のマージのルールも知っておくとスムーズにマージできます。
70 / 153
astah* チュートリアル
参照プロジェクト管理ってどんな機能？
使用できるエディション： astah* professional
デモ動画：http://astah.change-vision.com/ja/movie.html#reference-project
複数人でモデルを編集するための補助機能が、参照プロジェクトです。
プロジェクトから複数のプロジェクトを参照し、”取込み中プロジェクト”優先でマージし、参照するプロジェクト
にあるモデルを読み取り専用のモデルにする機構です。
参照先のファイルのタイムスタンプかモデルのタイムスタンプが変更されれば、参照元から更新ができます。
(タイムスタンプの設定については、[ツール]-[システムプロパティ]-[プロジェクトのマージ]-[参照プロジェクト更新
時にファイルのタイムスタンプでなく、モデルのタイムスタンプを使う] (デフォルトは 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
参照プロジェクト管理を使ってみよう
71 / 153
astah* チュートリアル
例えば、以下の手順でプロジェクト分割すると、スムーズにマージすることができます。
(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”パッケージを作
成し、読み取り専用の”共通”モデルを使用しながら、モデリングします。
72 / 153
astah* チュートリアル
3. 場合によっては、CVS、SVN、VSS などの構成管理ツールと組み合わせると良いかもしれません。
注意点として、構成管理ツールでチェックアウトした後のファイルのタイムスタンプは、チェックアウト時の
タイムスタンプになっています。参照プロジェクト管理では、ファイルのタイムスタンプが変更されると更新
を促されます。こういうケースのために、astah*ではモデルのタイムスタンプを用意しています。astah*で保存
したときのタイムスタンプを asta ファイルの中に埋め込み、参照プロジェクトでモデルのタイムスタンプを使
用できる機構も用意されています。
73 / 153
astah* チュートリアル
[ツール]-[システムプロパティ]-[プロジェクトのマージ]-[参照プロジェクト更新時にファイルのタイムスタンプ
でなく、モデルのタイムスタンプを使う](デフォルトは OFF)
モデルのタイムスタンプは、プロジェクトのプロパティビュー”バージョン履歴“の”モデルのタイムスタンプ”
で確認できます。
また、コミットするときのコメントに、プロジェクトの簡易比較で出力されるテキストのモデルの DIFF を張
り付けてもいいかもしれませんね。
4. メンバ内で作業中に共通部分に編集が必要になった場合は、common.asta を変更し、保存します。
編集が終われば、メンバに通知し、それぞれのファイルを開き、common.asta を更新します。
74 / 153
astah* チュートリアル
5. 最後に A さん、B さん、C さんのモデリングが確定したら、参照モデルを解除し、それぞれを a2.asta、b2.asta、
c2.asta として保存します。
75 / 153
astah* チュートリアル
最終成果物として a2.asta を fixed.asta として保存します。b2.asta、c2.asta を取込み中プロジェクト優先で簡
単マージします。
最後に、fixed.asta から common.asta を参照します。“共通“パッケージ配下が読み取り専用のアイコンが表
示されています。
これで求めるモデルを作成できましたね。
76 / 153
astah* チュートリアル
「参照プロジェクトを使用する上でのポイント」
・共通化にするモデルのスコープや担当を明確にし、早期に共通モデルを FIX することが重要です。
・構成管理ツールを使用する場合は、モデルのタイムスタンプを使用しましょう。(システムプロパティで設
定)
77 / 153
astah* チュートリアル
要求を整理してみよう
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/
SYSML での各図
SysML 図類は、図 4.4 に示されます。
78 / 153
astah* チュートリアル
ピンクの点線で囲まれた要求図(Requirement Diagram),パラメトリック図(Parametric Diagram)が新規図で、太枠の
アクティビティ図が UML2 の拡張、太枠で文字が緑のブロック定義図(Block Definition Diagram)は UML2 のクラス
図の拡張の新規図、内部ブロック図(Internal Block Diagram) は UML2 の合成構造図の拡張の新規図です。
引用：OMG SysML1.1 仕様書 P11
http://www.omg.org/spec/SysML/1.1/changebar/PDF/
79 / 153
astah* チュートリアル
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
デモ動画：http://astah.change-vision.com/ja/movie.html#requirement-diagram
80 / 153
astah* チュートリアル
どんな要求があるかと、要求間の関係を定義する図です。
導出、コピー、満足、検証、洗練、トレース
使用できるエディション： 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
http://www.omg.org/spec/SysML/1.1/changebar/PDF/
81 / 153
astah* チュートリアル
コピー <<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*では、モデル※から要求に引くことができます。
モデル※とは以下を示します。
パッケージ、モデル、サブシステム、クラス、関連クラス、インターフェース、
エンティティ、コントロール、バウンダリ、アクター、ユースケース
82 / 153
astah* チュートリアル
コンポーネント、成果物、ノード、要求、テストケース
要求のプロパティビューの”依存元”タブ、”依存先” タブ、テストケースのプロパティビューの”依存先” タブ、もし
くは、要求テーブルの要求のポップアップメニュー”依存元の設定”、”依存先の設定”から追加できます。
A Satisfy relationship is a dependency between a requirement and a model element that fulfills the requirement. As
with other dependencies, the arrow direction points from the satisfying (client) model element to the (supplier)
requirement that is satisfied.
引用：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
http://www.omg.org/spec/SysML/1.1/changebar/PDF/
83 / 153
astah* チュートリアル
洗練とは、モデルから要求に詳細化する依存関係です。他の依存関係と同様に、矢方向は、クライアントモデルか
らサプライヤ要求の方向を示します。
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/
84 / 153
astah* チュートリアル
これと同等のモデルを書いてみます。
要求のモデルや、要求図と要求テーブルのそれぞれで表現できますが、ここではまず要求図を作成してみましょう。
まず、図メニューから“要求図”を選択し、要求図を作成します。
エディタのボタンから“要求”作成ボタンをクリックし、図上に要求を作成します。要求名、要求の ID を入力しま
す。Text の項目には、その要求の説明を入力します。（astah*では、ID と Text の順序が例と異なります）
85 / 153
astah* チュートリアル
同様に他の要求についても作成します。次に、要求間の関係を作成してみましょう。
要求間の導出関係とネスト関係を、それぞれ、ツールバーのボタンを押して、作成します。
ネスト関係については、作成時に、親子関係が変わることを、構造ツリーで確認できると思います。
ここまでで、例の要求図が完成しました。図だと要求間の関係を一目で把握できますね。
86 / 153
astah* チュートリアル
これらの要求と分析・設計モデルとの関係も定義してみましょう。具体的な例ではないですが、もし UsecaseA が
Pavement friction を満足する関係があり、TestCaseA が、Pavement friction を検証する関係である場合は、次のよ
うに図上で表現することもできます。ユースケースやクラスを構造ツリーから図にドラッグアンドドロップして配
置しています。
また、下の図のようにパッケージを指定して、要求テーブルを作成することもできます。
87 / 153
astah* チュートリアル
要求図を書く時に作成されたモデルから、次のような要求テーブルが作成されます。要求テーブルは、ネームスペ
ース毎に一つ作成可能で、その配下に存在する要求が自動的にリストに表示されるようになっています。
要求図と要求テーブルでは同一のモデルが利用されますので、一方で変更すればもう一方にも反映されます。また、
それぞれのポップアップメニューから、図やテーブルに相互にジャンプ可能になっています。
さて、同等のモデルをはじめから要求テーブルを使用して作成する場合を見てみましょう。次のような手順になり
ます。
まず、図メニューから”要求テーブル”を選択し、要求テーブルを作成します。
要求テーブルを右クリックしてポップアップメニューから”要求の追加”で
Adhesion utilization, Vehicle conditions, Test and procedure conditions, Pavement friction, ASTM R1337-90
の要求を追加していきます。
88 / 153
astah* チュートリアル
要求テーブルからは ID、名前、テキストの編集のほかに、要求を選択し、以下の操作も可能です。
・子要求の追加
・兄弟要求の追加
・依存元の設定
・ユースケースへの変換
Vehicle conditions は Adhesion utilization とネスト関係がありますので、ポップアップメニューから”子要求の追加”
から追加します。Test and procedure conditions も同様です。
また、Test and procedure conditions から Pavement friction、Pavement friction から ASTM R1337-90 へ導出
<<deriveRept>>でつながっていますので、ポップアップメニューから”依存先の設定”から追加します。(“依存元の
設定”でも可能です。) ちなみに、導出<<deriveRept>>とは、要件から別の要件が導き出される関係のことです。
89 / 153
astah* チュートリアル
以下が作成したモデルです。
要求テーブルと要求図の両方を使って、それぞれの利点を活かすといいですね。
要求図と要求テーブルを使用して要求をモデリング [WEB 系サンプル ]しよう
使用できるエディション： astah* professional
ここでは、ストーリー仕立てで要求モデリングしていきたいと思います。
「登場人物」
プロジェクトマネージャー A さん
営業
X さん
開発リーダー
B さん
要求開発リーダー
R さん
プロジェクトマネージャーである A さんは、営業 X さんと取引先に新案件の打ち合わせに行きました。
A さんは、いつものように PC を起動しマインドマップでヒアリングを開始しました。
90 / 153
astah* チュートリアル
どうやらいつもの WEB アプリケーションのようです。顧客はいつもおざなりになりがちな非機能要件周り、レス
ポンスやセキュリティ、障害対策について注意してほしいとのことでした。機能要件については、ログイン程度簡
単なものにとどまり、打ち合わせも無事終了しました。作成したマインドマップは以下です。
プロジェクトマネージャーA さんは、会社に戻り、さっそく以下のようなユースケースを書いてみました。
91 / 153
astah* チュートリアル
その後、プロジェクトマネージャーA さんはヒアリングした要求を機能要件、非機能要件もまとめて、要求の機能
をまとめてみることにしました。頭のなかに浮かんだのは以下のモデルです。
プロジェクトマネージャーA さんは要求テーブルからネスト関係を考慮しながら、要求を入力していきました。
92 / 153
astah* チュートリアル
次に要求間の依存関係を設定していきます。
先ほど軽く、ユースケース分析をしていました。ユースケースの"ログインする"の詳細は、要求の"ログインボタン
"にあたります。このように機能要件のユースケースから機能要件の要求に対して詳細化するという意味合いの洗練
<<refine>>を引くことができます。このように既存の UML のダイアグラムと関連し合っているため、この様に可
視化することにより、仕様の共有化に一役買うことにもなるでしょう。操作方法は、要求テーブル上で依存を張り
たい要求を選択し、ポップアップメニューから”依存先の設定”から追加します。(“依存元の設定”でも可能です。)
また、プロジェクトマネージャーA さんは顧客からログイン時のレスポンスやセキュリティの要求に注意するよう
に言われていたのを思い出しました。非機能要件を満たせないと顧客から信頼をなくしかねません。
機能要件の要求"ログインボタン"は、非機能要件の要求"レスポンス要求"、"セキュリティ要求"を導き出しています。
同様に機能要件の要求"正常遷移"から機能要件の要求" XX 画面要求"へも同様です。
このように、導出<<deriveRept>>とは、要件から別の要件が導き出される関係のことを表します。
操作方法は、要求テーブル上で依存を張りたい要求を選択し、ポップアップメニューから”依存先の設定”から追加
します。(“依存元の設定”でも可能です。)
次にテストケースについて考えています。
テストケースは、astah*内でもモデルとして生成できます。実際のそのテストケースの内容ですが、自動テストに
するか EXCEL でテスト仕様書を書くのか現段階では決まっていませんが、ここは顧客・メンバと話し合うため、
成果物は何にするかは、懸案事項として置いておくとします。
93 / 153
astah* チュートリアル
ただ、自動テストならソースや結果のドキュメント、テスト仕様書なら、ドキュメントへ、シナリオならフローチ
ャートやアクティビティ図へのハイパーリンクを張るのか、またはテストケースの定義に書くのかなど、事前にプ
ロジェクトで話し合ってよりよい合意をとったほうがよさそうです。
プロジェクトマネージャーA さんは、この点をメモしておき、開発リーダーB さんにテストケースの設計を指示し
ました。開発リーダーB さんは、まずネスト関係に注意しながら、テストケースを設計し始めました。
また、テストケースと要求間では、検証<<verify>>といって要求を満たすことをテストケースで検証するための依
存関係をはることができます。開発リーダーB さんは、プロジェクトマネージャーA さんが作ったモデルを自分の
モデルにマージし、検証関係を張っていきました。出来上がったモデルは、以下でした。
94 / 153
astah* チュートリアル
その後は、プロジェクトマネージャーA さんは要求開発リーダーの R さんに要求の詳細化を依頼しました。
要求開発リーダーR さんは、自身を中心に、要求開発グループで展開させるために、要求テーブルを EXCEL で出
力してチーム内の共有を開始しました。[ツール]-[要求]-[要求テーブルを Excel ファイルに出力]で出力できます。
95 / 153
astah* チュートリアル
出力ダイアログが表示されます。
出力された Excel は以下の通りです。
要求テーブルを Excel 形式で受け取った要求開発チームは、要求の階層化と要求テーブルの書式やルール決めを行
い、要求をつめていきました。詳細化された Excel ファイルをプロジェクトマネージャーA さんが持つプロジェク
トファイルに、Excel 入力の機能を使用し、反映しました。
[ツール]-[要求]-[要求テーブルを Excel ファイルに入力]で行います。
96 / 153
astah* チュートリアル
要求テーブルの入力時には、まず ID が同じ要求を同一の要求とし、次に名前が等しい要求を同一の要求として更新
します。
要求が固まってきたところで、プロジェクトマネージャーA さんは、要求開発リーダーR さんとレビューを繰り返
し、要求を具体化していきました。その後、明確化された要求を元に開発リーダーB さん中心に実装とテストケー
スを作成していきました。
[要求の機能のポイント]
SysML では主に組み込み系を想定ターゲットとしていますが、それ以外のソフトウェア分野にも汎用的に利用
できるものです。忘れられがちな非機能要件について初期の段階から強く意識できることなども要求モデリ
ングの魅力の一つです。
また、astah で要求モデルを扱う利点は、要求間の関係を図示しやすいことと、要求とモデルの間の関係につ
いても管理しやすくなることです。
97 / 153
astah* チュートリアル
言語サポート機能を使ってみよう
使用できるエディション： astah* professional、astah* UML
astah*では、基本的によく使用される基本的な言語 Java、C++、C#に対応されています。
JAVA
使用できるエディション： astah* professional、astah* UML
JAVA 基本機能
プロジェクトの言語設定をしてみよう
プロジェクトの言語設定は、プロパティビュー、または、システムプロパティで設定します。
プロジェクトのプロパティビュー[プロジェクトの設定]タブ
[ツール]-[システムプロパティ]-[ファイル]-[プロジェクトの新規作成時の言語]-[Java]
JAVA 言語固有の設定をしてみよう
クラス、属性、操作の[言語]タブ（プロパティビュー）で、Java 言語固有の設定が可能です。
[クラス]
[属性]
98 / 153
astah* チュートリアル
99 / 153
astah* チュートリアル
JAVA のデフォルトモデルを使ってみよう
astah* professional インストールフォルダ¥ template¥project¥ Java1.4.asta
astah* professional インストールフォルダ¥ template¥project¥ Java5.asta
システムプロパティでデフォルトモデルを設定していない場合は、[ファイル]-[テンプレートからプロジェクトの新
規作成]-[ Java1.4.asta]または[Java5.asta]を選択します。
以下のような内容です。
[Java5.asta]
[Java1.4.asta]
またシステムプロパティで新規プロジェクト作成時のデフォルトモデルの設定もできます。
100 / 153
astah* チュートリアル
JAVA スケルトンコードを作成してみよう
作成したモデルから Java のスケルトンコードを出力できます。
インストールフォルダ配下の Sample.asta を開いて出力してみましょう。
メインメニューの[ツール] - [Java] - [Java スケルトンコードの作成]を選択します。
101 / 153
astah* チュートリアル
Class パッケージの直下のソースを出力してみます。
以下のように出力されましたね。
Monitor.java を開いてみます。
102 / 153
astah* チュートリアル
正しく出力されていることがわかりますね。
JAVA ソースコードの読み込みをしてみよう
今度はプロジェクトを新規作成し、前章で出力したソースをリバースしてみます。
(1) プロジェクトを開き(または、新規作成し)、メインメニューの[ツール] - [Java ソースコードの読み込み] を選
択します。
(2) Java ファイル選択ダイアログで、Java のファイルを選択します。
(3) Java のソースコードよりパッケージやクラスのモデルを生成します。
リバース時には関連にしたい属性を指定することもできます。
以下のダイアログで Close ボタンをクリックすると終了です。
103 / 153
astah* チュートリアル
以下のようにリバースされました。
(4)リバースしただけではクラス図は作成されませんので、生成したモデルからクラス図を自動作成します。
構造ツリーのプロジェクトのポップアップメニューより以下のメニューを選択します。
104 / 153
astah* チュートリアル
- [クラス図を自動作成する]
- [詳細クラス図を自動作成する]
以下のようにクラス図が自動生成されました。
105 / 153
astah* チュートリアル
C++
使用できるエディション： astah* professional、astah* UML
C++基本機能
プロジェクトの言語設定をしてみよう
プロジェクトの言語設定は、プロパティビュー、または、システムプロパティで設定します。
プロジェクトのプロパティビュー[プロジェクトの設定]タブ
[ツール]-[システムプロパティ]-[ファイル]-[プロジェクトの新規作成時の言語]-[C++]
C++言語固有の設定をしてみよう
クラス、属性、操作の[言語]タブ（プロパティビュー）で、C++言語固有の設定が可能です。
[クラス]
[属性]
[操作]
106 / 153
astah* チュートリアル
C++用のデフォルトモデルを使ってみよう
astah* professional インストールフォルダ¥ template¥project¥ C++.asta
システムプロパティでデフォルトモデルを設定していない場合は、[ファイル]-[テンプレートからプロジェクトの新
規作成]-[ C++.asta]を選択します。
以下のような内容です。
またシステムプロパティで新規プロジェクト作成時のデフォルトモデルの設定もできます。
107 / 153
astah* チュートリアル
型修飾子（*、&等、ポインタ情報）を使ってみよう
プロパティビューより型修飾子を入力できます。型修飾子はダイアグラムエディタ上でクラスや属性等の図要素
に表示されます。HTML 出力や RTF 出力にも対応しています。
C++ プリミティブ型の対応
108 / 153
astah* チュートリアル
各プリミティブ型に対応しています。
bool / char / signed char / unsigned char / short / unsigned short / short int / signed short int / unsigned short int /
int / signed int / unsigned int / long / unsigned long / long int / signed long int / unsigned long int / float / double /
long double / wchar_t
C++スケルトンコードを作成をしてみよう
使用できるエディション： astah* professional、astah* UML
インストールフォルダ配下の Sample.asta を開いて、プロジェクトのプロパティビューの"プロジェクトの設定"で
C++を ON にします。
以下の MSG ではいを選択します。
メインメニューの[ツール] - [C++] - [C++スケルトンコードの作成]を選択します。
109 / 153
astah* チュートリアル
Class パッケージの直下のソースを出力してみます。
またオプションに次があります。
以下のようにヘッダーファイル、ソースファイルともに、出力されましたね。
110 / 153
astah* チュートリアル
Monitor.h を開いてみます。
Monitor.cpp を開いてみます。
111 / 153
astah* チュートリアル
正しく出力されていることがわかりますね。
112 / 153
astah* チュートリアル
C++リバースをしてみよう（サンプル、サポート対象外）
使用できる製品: astah* professional
[使用方法]
詳しい使用法は astah* C++リバース利用ガイドをご参照ください。
astah* professional インストールフォルダ¥api¥sample¥sample_doxygen_c_plus¥sample_doxygen_c_plus.html
[イメージ]
Doxygen
ソース
リバースツール
XML
*.asta
[Doxygen を利用してリバース]
[C++のスケルトンコードを作成]の章で出力したソースを Doxygen を使用し、XML に変換します。
113 / 153
astah* チュートリアル
読み込みソースパス配下のファイルがすべて対象な時には RECUSIVE のチェックが必要なので、注意してくださ
い。また、ソースのエンコードもファイルのエンコードと揃えてください。
また、ヘッダーファイルのパスも追加するのも重要です。
[Doxygen の設定ポイント]
特に以下に注意してください。
・[Expert]-[Input]-[RECURSIVE]
・[Expert]-[Input]-[INPUT_ENCORDING]
・[Expert]-[Preprocessor]-[INCLUDE PATH]
以下のように出力されました。
114 / 153
astah* チュートリアル
これを API サンプルを経由してプロジェクトを作成します。作成した結果を開いてみます。
115 / 153
astah* チュートリアル
この時点ではクラス図がないため、クラス図を自動生成してみます。
次のようにクラス図が自動生成されました。
116 / 153
astah* チュートリアル
リバース前のクラス図と比較するため、移動と色付けをします。
これがフォワード前のモデルです。
117 / 153
astah* チュートリアル
比較するとグローバルな Global クラスがあります。これは C++では、クラスに属さないメソッド等が生成される
ため、リバース時に各名前空間に Global クラスが生成されます。
また、Tracer クラスと Engine クラス、Tracer クラスと Steering クラス、Tracer クラスと Monitor クラス、Tracer
クラスと State クラスの関連がありませんが、その代わり、Tracer クラスには、属性として、Engine クラス、Steering
クラス、Monitor クラス、State クラスを持ち、逆参照も付加されます。UML2.0 では属性も関連もプロパティとい
う概念になり、意味合いは同じです。
また、Monitor クラスと Engine クラス、Monitor クラスと Steering クラスの関連がないこと
Monitor クラスと LightSensor クラスの関連がないことも同じです。
118 / 153
astah* チュートリアル
C#
使用できるエディション： astah* professional、astah* UML
C#基本機能
プロジェクトの言語設定をしてみよう
プロジェクトの言語設定は、プロパティビュー、または、システムプロパティで設定します。
プロジェクトのプロパティビュー[プロジェクトの設定]タブ
[ツール]-[システムプロパティ]-[ファイル]-[プロジェクトの新規作成時の言語]-[C#]
C＃言語固有の設定をしてみよう
クラス、属性、操作の[言語]タブ（プロパティビュー）で、C#言語固有の設定が可能です。
[クラス]
[属性]
119 / 153
astah* チュートリアル
[操作]
120 / 153
astah* チュートリアル
C#用のデフォルトモデルを使ってみよう
astah* professional インストールフォルダ¥ template¥project¥ C_Sharp.asta
システムプロパティでデフォルトモデルを設定していない場合は、[ファイル]-[テンプレートからプロジェクトの新
規作成]-[ C_Sharp.asta]を選択します。
以下のような内容です。
またシステムプロパティで新規プロジェクト作成時のデフォルトモデルを設定できます。
121 / 153
astah* チュートリアル
C# プリミティブ型の対応
各プリミティブ型に対応しています。
bool / byte / char / decimal / double / float / int / long / object / sbyte / short / string / uint / ulong / ushort
C#スケルトンコードを作成してみよう
使用できるエディション： astah* professional、astah* UML
インストールフォルダ配下の Sample.asta を開いて、プロジェクトのプロパティビューの"プロジェクトの設定"で
C#を ON にします。
以下の MSG ではいを選択します。
122 / 153
astah* チュートリアル
メインメニューの[ツール] - [C#] - [C#スケルトンコードの作成]を選択します。
Class パッケージの直下のソースを出力してみます。
またオプションに次があります。
123 / 153
astah* チュートリアル
以下のように出力されましたね。
Monitor.cs を開いてみます。
正しく出力されていることがわかりますね。
124 / 153
astah* チュートリアル
C#リバースをしてみよう（サンプル、サポート対象外）
使用できる製品: astah* professional
[使用方法]
詳しい使用法は astah* C#リバース利用ガイドをご参照ください。
astah* professional インストールフォルダ¥api¥sample¥sample_doxygen_c_sharp¥sample_doxygen_c_sharp.html
[使用イメージ]
Doxygen
ソース
リバースツール
XML
*.asta
[Doxygen を利用してリバース]
[C#のスケルトンコードを作成]の章で出力したソースを Doxygen を使用し、XML に変換します。
読み込みソースパス配下のファイルがすべて対象な時には RECUSIVE のチェックが必要なので、注意してくださ
い。また、ソースのエンコードもファイルのエンコードと揃えてください。
125 / 153
astah* チュートリアル
以下のように出力されました。
126 / 153
astah* チュートリアル
これを API サンプルを経由してプロジェクトを作成します。
作成した結果を開いてみます。
127 / 153
astah* チュートリアル
この時点ではクラス図がないため、クラス図を自動生成してみます。
次のようにクラス図が自動生成されました。
128 / 153
astah* チュートリアル
リバース前のクラス図と比較するため、移動と色付けをします。
これがフォワード前のモデルです。
129 / 153
astah* チュートリアル
Tracer クラスと Engine クラス、Tracer クラスと Steering クラス、Tracer クラスと Monitor クラス、Tracer クラ
スと State クラスの関連がありませんが、その代わり、Tracer クラスには、属性として、Engine クラス、Steering
クラス、Monitor クラス、State クラスを持ち、逆参照も付加されます。UML2.0 では属性も関連もプロパティとい
う概念になり、意味合いは同じです。
また、Monitor クラスと Engine クラス、Monitor クラスと Steering クラスの関連がないこと、Monitor クラスと
LightSensor クラスの関連がないことも同じです。
130 / 153
astah* チュートリアル
構造化分析しよう
構造化分析とは
構造化分析(Structured Analysis)は、トム・デマルコによって考案され、1970 年代後半から普及した要求を階層的
に設計していく分析手法です。構造化分析では、データフロー図（DFD）、データディクショナリ、ミニ仕様書と
いったツールを利用します。
ツール
概要
astah*での対応
データフロー図（DFD）データの流れを表現する図
デマルコ式/ゲイン・サーソン式で編集可能。
外部エンティティ、プロセス、データスト
ア、アンカー、データフローが表現可能。
データディクショナリ
システムのデータのディクショナリ(辞
astah*では未対応。
書)で、データフローの詳細な構成内容を
記載するもの
ミニ仕様書
プロセスにつき１つ、プロセスの基本機
astah*では未対応ですが、
能について記述する仕様書のこと
Excel で作成し、ハイパーリンクを張るなど
という対応も可能。
参考書籍：
『構造化分析とシステム仕様』日経 BP 出版センター
トム・デマルコ著
実際には、これだけでは多種多様なデータを扱うには適さず、大規模な開発ではむしろデータを中心に据えたオブ
ジェクト指向に関心が移る事となった。しかし部分部分の処理分割では構造化が基本であり、オブジェクト指向と
構造化プログラミングが対立しているわけではない。理想的な構造化プログラミングに、データの多態と継承など
のオブジェクト関係性を扱う能力を持たせると、ほとんどオブジェクト指向と区別がつかないものとなり、パラダ
イムとしては案外に隣り合わせの関係にあることが分かる。
引用:
構造化プログラミング. (2009, 9 月 27). Wikipedia, . Retrieved 07:45, 11 月 11, 2009 from
http://ja.wikipedia.org/w/index.php?title=%E6%A7%8B%E9%80%A0%E5%8C%96%E3%83%97%E3%83%AD
%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0&oldid=28206959.
131 / 153
astah* チュートリアル
DFD(データフロー図 )
使用できるエディション： astah* professional
デモ動画：http://astah.change-vision.com/ja/movie.html#dataflow-diagram
データの入出力や流れを可視化する図です。
astah* の DFD の主な機能は以下の通りです。
・DFD 作成（外部エンティティ、プロセス、データストア、データフロー）
・デマルコ式、ゲイン・サーソン式の両記法
・CRUD との連携（機能軸に DFD を指定）
・Excel にプロセスの階層表を出力
・UML との連携（外部エンティティからアクターへの変換、プロセスからユースケースへの変換）
・ER 図との連携（データストアから ER エンティティに変換、データフローから ER エンティティに変換）
・マインドマップとの連携（トピックから、DFD の図要素への変換）
・外部エンティティ、データストアに別名指定
132 / 153
astah* チュートリアル
DFD(データフロー図 )を使ってみよう
インストールフォルダ配下の Sample.asta を開いて出力してみましょう。４つの DFD がありますね。
システムプロパティの[プロジェクトビュー]-[階層ツリーの表示(要再起動)]を ON にして astah*を再起動します。
左のプロジェクトビューの”階層ツリー“を表示します。
133 / 153
astah* チュートリアル
これらの図は階層化されていることを意味します。
例えば、” 0. Withdrawal service of saving account[Context]”図の“Withdrawal service of saving account”プロセス
を選択して、右プリックして、ポップアップメニューの“図を開く”を選択します。
(“Withdrawal service of saving account”プロセスをダブルクリックでもかまいません。)
一階層下の“00.Withdrawal service of saving account”が開かれます。
つまり、上の階層のプロセスの詳細化した図であることを意味しています。
134 / 153
astah* チュートリアル
同様に、” 00.Withdrawal service of saving account”図の“Customer Certification”プロセスを選択してダブルクリ
ックします。(“Customer Certification”プロセスの右プリックして、ポップアップメニューの“図を開く”でもか
まいません。)
一階層下の“1. Customer Certification”が開かれます。
135 / 153
astah* チュートリアル
また、一階層上の図” 00.Withdrawal service of saving account”に戻り
“Confirm Balance”プロセスを選択して、右プリックして、ポップアップメニューの“データフロー図(DFD)を
作成する”を選択します。(“Confirm Balance”プロセスをダブルクリックでもかまいません。)
以下のように、階層化関係を持つ新しい DFD が作成されました。
136 / 153
astah* チュートリアル
このように階層構造を意識しならがモデリングできるような仕組みになっています。
[データフロー図(DFD)作成ポイント]
階層関係を意識しながらモデリングすることが重要です。
137 / 153
astah* チュートリアル
フローチャートを使ってみよう
使用できるエディション： astah* professional
デモ動画：http://astah.change-vision.com/ja/movie.html#flowchart
astah* のフローチャートの主な機能は以下の通りです。
・フローチャート作成
・フローチャートのテンプレート
・図要素のパレットを利用した作図
・フロー記号のテンプレート
・フロー要素からユースケースの作成
・レーンからアクターの作成
インストールフォルダ配下の Sample.asta を開いて出力してみましょう。
画面左にフロー記号パレットが表示されていますね。
このようにデフォルトでサーバーや端末のようなアイコンでフローチャートを書けるようになっています。
また、産能式(産能大式事務工程分析図表の記号)と呼ばれるものにも対応しています。
138 / 153
astah* チュートリアル
また、フロー記号パレットを作成できます。
[ツール]-[テンプレートの設定]-[フロー記号]を選択し、追加ボタンをクリックします。
設定ファイルを保存する場所を選択します。
139 / 153
astah* チュートリアル
“フロー記号点テンプレートの設定”ダイアログに戻ります。
編集ボタンをクリックします。” フロー記号点テンプレートの編集”ダイアログが表示されます。
追加ボタンをクリックします。
使用するイメージを選択し、開くボタンをクリックします。
140 / 153
astah* チュートリアル
アイコンが追加されました。
了解ボタンをクリックして、メイン画面に戻ります。フロー記号パレットに新しいタブと追加したアイコンが追加
され、フローチャートの編集に使用できるようになります。
141 / 153
astah* チュートリアル
トレーサビリティマップを使ってみよう
使用できるエディション： astah* professional
デモ動画：http://astah.change-vision.com/ja/movie.html#traceability-map
astah* では、選択したモデルがどの図で使用されているか、どのモデルに関連しているかというような、モデルの
影響範囲を可視化するトレーサビリティマップを用意しました。モデルのトレーサビリティ（追跡可能性）を把握
でき、スムーズなモデリングをサポートします。
インストールフォルダ配下の Sample.asta を開いて出力してみましょう。
この図の Tracer クラスについてどのモデルで参照されているか見てみましょう。
構造ツリーで Tracer クラスを選択し、“トレーサビリティマップを開く”を選択します。
以下のようなトレーサビリティマップが作成されました。
142 / 153
astah* チュートリアル
依存先と依存元描画している図などがグラフィヵルに表示されます。
モデル設計がパッケージをまたいで多数の個所から参照されているときなどに有効です。
トレーサビリティマップで、どこまでたどって依存関係を表示するかは、システムプロパティや図のプロパティで
変更可能です（ver.6.1 より）。複雑なモデルの場合、表示する階層を大きくすると時間がかかることがあるのでご
注意ください。
143 / 153
astah* チュートリアル
納品資料としてのドキュメントを作成してみよう
RTF 出力してみよう
使用できるエディション： astah* professional、astah* UML、astah* think!
デモ動画：http://astah.change-vision.com/ja/movie.html#rtf-export
パッケージ、クラス、ユースケースの一覧、各図のイメージ、クラスの詳細（属性、操作）といったプロジェクト
の詳細なドキュメントをリッチテキスト形式で作成します。オプションで詳細なカスタマイズも可能で、納品ド
キュメントの作成などにも便利です。
例えば、java ソースコードを読みこんだプロジェクトをドキュメントに出力し、各クラスの概要を把握するといっ
た利用ができます。
インストールフォルダ配下の Sample.asta を開いて出力してみましょう。
ファイルを開き、[ツール]-[RTF ドキュメント作成]を実行します。
次のようなダイアログが表示されます。
“オプション”ボタンをクリックします。出力用の様々な設定ができるようになっています。
144 / 153
astah* チュートリアル
では出力してみます。
納品用の資料やレビュー用にぜひご利用ください。
145 / 153
astah* チュートリアル
HTML 出力してみよう
使用できるエディション： astah* professional、astah* UML
作成したモデルををブラウザで閲覧できる HTML 形式で出力します。
y Javadoc 形式で、HTML ドキュメントを出力
y 図の出力が可能
y 図上のクラスのリンクから、クラスの詳細を参照可能
インストールフォルダ配下の Sample.asta を開いて出力してみましょう。
ファイルを開き、[ツール]-[HTML 作成(javadoc)]を実行します。
出力先のディレクトリを選択します。
出力が終わると次のような MSG が表示されます。
146 / 153
astah* チュートリアル
“はい”を選択して結果を開いてみます。
左上に”All Diagrams”というフレームが出力されますが、ここには、プロジェクトに含まれる図イメージが出力され
ます。
147 / 153
astah* チュートリアル
この出力は、[システムプロパティ]-[ファイル]-[HTML 作成時に図の情報を出力する] が ON のときに出力されます。
“All Diagrams”の”Class Digram”のリンクをクリックしてみます。
148 / 153
astah* チュートリアル
図の”Tracer”をクリックしてみます。
“Tracer”クラスの詳細に遷移しましたね。
例えば、完成された API 群をプロジェクト内部で仕様を展開するときなどに、作成しておくと便利ですね。
149 / 153
astah* チュートリアル
便利な機能を使ってみよう
図上でマウスを使ってスクロール
使用できるエディション： astah* professional、astah* UML、astah* think!、astah* community
図上で右クリックしながらマウスを移動させると、画面がスクロールします。大きな図を編集するときに重宝しま
す。また、Ctrl を押しながらマウスホィールを動かすと図を拡大・縮小できます。
編集を取り消す (UNDO)
使用できるエディション： astah* professional、astah* UML、astah* think!、astah* community
astah*はしっかりした Undo（編集の取り消し）、Redo（編集のやり直し）機構を持っていて、 100 回前の編集ま
で取り消すことが可能です。この回数はシステムプロパティから変更できます。
[ツール]-[システムプロパティ]-[その他]-[編集の取り消しの最大回数]
モデルから図へのジャンプ
使用できるエディション： astah* professional、astah* UML、astah* think!
デモ動画：http://astah.change-vision.com/ja/movie.html#model-to-diagram
大きなモデルの設計中は、構造ツリー上のどのモデルがどの図に書かれているか分かりにくくなりがちです。
astah*では、構造ツリーのポップアップメニュー[図要素へジャンプ]から参照されている図へジャンプできます。
150 / 153
astah* チュートリアル
図からツリーへのジャンプ
使用できるエディション： astah* professional、astah* UML、astah* think!
デモ動画：http://astah.change-vision.com/ja/movie.html#model-to-diagram
大きなモデルの設計中は、図に書かれているモデルが構造ツリー上のどのモデルに該当するのかが分かりにくくな
りがちです。astah*では、図のポップアップメニュー[構造ツリー上のモデルへジャンプ]から、構造ツリーの元のモ
デルにジャンプできます。
151 / 153
astah* チュートリアル
152 / 153
API を使ってみよう
astah*では API も用意されており、プロジェクトファイルの内容を他のアプリケーションからも利用できます。
また以下の各種ドキュメントも参考にしてください。
[API 概要、XMI 入出力]
http://astah.change-vision.com/ja/astah-api.html
[API 利用ガイド]
astah*インストールフォルダ¥api¥doc¥index.html
[API の JavaDoc]
http://members.change-vision.com/javadoc/astah-api/6_0/api/ja/doc/javadoc/index.html
astah*インストールフォルダ¥api¥doc¥ javadoc¥index.html
[分析設計モデルをわがままに活用しよう JUDE API 入門 ]
http://codezine.jp/article/detail/3165
モデル参照 API
使用できるエディション： astah* professional、astah* UML、astah* community
モデル編集 API
使用できるエディション： astah* professional、astah* UML
図要素参照 API
使用できるエディション： astah* professional、astah* UML
図要素編集 API
使用できるエディション： astah* professional、astah* UML
API のサンプル
使用できるエディション： astah* professional、astah* UML、astah* community
astah* インストールフォルダ¥ api¥sample 配下にいくつかのサンプルがありますので参考にしてください。
153 / 153

Download Report