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

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

・アスペクト指向要求工学（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