1 オブジェクト指向 の リ・オリエンテーション 株式会社豆蔵取締役グループCTO/IPA主任研究員 UMTPモデリングアンバサダー 羽生田栄一 [email protected] Hanyuda Mamezou 2024 Object-Oriented Conference 2024.3/24 基調講演 @お茶の水女子大

•2 羽生田 栄一 Hanyuda Eiiti 経産省 DXレポート 2000 SWエンジニアリングベンチャー「豆蔵」創業 ２０１８ 経産省/情報処理推進機構IPA 研究員 ２０２1 豆蔵デジタルHDグループCTO 2

キーワードとしてのソフトウェア工学 （＋社会エコシステム）の50年 1970年代：「構造化」の時代 – 構造化チャート、抽象化、ソフトウェアライフサイクル 1980年代：「管理技法とCASE」の時代（2次AIブーム） – プロセスプログラミング、ピープルウェア 1990年代：「オブジェクト指向」の時代（AI冬の時代） – アーキテクチャとパターン、CMM等プロセスモデル 2000年代：「アジャイル」「プロダクトライン」の時代 – アジャイル、モデルベース開発、（第2次）形式手法 ＊日本の開発の現場へは10年遅れて展開 Hanyuda Eiiti，Mamezou 3 アジャイル のゆりかご としての オブジェクト 指向 人材の流入

Alan Kayから始まった • ハッカーでもあるが、それ以前にプロのジャズギ タリストであり、ものすごい人文教養主義者・民 主主義者・啓蒙的教育者 • 世界中の人・モノ・制度を自律分散的なオブジェ クトの再帰的な世界として育てていきたいという 強い情熱をもつ • 『Object-Oriented』という言葉の 生みの親 • 2003年 チューリング賞。オブジェクト指向 プログラミングに関する貢献に対して Hanyuda Mamezou 2024 4

Alan Kayの３つのメッセージ 正しい主張というよりアラン“系”の夢 • オブジェクト指向の肝はメッセージングによって物 事を抽象化し処理を可能な限り遅らせることだ ➔ ポリモルフィズム、カプセル化、継承による差分開発 • ダイナブックとは誰でも自由にお互いに教え合い ながら学習し編集し発信できる、世界とつながった ダイナミックかつメタな情報メディアである ➔ PC, 学習しつづけるアジャイルな自律運営組織 • 未来を予測する最も確実な方法は、自分たちの手 でそれを作り出すことである ➔ アイデアからシステムやドメインモデルの“発見発明” Hanyuda Mamezou 2024 5

オブジェクト指向概念の複数の源泉 • Simula言語 – Nygaard, DahlらのAlgol系シミュレーション用言語 • Alan Kayの新コンピューティング理念とマクルーハン社会論の影響下のダイナブック構想 – メッセージングと状態プロセスのカプセル化と物事の徹底的遅延実行。Smalltalkはその縮退実装。 – マクルーハン「メディアはメッセージである」、メディアが身体・感覚を拡張し、思考を変え、文化をつくる – メッセージを送って仕事を依頼する極小マシンの再帰的集合としてのメタ・メディアDynaBookを社会へ（ そこには子どもの学習や人間の活動も含まれる） • Actor理論 – Hewittの論理式を手続きとして解釈するAI言語Plannerの派生としての自律エージェントどうしのメッセ ージングによるλ計算の一般化としての自律協調計算モデル • 抽象データ型 – LiskovのCLU言語におけるデータと関連操作をまとめたユーザー定義機構としての抽象データ型 • フレーム理論 – MinskyによるAIのための知識表現形式で、１つの概念や事例をスロットとフレームで表す • ERモデルおよびその派生の意味データモデル – Ｃｈｅｎによるデータモデルで、関係データモデルの実世界モデル化能力を乗り越えるために、実体Ｅｎｔｉ ｔｙとそれらの間の関係Relationshipがきっかけとなり、様々な意味データモデルが登場 • OSケイパビリティ概念 – Ｄｅｎｎｉｓらにより1960年代半ばに提案された、ＯＳにおける資源保護メカニズムであるケイパビリティ概 念：セグメント、ページなどの記憶領域や入出力デバイスなどに対する識別性とアクセス権を管理する 単位 Hanyuda Mamezou 2024 6 米澤明憲・柴山悦哉「岩波講座ソフトウェア科学17：モデルと表現」1992

データでもなく機能でもなく マクロで長期的な展望として • 縦軸：データ • 横軸：機能 • マトリクス 列：機能中心 行：データ中心 ↓ 抽象データ型（OO） 対角化のようなもの ↓ いずれ圏論へ Hanyuda Mamezou 2024 7

