ゴール指向分析ＫＡＯＳにおける依存性を考慮した要求抽出法の考察
•Download as PPTX, PDF•
0 likes•984 views
ソフトウェア・シンポジウム２０１７宮崎で発表したプレゼン資料とそのときのＱ＆Ａです
Recommended
More Related Content
Similar to ゴール指向分析ＫＡＯＳにおける依存性を考慮した要求抽出法の考察
Similar to ゴール指向分析ＫＡＯＳにおける依存性を考慮した要求抽出法の考察 (20)
More from Michitaro Okano
More from Michitaro Okano (16)
ゴール指向分析ＫＡＯＳにおける依存性を考慮した要求抽出法の考察
- 2. 背景と目的 • 本研究の対象 – 要求分析について • 要求分析で求められること – 設計・実装・テストに必要な情報が獲得されること • 本研究の目標：以下の知見を得る – 「設計・実装・テストに必要な情報」は何か – その情報を獲得するには，どのような手法を用いれ ばよいか • 本研究のアプローチ – 「要求の獲得手法」としてゴール指向要求分析のＫＡ ＯＳを用いる：ゴールの詳細化により要求が得られる 2
- 3. アジェンダ • 用語の説明 – 「設計・実装・テストに必要な情報」、ゴール、ＫＡＯＳ、 詳細化の手法 • 詳細化の事例としての「酒屋倉庫問題」 – 本稿の課題：「依存性の表現」 • 「依存性の表現」方法の提案 – 提案手法の事例適用：「酒屋倉庫問題」 • 関連研究など – i*,UMLとの比較 – 今後の研究 – まとめ 3
- 4. 用語の説明（１） 「設計・実装・テストに必要な情報」 • 設計・実装・テストに必要な 情報」は，要求仕様書に文 や図としてまとめられる – 図も文で表現可能なので、文 について考える • 文は、「システム開発者の 意図」を含むかどうかで分 けられる（ Lamsweerde[1] ） – 意図を含む場合はゴールで あり、ゴールであり、詳細化 すると要求と期待に分類 – 含まない場合はドメイン知識 とシステム固有情報に分類 – 文の分類（[1]を元に作成） • 必要な情報は要求、ドメイ ン知識、システム固有情報 – 本稿は「要求」を扱う [1] Axel van Lamsweerde,“Requirements Engineering:From System Goals to UML Models to Software Specications ”,Wiley,2009. 自然法 則・法 律等 4
- 5. 用語の説明（２） ゴールとKAOS • 「意図を含む文」の広さは 様々ある – システムが満たすぺき大き な目標 – 担当者が行う作業の目標 • 作業を行う人やシステム： エージェント • ゴール： – エージェントの協調によって 満足すべき意図を示した規 範的な文[1] – 本稿では「ある状態Pからあ る状態Qになる(P→Q)」という 形（達成ゴール）を扱う • KAOS[1] – システムが満たす大目 標＝トップゴール • 現状→目標の状態へ – トップゴールを詳細化し て、サブゴールに分割 • 詳細化の手法は後述 – サブゴールをさらに詳細 化し・・・と詳細化を繰り 返す – 最終的には、１エージェ ントが達成可能なほど小 さなゴールとなる＝要求 とする [1] Axel van Lamsweerde,“Requirements Engineering:From System Goals to UML Models to Software Specications ”,Wiley,2009. 5
- 6. 用語の説明 ＫＡＯＳにおける詳細化の手法 • マイルストーン分解[1] – P→Qに状態が変化（状態 遷移）する際に状態Mを 経るのであれば、P→M、 M→Qに分解する • 要素分解[2] – 事後状態Q がいくつかの要素 ｛Q1,Q2,・・・Qn｝から成り立つとき – P→Q1,P → Q2,…,P → Qnに分解 • それだけでは｛Q1,Q2,・・・Qn｝とい う各要素が存在する状態になるだ けで，Qになるとは限らないので – さらに{Q1,Q2,・・・Qn｝→Qも付加 する（こともある）分解法 ゴール： 現在の状態P 目標の状態Q （事前状態） （事後状態） ここを分解 マイルストーン分解 ここを分解 要素分解 ここは？ 本稿の考察 [1] Axel van Lamsweerde,“Requirements Engineering:From System Goals to UML Models to Software Specications ”,Wiley,2009. [2]岡野道太郎・中谷多哉子, 状態と状態遷移に着目した ゴール指向要求分析手法の考察, 知能ソフトウェア工 学研究会(KBSE) , 電子情報通信学会技術研究報告 : 信学技報Vol.116 No.493,2017,pp25-30 要素は 様々* *ユースケース、構成要素、機能・・・ 6
- 7. 詳細化の事例「酒屋倉庫問題」（１） • 「酒屋倉庫問題」とは – 情報処理[3] に記載されている「ある酒類販売会 社」（以下酒屋と記す）における「受付係」の仕事 （在庫なし連絡，出庫指示書作成，在庫不足リス ト作成）のための計算機プログラムを作成する」 – 酒屋には倉庫係，受付係がある – 業務：入庫、出庫 • 入庫（倉庫係）→積荷票を渡す（倉庫→受付） • 出庫依頼受付（受付）→在庫有り：出庫指示／在庫な し：在庫無し連絡＆不足リスト作成 [3]山崎利治, 共通問題によるプログラム設計技法解説，情報処理Vol25 No9(1984). 7
- 10. 詳細化の事例：問題１ • 「Ｎ→Ｌ１：在庫なし連絡票の出力項目の求め方が決まっている」 • Nを満たすにはN1,N2,N3を実行する必要がある – 「Ｍ→Ｎ１：在庫なし連絡票の出力項目が決まっている」 – 「Ｍ→Ｎ２：出庫指示書の出力項目が決まっている」 – 「Ｍ→Ｎ３：在庫不足リストの出力項目が決まっている」 • 実際にはL1を行うためには、Ｍ→Ｎ１だけで十分 – →成立条件が厳しくなる • 依存性を広く取りすぎている問題 本稿での依存性 ゴールＭ→Ｑの事前状 態の成立が，ゴールＰ →Ｍの達成結果による 場合，ゴールＭ→Ｑは ゴールＰ→Ｍに依存し ているといい，この関 係を依存性という． 10
- 11. 詳細化の事例：問題２ • 「Ｌ→Ｇ１：在庫なし連絡票のレイアウトが決まっている」 • G1に必要なこと – 「Ｎ→Ｌ１：在庫なし連絡票の出力項目の求め方が決まっている」 – 「Ｐ→Ｍ１：在庫なし連絡票を出力するメディアが決まっている」 • ただし，両方同時並行で行っても構わない – Ｐ→Ｍ，Ｍ→Ｎ，Ｎ→Ｌという表記は同時並行を認めない書き方 – →事前状態の成立条件が厳しくなってしまう • 同時並行で処理している場合、確実に終了している必要のある依 存性の書き方の問題 複雑化した並列作業で重要：アジャイル 11 ウォー ター フォー ル
- 12. 「依存性の表現」方法の提案 問題１（依存性の範囲の明示） • Ｐ⊃Ｐ１→Ｑ（ ⊃で表現） – 事前状態Ｐがいくつかの要素｛Ｐ１， Ｐ２，Ｐ３・・・Ｐｎ｝に分解可能で， – それらの要素の一部が成立すれ ば事前状態が成立したとみなせる 場合， – 事前状態Ｐの後に⊃をつけ，その 要素を列挙することにより，その列 挙した状態が成立すれば，事前状 態が成立したとみなす． • 例えば，事前状態Ｐが｛Ｐ１，Ｐ２， Ｐ３｝に分解可能で，Ｐ１を満たせ ば事前状態が成立したとみなせ る場合は，Ｐ⊃Ｐ１→Ｑと記述 問題２（依存要素全部の記述） • Ｍ＞Ｐ１→Ｑ１（＞で表現） – 事前条件の前に成立していることを 明示したい場合は， – 事前状態Ｐの後に＞をつけ，明示し たい状態を列挙する • 例えば， – Ｐ→Ｑが，Ｐ→Ｍ，Ｍ→Ｑと分解でき – Ｐが｛Ｐ１，Ｐ２，Ｐ３｝ – Ｍが｛Ｍ１，Ｍ２，Ｍ３｝ – Ｑが｛Ｑ１，Ｑ２，Ｑ３｝に分解可能な 時， • Ｍ⊃Ｍ１→Ｑ１の事前状態Ｍ１が成 立する前に，Ｐ１，Ｐ２が成立する 必要がある時、Ｍ⊃Ｍ１，Ｍ＞｛Ｐ１， Ｐ２｝→Ｑ１と記述 M1>{P1,P2}→Q1と書く 方法も考えられる 12
- 14. 関連研究 • i*との比較 – i*は依存性を表現してい るがトップゴールと要求 の関係を示していない • ＵＭＬとの関係 – 振る舞い図 • アクティビティ図等 • プロセスを表している • マイルストーン分解 – 構造図 • クラス図等 • データ構造を表す • 要素分解 • 本稿の提案により、１つ の図（ＫＡＯＳ[1]）で依 存性・振る舞い・構造が 表現できる – トップダウンから要求ま での詳細化において、プ ロセスと構造の分解を 繰り返し行う – これを１つの図で表現し たい場合に有効 ＊[1] Axel van Lamsweerde, “Requirements Engineering:From System Goals to UML Models to Software Specications ”,Wiley,2009. の表紙は「バベルの塔」が書かれている 14
- 15. 今後の研究 • ゴールの種類について • 今回取り上げたのは – 達成ゴール：機能要求中心 • 今後の課題： – ソフトゴール・回避ゴール • セイフティ・セキュリティ（悪 いことは起こらない） • 非機能要求 • 酒屋倉庫問題に関して – 酒屋倉庫問題で記述され ていない要求について • 注文番号は出庫指示書の 出力項目として挙げられて いるが，どのように生成さ れるか明示されていない ＝要求の抜けを発見でき るか？ • 積荷票からどのように出庫 を割り当てるか，明示され ていない→ＷＧ１３で、「ＡＩ 版酒屋倉庫問題」として議 論 15
- 16. まとめ • 要求を抽出する方法：KAOS – 大きなシステム目標から１エージェントに対する要求 まで、ゴールを詳細化する • ゴールの詳細化の方法 – マイルストーン分解（→）：P→Q：P→M、M→Q – 要素分解：P→Q（Q)：P→Q1…P→Qn,{Q1…Qn}→Q • 詳細化した場合、Pを見直さないと、以下の問題 – 不必要な事前条件が含まれてしまう（問題１） – 問題１を行うことで必要な事前条件が抜ける（問題２） • これらは依存性の問題：依存性を記述できる KAOSの方法を提案し、記述できることを確認した 複雑化した並列作業で重要：アジャイル 16
- 17. Ｑ＆Ａ（１） • Ｑ１：ゴール間と依存性の関係について – 分割方法によって、依存性が密になってしまう方法、 疎になる方法がある。 – 依存性が疎になるほうが望ましいが、それには、特 に「要素分解でどの視点で分割するか」が重要であ ることが研究上、感じている – ただし、その「要素分解でどの視点で分割するか」の 視点と順番が、業務などの対象で違う模様 • Ｑ：今回は、その研究のため、まず記述法を提案 したということ？ – そのとおり 17
- 18. Ｑ＆Ａ（２）－１ • Ｑ２：視点の分類について、山本先生がＤ－ＣＡ ＳＥでいろいろあげているが・・・ – 存じ上げております。ただし、視点を１つ適用すれば いいというものでもなく、業務に適用するには、どの 視点をまず利用し、次にどの視点・・・というのが業務 ごとに考えられるので、その点が今後の研究対象 • Ｑ：自動車でできると面白いかも – （その場では言ってませんが）考えてます。自動車の 場合、どの機種でも考慮することというケースがあり、 それが共通化できるだけでも意味あると思っている 18
- 19. Ｑ＆Ａ（２）－２ • Ｑ２（つづき）今後の研究の「注文番号」は業 務的にないとおかしいという意味？ – そうではなく、いきなり注文番号がでてきたけど、 どのように生成するか書かれていないので、おか しいという意味 – 今後の話として２つあり、（１）のあとに（２）と思っ ている • 検証により、書かれているものが、書かれていないの でおかしいと判断する：今回の研究の延長にある？ • 業種別にゴール分解を考え、この業種なら、この項目 がないとおかしいと判断する→Ｑ＆Ａ（１）に関連 19