SPINについて（概要）

■SPINについて
・SPINは、モデル検査ツールの１つ
・プロセス単位で手続き的にモデルを記述

＜＜モデル検査ツール＞＞
　　有限状態モデル＋対象システムが満たすべき性質
　　　　　　↓
　　　モデル検査ツール
　　　　　　↓
　　　成り立つ？成り立たないとき反例
　　　シュミレーション

モデル検査の例：SPIN,SMV,LTSA,UPPAAL、Java Path Finder
SPINは、
・デッドロック検証
・PLTL式検証のほか、
・表明（アサーション）や、ループ進行性のパラメタをいれて、検証できる
　　　・progress
　　　・never
　　　・assert（ブール式）

---

■モデル検査で扱う「システムの性質」とは？

・到達可能性
　　　→ある状態に到達する
・安全性
　　　→デッドロックにならないなど
　　　　望ましくない状態に陥らない
・活性
　　　→望ましい状態にかならず到達する
・公平性
　　　→ある状態が無限回起こる

ただし、モデル検査ツールすべてが、上記の性質を扱うわけではない。

---

■性質を表現するには？

SPINの場合

・PLTL（線形時相論理）を使う

　[] p （つねにPが成り立つ）
　＜＞ｐいつかPが成り立つ
　ｐUｑ　ｑがいつか成立し、それまでPがなりたつ

　　　＋

　否定、and、or

・安全性
　　→同時にクリティカルセクションに入らない

・活性
　　→飢餓状態（スタベーション）は発生しない
　　　ずっと待たされることはない
　　　いつかは、クリティカルセクションに入れる

---

■性質の記述パターン
・なかなか、表現がわからないので、

・表現のパターンがある（CTLもある）
　　　http://patterns.projects.cis.ksu.edu/
　　→スコープ（対象とする範囲を定めたもの）が大事

・パターン（大きく２種類）
　Occurenceパターン（おきる・おきない：発生を記述）
　Orderパターン（順序を表現）

---

■SPINに話を戻し、しくみは？

Promelaで記述したシステムモデル
　　　　↓
　　　Xspin
　　　　↓
　　　spinが検証用プログラム生成
　　　　↓
　　　コンパイル、実行

---

■SPINのモデル構成要素
おおきく、４つ
（１）記号定数定義
　　　　mtype={変数１,変数２};