プログラミング言語の歴史として Hanyuda Mamezou 2024 8 Bitから抽象そしてアイデア（概念・関心事）へ • Bit列→記号化→手続き抽象→構造化（３構造） →モジュール（データと手続きのとりまとめ） →ゆる抽象データ型（自由なユーザー型定義）* →オブジェクト指向（3要素で開閉原則の実現） • OCP *ゆる がつくのは、厳密な抽象データ型ではないから

抽象データ型（Abstract Data Type, ADT）とは 仕様を操作間の関係性で示し実装を隠す • 仕様（インターフェース） と表現（実現方法）を 分離する • 仕様では、操作の意味 をシグニチャと 操作どうしの関係性 （一種の代数）として定義 • 例：Stack ・isEmpty, push, pop, peek, sizeの5操作で 仕様定義している ・内部データ構造は外部に見えない（getter/setterはない！） 通常言語では完全な抽象データ型は定義しきれないので、ゆる抽象データ型 Hanyuda Mamezou 2024 9

OOPの段階論 段階 タイトル 観点 概念 原則 段階 １ オブジェクト指向 ミニマム OOP オブジェクトとメッセージ 低結合度、抽象化、メッ セージング 段階 2 責務・ロールの概 念整理 OOD OOP リスポンシビリティ、クラ スとメソッドへのよい命名 高凝集度、SRP、デメテル 設計原則 段階 3 いわゆるオブジェ クト指向の3要素 OOP クラス、継承、ポリモル フィズム 形式的カプセル化 （getter/setter、抽象データ 型に反するクラス定義）、原 則なき継承、原則なきポリ モルフィズム 段階 4 構造主義的OO OOD OOP 抽象データ型、サブタイ ピング、インターフェース、 コンポジション（委譲） OCPとLSP、インターフェー ス指向設計、DbC（契約に よる設計）、SOLID原則 段階 5 DDD基本 OOAD パッケージ、レイヤーと 依存反転、関数型・イ ミュータブル、ドメインモ デル SoC（関心の分離）、パッ ケージ設計原則（R2EP、 CRP, CCP, ADP, SDP, SAP） Hanyuda Mamezou 2024 10 形式的な段階3に意味はないので、さっさと段階4へ！

第1段階のオブジェクト指向 オブジェクト指向ミニマム 1個1個区別可能 メッセージ受信 メッセージ送信 メッセージに反応 オブジェクトは 1[oid] 1個1個区別できる 2[カプセル化] 外から見えない内部状態をもつ 3[メッセージ・応答] メッセージ（仕事の依頼）に応答する能力 （責務＝リスポンシビリティ＝リスポンス＋アビリティ） ＝オブジェクトはメッセージに対応する責務をもつ 4[メッセージ・送信] 他のオブジェクトにメッセージ（仕事の依頼） を送れる 11 責務としての 操作の実行 内部状態の変更 メッセージ 内部状態

状態マシンとしてのオブジェクト • メッセージで相互作用するオートマトンとしてのオブジェクト • パブリックなメソッドの裏にカプセル化された状態 • 内部状態は外からのメッセージの受信イベントとして遷移（ 状態更新）させる Hanyuda Mamezou 2024 12

第2段階のオブジェクト指向： 責務・ロールの概念整理 リスポンシビリティとは応答能力 • 責務とはメッセージへの応答能力！ – そのオブジェクトの本来の目的に応じたメッセージに きちんと応答し責任を果たすこと • SRP（Single Responsibility Principle）は、そのオ ブジェクトの存在理由を１つに見定めて、明確な １つの責務＝応答責任を与えることで、凝集度 の高いオブジェクト設計をするための基本原則 • Rebecca Wirfs-Brockさんのエピソード – Responsibility = Response + Ability との説明に驚き！ Hanyuda Mamezou 2024 13

第3段階のオブジェクト指向： クラス・継承・ポリモルフィズム • 説明省略 いつものアレ – 「カプセル化（クラス）、継承、ポリモルフィズム」説明略 • よくある問題点 – クラス定義さえすれば抽象データ型だと勘違い – getter/setterでアクセスすればカプセル化を守っていると 勘違い – スーパークラスとは見做せないサブクラスを継承で安直 に定義してしまう勘違い – インターフェースを意識していない思い付きのポリモーフ ィックなメッセージ定義（意図が曖昧で、引数型と戻り値 型の妥当な扱いができていないポリモルフィズム） Hanyuda Mamezou 2024 14

契約とは 抽象データ型や継承の正しい理解に不可欠な素養 • クライアントオブジェクトとサプライヤ（サーバー） オブジェクトの間の契約（取り決め） Hanyuda Mamezou 2024 15 事前条件を 守って、結果 （事後条件）を 手に入れたい 公開サービス クライアント サプライヤ（サーバー） m1(A):R 事前条件Pre 事後条件Post 不変条件Inv m1(a) r 契約 契約内容： ・もしクライアントが事前条件Preを満足した状態で、 ・サービスm1（A）を呼び出してくれたならば ・サプライヤである私は、事後条件Postを満たした状態でR型の戻り値を返す ことを約束します。

