Download as PDF, PPTX
![第1部 基本編の構成
• 概論 [第1回]
• 開発プロセス [第2回]
• 基本モデル [第3回]
• 静的モデル(1) [第4回]
• 静的モデル(2) [第5回]
• 動的モデル [第6回]
• 協調モデル [第7回]
• 関数モデル [第8回]
• 物理モデル [第9回]
• 作業分野 [第10回]
• ビジネス・モデリング [第11回]
• 要求 [第12回]
• 要求/ユースケース [第13回]
• 要求/シナリオ [第14回]
• 分析 [第15回]
• 分析/コンポーネント分析 [第16回]
• 分析/イベント駆動 [第17回]
• 作業分野
• 設計 [第18回]
• 設計/アーキテクチャ設計 [第19回]
• 設計/コンポーネント設計(1) [第20回]
• 設計/コンポーネント設計(2) [第21回]
• 設計/コンポーネント設計(3) [第22回]
• 設計/ドメイン設計 [第23回]
• 設計/ UX/UI設計 [第24回]
• 実装 [第25回]
• テスト [第26回]
• アプリケーション・アーキテクチャ [第27回]
• ドメイン・モデル [第28回]
• アプリケーション・モデル [第29回]
• プレゼンテーション・モデル [第30回]
• ケーススタディ[第31回]
• 要求モデル [第32回]
• 分析モデル [第33回]
• 設計モデル [第34回]
• 実装 [第35回]
• テスト [第36回]](https://image.slidesharecdn.com/design-component-spec-230407112240-7d10c8f2/75/2-21-3-2048.jpg)
![原理 (Principle)
• Agile 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
• …](https://image.slidesharecdn.com/design-component-spec-230407112240-7d10c8f2/75/2-21-6-2048.jpg)
![パターン (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, …](https://image.slidesharecdn.com/design-component-spec-230407112240-7d10c8f2/75/2-21-7-2048.jpg)
![DTO (Data Transfer Object) [PEAA]
• コンポーネントのインタフェースのオペレーションの引数と復
帰値ではDTOを⽤いるのがお勧め
• Value Object [DDD]
• 値として振る舞うオブジェクト
• 同定⽐較は参照ではなく値で⾏う
• ネットワーク経由での送付、バイナリ・データとしての格納が可能
• JSONでの整列化
• ADT (Algebraic Data Type)
• 代数的データ型
• 関数型で使⽤する論理積、論理和をサポートしたデータ型
• 可能であればADTにした⽅が関数型プログラミングと相性がよい](https://image.slidesharecdn.com/design-component-spec-230407112240-7d10c8f2/75/2-21-16-2048.jpg)
![コンポーネント仕様の⽅針
• 分析モデルで抽出した責務を実現
• 疎結合、⾼凝集 ( Low Coupling, High Cohesion [GRASP])
• 部品としての再利⽤性を⾼める
• テスト容易性 (Testability)に配慮する
• 保守性 (Serviceability)に配慮する](https://image.slidesharecdn.com/design-component-spec-230407112240-7d10c8f2/75/2-21-23-2048.jpg)
![復帰値
• エラー情報を返すScalaモナド＋DTO
• 例：Try[ReserveResult]
• 復帰値にもDTOが望ましい
• ソース互換/バイナリ互換
• 疎結合性を⾼めるため参照ではなく値を渡すのが望ましい
• RPC
• Tryを使うことで、関数型プログラミングを活⽤して、エラー
ハンドリング処理を効率的に⾏うことができるようになる
• 必要に応じて専⽤のScalaモナドを作成するのもよい](https://image.slidesharecdn.com/design-component-spec-230407112240-7d10c8f2/75/2-21-33-2048.jpg)
![まとめ
• コンポーネント仕様の⽅針
• 疎結合、⾼凝集 ( Low
Coupling, High Cohesion
[GRASP])
• 部品としての再利⽤性を⾼める
• テスト容易性 (Testability)に配
慮する
• 保守性 (Serviceability)に配慮
する
• コンポーネント仕様
• インタフェース
• オペレーション
• レセプション
• ⽣成
• 拡張点、変化点
• メトリクス
• データ分析
• 物理モデル](https://image.slidesharecdn.com/design-component-spec-230407112240-7d10c8f2/75/2-21-59-2048.jpg)
Uploaded byTomoharu ASAMI
設計/コンポーネント設計(2) 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第21回】
MaruLaboの浅海ゼミでの講座のスライドです。 https://www.marulabo.net/docs/asami21/ 作業分野「設計」についてアーキテクチャ設計、コンポーネント設計、ドメイン設計、UX/UI設計の順に 取り上げています。 今回はコンポーネント仕様設計について説明しました。 コンポーネント仕様設計ではソフトウェアを実装するプログラミング言語や動作基盤をターゲットにした モデリングを行います。 次回のコンポーネント実現設計で、コンポーネント仕様設計のモデルをプログラミング言語(Scala)で 実現する方法について説明する予定です。
設計/コンポーネント設計(2) 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第21回】
- 1.
- 2. SimpleModeling2021 • オブジェクト指向分析設計での共通範囲 • UML/UP •本講座で使⽤するUMLプロファイル • プロファイル：SimpleModeling2021 (SM2021) • オブジェクト指向分析設計の基本からの拡張部を明確化 • アジャイル開発 • Communication • Embrace Change • Travel Light • Scaling • Component-Based Development • クラウド・アプリケーション • モデル駆動開発 SM2021 Travel Light Embrace Change Cloud Model-Driven Scaling CBD
- 3. 第1部 基本編の構成 • 概論[第1回] • 開発プロセス [第2回] • 基本モデル [第3回] • 静的モデル(1) [第4回] • 静的モデル(2) [第5回] • 動的モデル [第6回] • 協調モデル [第7回] • 関数モデル [第8回] • 物理モデル [第9回] • 作業分野 [第10回] • ビジネス・モデリング [第11回] • 要求 [第12回] • 要求/ユースケース [第13回] • 要求/シナリオ [第14回] • 分析 [第15回] • 分析/コンポーネント分析 [第16回] • 分析/イベント駆動 [第17回] • 作業分野 • 設計 [第18回] • 設計/アーキテクチャ設計 [第19回] • 設計/コンポーネント設計(1) [第20回] • 設計/コンポーネント設計(2) [第21回] • 設計/コンポーネント設計(3) [第22回] • 設計/ドメイン設計 [第23回] • 設計/ UX/UI設計 [第24回] • 実装 [第25回] • テスト [第26回] • アプリケーション・アーキテクチャ [第27回] • ドメイン・モデル [第28回] • アプリケーション・モデル [第29回] • プレゼンテーション・モデル [第30回] • ケーススタディ[第31回] • 要求モデル [第32回] • 分析モデル [第33回] • 設計モデル [第34回] • 実装 [第35回] • テスト [第36回]
- 4. 本講座のアプローチ • オブジェクト指向分析設計の基本を確認 • UML+ UP(Unified Process) • CBD (Component-Based Development) • 最新技術でアップデート • クラウド・コンピューティング • イベント駆動、分散・並列 • ビッグデータ、AI、IoT • コンテナ • 関数型 • OFP(Object-Functional Programming), Reactive Streams • ルール, AI • DevOps • アジャイル開発 • DX (Digital Transformation) 第25回 アプリケーション・アーキテクチャ 第2回 開発プロセス 第9回 物理モデル 第11回 ビジネス・モデリング 第2部 クラウド・アプリケーション編 第21回 設計/ドメイン設計 第20回 設計/コンポーネント設計 第2部 クラウド・アプリケーション編
- 5. 本講座の選択 • プログラミング⾔語 • Scala •Javaエコシステム • Pythonを併⽤ • コンテナ • Docker/Kubernetes • CI/CD • Daggar • ミドルウェア • AWS • クラウド・プラットフォーム • AWS • アプリケーション・フレームワーク • 本講座が定義する仮想的なアプリケーション・フレームワーク • コンポーネント・フレームワーク • クラウド・アプリケーション • 関数型
- 6. 原理 (Principle) • AgileSoftware 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 • …
- 7. パターン (Pattern) • DesignPatterns [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, …
- 8. 内容 • コンポーネント • コンポーネント設計へのアプローチ •コンポーネント仕様設計 • 準備 • 論理モデル • 物理モデル • コンポーネント実現設計
- 9.
- 10. 制約 (Constraint) • テキストで表された⾃然⾔語または特定のフォーマル⾔語による意味的な 条件または制限 •OCL (Object Constraint Language) • オブジェクト制約記述⾔語 • ⼀種の関数型⾔語 • 契約による設計 (Design by Contract) • 不変条件 (invariant) : オブジェクトで常に真となる条件 • 事前条件 (pre-condition) : オペレーションの実⾏の前提となる条件 • 事後条件 (post-condition) : オペレーションの実⾏完了の前提となる条件 • 制約を重視する理由 • 散逸しがちな要件を確実に記録して実装につなげる • 要件と実装の距離が短い分野なので効果抜群 • できるだけ上流のモデルで実装に直結する精度の仕様を確⽴しておきたい 再掲 第5回 静的モデル(2)
- 11.
- 12. 制約の使い所 • データ型/値域 • データ型の不変表明として定義 •画⾯⼊⼒、データ移⼊のパラメタ/データ検証 • 画⾯⼊⼒の⼊⼒補助 • クラス/不変表明 • バグの検出に有効 • オペレーション/事前条件 • 画⾯⼊⼒、データ移⼊のパラメタ/データ検証 • 画⾯⼊⼒の⼊⼒補助 • オペレーション/事後条件 • バグの検出に有効 • データ破壊を未然に防ぐ効果 • データ移⼊・移出 • 異常データのチェック・クレンジング 再掲 第5回 静的モデル(2) コンポーネント仕様では、できるだけ制約 を⽤いて仕様を精密に定義したい コンポーネント実現では、必要に応じて 適材適所で使うとよい Travel Light
- 13. シグナル (Signal) • インスタンス間を通信する⾮同 期な刺激の仕様 •いわゆる「イベント」はUML上 はシグナルとしてモデル化して いくことになるが… • ビジネス領域で発⽣するイベント • ビジネス・イベント • 業務ドメインで発⽣するイベント • ドメイン・イベント • アプリケーション上で発⽣するイ ベント • アプリケーション・イベント 再掲 第6回 動的モデル
- 14. イベント (Event) • 4種類のイベント •CallEvent • オペレーションが呼び出された時に発⽣するイベント • SignalEvent • シグナルを受信した時に発⽣するイベント • TimeEvent • 指定した時間に発⽣するイベント • after : ⼀定時間後 • when : 指定時間 • ChangeEvent • 指定した条件式が真になった時に発⽣するイベント • プロパティの変更時など • UMLではオブジェクトがシグナルなどの刺激を受けたことを通知す るモデル要素としてイベントを定義している 再掲 第6回 動的モデル
- 15. アプリケーション領域でのイベント • UMLのメタモデル上は、いわゆる「イベント」はSignalEvent として扱い、「イベント」の設計はSignalを⽤いることになる が、慣習にしたがって「イベント」として扱っていく • ビジネス・イベント •ドメイン・イベント • アプリケーション・イベント SM2021 再掲 第6回 動的モデル
- 16. DTO (Data TransferObject) [PEAA] • コンポーネントのインタフェースのオペレーションの引数と復 帰値ではDTOを⽤いるのがお勧め • Value Object [DDD] • 値として振る舞うオブジェクト • 同定⽐較は参照ではなく値で⾏う • ネットワーク経由での送付、バイナリ・データとしての格納が可能 • JSONでの整列化 • ADT (Algebraic Data Type) • 代数的データ型 • 関数型で使⽤する論理積、論理和をサポートしたデータ型 • 可能であればADTにした⽅が関数型プログラミングと相性がよい
- 17. モナド • 本講座では必要に応じて⽤語モナドを以下の呼び⽅で使い分け ます • Monad •Catsで定義してモナド則に従ったモナド • CatsのProperty-Basedテスティングでモナド則確認済み • Scalaモナド • Scalaのfor内包表記(comprehension)のコンベンション(map/flatMap コンビネータ)に従ったオブジェクト • モナド則を満たしていないことがある(Tryなど) 第8回 関数モデル
- 18.
- 19. コンポーネント仕様 (Component Specification) •論理モデル • 物理モデル
- 20.
- 21.
- 22. コンポーネント仕様 (Component Specification) •インタフェース • 提供インタフェース (Provided Interface) • 要求インタフェース (Required Interface) • レセプション • イベント • ⽣成 • ファクトリ • DI (Dependency Injection) • 拡張点 • 変化点 • メトリックス (Metrics) • データ分析
- 23. コンポーネント仕様の⽅針 • 分析モデルで抽出した責務を実現 • 疎結合、⾼凝集( Low Coupling, High Cohesion [GRASP]) • 部品としての再利⽤性を⾼める • テスト容易性 (Testability)に配慮する • 保守性 (Serviceability)に配慮する
- 24. テスト容易性 (Testability) • コンポーネントのテストのしやすさ •他のコンポーネントとの依存性をできるだけ排除する • インタフェース(提供、要求)を通してアクセス • コンポーネントの作成はDI(Dependency Injection)を可能にす る • クライアントの実⾏⽂脈は実⾏コンテキスト経由で取得するよ うにする • 認証情報、時間 • コンポーネントの内部情報がテスト・プログラムから取得でき るようにする
- 25. 保守性 (Serviceablity) • コンポーネントの維持管理のしやすさ •コンポーネントのバージョン管理 • コンポーネントを構成するソースコードやマニュアルを⼀元管 理する • 管理に必要なコンポーネントの内部状態を取得可能にする • コンポーネントのチューニングに必要なメトリクスを採取する
- 26.
- 27. インタフェース設計 • インタフェースの種類 • 提供インタフェース(providedinterface) • 要求インタフェース (required interface) • 契約による設計 (Design by Contract) • 事前条件、事後条件、不変条件を使ってオペレーションの仕様をより 精密に記述する • ISP (The Interface Segregation Principle) • いろいろな⽤途に使える巨⼤インタフェースではなく、⽬的ごとに定 義したインタフェースを複数⽤意する
- 28. オペレーション設計の⽅針 • コンポーネントのオペレーション設計は通常のオペレーションより も頑健さを⽬指す • 仕様の明確化・暗黙の仕様を排除 •仕様をできるだけ型に落とし込んでコンパイル時にエラー検出できるように する • ⽤途に特化したDTOやデータ型の採⽤ • 関数型 • 型で記述できない仕様もDbC(契約による設計)などを⽤いて仕様化 • 仕様の明確化 • 実⾏時チェック • 部品としての再利⽤性を⾼める • 仕様変更が起きにくい仕様 • ソース互換/バイナリ互換
- 29.
- 30.
- 31. オペレーション設計の着眼点 • 引数 • 復帰値 •エラー・ハンドリング • 契約による設計 • バイナリ互換/ソース互換 • RPC • 実⾏コンテキスト • オペレーションの特性 • ⾮同期
- 32. 引数 • 明⽰的引数としてDTOオブジェクトを1つ渡す形を推奨 • ソース互換/バイナリ互換 •疎結合性を⾼めるため参照ではなく値を渡すのが望ましい • RPC • 必要に応じて暗黙引数で実⾏コンテキストを渡す • 暗黙引数がサポートされていない⾔語では明⽰的な引数として渡す
- 33. 復帰値 • エラー情報を返すScalaモナド＋DTO • 例：Try[ReserveResult] •復帰値にもDTOが望ましい • ソース互換/バイナリ互換 • 疎結合性を⾼めるため参照ではなく値を渡すのが望ましい • RPC • Tryを使うことで、関数型プログラミングを活⽤して、エラー ハンドリング処理を効率的に⾏うことができるようになる • 必要に応じて専⽤のScalaモナドを作成するのもよい
- 34. エラー・ハンドリング • エラー・ハンドリングの⽅式 • 例外 •Scalaモナド • 本講座ではScalaモナドであるTry,Futureをメインに使⽤す る • Try: 同期 • Future: ⾮同期 • 例外 • アプリケーション・ロジックの管轄外の異常処理で⽤いる • Java向けAPI
- 35. 契約による設計 (DbC: Designby Contract) • Scala/Javaではオペレーションに対する制約で実現 • 不変条件 (invariant) : オブジェクトで常に真となる条件 • 事前条件 (pre-condition) : オペレーションの実⾏の前提となる条件 • 事後条件 (post-condition) : オペレーションの実⾏完了の前提となる条 件 • 仕様を明⽰する • 実⾏時にエラーチェックが⾏われる • 型のエラー・チェックはコンパイル時
- 36.
- 37. ソース互換/バイナリ互換 • 仕様追加・変更がオペレーションの引数、復帰値の変更になり難い構 造を選ぶ • プログラミング⾔語要因も考慮 •Scala：デフォルト引数を使うとバイナリ⾮互換の要因になる • 部品として再利⽤していくために重要な観点
- 38. 実⾏コンテキスト • 主な管理対象 • ユーザー認証 •トランザクション • 国際化 • 表⽰フォーマット (⽇時、通貨、数値など) • できるだけ実⾏コンテキストを使⽤しないオペレーションが望 ましい • RPCでは実⾏コンテキストの移送が必要 • コンポーネント・フレームワークでのサポートが必要
- 39. オペレーションの特性 • Accessor :参照のみ • Function : (純粋関数型⾔語の)関数の性質を満たす • Mutator : 更新 • Idempotent : 冪等性 • 冪等性 • 何度呼び出してもオブジェクト側の状態は同じものになる • RPCと相性がよい(何度リトライしても同じ結果が得られる) • できるだけ: • Function > Accessor > Idempotent > Mutator
- 40. RPC (Remote ProcedureCall) • オペレーションをネットワーク経由で呼び指す可能性があるのでRPC 向きの仕様にしておくことが望ましい • 引数にはDTOを⽤いる • RPC機能は送受信とも、コンポーネント・フレームワークの機能を⽤ いる • 実⾏コンテキストが引数にある場合は、コンポーネント・フレーム ワークの機能を⽤いて移送する必要がある
- 41. ⾮同期 • ⾮同期のメカニズム • Future •クライアント側で処理を多重化できる • ジョブ • ジョブ管理で⾮同期実⾏ • オペレーションの反応時間を改善 • バッチ • 定時に⼀括実⾏ • データを蓄積した⼤規模データの扱いに適している • ジョブとバッチはコンポーネント・フレームワークの機能を利 ⽤
- 42.
- 43. レセプション • 分類⼦がシグナルの受信に対 する反応を⽤意しているとい う宣⾔ • 通常はプログラミング⾔語の 仕様外 •コンポーネント・フレームワー クで補完する必要がある • JavaではJavaBeans(コンポー ネント拡張)でレセプション相 当の機能(EventObject, EventListener)を提供 再掲(更新) 第6回 動的モデル
- 44. レセプション • レセプションで受け付ける刺激(stimulus) • イベント •メッセージ • イベント • (サービス・バスなどを経由した)外部からの刺激 • レセプションでイベント・オブジェクトを受け取る • レセプションの呼び出しはコンポーネント・フレームワークが⾏う • メッセージ • 本講座ではAkka Actorを使⽤
- 45. イベント・モデル • コンポーネントで定義するイベント • ビジネス・イベント •ドメイン・イベント • アプリケーション・イベント
- 46.
- 47. ⽣成 • コンポーネントの⽣成⽅法 • コンストラクタ •ファクトリ • ビルダー • DI (Dependency Injection) • コンポーネントのカスタマイズ項⽬を⽣成時のパラメタでなく 変化点や実⾏コンテキストとして実現することで⽣成処理を単 純化できる
- 48. DI (Dependency Injection) •本講座ではコンストラクタに対するDIを採⽤する • コンストラクタで必要な依存性情報を受取り設定する構造にす る • アノテーションなどでコンストラクタをDI対象に指定
- 49.
- 50. 拡張点 (extension point) •要求インタフェースを使⽤して、後付で機能拡張を可能にする • 部品化による再利⽤には重要な機能 • 拡張点の実現⽅法 • コンストラクタでパラメタとして受け取る • DIで注⼊ • 外部リソース(環境変数、ファイル、DB)の情報から設定 • 拡張点にOSGiを採⽤することでライブラリ・バージョン衝突 問題(ライブラリ・ヘル)を解決できる
- 51.
- 52. 変化点 (variation point) •各種デフォルト値や処理ロジックの選択などを起動時の外部パ ラメタで与える • 部品化による再利⽤には重要な機能 • 変化点の実現⽅法 • コンストラクタでパラメタとして受け取る • DIで注⼊ • 外部リソース(環境変数、ファイル、DB)の情報から設定
- 53.
- 54. メトリクス • コンポーネントの振る舞いに関する記録 • 例：オペレーションのコール数、キャッシュのヒット率 •テスト容易性、保守性の向上に寄与 • コンポーネント・フレームワークで採取、⼀元管理するのが望 ましい
- 55.
- 56. データ分析 • データ分析⽤の実⾏記録デー タ採取 • ⽤途 •レポート作成 • コンポーネントから使⽤できる データに加⼯ • AIサービスの学習データ • 実⾏記録データの種類、採取 場所、採取⽅法を設計する 第2部 クラウド・アプリケーション編
- 57.
- 58. 物理モデル • 具体的な成果物は実装で作成するので、コンポーネント仕様で は⼤枠だけ決める • コンポーネントの⼊れ物 •コンポーネント • モジュール • コンポーネントの内容物 • マニュアル • リファレンス・マニュアル • ユーザー・マニュアル • 定義ファイル • テストセット
- 59. まとめ • コンポーネント仕様の⽅針 • 疎結合、⾼凝集( Low Coupling, High Cohesion [GRASP]) • 部品としての再利⽤性を⾼める • テスト容易性 (Testability)に配 慮する • 保守性 (Serviceability)に配慮 する • コンポーネント仕様 • インタフェース • オペレーション • レセプション • ⽣成 • 拡張点、変化点 • メトリクス • データ分析 • 物理モデル
- 60. 参考⽂献 • The UnifiedModeling 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)