クラウドアプリケーションのためのオブジェクト指向分析設計講座
一般社団法人MaruLaboにて、オブジェクト指向分析設計の講座「クラウドアプリケーションのためのオブジェクト指向分析設計講座」を開講しました(全47回)。
本ページでは、その講義の概要と各回の公開リンクをまとめています。
目的
1997年にUML (Unified Modeling Language)(Unified Modeling Language)がOMG(Object Management Group)によって公式にリリースされ、その後2000年初頭にはオブジェクト指向分析設計の標準的プロセスであるUnified Process(UP (Unified Process))が登場しました。
それからおよそ四半世紀が経ち、ソフトウェア開発の現場ではアジャイル開発、クラウド・コンピューティング、DevOps、関数型プログラミングといった新たな技術潮流を取り入れてきており、開発方法論は大きく変化してきました。
オブジェクト指向技術の到達点であるUML/UPはオブジェクト指向技術体系全体をカバーするため重厚な仕様になっており、アジャイル開発が広く受け入れられている現場では、その存在感は薄れつつある状況といえるでしょう。
とはいえ、現代のソフトウェア開発はオブジェクト指向技術が基盤になっているのは間違いなく、オブジェクト指向技術を効果的に取り入れる必要があります。
元々UML/UPは網羅的な仕様の中からプロジェクト毎に必要なモデル (Model)のみ選択したプロファイルを定義し、このプロファイルを使ってソフトウェア・システムのモデル化を行うことが想定されています。
本講座の目的は、以下の3点に集約されます:
-
オブジェクト指向分析設計の現在地を棚卸し
-
新しい技術要素の導入とモデリング技術の再構築
-
クラウド・コンピューティング
-
DevOps
-
関数型プログラミング
-
-
プロジェクトに応じた実践的なモデリング技術の提示
実開発において無理のない適用が可能なプロファイルを設定し、「現実的に使えるオブジェクト指向設計手法」を提示します。
本講座の構成
講座は以下の5つのセクションで構成されています:
-
基本モデル:ユースケースモデル、クラス図 (Class Diagram)、ステートチャートなどの基本的なUMLモデリング技術
-
作業分野:UPの作業分野(ビジネスモデリング、要件、分析、設計、実装、テスト (Test)など)の整理と解説
-
アプリケーション・アーキテクチャ:クラウドアプリケーションを前提としたソフトウェアアーキテクチャの整理とUML適用の検討
-
ケース・スタディ:プロファイル定義を行い、現実的な規模のアプリケーションを題材にした実践的モデリングの試行
概要
第1回、第2回では講座の概要を説明します。
| 回 | タイトル | URL |
|---|---|---|
1 |
概論 |
|
2 |
本セクションでは、UMLとUnified Process(UP)の基礎的な考え方と、現代のクラウドアプリケーション開発においてこれらをどう再解釈するかの問題意識を提示します。
このセクションは導入としての役割を果たし、全47回の講義の前提理解を助けるためのものです。
基本モデル
第3回から第9回はオブジェクト指向分析設計に用いるオブジェクト・モデル (Object Model)について説明します。
| 回 | タイトル | URL |
|---|---|---|
3 |
基本モデル |
|
4 |
静的モデル(1) |
|
5 |
静的モデル(2) |
|
6 |
動的モデル |
|
7 |
||
8 |
関数モデル |
|
9 |
物理モデル |
UMLが提供する構造・振る舞い・相互作用の3つの視点に基づいた基本モデリング技法を解説します。
-
ユースケース図(機能要求の明確化)
-
クラス図(構造モデルの基盤)
-
オブジェクト図(インスタンス関係の明示)
-
シーケンス図、コミュニケーション図(動的相互作用の記述)
-
ステートチャート図、アクティビティ図(振る舞い (Behavior)の可視化)
このセクションでは、記法の学習よりも、設計の意図をどのように表現するかに重点が置かれています。現場で「どの図を、どの粒度で、どのタイミングで使うか」の指針が中心となります。
作業分野
第10回から第33回はオブジェクト指向分析設計の開発を遂行する各作業分野について説明します。
| 回 | タイトル | URL |
|---|---|---|
10 |
作業分野 |
|
11 |
ビジネス・モデリング |
|
12 |
要求 |
|
13 |
要求/ユースケース |
|
14 |
要求/シナリオ |
|
15 |
分析 |
|
16 |
分析/コンポーネント分析 |
|
17 |
分析/イベント駆動 |
|
18 |
設計 |
|
19 |
設計/アーキテクチャ設計 |
|
20 |
設計/コンポーネント設計(1) |
|
21 |
設計/コンポーネント設計(2) |
|
22 |
設計/コンポーネント設計(3) |
|
23 |
設計/ドメイン設計(1) |
|
24 |
設計/ドメイン設計(2) |
|
25 |
設計/ドメイン設計(3) |
|
26 |
設計/ドメイン設計(4) |
|
27 |
設計/ドメイン設計(5) |
|
28 |
設計/原理 |
|
29 |
設計/UX/UI |
|
30 |
実装(1) |
|
31 |
実装(2) |
|
32 |
実装(3) |
|
33 |
UPにおける各作業分野(discipline)を取り上げ、モデリングの位置づけを整理します。
-
ビジネスモデリング:業務領域とシステム境界の明確化
-
要求定義:ユースケース (Use Case)とアクターの整理
-
分析:概念モデルと責任の割り当て
-
設計:アーキテクチャ層、設計パターンの適用
-
実装・テスト:コードとの接続、テスト駆動の観点からの設計補助
このセクションでは、ウォーターフォール的な硬直した工程モデルではなく、反復型・進化型開発に対応する柔軟なプロセス適用が重視されます。
アプリケーション・アーキテクチャ
第34回から第39回はアプリケーション・アーキテクチャについて説明します。
| 回 | タイトル | URL |
|---|---|---|
34 |
アプリケーション・アーキテクチャ |
|
35 |
Cloud Native CBD |
|
36 |
ドメイン・サブシステム |
|
37 |
アプリケーション・サブシステム |
|
38 |
プレゼンテーション・サブシステム |
|
39 |
現代のアプリケーション開発(特にクラウドベース)において、どのようなアーキテクチャ構成が一般的かを確認し、それに応じたモデリング方針を提案します。
-
レイヤードアーキテクチャ、クリーンアーキテクチャ、DDD (Domain-Driven Design, ドメイン駆動設計)などの構造との関係
-
クラウドネイティブ環境(マイクロサービス、CI/CD、IaCなど)での構成要素
-
DevOpsやSREとの接続に必要な視点(運用・監視・回復性など)
-
関数型パラダイムとの整合(状態管理、不可変性、関心の分離)
UMLによるモデリングの「対象」が変化していることを踏まえ、モデリングの適用レベルや粒度の再設計が検討されています。
ケース・スタディ
総リスト
講義の総リストです。
| 回 | タイトル | URL |
|---|---|---|
1 |
概論 |
|
2 |
||
3 |
基本モデル |
|
4 |
静的モデル(1) |
|
5 |
静的モデル(2) |
|
6 |
動的モデル |
|
7 |
||
8 |
関数モデル |
|
9 |
物理モデル |
|
10 |
作業分野 |
|
11 |
ビジネス・モデリング |
|
12 |
要求 |
|
13 |
要求/ユースケース |
|
14 |
要求/シナリオ |
|
15 |
分析 |
|
16 |
分析/コンポーネント分析 |
|
17 |
分析/イベント駆動 |
|
18 |
設計 |
|
19 |
設計/アーキテクチャ設計 |
|
20 |
設計/コンポーネント設計(1) |
|
21 |
設計/コンポーネント設計(2) |
|
22 |
設計/コンポーネント設計(3) |
|
23 |
設計/ドメイン設計(1) |
|
24 |
設計/ドメイン設計(2) |
|
25 |
設計/ドメイン設計(3) |
|
26 |
設計/ドメイン設計(4) |
|
27 |
設計/ドメイン設計(5) |
|
28 |
設計/原理 |
|
29 |
設計/UX/UI |
|
30 |
実装(1) |
|
31 |
実装(2) |
|
32 |
実装(3) |
|
33 |
||
34 |
アプリケーション・アーキテクチャ |
|
35 |
Cloud Native CBD |
|
36 |
ドメイン・サブシステム |
|
37 |
アプリケーション・サブシステム |
|
38 |
プレゼンテーション・サブシステム |
|
39 |
||
40 |
ケース・スタディ |
|
41 |
ビジネス・モデル |
|
42 |
要求モデル |
|
43 |
要求モデル/BDD |
|
44 |
分析モデル |
|
45 |
設計モデル |
|
46 |
実装 |
|
47 |
参照
用語集
- オブジェクト (Object)
-
Objectとは、Classまたは他のClassifierによって分類され、構造、State、Behaviorを持ち得るInstanceです。Objectは、同じClassifierの他のInstanceと区別して参照できる個体として扱われます。
- モデル上の関連 (Association)
-
Undefined
- UP (Unified Process)
-
UMLを基盤とし、反復型・ユースケース駆動・アーキテクチャ中心のプロセスモデル。Rational Unified Process (RUP) などの派生形を持ち、CBD(コンポーネント指向開発)の実践基盤となる。
- UML (Unified Modeling Language)
-
オブジェクト指向分析・設計のための統一モデリング言語。クラス図、シーケンス図、ユースケース図などを通じてシステム構造と動作を表現する。UPおよびCBDの基盤言語。
- モデル (Model)
-
Modelとは、対象を特定のPurposeとConcernに基づいて選択し、理解、判断、検証、構築に利用できる形で表した抽象です。対象そのものではなく、目的に必要な要素、関係、意味を保持する表現です。
- クラス図 (Class Diagram)
-
Class Diagramとは、Class、Interface、Data Type、Association、Generalization、Dependencyなどを用いて、Modelの静的構造を示すUML Diagramです。
- テスト (Test)
-
Testとは、指定した条件で対象を実行または評価し、観測した結果を期待する結果やConstraintと比較して、要求または契約への適合を確認する活動とその仕様です。
- 開発プロセス (Development Process)
-
Undefined
- オブジェクト・モデル (Object Model)
-
Undefined
- 協調 (Collaboration)
-
UMLにおけるCollaborationは、専門化された機能を担う参加要素のRoleが共同して、目的とする機能を達成する構造を記述するClassifierです。
- クラス (Class)
-
Undefined
- 振る舞い (Behavior)
-
UMLにおけるBehaviorは、そのContextとなるBehaviored Classifierが時間とともにどのようにStateを変えるかを定める仕様です。可能な実行、創発する振る舞い、または特定の実行例を表せます。
- ユースケース (Use Case)
-
UMLにおけるUse Caseは、対象システムがActorまたは他の利害関係者に観測可能な価値あるResultをもたらすために実行するActionの集合を定めるModel Elementです。
- コンポーネント (Component)
-
責務・契約・依存関係を明示的に定義し、再利用可能で交換可能な単位としてカプセル化されたソフトウェア構成要素。論理モデルでは抽象構造単位として、物理モデルでは実装・デプロイメント単位として扱われる。
- イベント (Event)
-
UMLにおけるEventは、Behaviorの実行中に発生し得る出来事を記述するものです。EventのOccurrenceを受け取ることで、StateMachineのTransitionなどのBehaviorが起動されます。
- CBD (Component-Based Development)
-
CBD(コンポーネント指向開発)は、ソフトウェアを責務・契約・インターフェースを明確に定義したコンポーネント単位で構築・再利用する開発方式です。 コンポーネントは独立性と交換可能性を備え、システムを疎結合に構成することで保守性と再利用性を高めます。 論理モデルでは機能や契約を定義する抽象構造単位として、物理モデルでは実際の実装・デプロイメント単位として扱われます。
- Cloud Native Component Framework (CNCF)
-
Cloud Native Component Framework(CNCF)は、クラウド・アプリケーションを構成するコンポーネントを、単一かつ一貫した実行モデルで実行するためのフレームワークです。 Component / Service / Operation という構造を中核とし、command、server(REST / OpenAPI)、client、script といった異なる実行形態から、同一の Operation を再利用できることを特徴とします。 ログ、エラー処理、設定、配備といったクラウド・アプリケーションに必要な品質属性をフレームワーク側に集約することで、コンポーネントはドメイン・ロジックの実装に集中できます。 CNCF は、文芸モデル駆動開発および AI 支援開発を前提に、「何を実行するか」と「どのように呼び出すか」を分離するための実行基盤として設計されています。
- ドメイン駆動設計 (DDD, Domain-Driven Design)
-
Domain-Driven Designとは、複雑な問題領域をDomain Modelによって捉え、Ubiquitous Language、Bounded Context、Aggregateなどを用いて、業務上の意味とソフトウェア設計を接続するための原則、パターン、プラクティスの集合です。
- モデル関係 (Relationship)
-
Undefined
- BDD (Behavior-Driven Development)
-
Behavior Driven Development(BDD, 振る舞い駆動開発)とは、システムの振る舞いをシナリオとして記述し、関係者間で共有可能な形で仕様を明確化する開発アプローチである。