Liskovの置換原則と契約 • この原則の意味が理解できない人は継承使うな • 継承によって定義した派生クラスが上位クラスと 型として互換性があることを保証する • S extends Tとは、サブクラスＳのオブジェクトｓは スーパークラスＴとみなして自由に使いまわして よいということ – 「s:SをT型のオブジェクトとして処理して問題ない」 • （Javaでは別メソッド扱いになってしまうので関係 ないが一般に）サブクラスのメソッドは、その引数 の型は緩めてもよい、その戻り値の型は厳しくし てもよい – クライアントにって、渡す値の型が緩まるのは問題な いが、戻ってくる値の型が期待と違うのは困る Hanyuda Mamezou 2024 16

現代における継承と差分開発 • 継承は、 – サブタイピングとして強い型づけを意識し – LSPリスコフ置換原則および – OCP開放閉鎖原則の目的を果たすため のみに使用すべき • ミクロな差分プログラミングは、 – リファクタリングを伴う – コンポジション（委譲）で対応すべし • 現代における差分開発は、 – アジャイル開発におけるインクリメントのリリースに Hanyuda Mamezou 2024 17

第4段階のオブジェクト指向 構造主義的なオブジェクト指向の理解 Hanyuda Mamezou 2024 18 カプセル化 ポリモルフィズム 継承 開放閉鎖原則（Open Closed Principle） Bertrand Meyer 1988 • これを実現するために – カプセル化・ポリモルフィズム・継承が連携する！ "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification"; that is, such an entity can allow its behaviour to be extended without modifying its source code.

OCP:開放閉鎖の原則 ｛abstract｝ AbstractServer Client Server ClientA Server’ ClientB Functional Extension Copy&Edit Server Server’ Adding Derived classes (1)変更される個所(HotSpot) をみつける (2) そこがスーパークラスでもあると見做せるように抽象化する (3) その抽象スーパークラスのサブクラスとして変更に対応する • Open Closed Principle – 拡張に対してはOpen, 利用や修正に対してはClosed – 既存のクラスやメソッドを触ることなく機能を追加できる 手続き型 スタイル OOD: オブジェクト指向設計スタイル Abstract Class Interface Impl. Classes 19 * ClientA も B も Server / Server’ の実現方法は意識せずあくまで AbstractServerとして利用できる

クラスに関する設計原則 SOLIDと覚えるのはよいが、きちんと高凝集度・低結 合度と関連付けて意味を理解しよう • クラス内部の凝集度を高める 1. SRP：単一責任の原則 Single Responsibility Principle • クラス同士の結合度を下げる 2. DIP：依存性逆転の原則 Dependency Inversion Principle 3. ISP：インターフェース分離の原則 Interface Segregation Principle • 両方に関係（オブジェクト指向に固有の原則） 4. OCP：開放閉鎖の原則 Open Closed Principle 5. LSP：リスコフの置換原則 Liskov Substitution Principle Robert Martin 20

DIP： 依存性逆転の原則 • この設計原則が、手続き型や構造化プログラミングとOOを区別する分水嶺 • 手続き型 vs OO – 伝統的に、手続き型スタイルでは, 上位の方針や手続きは、下位の実装や 手続きに依存しています – OOでは, “抽象クラス/ インターフェース” が上位レベルに定義され、これに 対する「実装/実現」が下位レベルで定義される 21 FuncA SubA1 SubA2 Abstract class op1() op2() ｛upper｝ ｛lower｝ Impl class1 op1() op2() Impl class2 op1() op2() or Interface 依存の 方向性 呼び出す フックされる

第5段階のオブジェクト指向：DDD基本 レイヤー化しモジュール間の依存関係を制御し、 段階的進化がしやすいアーキテクチャを 方向づけ 推敲１ 推敲N ～ 構築1 ～ 構築M ～ ～移行L 反復しながら徐々に肉付け・リファクタリング 22

パッケージに関する設計原則 高凝集度・低結合度を意識して理解しよう • パッケージ内部の凝集度 1. REP：再利用･リリース等価の原則 Reuse Release Equivalent Principle 2. CRP：全再利用の原則 Common Reuse Principle 3. CCP：閉鎖性共通の原則 Common Closure Principle • パッケージ同士の結合度 4. ADP：非循環依存関係の原則 Acyclic Dependency Principle 5. SDP：安定依存の原則 Stable Dependency Principle 6. SAP：安定度・抽象度等価の原則 Stable Abstraction Principle Robert Martin 23

