要求獲得

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

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

---

■要求獲得で行うこと

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

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

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

・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