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-230220020053-da0a25e0/85/1-20-3-320.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-230220020053-da0a25e0/85/1-20-6-320.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-230220020053-da0a25e0/85/1-20-7-320.jpg)
![DI (Dependency Injection)
• IoC (Inversion of Control)
• 依存性の注⼊
• コンポーネント(オブジェクト)が必要とするコンポーネント(オブジェクト)
への参照作成を⾃ら⾏わず、外部から設定する
• 狙い
• コンポーネント(オブジェクト)間を疎結合[Low Coupling]にする
• 部品としての再利⽤性を⾼める
• テスト容易性を⾼める
• 注⼊のタイミング
• コンポーネント(オブジェクト)作成・組み⽴て時
• オペレーション(メソッド)呼び出し時](https://image.slidesharecdn.com/design-component-230220020053-da0a25e0/85/1-20-41-320.jpg)
Uploaded byTomoharu ASAMI
設計/コンポーネント設計(1) 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第20回】
作業分野「設計」についてアーキテクチャ設計、コンポーネント設計、ドメイン設計、UX/UI設計の順に 取り上げています。 今回はコンポーネント設計の枠組みと論点について説明しました。 次回、次次回にコンポーネント仕様設計、コンポーネント実現設計を説明する予定です。
設計/コンポーネント設計(1) 【クラウドアプリケーションのためのオブジェクト指向分析設計講座 第20回】
- 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.
- 12. UP (Unified Process) •『The Unified Software Development Process』 • 1990年代に乱⽴したオブジェクト指向開発プロセスを統⼀ • UMLが前提とするリファレン・スモデル • CBD (Component-Based Development) • アーキテクチャ • ユースケース駆動 (use-case driven) • 反復漸進 (iterative/incremental) • アーキテクチャ中⼼ (architecture centric) • ⼯程管理⽅式 • 計画駆動 • ⽂書中⼼ 第2回 開発プロセス 再掲
- 13.
- 14. コンポーネント (Component) • 再利⽤可能な部品 •明確な外部インタフェースを定め実装を隠蔽 • 新規開発を抑えることで開発期間短縮、品質向上を図る • 再利⽤性の⾼い部品化は⾃然にできることではないので、コストを掛けて積極的に狙い に⾏く • 論理モデルと物理モデルの両⽅の性質を兼ね備える • 配備の単位 • 物理的な側⾯ ⇒ モジュール • オブジェクト指向分析設計による開発の様々な側⾯を集約してパッケージ化 • モデリングとプログラミングの結節点 • モデリングはコンポーネントまで。コンポーネントの実現はプログラミングで。 • 再利⽤可能な部品にするための仕掛けが必要 • コンポーネント・フレームワーク • 実⾏コンテキスト Travel Light Travel Light 再掲 第5回 静的モデル(2)
- 15. オブジェクト指向分析設計の様々の側⾯ をコンポーネントに集約 • 機能の単位 • 機能を凝集(coherent)して実現 •開発の単位 • コンポーネント単位で開発の管理を ⾏う • 開発⼯程、担当者など • モデリングの単位 • コンポーネントの実現はプログラミ ングで • 運⽤の単位 • 配備の単位 • バージョン管理 • 仕様書・マニュアルの単位 • 外部仕様、マニュアルの作成 • テストの単位 • テスト仕様の作成単位 • テストの進捗管理の単位 • 障害調査の単位 • 障害発⽣箇所の特定 • 障害調査マニュアルの作成 • 販売・課⾦の単位 • 再利⽤可能な商品 Scaling 再掲 第5回 静的モデル(2)
- 17.
- 18. コンポーネント設計 • 分析で作成したコンポーネントを具体化する • 論理モデル •コンポーネント仕様設計 • インターフェース設計 • レセプション設計 • コンポーネント実現設計 • 内部構造・振舞い • 物理モデル • コンポーネント実現設計 • 組み⽴て情報 • モジュール CBD 第18回 設計
- 19. コンポーネント設計のポイント • 凝集(highly coherent)と疎結合(looselycoupled) • コンポーネントに機能を集約 • コンポーネント間の依存関係はできるだけ避ける • 共通情報などは実⾏コンテキストに集約 • 提供インタフェース(Provided Interface) • 外部に提供するインタフェースを定義 • 要求インタフェース(Provided Interface) • 使⽤する外部コンポーネントのインタフェースを定義 • イベント • サービス・バスを使ったイベント駆動 • 拡張点 (Extension point) • コンポーネントの機能拡張を外部プログラムで⾏うメカニズム • 要求インタフェースなどを使⽤ • 変化点 (Variation point) • コンポーネントを異なった要件で使⽤できるようにするためメカニズム • プロパティ・ファイルなどで実現 Cloud 第9回 動的モデル 再掲 第5回 静的モデル(2)
- 20. コンポーネント設計の着眼点 • コンポーネント境界を仕様でがっ ちり守る • インタフェース •レセプション • 頑健な仕様を作る • 静的型付け • 制約 (Constraint) • 契約による設計 (Design by Contract) • 関数技術の活⽤ • 型の活⽤ • アルゴリズム記述能⼒ • 疎結合 • 機能の本質に集中 • 再利⽤ • テスト容易性 • 再利⽤可能な部品 • 変化点、拡張点、型クラス • コンポーネントの実現は臨機応変 に • プログラミング主導でかまわない • 必要に応じてモデリングを⾏う Travel Light
- 21. 関数技術の活⽤ • 型クラス • 代数的データ型 •代数的性質 • Monoid • Functor • Monod • Applicative • Foldable • Traverse • Reactive Streams • ルール 第8回 関数モデル 本講座ではコンポーネント仕様に 積極的に取り込む コンポーネント利⽤者に関数型プログラミ ングを強制しない点には留意
- 22.
- 23.
- 24. 振舞いモデル • クラス • オペレーション(Operation) • 呼び出され振舞いを実⾏する • レセプション (Reception) • イベントを受付け振舞いを実⾏する • 振舞い (Behavior) • 状態機械 (StateMachine) • 状態機械図 • 活動 (Activity) • アクティビティ図 • 不透明振舞い (OpaqueBehavior) • プログラミング⾔語による⼿続き/関数 再掲 第6回 動的モデル
- 25. オペレーション • 振舞いに作⽤するために任意 のクラスのオブジェクトから 要求されることができるサー ビスの実装 • プログラミング⾔語ではメ ソッドとして実現 再掲第6回 動的モデル 本講座では関数型の技術を適⽤する
- 26. レセプション • 分類⼦がシグナルの受信に対 する反応を⽤意しているとい う宣⾔ • 通常はプログラミング⾔語の 仕様外 •イベント駆動のフレームワーク で補完する必要がある • JavaではJavaBeans(コンポー ネント拡張)でレセプション相 当の機能(EventObject, EventListener)を提供 再掲 第6回 動的モデル コンポーネント仕様で定義
- 27. 例外 (Exception) • UML1ではシグナルの⼀種だったが、UML 2からプログラミング⾔ 語の例外機能に即したモデル要素になった • UMLのメジャーな機能ではないという認識でよさそう • オペレーションに例外を指定する⽅法も仕様化されていない • メモリ不⾜などで処理の継続が困難といったケースなど、アプリ ケーション・ロジックを超えた例外処理には引き続き有効 • UMLでもアクティビティで例外ハンドラーを設定できるようになっている • パラメタエラー等のアプリケーション・ロジックの範囲でのエラー 処理に⽤いるのは⾮推奨 • 関数型の⼿法で対応するのがおすすめ • プログラミング⾔語を軸にオブジェクト指向開発をする場合など、引き続き 使⽤するのも問題はない 第8回 関数モデル 再掲 第6回 動的モデル 本講座では、コンポーネント仕様では 関数型のアプローチでエラー処理を⾏う
- 28.
- 29. シグナル (Signal) • インスタンス間を通信する⾮同 期な刺激の仕様 •いわゆる「イベント」はUML上 はシグナルとしてモデル化して いくことになるが… • ビジネス領域で発⽣するイベント • ビジネス・イベント • 業務ドメインで発⽣するイベント • ドメイン・イベント • アプリケーション上で発⽣するイ ベント • アプリケーション・イベント 再掲 第6回 動的モデル
- 30. イベント (Event) • 4種類のイベント •CallEvent • オペレーションが呼び出された時に発⽣するイベント • SignalEvent • シグナルを受信した時に発⽣するイベント • TimeEvent • 指定した時間に発⽣するイベント • after : ⼀定時間後 • when : 指定時間 • ChangeEvent • 指定した条件式が真になった時に発⽣するイベント • プロパティの変更時など • UMLではオブジェクトがシグナルなどの刺激を受けたことを通知す るモデル要素としてイベントを定義している 再掲 第6回 動的モデル
- 31. アプリケーション領域でのイベント • UMLのメタモデル上は、いわゆる「イベント」はSignalEvent として扱い、「イベント」の設計はSignalを⽤いることになる が、慣習にしたがって「イベント」として扱っていく • ビジネス・イベント •ドメイン・イベント • アプリケーション・イベント SM2021 再掲 第6回 動的モデル コンポーネント仕様の定義で 重要な項⽬
- 32.
- 33. 制約 (Constraint) • テキストで表された⾃然⾔語または特定のフォーマル⾔語による意味的な 条件または制限 •OCL (Object Constraint Language) • オブジェクト制約記述⾔語 • ⼀種の関数型⾔語 • 契約による設計 (Design by Contract) • 不変条件 (invariant) : オブジェクトで常に真となる条件 • 事前条件 (pre-condition) : オペレーションの実⾏の前提となる条件 • 事後条件 (post-condition) : オペレーションの実⾏完了の前提となる条件 • 制約を重視する理由 • 散逸しがちな要件を確実に記録して実装につなげる • 要件と実装の距離が短い分野なので効果抜群 • できるだけ上流のモデルで実装に直結する精度の仕様を確⽴しておきたい 再掲 第5回 静的モデル(2)
- 34.
- 35. 制約の使い所 • データ型/値域 • データ型の不変表明として定義 •画⾯⼊⼒、データ移⼊のパラメタ/データ検証 • 画⾯⼊⼒の⼊⼒補助 • クラス/不変表明 • バグの検出に有効 • オペレーション/事前条件 • 画⾯⼊⼒、データ移⼊のパラメタ/データ検証 • 画⾯⼊⼒の⼊⼒補助 • オペレーション/事後条件 • バグの検出に有効 • データ破壊を未然に防ぐ効果 • データ移⼊・移出 • 異常データのチェック・クレンジング 再掲 第5回 静的モデル(2) コンポーネント仕様では、できるだけ制約 を⽤いて仕様を精密に定義したい コンポーネント実現では、必要に応じて 適材適所で使うとよい Travel Light
- 36.
- 37. 第9回 物理モデル 第16回 分析 第18回設計 再掲 再掲 再掲
- 38. コンポーネント・フレームワーク (Component Framework) • コンポーネントの実⾏基盤 •メカニズム • DI (Dependency Injection) • 拡張点 • 変化点 • 実⾏コンテキスト • 配備 • ライブラリ管理 • モニタリング • 機能 • ログ • セキュリティ • 認証、認可、監査 • 機能(続き) • イベント駆動 • イベント • サービス・バス • 状態機械 • ジョブ管理 • ⾮同期実⾏ • バッチ実⾏ • 国際化 • RPC • データストア⼊出⼒ • キャッシュ • ⾮同期書き込み • データ整列化 • エラー体系 Cloud 再掲 第5回 静的モデル(2) 本講座⽤の仮想のコンポーネント・フレー ムワークを⽤いる予定
- 39. 実⾏コンテキスト (Execution Context) •コンポーネントの実⾏⽂脈を切り替えるメカニズム • コンポーネントのユニットテストにも必要 • スコープ • セッション・コンテキスト • アプリケーション・コンテキスト • システム・コンテキスト • 機能 • 認証済みプリンシパル • トランザクション • UnitOfWork • 時間 • ⽇時、タイムゾーン • 国際化 • ロケール、メッセージ、通貨 再掲 第5回 静的モデル(2) 本講座⽤の仮想のコンポーネント・フレームワー クが提供する実⾏コンテキストを⽤いる予定
- 40.
- 41. DI (Dependency Injection) •IoC (Inversion of Control) • 依存性の注⼊ • コンポーネント(オブジェクト)が必要とするコンポーネント(オブジェクト) への参照作成を⾃ら⾏わず、外部から設定する • 狙い • コンポーネント(オブジェクト)間を疎結合[Low Coupling]にする • 部品としての再利⽤性を⾼める • テスト容易性を⾼める • 注⼊のタイミング • コンポーネント(オブジェクト)作成・組み⽴て時 • オペレーション(メソッド)呼び出し時
- 43. DI(Dependency Injection)の種類 • DIコンテナ •DIコンテナが利⽤サービスをワイヤリング • Cakeパターン • Scalaのモジュール機能を使って利⽤サービスをワイヤリング • Readerモナド • Readerモナドで利⽤サービスを受け渡す • Freeモナド • Freeモナドのインタープリタで利⽤サビースを受け渡す • 実⾏コンテキスト • 実⾏コンテキスト経由で利⽤サービスを受け渡す • コンストラクタ • 利⽤サービスをコンストラクタで受け渡す
- 44. まとめ • コンポーネント仕様設計、コンポーネント実現設計の論点の洗 い出しを⾏った • 振舞いモデル •イベント・モデル • 制約 • コンポーネント・フレームワーク
- 45. 参考⽂献 • 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)