クラスとパッケージの各原則の対応 SOLID原則とパッケージ原則は高凝集・低結合という共通目標 • クラスとパッケージで対応関係のないもの – LSPリスコフの置換原則=>クラス継承にのみ関わる – REPパッケージ再利用リリース等価原則=>パッケージのみ – ADP非循環依存関係原則=>「クラス間の循環参照は可能なら無くす」 • クラスとパッケージに共通に適用した原則 – SRP単一責任の原則CCP閉鎖性共通の原則 – OCP開放閉鎖の原則SAP安定度抽象度等価の原則 – DIP依存性逆転の原則SDP安定依存の原則 – ISPインターフェース分離の原則CRP全再利用の原則 ➔ • 機能要求を満たしつつ各設計原則も満たした設計を検討 • それらの設計原則は、テスト容易性や拡張性、順応性、保守 容易性の向上をもたらす 24

DDD基本段階の初歩の初歩 • そのドメインで参照する重要なデータ型は独自に用意するべし – Javaなどの言語の提供する組込み型やコレクション型をラッピングしたクラス を用意し、そのクラス内にその業務の制約やビジネスルールも埋め込む • ビジネスロジックはドメイン層のEntityとValueObjectに持たせる。 – 業務上のリスポンシビリティを担うエキスパートobj達 – エキスパートobj達を生成するファクトリやアグリゲーションを担うobj達 • アプリケーション固有の機能はApplicationServiceに持たせる。 – アプリケーションの柔軟性のために、ビジネスユースケースの実行やドメイン オブジェクトの操作を適切に分離 – ビジネスユースケースに対応したシステムイベントを処理するコントローラ的 な役割のオブジェクト達 – それら機能のうち共通に使える汎用性が見えてきたらアプリケーション層か らドメイン層のDomainServiceに移す • オブジェクト間のメッセージによる相互作用はデメテル設計原則で – 「Don’t talk to strangers」：直接知り合いのオブジェクトとだけメッセージせよ。 （内部オブジェクトを通さず）クライアント目線での希望を直接リクエストする – メッセージ・チェーンがダメなわけでない： クライアント目線の戻り値ならOK 25 Hanyuda Mamezou 2024

モデリングの段階論 段階 タイトル 始点 概念 原則 段階 １ 整理の方法論 一般 箱と矢印 大事な物事・気になる事柄 とそれらの依存関係 段階 2 クラス図、ER図 表層 分析 概念エンティティと関連、 多重度 UMLないしは各種ER図法 への準拠 段階 3 概念モデリング 深層 分析 ER図＋分析フレーム ワーク（例：椿モデルパ ターン、アナリシスパター ン） ドメインや業務に対する効 果的な視点や構造を導入 したモデリング 段階 4 企画・要求分析 企画 要求 ビジネスキャンバス、ス テークホルダー、ユース ケース、ビジネスプロセ ス、イベントストーミング、 ロバストネス図 ビジネス目的からBizキャ ンバスやユースケース図 を描きシステムスコープを 確認し、必要に応じてユー ズケース分析やロバストネ ス分析 段階 5 統合的DDD活動 統合 DDD 企画・要求分析ｘ概念モ デルｘDDD 第5段階のOOPとモデリン グ第4段階の統合 Hanyuda Mamezou 2024 26

SE4BSの価値駆動プロセス • モデルベース: 変換の連続を通じ可視化、段階的検証可 • トレーサブル: ステークホルダー分析からリリースまで追跡可 Hanyuda Mamezou 2024 27 情 意 意 意

現代におけるOOADへの提言 • 要求把握は、ユースケース図やユースケース概要記述（ ストーリー同等）を使おう。シンプルにシステムの企画や 要求、スコープを整理するのに役に立つ – そのあと、イベントストーミング等やればOK • 理解の概念モデリングでは、まずは常識や日常語を使っ て、素直な構造のスケッチをすることから始めよう – その際、クラスの箱□と単方向関連ーー＞、サブからスーパー への汎化関係ーー▷、それ以外のゆるい依存関係・・・＞のみで クラス図を描けばよい（この段階で抽象クラスとインターフェース は区別しなくてよい） • 解決の概念モデリングでは、過去の偉大なデータ中心設 計（とくに椿名人、渡辺幸三さん等の各業種ごとのデータ モデルはアイデアの山。ただし記法は特異で慣れが必要 ）から素直に学び盗もう Hanyuda Mamezou 2024 28