（２）大域変数定義
　　　chan toS
(chan　＝＞　チャネルを示す）

（３）プロセス定義
　　　　proctype →本文

（４）init文
　　　init{
　　　　　プロセス生成

---

■文の中身

・データ型
・代入文
　　変数＝値
・制御構造（ガード文）
　　goto
　　if
　　do
・メッセージの送受信
　　出力チャンネル名！値１
　　入力チャンネル名？値１
　　chan チャンネル名＝[バッファサイズ] of ｛型の並び｝

バッファサイズ０だと同期、１以上の数を指定し、非同期にできる

マニュアル
・日本語
http://www.asahi-net.or.jp/~hs7m-kwgc/spin/Man/Manual_japanese.html

・Reference manual
http://spinroot.com/spin/Man/promela.html

---

■Xspinのちょーかんたんな使い方

・File→Openで読み込むか、ファイルをエディットする
・Run→SetSimulationParametersをチェック

・でてきたパネルで、Start

・以下のようにウィンドウが３つでてきて、実行

---

■デッドロックの確認

・Run→Set　Verification　Option

・そうすると、ダイアログが出てくるので、Run

・デッドロックがあると、errorsというのがでてきて、Suggested Actionダイアログが出る

・Run　Guided　Sumilationをクリック

・出てきた画面（３つ）のうち、左上のダイアログ「Run」をクリック
　　→右側にシーケンスがでる

---

■PLTLを使う

・Run→LTL　Property　Managerを選択
・Formulaに、式を書く
[] a && b && c

・aの条件式を、Symbol Definitionに書く
#define a x <5 ・generateをクリック

・Run Varificationをクリック

・新しく出てきたダイアログで、Runをクリック


※参考「いつかは、～にもどる」
[]（！（a && b && c） →　 []（＜＞ a && b && c））

クラウドより、ISPのほうが、安全ってことっすかね？

Wikileaksって、Amazonから、追い出されたじゃないですか・・・

Wikileaks、Amazonのサーバから追い出される
http://www.itmedia.co.jp/news/articles/1012/02/news034.html

ってことは、アメリカの意向に逆らった場合、
アメリカのクラウドにおいておくと、業務停止になる可能性がある
ってことですよね・・・
これって、ものすごいカントリーリスクですよねえ・・・

でも、実際にWikileaksって、サーバーうごいてるじゃないですか・・
それは、

内部告発サイト『Wikileaks』の内部は恐ろしいくらいカッコいい　完全に悪の秘密基地だこれ
http://2r.ldblog.jp/archives/3815031.html

ってことで、ISPが保護していてくれるから・・・

ってことは、やっぱり、クラウドにおくより、信頼できるISPにおいておいたほうが、
リスクは少ないってこと？

astah*を使って、ICONIX風一気通貫システム開発 その８：フレームワーク決定

「astah*を使って、開発の要求仕様から、プログラム作成までを、トレーサビリティを保って、どのように開発するかを書いてみる」という、このシリーズ、以下の手順で説明する予定ですが、

（１）作るべきもののユースケースを書く
（２）ユースケースシナリオを書く
（３）ロバストネス分析
（４）バウンダリ（画面）、エンティティ（テーブル等）の属性を埋めていく
（５）バウンダリの項目を元に、画面構成を考える。
（６）(必要があれば）エンティティを正規化して、ER図にする
（７）フレームワークを決定する
（８）画面クラスをソースコードに書き直す
（９）エンティティをDBのテーブルと、DAOに書き直す
（１０）コントローラーを書き直す

前回、（５）をやったので、今回は、「（７）フレームワークを決定する」について。

---

■概要と位置づけ

　（５）によって、画面項目と画面遷移、（６）によって、データベース側の項目は決まりました。
　つまり、論理的には、もう決まったので、ここからは、どのように、実装をしていくかを考えます。

　最近の開発の場合、フレームワークを使って開発するのが主流です。
　フレームワークが決まってしまうと、なにを開発すればよいかの大枠がきまります。
　なので、実装の最初は、まず、フレームワークに何を選ぶかを決めます。

　フレームワークが決定してしまうと、コンポーネント構成なども大体きまってしまいます。
　そして、システムの画面と、DBまでのつながりが大まかにきまるので、外部設計的にはひと段落と成ります。
　つまり、フレームワークが決定したら、外部設計をまとめて、お客さんに確認をとることで、外部設計的にはひと段落します（フレームワークが決まらないと、外部レイアウトが正しく決まりません。なので、この前で同意を取るのは、危険だったりします）。

---

■決め方の観点

　まず、何を決めるかですが、最近は、MVCで考えることが多いと思います。

　V＝ビュー：画面、ユーザーインターフェース

　C＝コントロール：画面とモデルのつなぎ

　M=モデル：処理部分。
　　　　モデルのロジック部分と、データベースアクセス部分がある。

　ってことで、

　・ビュー→コントロール
　　　ビュー自体は、HTMLファイルとか、JSPファイルとかになり、
　　　コントロール部分は、Javaのソースコードになる。
　　　これをつなぐところにフレームワークが「入ることが多い」
　　　（自動生成してしまうフレームワークとかもあるし、
　　　　画面をフレームワーク化とかも、ないわけじゃない）

　・モデル部分の管理
　　　各ビジネスモデルは、それぞれ作るにしても、それを管理する部分に
　　　フレームワークを使う。DIなんか・・

　・データベースアクセス
　　　データベースアクセス部分にフレームワークを使う。
　　　DAOを使ってアクセスする。
　　　O/Rマッピングなどを行うもの
　　　
　という部分に、どんなフレームワークを当てるか？ということを考えます。

　なお、この全部を、１つのフレームワークで行う場合、
　「フルスタックフレームワーク」といいます。

---

■たとえば・・・

　ビュー　→　コントロール：Struts
　モデル部分の管理　　　　：Spring
　データベースアクセス　　：Hibernate

など。この場合、Strutsを使うと、JSPなので、Web用のブラウザで見る場合はつなぎやすいけど、
AJAXをやる場合、つなぎにくい（出来ないわけではない。十分出来るんだけど、もっとふさわしい方法がある）そこで

　ビュー　→　コントロール：T2フレームワーク
　モデル部分の管理　　　　：Spring
　データベースアクセス　　：Hibernate

とかも、ありえるかもしれない。

このように、GUIとかによって、フレームワークが変わってきたりする。
もちろん、フレームワークを作るとか、使わないという選択肢もあるが、自作する、使わないということを、この場で、「決める」ことになる。

要求獲得

■要求分析の流れの中の要求獲得の位置づけ

要求獲得（要求抽出）
　↓
要求記述
　↓
要求検証
　↓
要求管理

---

■要求獲得で行うこと

・最初に行うこと：ステークホルダーを明らかにする
　　要求：現実世界とマシン（開発されるもの、ソフトとか）の共有部分。
　　　　　現実世界とマシン全体で、システム

　　要求と要求仕様
　　　要求：こんなふうにしたら、こんな風になるっていうのが要求
　　　要求仕様：要求を満たすのに、システムは何をしないといけない
　　　　　　→要求がないと決まらない

・ステークホルダー→課題→要求→要求仕様の順に流れる

・as-isとto be
as-is　　　　　　　　　　　　　　　to be
現在のシナリオ→ゴールを発見→それができるとどうなる：求めるシナリオ
　　↓　　　　　　　　　　　　　　　　　　　↓
現在のモデル　　　　　　　　　　　　　　　将来のモデル

ということは将来モデルの説明ができないといけない

---

■具体的な手順

・ステークホルダーの識別＝リッチピクチャ
・現状システムの理解
・現在モデル作成
・課題抽出　　　　　　　＝役割依存
・ゴール抽出
・将来の状況のシナリオ
・将来モデルの構築
　　　　　　　　　　　　＝CATWOE

---

■ステークホルダーを考える上で・・・

システムにかかわるのは、３種類いる（＝これらの人がリッチピクチャに出てくる）

Actor：手足を動かす人
Owner：Actorにがんばれという人
customer：Actorががんばるとうれしい／かなしい人
　　　　　　→影響を受ける人

この３者には依存関係がある
　　→タスク達成・ゴール達成・リソース共有：コンテキスト依存モデル

Actorが課題を出すことも多い
でも、Ownerが、Actorをくびにしてしまったら、Actorは関係なくなる
　→Ownerが大事

・つまり、Actor、Owner、customerにわけて、要求を聞いていこう。

・ただし、個人は、いくつかのロールをもつ（ロールホルダー）

・そしてロールは、あるときには、「あるもののアクター」
　　　　　　　　　あるときには、「あるもののオーナー」
　と、物によっては、アクター、オーナーがかわる。

→さっき、Ownerが大切って言ったけど、ロールにって、同じ人でも、ActorにもOwnerにもなるんだから、
　ある人の意見でも、役割を考えることが大事。
→さらに、課題を出してきても、その人の世界観があるから、それが本当の課題かどうかわからない
　　　　→組織的課題と個人的課題がある

---

■課題の分析＝役割依存モデル

・ロールを確認→課題はとるにたらないか、とるべきものか？
　　　リソース、プロセス、ゴールに対して、O(Owner）、A（Actor),C(Customer）を分けて書く

---

■CATWOE分析

　Ownerの世界観を分析するため

　　Customerの望ましくない状況
　　　　　　↓
　　　変換プロセス（Actorが実施：ただし、どうやって変えるかは定義不要）
　　　　　　↓
　　Customerの望ましい状況

（要するに陰仕様でよいみたい）

W：Ownerの世界観
　　→なぜ今の状況が望ましくなく、かえるとなんで望ましいか？
　　　　　→つまり信念

※ってことは、望ましくない状況、望ましい状況は、顧客に確認する必要がある

ゴールモデルの断片が出てくる

---

■まとめると、手順は・・・

・リッチピクチャ
・役割依存モデル
・CATWOE

エラーチェックの論理的な方法

　プログラムでエラーチェックを行うけど、これの論理的な方法を考える。
　ちなみに、エラーチェックに引っかからない＝正常系データとなるので、
　テストデータの合理的な作り方ということにもなる。

---

■処理をするには・・・

　プログラムである処理をやって、結果を得るということを考える。
　この際、すでに保存してあるデータを利用する。
　また、処理を行ってもらうために、データを投入することもある

　つまり、こんなかんじ

　(データ投入）→(保存してあるデータ読み込み）→(結果データを得る）

　このとき、
　　投入するデータや読み込むデータが、起動時に満たすべき条件＝事前条件
　　保存、書き込みするデータが常に満たすべき条件＝不変条件
　　処理後、結果が満たしている状態（の条件）＝事後条件

　となる。

　プログラムにおけるデータチェックとは、この事前条件を満たすかどうかをチェックしていることになる。

---

■事前条件が満たすべき要件

　ということは、「事前条件が満たすべき要件」が判れば、データチェックすべき項目がわかることになる。

　　事前条件を満たしてれば、不変条件に違反しないで処理すると、事後条件になるのだから、

　逆に考えると、

　　処理をしたら事後条件に達し、かつ処理中・処理後に不変条件に抵触しないこと

　が事前条件に求められる。ここで、

　不変条件は、データがもともと、満たすべき性質だから
　（たとえば、人数が、マイナスになることはないなど）
　まとめると、

　処理をして、事後条件に抵触せず、かつ不変条件（アクセスするデータがもともと満たす条件）に違反しないように、事前条件に書くし、それをエラーチェックに書けばいい

ということになります。

---

■具体例

・利用者登録、利用者削除を考えます。

　ここで、利用者テーブルというのが、保存されているものとします。

　利用者テーブルには、
　　　　利用者IDがあり、これが、一意である
　　　　利用者名がかならず入っている

　とします。（＝不変条件）

・利用者登録は、利用者名を入力して、
　利用者テーブルに、利用者を登録します。
　（＝事後条件：利用者テーブルに利用者が登録されている）

　利用者が登録されているのですから、このとき、不変条件を満たさないといけません。
　不変条件中、利用者IDは、新規にプログラムで振ります。
　利用者名は、入力されるのですが、このとき、不変条件では利用社名が必ず入っているのですから、引数に利用者が必ず入っていないといけません。

　これが、事前条件、つまり、利用者名が必ず設定されている。

　ということは、エラーチェックは事前条件を確認することだから、利用者名の設定チェックということになります。


・利用者削除は、利用者IDを指定されたら、そのIDの利用者を削除します。
　ということは、事後条件（＝処理後）は、利用者テーブルに、そのIDの利用者がないことです。
　削除したらなくなるのですから、
　削除する前は、そのIDの利用者は、存在することになります。
　事前条件はしたがって、「利用者テーブルに、そのIDの利用者が存在する」ということになります。

　ってことは、エラーチェックは、事前条件を確認するのですから、「利用者テーブルに、そのIDの利用者が存在する」ことになりますけど、これはわざわざDBアクセスすることになるので、ここまでは求めず、IDが設定されてることで済ましてしまうこともあります（ただし、IDが設定されていることが本質ではない。あくまでも、存在チェックの前提として、補助的なチェックをしている）

---

こんなかんじかな

astah*を使って、ICONIX風一気通貫システム開発 その７：テーブル定義

「astah*を使って、開発の要求仕様から、プログラム作成までを、トレーサビリティを保って、どのように開発するかを書いてみる」という、このシリーズ、以下の手順で説明する予定ですが、

（１）作るべきもののユースケースを書く
（２）ユースケースシナリオを書く
（３）ロバストネス分析
（４）バウンダリ（画面）、エンティティ（テーブル等）の属性を埋めていく
（５）バウンダリの項目を元に、画面構成を考える。
（６）(必要があれば）エンティティを正規化して、ER図にする
（７）フレームワークを決定する
（８）画面クラスをソースコードに書き直す
（９）エンティティをDBのテーブルと、DAOに書き直す
（１０）コントローラーを書き直す

前回、（５）をやったので、今回は、「（６）(必要があれば）エンティティを正規化して、ER図にする」について。

---

■概要と位置づけ

　（４）で、エンティティについて項目を振り分けたので、各エンティティにおいて、保存すべきデータ項目は、全部出ているはずです。

　で、NoSQLなら、これでいいともいえます。エンティティオブジェクトをそのまま、XMLに変換し(JAXB)、そのXMLを保存、編集、削除すればいいわけです（まあ、オブジェクトをそのまま、シリアライズして保存してもいいけど）。

　しかし、この場合、たとえば、

　　　受注票１番に、商品番号２３４が入ってて、
　　　受注票２番に、商品番号２３４が入ってて、
　　　受注票３番に、商品番号２３４が入ってて、
　　　　　　：

　商品番号２３４の商品名をいっぺんに変えたい！
　というと、今のままだと、オブジェクトがファイルに保存されている場合（受注票が全部ファイルに保存されている場合）、受注票１番から９番のファイルを開いて、商品オブジェクトの番号２３４の商品名を変えるという作業を、全部に対して行わないといけません。
　これは、時間がかかります。

　この事態を避けるには、

　　　・受注票から、商品オブジェクトを分離して、
　　　・受注票は、商品オブジェクトのリンク情報（受注番号）だけ持っていれば
　　　・商品オブジェクトの商品名を変えるだけでOK！

　となります。つまり、
　　　・オブジェクトは一つ一つ分けて、
　　　・他のオブジェクト(受注票）が、当該オブジェクトを参照したい場合は、
　　　・ID（商品番号）を元に、検索する

　ということになります。このように、オブジェクトごとに、一つ一つ分けるためには正規化を行います。
　ちなみに、このように、データの重複を避け、ダイナミックにリンクを切り替えられる（リレーションによって）のが、RDBということになります。
　なので、NoSQL（実質NoRDB)という場合は、これを出来る仕組みを保証していない＝アプリ側で自己責任で行うことになります。
（つまり、アプリ側で、上記のように全部、商品オブジェクトの値を変えるか、商品オブジェクトを書き換えればいいだけにするような仕組みを自分で作る。RDBは、後者の仕組みをDBMSで提供・保証してくれている）

　この部分は、RDBの場合、外部設計のテーブル定義ということになります。
　テーブルは、正規化されたエンティティということになります。

---

■正規化
　正規化は、１，２，３，３．５，４，５とありますが、このうち、
　　第１，２，３，３．５正規系までの話と、
　　第４，５正規化は、まったく違う話になります。
　そして、３．５正規形は、データが失われることがあるので、
　理屈上、１，２，３までをやれば、いいことになります（いや、３．５をやってもいいけど）。

　正規化の目的は、結局、オブジェクトの中にオブジェクトを含んでいるような、コンポジットなオブジェクトを、１つ１つのオブジェクト、オブジェクトの中にはオブジェクトを含まないようにするということです。オブジェクト的に言うと・・・
　(上記のオブジェクトを、エンティティに言い換えると、一般的になる）

　第一正規形は、繰り返している部分を分離します。
　　　たとえば、３個繰り返しているものは、
　　　　１個目、２個目、３個目と、それぞれ、分離できます。
　　　このように、繰り返し部分がある場合、
　　　その繰り返し個数分、それは、確実に分離できるわけです。
　　　なので、繰り返し部分を分離します。

　第二正規形は、まず、オブジェクトを認識するためのIDを振ります。
　　　あらたに、ID項目を振ってもいいですけど、
　　　時刻と場所で１つのオブジェクトに限定できるのであれば、そういうほうがいいです。
　　　上記の場合、時刻と場所をIDとします。

　　　さてここで、IDが、時刻と場所というように、
　　　　　　２つ以上から構成されている場合を考えます
　　　住所は、場所が限定してしまえば、時刻が変わっても、変わりません。
　　　このように、IDが２項目以上から構成されていて、
　　　そのうちの一部の項目（＝場所）が決まれば、他の項目が決まってしまう（住所）場合、
　　　一部の項目と、決まってしまう項目を別に分離します（場所オブジェクトを作ります）

　第三正規形は、ID以外で、ある項目がきまると、他の項目も決まってしまう場合、
　　　それを分けます。
　　　たとえば、場所には、１台のコンピューターが設置され、コンピューターのクロック数も
　　　項目にあった場合、コンピューターが決まれば、クロック数も決まります
　　　(この場合、オーバークロックしてるものは、別のコンピューターと考える）
　　　そこで、コンピューターを別のオブジェクトとして分離します。

　これらの操作で分離したものを、エンティティ（RDBの場合、テーブル）としてまとめて、ER図（やテーブル定義書）をつくります。

---

今回の作業はここまで。

12月7日(火)のつぶやき

00:13 from web
YouTubeにNHKオンラインのチャンネルがあるんだ！ http://www.youtube.com/user/NHKonline
by xmldtp on Twitter

ユースケースとアスペクト指向（機能追加を行うためのアスペクト指向）

■アスペクト指向いろいろ

・アスペクト指向要求工学（Early　Aspect）
　　　→ヤコブソン（こいつが、機能追加を行うためのアスペクト指向を扱う）

・アスペクト指向アーキテクチャ、モデリング、設計

・アスペクト指向プログラミング

・アスペクト指向の形式手法

・アスペクト指向ミドルウエア

---

■ユースケースにおけるオブジェクト指向とのミスマッチ


ユースケース：外部から見える振る舞いの関心事
　　→ユースケースは、オブジェクト指向と直接関係ないので、
　　　オブジェクトとは関係なく、横断的関心事になる？
　　→ユースケースの関心事が、オブジェクト指向開発時に離れ離れになってしまう

ユースケース間の関係を記述することはできるが・・・
　　　include（共通部分）→オブジェクト指向で記述できる
　　　汎化・特化→オブジェクト指向でもあるのでOK
　　　拡張→既存のユースケースをあとからピンポイントで差し込む
　　　　　　　　：機能追加
　　　　　　→オブジェクト指向では、ない。
　　　　　　→「後から差し込む」って、まさに、アスペクト指向

---

■ユースケースの機能追加extendとAOSD（アスペクト指向ソフトウエア開発）

　ユースケース：機能追加を考えている（extend）
　オブジェクト指向：ない（修正しないと）

　ユースケースの機能追加extend　⇔　アスペクト指向で実現できそう
　→アスペクト指向なら、あとから差し込むことができるので。
　　　→AOSD（アスペクト指向ソフトウエア開発）
　　　　　　→ユースケースで分離できた関心事をそのまま設計、実装が可能になる

---

■AOSD（アスペクト指向ソフトウエア開発）

・横断的関心事を２つに分ける（ピアと拡張）
　　　・アプリケーションピアユースケース
　　　　　　→機能要求
　　　・アプリケーション拡張ユースケース
　　　　　　→機能追加など
　　　・基盤ユースケース
　　　　　　→非機能要求
　　　・依存ユースケース
　　　　　　→プラットフォーム依存のもの

・ピア
　　主要機能を表す独立的関心事だが、横断の可能性もある
　　ユースケース
　　　　・ユースケースの違いにかかわりなく必要：ユースケース独立スライス
　　　　・そのユースケースのみに必要な部分：ユースケーススライス
　　　　　　→ユースケーススライスから、ユースケース独立スライスを拡張


　　拡張部分を、アスペクトにする（インタータイプ宣言）

・拡張
　　拡張ポイント＝AOPのジョインポイント　

---

■手順
（１）ドメインモデルの作成
（２）ユースケースの識別
（３）ユースケースの分析 -------ここまでは、普通のユースケース分析と同じ
（４）クラスの分析と責務の調停
　　　　　→ここで、ユースケース依存か独立（共通）を分離する
（５）独立スライス→ユースケーススライス（ピア→拡張）の順に
　　　スライス作成→クラス実装

会社の全社的な目標から、要求仕様分析が出るまで

会社の全社的な目標（をだす現状分析）から、要求仕様分析が出てくるまでの流れを
まとめてみた。

---

■全社的現状分析→全社的戦略（→情報戦略）

財務分析
　　・各種財務指標
　　・キャッシュフロー、EBITDA

マーケット分析
　　業界全体：トレンド分析
　　自社VS社外：３C分析、５F分析
　　自社内：PPM

人事（分析方法？）

　　↓
全体像：SWOT ----ここまで、過去の資料を集めて作成
　　↓

目標・戦略：BSC等
　　　→１つとして、情報戦略

---

■情報戦略→RFP

情報戦略のブレークダウン
　　　　・ロジカルシンキングで？
　　　　・KJ法で？
　　　　・SSMで？
　　　　・マインドマップで？
　　　　　　　　いやー、目標は出てこないでしょう・・・
　　　　　　　　(話がむしろ、拡散しそうだ・・・）

情報関連目標：出てきたと仮定する
　　　　・目標達成時のイメージを作成・共有する
　　　　・達成までのストーリーを描く
　　　　　　　　ブレインストーミング→KJ法的にまとめていく

　　　　・ストーリーに出てくる登場人物をまとめる
　　　　　　　　ステークホルダー分析

　　　　・ストーリーを登場人物を含めてモデル化：ビジネスモデリング
　　　　　　　　　　↓
　　　　　そこで出てくるモノを概念モデルとしてまとめる：ドメイン分析
　　　　　　　　　→開発範囲の確定

目的、目標、ビジネスモデル、ドメイン分析、開発範囲などの文書化
：RFP

---

■RFPから提案書

　RFPの目標からスタートし、解決策をブレークダウン：i*,KAOS
　　　　　　↓
　担当者とその責務が決まるまでブレークダウン
　　　　責務＝ユースケース
　
　開発規模の見積もり
　　　ユースケースとドメインモデルから大雑把に

　それらをまとめる：提案書

---

■提案書から要求仕様書

　ユースケース
　　　　→ストーリーをつけて、ユースケースシナリオに

　ユースケースシナリオから、ドメインモデル作成へ
　　　　→機能要件がまとまる

　非機能要件のまとめ（チェックリスト、ミスユースケースなど）

　それらをまとめる：要求仕様書

---

戦略から、RFPを出すところが判ってないね。

astah*を使って、ICONIX風一気通貫システム開発 その６：画面構成

「astah*を使って、開発の要求仕様から、プログラム作成までを、トレーサビリティを保って、どのように開発するかを書いてみる」という、このシリーズ、以下の手順で説明する予定ですが、

（１）作るべきもののユースケースを書く
（２）ユースケースシナリオを書く
（３）ロバストネス分析
（４）バウンダリ（画面）、エンティティ（テーブル等）の属性を埋めていく
（５）バウンダリの項目を元に、画面構成を考える。
（６）(必要があれば）エンティティを正規化して、ER図にする
（７）フレームワークを決定する
（８）画面クラスをソースコードに書き直す
（９）エンティティをDBのテーブルと、DAOに書き直す
（１０）コントローラーを書き直す

前回、（４）をやったので、今回は、「（５）バウンダリの項目を元に、画面構成を考える」について。

---

■概要と位置づけ

　前回、出力を元に入力を考え、入力から出力が出来ることを確認したわけです。
　ということで、画面の入出力項目は、すべて出揃ったことになります。

　ただし、項目が出揃ったというだけで、１つの画面に、物理的に全て表示できるかどうかわかりません。また、今まで非機能要件について考えていませんので、もしかしたら、とっても使いにくい画面になっているかもしれません。

　ということで、ここで、画面を分割し、画面項目を振り分けていきます。

　そして、それらの画面を、どんな順番で動かしていくかという、画面遷移を考えます。

　この段階で、遷移上、必要な画面（ボタンやリンクをクリックして、画面表示するだけのメニュー画面など）も出てきますので、それを追加します。

　つまり、この段階では、画面分割と画面遷移を扱うわけで、これにレイアウトを加えると、外部設計中の画面設計ということになります。

---

■画面分割

　前回（４）まででは、ロバストネス分析をした状態なので、画面は、処理(ユースケース）に対して１つになっていると思います。
　これでいい場合は良いのですが、画面が大きすぎる場合は、分割します。

　この分割する際、なんらかの方針を持っているほうが、やりやすいし、操作性を向上させます
　たとえば、「編集画面は、一覧を出して、詳細を出すようにする」とか・・・

　新しい画面もクラスとして表現します。

　　項目が、属性となります。

　　ボタンをクリックしたり、何かを選択したりすると、JavaScriptだと、ファンクションを呼び出しますが、それら、

　　イベントはメソッドとして書き出します。

---

■画面遷移

　そして、画面ができたら、画面遷移図を書きます。
　画面を並べて、どんなイベントが起きたら、次にどの画面に飛ぶかを→で書くのが画面遷移図ですが、Astah*にはないので、とりあえずステートマシン図で代用します

　　状態（角丸四角形）を、１画面とします(画面表示状態とします）。
　　そして、→で遷移をあらわします。
　　ガードに条件を書くかんじ・・・

　そんなかんじで画面遷移図を書いていきます。
　このとき、起動するためのメニュー画面とか、認証するためのログイン画面とかが不足するので、追加しておきます。

---

■マスタメンテナンス

　なお、不足する画面の中で、データベースにデータを入れる、マスターメンテナンス画面が必要になる場合があります（DBのツール等から直接データを入力するためにいらないこともあります）。

　マスタメンテナンスは、ふつう各テーブルごとになります（受注と受注明細をあわせるなど、関連あるものをあわせてしまうことはある）。

　画面構成は、
　　　　一覧選択画面：削除はこの画面から
　　　　詳細画面　　：編集、新規作成
　の２種類、ないしは詳細画面は表示だけとし、
　編集画面を別に作って、そこから、編集、新規作成する場合もあります。
　また、検索画面というのを作ることもあります。
　この、【一覧、詳細、（編集、検索）画面】ひとそろえで、１テーブル分という感じになります。

---

■このあと

　画面レイアウトを作成することになります。

　これはAstah＊では出来ないので、HTML作成エディタなどで作成します。

　これら（画面構成＆画面遷移図＆画面レイアウト）をもとに、画面定義書を作成することになります。

12月6日(月)のつぶやき

12:36 from web
「Dreamforce '10」基調講演インターネット中継、12月8・９日午前2:00-4:00って、まーそーなるわな（＾＾；）（なんで、再放送を12月8・９日午前10:30-12:30にするらしいけど） http://www.salesforce.com/live
14:18 from web
いつのまにか、OTNの「領域サイズ見積り」が終わってた（＞＿＜！） http://otn.oracle.co.jp/document/estimate/index.html
14:43 from web
よんだ。【速報】高橋愛「30歳年上でもお金持ちなら結婚したい」 http://blog.livedoor.jp/uwasainfo/archives/1611613.html
by xmldtp on Twitter

UMLに時間（オートマトン）、UMLと開発プロセス→検証

まとまりのない話だけど・・・

---

■UMLに時間
UMLの中でも、ステートチャート図、さらに、UML　Profile for SPTを使って考える
UML Profile : UMLにつけるこめんとみtainamonn
UML　Profile for SPT:時間に関してのコメント。今回は３つのステレオタイプを使う
　　　　　RTtimeout　　RTstart
　　　　　　　　　　　　その時間とどまってから実行

　　　　　SAaction　　　SAworstcase,SAdelay：doアクティビティの最大、最小時間
　　　　　　　　　　　　これがなければ、瞬時に実行

　　　　　CRsynch　　　なし：完全同期（相手が準備完了になるまでブロック）
　　　　　　　　　　　　つけないとき、キューの長さ１

　こいつをつかって、Uppaalに落とす。
　ステートチャートのアクティビティ１個が、Uppaalの１ロケーション

---

■開発プロセスとUML

開発プロセス

要求分析　　　　　　：ユースケース図、システム構成図、シナリオ記述、非機能要件
システム分析　　　　：アクティビティ図、シーケンス図（分析モデル）
ドメイン定義　　　　：クラス図／パッケージ図
エンティティ分析　　：クラス図（分析モデル）
ドメイン内部の分析　：クラス図、コラボレーション図、ステートチャート図
アーキテクチャ設計　：非機能要件→各図へのコメント追加
詳細設計　　　　　　：クラス図、シーケンス図、ステートチャート図


ドメイン内部の設計＝基本設計

そのあと、実装→テストとなっていく。

---

■検証モデルをつくるために、設計モデルに必要な要件
・個々の処理フローがわかる（ないしは、未定のところがわかる）
・入出力と処理の関係がわかる
・（Uppaalで行う場合）時間情報がわかる

■適用する際に考えること
　　・検証モデル：なにを検証したいか（対象）
　　・検証したい性質：何について検証するか

Oracleの説明、新人研修用に使えそうなサイト

新人にoracleを説明する際に、使えそうなサイト

OTN セミナー　オンデマンド コンテンツ
http://www.oracle.com/technology/global/jp/ondemand/otn-seminar/beginner/index.html
の以下のもの

超入門！Oracleデータベースって何だ！？
今さら聞けない Oracle 入門
ここからはじめよう　Oracle SQL入門
SQL Developer と Data Modeler で楽々アプリケーション開発
java超入門！

なお、これも、余裕があったら見たほうがいい
意外と簡単!? Oracle Database 11g　-データベース構築編-
意外と簡単!?　OracleDatabase11g -データベース設定編-

---

新人には、いらないだろうが。。。
容量サイズ見積もりについて

昔は、「領域サイズ見積り」というサービスがあったが、終わっている

ということで、以下の資料しかないのかなあ・・・
http://otndnld.oracle.co.jp/deploy/maintenance/pdf/size_est.pdf

または
第3部 テーブルの設計
http://otndnld.oracle.co.jp/skillup/oracle9i/3_1/index.html
でも、9i用だから、かなり古い。

---

ダウンロード(windows版）

たしか、フリーのもの

DB
Oracle Database 10g Release 2 (10.2.0.1)Express Edition for Microsoft Windows
http://www.oracle.com/technology/global/jp/software/products/database/xe/htdocs/102xewinsoft.html

操作ツール
Oracle Enterprise Manager
http://www.oracle.com/technology/global/jp/software/products/oem/index.html

---

オラクルダイレクトセミナー
http://www.oracle.co.jp/direct/seminar

いろんな講義が、ただでやっている。

12月5日(日)のつぶやき

21:38 from web
ブログった「グーグルが中国国内から受けたサイバー攻撃は、中国最高指導部のメンバーの指示っていう、WikiLeaksの記事って、これ？ 」 　http://plaza.rakuten.co.jp/struts/diary/201012050000/
by xmldtp on Twitter

都条例が厳しくなっても、マンガを電子化して海外から販売すれば？（０時追加）

ここの痛いニュース
漫画・アニメ中での暴力表現も「非実在犯罪」として規制に…都条例の問題点
http://blog.livedoor.jp/dqnplus/archives/1573043.html

なんか、痛いニュースを読む限りでは「刑罰法規に触れる行為」はいけないそうだから、
殺したりするのはだめ、
ということで、北斗の拳とかもだめだろうし、
「ハンターXハンター」とか、もってのほかだな（＾＾；）

もー、こーなったら、マンガ電子化しか、ないでしょ

これ、東京都で、マンガを売ったり、映画を上映した場合に、
問題になるんだよねえ・・・

じゃあ、

　　・ケイマン島に本社をおいて、
　　・アメリカにサーバーを置き、
　　・そこからマンガを電子的に配布
　　・決済は、カードまたは、コンビニ払い

の場合、本を置いてないし、上映もしてなし、
モノは日本にないし、日本の会社じゃ、そもそもないから、
規制できないよねえ。



カードまたは、コンビニ決済にして、お金入金後、
メールでURLを教えてくれて、
そこから、Webまたはケータイからアクセスすると読める
（ダウンロードは不可だけど、一度お金を払えば、いつでも見れる。
　バックナンバーもOK)
っていうようにすれば、日本国外のオタク（フランス？）も見れるし、
もし、支払先のコンビニがわかって、キックバックできるようになれば、
コンビニも本置かないで、お金入ってくるから、そっちのほうがいいよな



都条例が厳しくなると、マンガは、電子化ですかねえ・・・

---

（０時追加）
痛いニュースの引用元のブログは、そう書いてなかった。
ただ、そうだとしても、
「いくら都条例が変わっても、電子化されて、海外サーバーに置かれたら意味無い」
っていう構図はかわらないので、エントリーは削除せす、赤字部分を追加しました。