要求 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第12回】
•
0 likes•74 views
MaruLaboの浅海ゼミでの講座のスライドです。 https://www.marulabo.net/docs/asami12/ オブジェクト指向開発の要求モデリングについて説明します。
![第1部 基本編の構成
• 概論 [第1回]
• 開発プロセス [第2回]
• 基本モデル [第3回]
• 静的モデル(1) [第4回]
• 静的モデル(2) [第5回]
• 動的モデル [第6回]
• 協調モデル [第7回]
• 関数モデル [第8回]
• 物理モデル [第9回]
• 作業分野 [第10回]
• ビジネス・モデリング [第11回]
• 要求 [第12回]
• 要求/ユースケース [第13回]
• 分析 [第14回]
• 作業分野
• 設計 [第15回]
• 実装 [第16回]
• テスト [第17回]
• アプリケーション・アーキテクチャ [第18回]
• ドメイン・モデル [第19回]
• アプリケーション・モデル [第20回]
• プレゼンテーション・モデル [第21回]
• ケーススタディ[第22回]
• 要求モデル [第23回]
• 分析モデル [第24回]
• 設計モデル [第25回]
• 実装 [第26回]
• テスト [第27回]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
Recommended
More Related Content
Similar to 要求 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第12回】
Similar to 要求 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第12回】 (20)
More from Tomoharu ASAMI
More from Tomoharu ASAMI (9)
要求 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第12回】
- 2. 第1部 基本編の構成 • 概論 [第1回] • 開発プロセス [第2回] • 基本モデル [第3回] • 静的モデル(1) [第4回] • 静的モデル(2) [第5回] • 動的モデル [第6回] • 協調モデル [第7回] • 関数モデル [第8回] • 物理モデル [第9回] • 作業分野 [第10回] • ビジネス・モデリング [第11回] • 要求 [第12回] • 要求/ユースケース [第13回] • 分析 [第14回] • 作業分野 • 設計 [第15回] • 実装 [第16回] • テスト [第17回] • アプリケーション・アーキテクチャ [第18回] • ドメイン・モデル [第19回] • アプリケーション・モデル [第20回] • プレゼンテーション・モデル [第21回] • ケーススタディ[第22回] • 要求モデル [第23回] • 分析モデル [第24回] • 設計モデル [第25回] • 実装 [第26回] • テスト [第27回]
- 3. SimpleModeling2021 • オブジェクト指向分析設計での共通範囲 • UML/UP • 本講座で使⽤するUMLプロファイル • プロファイル：SimpleModeling2021 (SM2021) • オブジェクト指向分析設計の基本からの拡張部を明確化 • アジャイル開発 • Communication • Embrace Change • Travel Light • Scaling • クラウド・アプリケーション • モデル駆動開発 SM2021 Travel Light Embrace Change Cloud Model-Driven Scaling
- 4. 原理 (Principle) • Agail Software Development [ASD] • SRP (The Single Responsibility Principle) • OCP (The Open-Close Principle) • LSP (The Liskov Substitution Principle) • … • GRASP (General Responsibility Assignment Software Patterns or Principals) • Low Coupling • High Cohesion • … • Writing Effective Use Cases [WEUC] • Scope • …
- 5. パターン (Pattern) • Design Patterns [DP] • Observer, Strategy, … • Domain Driven Design [DDD] • Ubiquitous Language, Intention- Revealing Interfaces, … • Analysis Patterns [AP] • Party, Quantity, … • Pattern-Oriented Software Architecture [POSA] • Layers, Pipes and Filters, … • Patterns of Enterprise Application Architecture [PEAA] • Unit of Work, Data Transfer Object, … • Enterprise Integration Patterns [EIP] • Message Bus, Aggregator, … • Patterns for Effective Use Cases [PEUC] • CompleteSingleGoal, VerbPhraseName, … • AntiPatterns [AnP] • Stovepipe System, Analysis Paralysis, …
- 6. 内容 • 要求作業の概要 • 開発⽂脈の整理 • 要求モデル • ユースケース・モデル • 情報モデル
- 7. 概要 ⽬的、全体像
- 8. 第10回 作業分野
- 12. SM2021
- 14. ビジョン
- 15. 要求モデル • ビジョン宣⾔ • コンテキスト・モデル • 機能要求 • ⾮機能要求
- 16. ビジョン宣⾔ • システム開発の⽬標 • システム開発のモデリングする際のガイドとなる • ビジネス・モデリングのビジョン宣⾔をシステム開発に落し込 む • ビジネスを成功させるためのシステムの⽬標 → システム開発の⽬標
- 18. 【⾷堂予約システム】ビジョン宣⾔ • スマートフォンアプリから⼊場予約ができるシステムを開発 • 実現可能性を確認するための最⼩構成のシステム開発を⾏う • 将来⼊店予約に加えてテーブル予約も⾏いたいので、将来の拡 張を意識した構造にする 開発ターゲット システム構成 将来構想 システム開発の観点でビジョンを定義
- 22. 要求モデル
- 23. 機能要求 • 要求 (Requirement) • 要求項⽬を⾃由フォーマットで記述 • 要求ごとに優先度や⾒積もりを定義する • その他、必要に応じてモデル要素を追加する • 例：ゴール問題(Goal/Problem)、価値(Value)
- 24. 要求 (Requirement) • システムに対する要求を⾃由フォーマットで記述 • 基本形(の例) • ID The system shall function • ID system は function すべき • ⽇本語の⽂法には合っていないので表などで管理するのがよさ そう • 必要に応じて属性や記述⽅法は追加する ID 優先度 サブジェクト 機能 123 Shall ⾷堂予約システム ⼊場待ちの予約ができる
- 25. 要求のMosCow基準 優先度 意味 備考 Must have 必須要求 要求 Should have 重要な要求 要求 Could have 可能であれば実現したい要求 要件 Want to have 将来検討 要望
- 26. 要求の属性 (RUP) 属性 意味 状態 (Status) 提案(Proposed), 承認(Approved), 却下(Rejected), 登録(Incorporated) 便益 (Benefit) 決定的(Critical), 重要(Important), 有⽤(Usefull) 労⼒ (Effort) 時間と⼯数の⾒積もり リスク (Risk) 実現のリスク: ⾼(High), 中(Medium), 低(Low) 安定性 (Stability) 要求の変更の可能性:⾼(High), 中(Medium), 低(Low) リリースバージョン (TargetRelease) 要求が実現されるべき製品バージョン
- 27. ⾒積もり • ファンクション・ポイント法 • ユースケース・ポイント法 • ⾒積もりのための予備設計をどこまでやるか • 次回検討予定
- 28. 【⾷堂予約システム】機能要求 ID 優先度 サブジェクト 機能 1 Must ⾷堂予約システム ⼊場待ちの予約ができる 2 Should ⾷堂予約システム ⼀定の時間前にリマインダのメッセージを送付 3 Could ⾷堂予約システム 送付時間を管理画⾯で設定可能 4 Could ⾷堂予約システム リマインダメッセージを管理画⾯で設定可能
- 29. ⾮機能要求 • システムの制約事項に関する要求 • ⾮機能要求の種類 • 性能 • 容量 • 可⽤性 • 標準準拠 • セキュリティ
- 30. 【⾷堂予約システム】⾮機能要求 項⽬ 内容 性能 レスポンスタイム：3秒以内 スループット：10回/秒 容量 最⼤利⽤者⽬安：100名 可⽤性 稼働率：4σ (ダウンタイム約33分/年) メンテナンス時間：⽉3時間夜間 標準準拠 AWS上に構築 セキュリティ HTTPSを使⽤ ⼀時ユーザーはスマートフォンの端末番号 恒久ユーザーはパスワード⽅式＆SNS認証
- 31. 稼働率 • A : 稼働率 • MTBF : 動作可能時間 • MTTR : 動作不能時間 • 𝐴 = !"#$ !"#$ %!""& σ % 稼働率(ダウン時間/1年) 1σ 68.269 約113⽇ 2σ 95.45 約16⽇ 3σ 99.73 約23時間 4σ 99.99367 約33分 5σ 99.999426 約3分 6σ 99.9999998 約0.06秒
- 32. ユースケース・モデル
- 33. ユースケース・モデル • ユースケース • システムの振る舞いを利⽤者視点の物語として記述 • アクター、ステークホルダなどシステム外部との接点を明確化 • ⾒積もりの対象 • ユースケース記述 • 物語の脚本を⾃然⾔語で記述 • ロバストネス分析 • 脚本からシステムの構造を抽出する技法 • ユースケース駆動開発 • ユースケースを起点にプログラム、テストケース、マニュアルを作成 • ユースケースを⽤いて開発の優先順位を管理 第14回 分析 第7回 協調モデル 第10回 作業分野
- 35. 【⾷堂予約システム】ビジネス・ユースケース記述 • ユースケース名: ⼊店予約して⼊店する • プライマリ・アクター: 利⽤者 • あらすじ: ランチでお店が満杯だったので、予約システムに登録をし て、空きができたことをSMSで取得後に、再度お店に⾏き⼊店した。 • シナリオ: 1. ランチでお店に⾏ったところ満杯だった 2. 予約システムに会員アプリで登録してその場を離れた 3. SMSで通知があったで、会員アプリを⾒たところ⼊店の順番が近づいてい ることが分かった 4. お店についた頃にSMSで再度通知があって、⼊店が可能になっていること が分かった 5. お店についてホール係にアプリ画⾯を⾒せると⼊店できた 第11回 ビジネス・モデリング 要求モデルのユースケース記述に連携
- 36. フィーチャー・モデル • 開発する機能や制約などを開発項⽬としてモデル化する • ユースケースが物語を記述する重いモデルであるため、ちょっ とした要件にはオーバースペック • フィーチャーとしてモデル化
- 38. 情報モデル
- 39. 情報モデル • 分析・設計でのモデリング対象の準備モデル • エンティティ・モデル • システムが扱う永続オブジェクト • ルール・モデル • システムが準拠する規則 • 要求モデルとユースケース・モデルを記述する際に使⽤する語 彙を⽤語集と規則集として整備 • ⽤語集、規則集を発展させてエンティティ・モデル、ルール・モデル を構築
- 40. エンティティ・モデル • エンティティ • システムが扱う永続オブジェクト • データベースに格納して管理する • アクター • システム外にあるオブジェクト(の代理オブジェクト) • システムが⾃由に操作することができない • ⽤語集 • エンティティ⼀覧
- 41. 【⾷堂予約システム】⽤語集 ⽤語 クラス ステレオ タイプ 意味 予約システム 開発対象のシステム。(SuD: System under Development) 利⽤者 User actor ⾷堂に⾷事に来た顧客 ホール係 Staff actor ⾷堂のホール係 ⽀配⼈ ⾷堂の管理者 予約 Reservation business event 予約の総称 ⼊店予約 EnterRservation business event ⼊店の予約。昼⾷時の待ち⾏列のエントリーに使⽤ する。 テーブル予約 TableReservation business event テーブルの予約。コース料理の予約の場合に使⽤で きる。 テーブル Table resource テーブル。予約対象になる。 第11回 ビジネス・モデリング 情報モデルの⽤語集に連携・統合
- 42. 【⾷堂予約システム】⽤語集 ⽤語 クラス ステレオ タイプ 意味 予約システム 開発対象のシステム。(SuD: System under Development) 利⽤者 User actor ⾷堂に⾷事に来た顧客 ホール係 Staff actor ⾷堂のホール係 ⽀配⼈ ⾷堂の管理者 予約 Reservation business event 予約の総称 ⼊店予約 EnterRservation business event ⼊店の予約。昼⾷時の待ち⾏列のエントリーに使⽤ する。 テーブル予約 TableReservation business event テーブルの予約。コース料理の予約の場合に使⽤で きる。 テーブル Table resource テーブル。予約対象になる。 ビジネス・モデリングのものを そのまま活⽤ ユースケース・モデリングにより 洗練されていく
- 47. ルール・モデル • システムの振る舞いに関する規則 • ルールの種類 • 制約 (Constraint) • 刺激/反応 (Stimulus/Response) • オペレーション制約 (Operation Constraint) • 構造制約 (Structure Constraint) • 導出 (Derivation) • 演算 (Computation) • 推論 (Inference) • 存在 (Existence) • トリガー/アクション (Triger/Action) • 規則集 • ルール⼀覧
- 48. 【⾷堂予約システム】ビジネス・ルール(兼 規則集) • 案内通知⼿段はメール、SMS、PUSHから選べる • ⼊店申請の2組前になった時に案内通知を⾏う • 案内通知の⽂⾯を管理コンソールで編集できる • ⼊店可能になったら案内通知を⾏う • 案内通知の⽂⾯を管理コンソールで編集できる • ⼊店可能後10分後に案内通知を⾏う • 案内通知の⽂⾯を管理コンソールで編集できる • ⼊店申請は⼊店受付してから30分でキャンセルになる • キャンセル時に案内通知を⾏う • 案内通知の⽂⾯を管理コンソールで編集できる 第11回 ビジネス・モデリング 要求モデルのルール・モデルへ連携・統合
- 49. 【⾷堂予約システム】ビジネス・ルール(兼 規則集) • 案内通知⼿段はメール、SMS、PUSHから選べる • ⼊店申請の2組前になった時に案内通知を⾏う • 案内通知の⽂⾯を管理コンソールで編集できる • ⼊店可能になったら案内通知を⾏う • 案内通知の⽂⾯を管理コンソールで編集できる • ⼊店可能後10分後に案内通知を⾏う • 案内通知の⽂⾯を管理コンソールで編集できる • ⼊店申請は⼊店受付してから30分でキャンセルになる • キャンセル時に案内通知を⾏う • 案内通知の⽂⾯を管理コンソールで編集できる ビジネス・モデリングのものを そのまま活⽤ ユースケース・モデリングにより 洗練されていく
- 50. まとめ • 要求作業の概要 • 要求作業の流れ • ビジョン • 要求モデル • ユースケース・モデル • 情報モデル • ユースケース・モデルの詳細は次回
- 51. 参考⽂献 • The Unified Modeling Language Reference Manual, 2nd (Rumbaugh他, 2004) • The Unified Modeling Language User Guide, 2nd (Booch他, 2004) • The Unified Software Development Process (Jacobson他, 1999) • The Object Constraint Language, 2nd (Warmer 他, 2003) • UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design (Arlow 他, 2005) • OMG Unified Modeling Language Version 2.5 (OMG, 2015) • 上流⼯程UMLモデリング (浅海, 2008) • Writing Effective Use Cases (Cockburn, 2000) • Java Modeling in Color With Uml: Enterprise Components and Process (Coad他, 1999)