ドメイン（概念）モデリングの基本 • 対象の業務（ドメイン）をわかりやすく説明するために欠かせない重要な言葉 ＝概念群とそれらの関係を表現する – 概念とは、1個1個区別識別され、関心をもって追跡・記録・管理したい対象のこと • クラス図を描くとともに読み解き方を文章としてモデル図に併記するとよい – UMLに不慣れな読者用に主要な記法の凡例を付ける – UMLの文法は意識しないで、業務の内容やビジネスの価値と構造と動きにフォーカスする • 業務の目的と照らして重要な管理対象は概念クラスとして表現する。つまり重 要概念は属性でなくクラスに。 • 重要クラスや逆にわかりづらい概念に対しては、その存在目的や注意事項、 具体例などをノートで記述する 「モブモデ」リング：その業務のエキスパートや関係者にヒアリングしながら、その 場で一緒に概念モデリングを行うべし。持ち帰り作業にしない。モデリングの目的 は、場とビジュアルの共有による関係者相互の脳内イメージ転送である。 「モデリング」であって「モデル」作成ではない：とにかく最初のスケッチをさっさと描 き始め、そこからどんどんレビューしながら、モデルをリファクタリングしていけば よい。大事なことを中心に、時間系列は左から右に、上下で抽象度を。 「モデルの検証作業」は、ユースケースやストーリーをドメインモデル上で関連す るクラス・属性・関係線を指差し確認しながらトレースしていく 29 Hanyuda Mamezou 2024

モノ・コト分析を表現する ５Ｗ１Ｈ ビジネスモデルパターン • Who/Whom [モノ（者）:リソース] – パーティ(誰が・誰に) • (Where) – 場所 • What/When/Why[コト:イベント] – 事実(取引・契約・事件) – 時点（datetime）の管理 • 実績⇒過去の事実 • 計画⇒未来の事実 • What/HowMuch [コト:イベント] – 事実明細(事実と対象の関連クラス、数量 の管理)：時点は全体「事実」から派生する • WhatFor [モノ（物）:リソース] – 対象(製品・サービス)記述 • (How) – 手段(連絡・支払・運搬) 事実 事実明細 対象 * １ * 誰が 手段 誰に datetime 数量 場所 30 Hanyuda Mamezou 2024

モノ・コト・バに基づくクラスの識別（概念カテゴリ表） ～モノ言葉＝オブジェクト指向モデリング言語における語彙の分類～ ＊経営やBI（Biz Intelligence）視点が重要な場合は「要約」概念を導入するが、初期の概念モデリングでは不要 31 分類 概念 定義 説明 例 モノ 管理対 象の基 本 物 物理的対象 区別して管理したい物理対象 商品、材料、資材、設備、工具、セン サー、デバイス 者 パーティ（法人・組織 や個人の役割） 業務に登場し識別管理したい個人・組 織などの役割。階層になること多し。 顧客、利用者、仕入先、納品先、委託 業者、メーカー、部門、事業部 コト 管理し たい事 象や事 態 事象 ビジネスイベント できゴト 業務で個別に管理したいイベント でき事や取引や事態（の記録や予定） 受注、発注、販売、入荷、出荷、請求、 支払、仕入、納品、加工、組立、人事 異動、設備変更、価格改定、仕様変更 事実 ビジネスルール きめゴト ビジネスルール、モノやコトの仕様やそ れらの間の制約、制度、守るべき事柄 契約ポリシー、決済方法、為替レート、 消費税計算、配送方法、価格表 バ モノや コトの 生起す る場 場所 物理的コンテナ （サイト・容れモノ） 重要なモノを管理する物理的コンテナ。 物理的な場所、容器・入れ物 地域、店舗、プラント、ライン、倉庫、保 管棚 場 論理的コンテナ （全体・コンテキスト） 登場するモノやコトを管理する論理的コ ンテナ。全体や場面、口座型 会社、XXサブシステム、XXサービス、 ショッピングカート、商品在庫、銀行口 座、勘定口座、顧客アカウント 要約 現状を 整理し た要約 データ 時点 要約 特定時点の断面の 要約データ 特定時点のモノや口座型の状態の断面の時 系列での要約（予定・実績） 貸借対照表、在庫、資産、債券債務 期間 要約 観点別要約データ 特定期間のデータ 指定した期間（週、月、4半期、年度）での経営 指標（生産高・売上高…）の観点別（期間、商 品、地域、部門、顧客…）の要約（予定・実績） 損益計算書、月次商品別売上高、部 門別間接費 Hanyuda Mamezou 2024

概念モデルの発見と発明 Alan Kayの「未来を予測するための発明」 の応用 • ドメイン理解のための素直なモデル – その領域や業務について、日常的な言葉や概念や比喩で素直 に理解が可能なモデル – とはいえ、人間が工夫する動物であり、過去の歴史を通して現在 の物事を理解する限り、素直なモデルといえども、領域や業界ご との特別な構造や仕組みが組み込まれている • ドメインの課題を解決するための深いモデル – 新たな概念や構造や仕組みを発明し、モデルに組み込む – とはいえ、多くの場合、他分野や他業種で既に発見され行われ ているものを自分たちのドメインの目的や制約に合わせて変換 したモノであることも多い – とはいえアジャイルに仮説検証を重ねて探索していくしかない Hanyuda Mamezou 2024 32

