UMLでロボット設計とかを考える場合の例

一般的かどうかは知らない。こういうお話をきいた。

---

■全体的な位置づけ

要求分析

設計

・UMLでの設計
　　１．コンテキスト図
　　　　　システムレベル
　　　　　デバイスレベル

　　２．ユースケース図
　　　　　概略
　　　　　詳細

　　３．クラス図


　　４．状態遷移図

・検証
　　A.検証モデルの作成

　　B.ツールでの検証

　　C.反例分析（うまくいかなかったら、Aへ）

・実装

・検査

・デバッグ

---

■１．コンテキスト図
　システム全体を１つのクラスとし、それに対してアクターを書く、システムレベルでのコンテキスト図と、
　各デバイスをクラスとして、そのデバイス間の関係と、外部のアクター間との関係を書く、デバイスレベルのコンテキスト図がありえる。


■ユースケース図
　一般的な、アクターとソフトの機能を書いた、概略のユースケース図と、デバイスをアクターとしてしまい、デバイス間の振る舞いまで記述する詳細版がありえる。

■クラス図
　
　　ハッサン ゴマという人が、クラス図の分け方を研究しているらしい。

　　それはさておき、レイヤ構造で考える。
　　　今、デバイスをアクターとし、そのアクターに対応するクラスを、一番下にデバイス層として考える。
　　　その上に、ドライバ層を置く
　　　さらにその上に、実行・制御するクラスを置く
　　　一番上位にアプリ層になるのかな・・・

■状態遷移図
　そのあとの検証モデルが作りやすいように、状態遷移図を描く
　たとえば、Uppaalで検査するなら、時間を入れる必要がある。

---

ってお話を、きいた。めちゃくちゃ簡単にまとめると・・・

要求仕様書の書く内容をまとめてみる

IEEE８３０と外れているところがあるけど、
ま、こんな感じなのかしら・・・

---

第一章　はじめに

１．１　目的
　本仕様書は　～　の要求仕様書である。
　読者は　～　を想定している。

１．２　範囲

・位置づけ／強みなど
　　概要
　　目的・目標など

１．３　定義、略号など
　本仕様書で使用される図式の表記はUML　Ver2.0に準拠する
　：
　：

１．４　参考文献
　お客様より提供された要望書は、以下のとおりである
　　　：
　　　：（もらったドキュメントを記述）


第二章　概要

・（ここに、利用者がどんな考えを持っているかを書いてしまう
　　　リッチピクチャなどを入れる手もある。
　　その図に、２．３利用者特性の利用者が出てくるはず。
　　また、ここの内容のまとめが、１．２　範囲に対応しているはず。
　　その後、as-is（あれば）と、ToBeモデルのアクティビティ図が入る。
　　スイムレーンに上記利用者がいるはず）。

２．１　製品の範囲
　・全体像
　・インターフェース

２．２　システム化境界とシステム機能
　・ユースケース図とその説明
　　とくに、今回開発しない部分があれば、そこの指摘
　　ユースケース図と、ToBeモデルのアクティビティ図に矛盾がないこと

２．３　利用者特性
　利用者とその人たちについて考慮しないといけないことなど
　利用者自体は、アクティビティ図（のスイムレーン）、ユースケース図（のアクター）に出ていると思われる。

第３章

３．１　前提条件
　前提条件を書く

３．２　制約
　非機能要件など

＜＜ここに状態遷移図あり＞＞

３．３～
ユースケース：ユースケースシナリオの記述を書く

３．最後　設計制約
設計上の制約（ブラウザ、OSなど）を書く

---

こんなかんじかしら・・・

画面遷移の汎用ツールとしてのStrutsIDE、Astah*の利用

　こんな、サイトがありました
画面遷移の仕様を「画面遷移表」で検算 ─ その1
http://blog.livedoor.jp/prjmng/archives/52141200.html

たしかに、画面遷移図と、各画面定義での記述がずれることがありますね・・・
そういう意味では、一元管理するには、strutsにおける画面遷移定義、struts-config.xmlを
GUIで作成するフリーソフト、StrutsIDEを（Struts以外でも）使うと便利かも？

・・・って、思った。

StrutsIDEは、Amaterasプロジェクトの１つで、
Struts作成のサポートをしてくれる。
　で、Strutsにおける画面遷移とかを記述した、struts-config.xmlを生成する画面とかも
提供してくれている（もちろん、他の機能も提供している）

　その画面は、こんなかんじ。

　ここで、JSPを画面(JSP)、ボタンがアクション（ギアみたいになっているの）と考えると、
上図のように、画面遷移が書ける。

　Strutsの場合は、日本語じゃあ、日本語クラス名をJavaではかけないのでだめだけど、
Java以外で利用する気なら、上図のように、日本語でわかりやすくしてOK!

　画面のハードコピー（PrintScrnボタンを押すと画面がハードコピーできるやつ）で画面遷移図
をとるという形。まあ、部分部分に分けて書いてもいいしね・・・

---

　で、画面レイアウトだけど、このレイアウトは、JSPないしはHTMLで書くことになる。
　ここで、上位の設計と連携させるなら、Astah＊のクラス図を画面と対応させて

　　　　クラス　＝１画面
　　　　属性　　＝画面の項目
　　　　メソッド＝画面のボタン（ないしはアクション）

　とすると、Astah＊のXMI出力で書き出されるXMLから、画面（JSP)と、入出力項目はでてくる。

　そこで、

　　　・入出力項目をデザイン関係なしに、JSPないしはHTML出力し、
　　　・画面と、メソッドをもとに、Struts－config.xmlを出力する

　プログラムを作っちゃえば、

１．Astah＊で画面と項目定義をして
（ICONIXのバウンダリはAstah＊ではクラスとして表現されるので、
　ICONIXを利用する場合は、そのバウンダリを属性、メソッドをいれて
　詳細化すればよい）
　　　　
２．それをXMI出力して、上記プログラムに入れると、

３．画面レイアウト部分のJSPと、Struts-config.xmlの画面とアクションが入ったのが出来るので

４．そのStruts-config.xmlをStrutsIDE上から、画面とアクションを→でつないで、完成させ、
　　画面遷移図とし、

５．画面レイアウト部分は、ちゃんとデザインすればよい。

６．なお、画面定義で記述する項目、ボタンについての説明は、Astah*の、
　　　項目については、「属性」の「ベース」の「定義」に、
　　　ボタンについては、「操作」の「ベース」の「定義」に
　　それぞれ書くようにする。
　　その内容が、「属性」については、JSP中、コメントとして、
　　「操作」については、Struts-configのアクションのコメントとして
　　書き出される。

７．画面遷移表は、Struts-configの内容を表形式にしたもの。
　　このように、必要なドキュメントは、struts-configとか、HTMLとかから
　　自動生成するようにする。

---

　とすれば、GUIで操作して、一元管理で画面遷移を管理できる。
　Struts関係なしに、この機能は、便利便利なのだ！

1月16日(日)のつぶやき

02:13 from web
このネーミングがすごい？「コミュニティラジオ きたくなるまち」 http://radikita.kitaku.net/
12:32 from web
生活って、「生命の活性化」の意味だったの（＠＿＠！）
by xmldtp on Twitter