オブジェクト指向と関数型の違いと共棲 Michael Feathers Michael Feathers @mfeathers 2010年11月4日 – OO makes code understandable by encapsulating moving parts. FP makes code understandable by minimizing moving parts. • OOオブジェクト指向は、可変部分をカプセル化（隠蔽）することによっ て、コードを分かりやすくする（状態マシンの内部は知らずに） • FP関数型は、可変部分を最小化することによって、コードを分かりや すくする（イミュータブルなデータ構造に関数適用、変数の参照透過） John Cook – “functional in the small, OO in the large” • メソッドやクラスはできる限りイミュータブルを中心としたコーディング作法で • クラスやモジュールの大局的な管理はオブジェクト指向設計で Hanyuda Mamezou 2024 33 John D. Cook, PhD Functional in the small, OO in the large Posted on 23 March 2009 by John http://www.johndcook.com/blog/2009/03/23/functional-in-the-small-oo-in-the-large/

メッセージングと並列処理 アラン・ケイ • 「子供達はまた、長い一連の逐次的な論理よりも並列処理 の方が得意なので、動的に相互作用する並列イベント式 のシステムを書く事に喜んでなじむ」 – 子ども向け言語環境Scratch のブロードキャスト・メッセージ機能 • 「一方で、ほとんどのプログラマは逐次処理と非オブジェク トという、正反対の事を強調する 『アルゴリズムとデータ構造』コースで習い始める」 大人の対応としては： 並列処理ライブラリを使う Go, Erlang, Elixirなどの言語を使う Actor, CSP, π計算などを使う Hanyuda Mamezou 2024 34 アベ先生 (CV: 阿部和広) (@abee2): 2018.6.27 からの引用

自然言語からみたポリモルフィズム 言葉の思考経済としてのポリモルフィズム ➔ ドメインモデルやユビキタス言語でもっと意識して使 いこなすべき（データモデルではあまり研究されてない） Run 「走る」 の言語ゲームの歴史 • 動物： 地面の上を足で蹴って前に速く進む – 馬が、草原を走る • 自動車： 地面の上を機械が自力で進む – 自動車が、ハイウェイを走る ・・・ • ソフトウェア： OSやコンピュータのような安定した抽象物の上 でプログラムが実行される – Cコンパイラが、Unix上で走る Hanyuda Mamezou 2024 35

OOと組込み系・ゲーム・メタバース • 組込み系やゲーム、ス マートシティやデジタル ツインの分野ではオブ ジェクト指向が基本 Hanyuda Mamezou 2024 36 三宅 陽一郎『デジタルゲームにおける 人工知能の認識モデリングとエージェ ント・アーキテクチャ』UMTPモデリング フォーラム2022

ユクスキュルの環世界とAIエージェント • 今後、個人はAIエージェントとペアで自然言語を 介して協働し、それは一種の環世界をなす。 環世界がUI/UXの基本単位となり、それらの相 互接続プロトコルも自然言語になる可能性 Hanyuda Mamezou 2024 37 NTT研究所「ふるえVol.25 2019Oct」 ユクスキュル「生物から見た世界」1973

メタバースと生成AI環世界UIはAlan Kayの夢の実現か？ • AIエージェントによるパーソナル環世界はDynabook的な世界に近づくと もいえるが… 一方で、Alan Kayは米国憲法の父ジェファーソンを引用して次のように言っている： • ジェファーソンの主張は、考えることを学び、十分な知識を得た国民は、今後に待ち受け る荒海（困難）や国民的議論を乗り越えて、「国家という船」をダイナミックに操れるというも のでした（逆に言えば、国民が十分に教育されていない場合、共和国は座礁してしまうの です）。 • このビジョンの重要なポイントは、教育の目的は、単一の視点を生み出すことではなく、異 なる観点を調和して扱える市民を育成することである、という点です。 Hanyuda Mamezou 2024 38 アラン・ケイが振り返る「Dynabook」の核心 https://xtech.nikkei.com/it/atcl/co lumn/14/081200041/

マイクロサービスの思想的意味 • 旧サービス指向と現代のマイクロサービスの違い – 昔のサービス指向は、オブジェクト指向、コンポーネント 指向といったソフトウェアアーキテクチャにのみ視点が 限定されていた • マイクロサービスの成功のカギ – モジュール（もの）とそれを開発・運用するチーム（ひと） と顧客ニーズ窓口（価値インターフェース）の3者を一体 化した“ゆるサービス指向” • 結局、わかったこと： – ソフトウェアだけでは意味がない、顧客価値とそれを提 供するアジャイルチームがセットでサービス！ – つまり、「学習し進化する組織としてのサービス」チーム ➔オブジェクト指向の夢は、モジュールｘヒトｘ価値として実 現したといえないこともない Hanyuda Mamezou 2024 39

自然言語プログラミングの基礎1 • 自然言語のやり取りの中から概念が浮かび上がってくる近未来 • 大量テキストからの単語間の隣接行列に対するSVD（特異値）分解 により文法知識を一切与えていないのに特異値の高い順に、名詞概 念、動詞概念、形容詞概念…が抽出されてくる ➔一種の自然言語の型推論に使える技術的な可能性の1段階 Hanyuda Mamezou 2024 40 Tai-Danae Bradley, Juan Luis Gastaldi, and John Terilla：The Structure of Meaning in Language: Parallel Narratives in Linear Algebra and Category Theory 2024

自然言語プログラミングの基礎2 • 圏論は、オブジェクト（対象）とアロー（射）を、関手・自然変換・高次圏・ 豊饒圏…などを通して、対象領域を自然かつ厳密にモデル化できる • モナドだけではない！例：オントロジーログologと圏論的データベース 設計 Hanyuda Mamezou 2024 41 David Spivak2014: Category theory for the Sciences

統一モデリング言語としての圏論 すべては圏と関手だ。 すべての人が圏論をUML統一 モデリング言語とみなして情報 処理全般に使ってくれることを 望んでいる。 David Spivak Hanyuda Mamezou 2024 42 例：射影関手とグロタンディック構成による 自然言語として理解する関係DB

自然言語プログラミングへ向けて • 文字の文化から声の文化へのパラダイムシフト – アジャイル文化 – パターンランゲージ – パートナーとしてのLLMベースの生成系AIエージェント ➔ 一般市民もエンジニアも対等にサービス・未来創造に参加できる • 今後、われわれはプログラマも普通人もみな、自然言語を使ってAIエ ージェントを相棒としてチームメンバーに引き入れながら、ソフトウェア を含む様々なサービス開発を行うようになるだろう • プロフェッショナルなソフトウェアエンジニアは、AIとの作業を前提とし た新しいソフトウェア・エンジニアリングを生み出す必要がある – 要求モデリング・プログラミング・検証の３つの視点の重みづけと関係性が変わっ てくるだろう – コーディングとコードレビューへのAI関与が当たり前になったように、 – 要求モデリングと検証に対する新たなAIの関わり方が生み出されてくるだろう • いずれ、3視点を統合した自然言語プログラミングが当たり前になるだ ろう Hanyuda Mamezou 2024 43

もう１つのオブジェクト指向 Object Lesson 「実物教育」という経験学習 Object Lesson： 実物教育、教訓となる実例 an event or story that shows you the right or wrong way of doing something • オブジェクト・レッスン１： Logo, Smalltalk, Scratch – 構成主義的プログラミング環境、4つのPの原則(Projects, Passion, Peers, Play) • オブジェクト・レッスン２： トヨタ生産方式『Genchi Genbutsu(現地現物)』 – 現地現物でものごとの本質を見極め、素早く合意、決断し、全力で実行する • オブジェクト・レッスン３： 裁判での交通事故現場模型とウィトゲンシュタ イン『論理哲学論考』 – 現実世界と意味空間との間の写像理論を生み出すきっかけ – 世界はモノの総体ではなく、世界は事実（命題）の総体である そしていちばんのオブジェクト・レッスンは、「アジャイル開発」というスタイル そのものである Hanyuda Mamezou 2024 44

まとめ１：OOPの段階論 再掲 段階 タイトル 観点 概念 原則 段階 １ オブジェクト指向ミ ニマム OOP オブジェクトとメッセージ 低結合度、抽象化、メッセージ ング 段階 2 責務・ロールの概 念整理 OOD OOP リスポンシビリティ、クラスと メソッドへのよい命名 高凝集度、SRP、デメテル設計 原則 段階 3 いわゆるオブジェク ト指向の3要素 OOP クラス、継承、ポリモルフィ ズム 形式的カプセル化（getter/setter、 抽象データ型に反するクラス 定義）、原則なき継承、原則な きポリモルフィズム 段階 4 構造主義的OO OOD OOP 抽象データ型、サブタイ ピング、インターフェース、 コンポジション（委譲） OCPとLSP、インターフェー ス指向設計、DbC（契約に よる設計）、SOLID原則 段階 5 DDD基本 OOAD パッケージ、レイヤーと 依存反転、関数型・イ ミュータブル、ドメインモ デル ｘ アジャイル SoC（関心の分離）、パッ ケージ設計原則（R2EP、 CRP, CCP, ADP, SDP, SAP）、 CI/CD, DevOps Hanyuda Mamezou 2024 45 第4段階インターフェース指向設計をOCPとLSPで実現したのが『オブジェクト指向』 インターフェース指向設計はOCP＋LSPを使わずに関数型ｘデータ指向でも実現可 ！ まずはJava相当言語で第4段階OCP＋LSPによるオブジェクト指向に到達しよう。それが同時にインター フェース指向設計であることが理解できたらＯＯを捨て、関数型ｘデータ指向に取り組む道が待っている

まとめ2：Alan Kayの３つのメッセージ 正しい主張というよりアラン系の夢 再掲 • オブジェクト指向の肝はメッセージングによって 物事を抽象化し処理を可能な限り遅らせることだ ➔ ポリモルフィズム、カプセル化、継承による差分開発 • ダイナブックとは誰でも自由にお互いに教え合い ながら学習し編集し発信できる、世界とつながっ たダイナミックかつメタな情報メディアである ➔ パーソナル・コンピューティング、シチズン開発 学習しつづけるアジャイルな自律運営組織 • 未来を予測する最も確実な方法は、自分たちの 手でそれを作り出すことである ➔ アイデアからシステムやドメインモデルの発見・発明 Hanyuda Mamezou 2024 46 コンポジション（委譲）

オブジェクト指向の リ・オリエンテーション （向き 直おし） 未知の世界に向き合うとき まずは、大事な/気になること（Object）をポンと置いてみる そいつに、いい名前を付けてやろう（Abstraction） そして、そいつに希望を伝えて（Message） 動くところを想像してみよう そのオブジェクトの裏で何がどう動くかは、これから考えればよい そのオブジェクトの目的を理解して現場・現物で学び考えよう それは、新しいサービス、そして未来を創造するということである Hanyuda Mamezou 2024 47

モデリングのススメ：UMTP • UMTPブースで簡単クイズでモデリングTシャツをGETしよう • モデリング認定試験を受験して腕試しをしよう Hanyuda Mamezou 2024 48

L4試験の概要 2015.9.29 Hanyuda Eiiti， 49 モデリングスキル レベル ・実践に基づいてモデリングを指導できる ・L3のスキルを有し、開発プロジェクトでモデリングを一 定数あるいは期間実践した経験を持つ 期間 受験申込みから最終合否通知まで、３～４か月 一次試験（書類審査） ・プロジェクト経歴等を記載した書類を受験申込み時に提出 ・実プロジェクトへのモデリング適用経験等を審査 二次試験 ・課題としてあたえられたモデリング問題を解く ・過去のモデリング適用実績をまとめる ・審査員からの中間レビューを受け、課題の回 答を完成していく （基本メールベースでのやりとりとなります） ・面談試験で、課題、過去の実績を発表する ・審査員からの質問に適切に応答する 合否 面談試験を含め総合的に判定 申込み UMLモデリング推進協議会 事務局 [email protected] 合格発表 面談試験終了後、事務局よりメールで通知

付録1：いくつかの勘違いを正す… • よく「getter/setterを使った抽象データ型をストラウスト ラップのオブジェクト指向では採用した…」という文 章を見かけるが、それは単なるユーザーデータ型 • これは世界中で誤って使われているが、 is-a関係という言い方で汎化関係を指すのは言語学 的にヘンです。 – インスタンス/クラス関係がis-aのはずだが今となってはさ らに誤解を生んでしまう – サブクラス/スーパークラス関係はako(a-kind-of)関係 • Polymorphismを多態と訳しているのはオブジェクト 業界だけなので、そろそろコンピュータサイエンスで の普通の言葉「多相」を使うほうがよいかも Hanyuda Mamezou 2024 50

付録2：いくつかの提案 • 1メソッドや1クラスのコードだけをみてオブジェクト指向か否か議論す るのはやめよう。構造主義を意識して、クラスやモジュール間の関係 性すなわちSOLID原則で「オブジェクト指向」を判断すべき。 – ポリモルフィズムないしインターフェースを重視して高い凝集度/低い結 合度を目指す設計が「オブジェクト指向」と呼ばれる • クラスを定義しただけでカプセル化というのは止めよう • Getter/setterを使うのは止めて、本来の抽象データ型を目指して業務 上意味のあるメッセージを！ • Liskovの置換原則が何かわからない限り、継承を使うのはやめよう • is-a関係という表現は止めて、厳格にLiskov置換原則を満たしてa- kind-of関係ということにしよう • 従来、OOAないしは要求およびドメインの分析を行う部分は、顧客 やビジネス価値ドリブンのアジャイル原則にもとづく新世代のソフトウ ェア工学ということになるが、もし呼びたいなら「オブジェクト志向」と 言い換えるか、「オブジェクトレッスン駆動」あるいは「現地現物当事 者に向き合う（Orientation）」と称するのがよいであろう – そして、いわゆる「オブジェクト志向」は段階的にAIと協調した「自然言語プログラ ミング」に移行しつつ消えていくことになるだろう Hanyuda Mamezou 2024 51