モデリング

2024/05/06

「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する

システムアーキテクチャ構築の原理」を読んでる。
平鍋さんの記事「『ソフトウェアシステムアーキテクチャ構築の原理(第2版)』読んだ #Java - Qiita」を読み直して、理解が深まった。
平鍋さんの記事に触発されたので、理解できたことをラフなメモ。
間違っていたら後で直す。

【参考】
『ソフトウェアシステムアーキテクチャ構築の原理(第2版)』読んだ #Java - Qiita

「システムアーキテクチャ構築の原理」の感想: プログラマの思索

【1】「システムアーキテクチャ構築の原理」を読んでいて分かりにくかったことは、ビュー、ビューポイント、パースペクティブという概念が出てきて混乱したこと。
これらの言葉は何を表しているのか、具体的に理解できていなかった。

平鍋さんの記事「『ソフトウェアシステムアーキテクチャ構築の原理(第2版)』読んだ #Java - Qiita」では、概念モデルでまとめてくれているので理解しやすかった。

【2】図4-3.コンテクストにおけるパースペクティブが「システムアーキテクチャ構築の原理」のメッセージを全て表している。
平鍋さんの解説が分かりやすい。

43

(引用抜粋 開始)
「非機能要件がシステムのアーキテクチャに影響を与える」という観点を本書は、この言説を徹底的に解説したもの。

非機能要件に限らず、横断的な視点を「パースペクティブ」として捉えている

実際にアーキテクチャを記述しようとすると、1つの文書ではとっても複雑で巨大な説明になる。「ステークホルダー」の「関心事」毎に分割するために、「ビュー」と「ビューポイント」を導入する

「パースペクティブ」は、従来の言葉で近いものとして「非機能要求」「横断的関心事」がある。本書ではこの「ビューポイント」と「パースペクティブ」のカタログを作っています。
(引用抜粋 開始)

【3】図15-1.ビュー間の関係では、ビューを開発や運用の観点で分解している。
この図は、システム開発とシステム保守で分割すれば理解しやすい。
今ならDevOpsだから、開発も運用も一体化しているだろう。

151

【4】図7-3.アーキテクチャ定義のプロセスは、「システムアーキテクチャ構築の原理」が提唱している、アーキテクチャを定義し評価するプロセス。
アーキテクチャ設計の中で、特に非機能要件を含めた横断的関心事をいかにアーキテクチャに盛り込むのか、を考えた一連のプロセスになる。
プロセスの流れは、アーキテクチャ要素や横断的関心事を段階的詳細化して組み立てたあとにアーキテクチャを評価するので、違和感はない。

73

【5】「システムアーキテクチャ構築の原理」では上記3つの図が本書のメッセージになると思う。
本書のやり方を各システム、各案件にテーラリングして設計、実装する必要があるから、本書は、アーキテクチャ設計のメタ概念、メタプロセスの解説書みたいな感触を持っている。

【6】「システムアーキテクチャ構築の原理」の副題「ITアーキテクトが持つべき3つの思考」が指す「3つ」とは、「ステークホルダー」「ビューポイント」「パースペクティブ」と最初に書かれている。

その意図は、ステークホルダーの横断的関心事、特に非機能要求をユーザ観点のビューポイント、システム観点のパースペクティブで分解して組み立てて、トレードオフを考慮したアーキテクチャを設計すること、を意味していると考える。

他にも気づいた他内容があれば書いていく。

| | コメント (0)

「システムアーキテクチャ構築の原理」の感想

システムアーキテクチャ構築の原理」を読む機会があったので感想をラフなメモ書き。

【参考】
「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する: プログラマの思索

『ソフトウェアシステムアーキテクチャ構築の原理(第2版)』読んだ #Java - Qiita

アーキテクチャ構築の原理 第2版を読んだ - 勘と経験と読経

【0】「システムアーキテクチャ構築の原理」は最新版の第2版もある。
僕は確か、デブサミ2010の時に会場で購入した記憶があり、第1版を持っている。
その時から興味のある部分だけかいつまんで読んでいたので、全部を通して読んでいなかったので、輪読するのは良かった。

システムアーキテクチャ構築の原理」を読んで興味を持った部分はいくつかある。

【1】1つ目は、2008年の初版でありながら、マイクロサービスやサービス志向のアーキテクチャ設計を目指していること。
機能的ビュー、情報ビュー、並行性ビューなどのソフトウェア構造のアーキテクチャ設計の観点は、業務システム設計と微妙に違うな、と感じていたが、実際はクラウドベースのマイクロサービス設計を目指しているのだろう。
実際、並行性ビューでは、昔のバッチ処理設計よりもイベント駆動の並列性アーキテクチャに力点をおいている。
たとえば、REST APIやAdapter・Facadeパターンのようなアーキテクチャ設計を念頭に置いて実装しようとしている。

そう考えると、マイクロサービス設計における新たな設計思想はまだ含まれておらず、荒削りな内容を感じるが、文章の背後にある著者の思い、こういうことを言いたいのではないか、を推測しながら読むと理解できるのでは、と感じる。

【2】2つ目は、ATAMという非機能要件の設計技法を解説してくれている点だ。

データベースコンサルタントのノウハウちょい見せ アーキテクチャをレビューする方法(ATAM)

ATAMはシナリオベースで非機能要件を評価する設計技法。
僕の理解では、システムのアーキテクチャの特に非機能要件を品質特性ごとに分類し詳細化して、それをシナリオに落とす。
そのシナリオを優先度付けして、シナリオベースにアーキテクチャを評価して整合性を取ったり、システム設計を明確化する。

利点は、非機能要件をアーキテクチャとして評価する技法として、シナリオベースを用いているので、アジャイル開発をやっている人には取り組みやすいと思う。
デメリットは、CMMIを作ったSEIがATAMを提唱しているので、重たいプロセスになりがちで、テーラリングが必須であり、プロマネによってばらつきが出やすいこと。

ATAMに関する日本語書籍は「システムアーキテクチャ構築の原理」と「間違いだらけのソフトウェア・アーキテクチャ―非機能要件の開発と評価 (Software Design plus)ぐらいしかないので、貴重だと思う。

データベースコンサルタントのノウハウちょい見せ 書評「間違いだらけのソフトウェア・アーキテクチャ―非機能要件の開発と評価」

【3】3つ目は、2009年頃の書籍なので、UMLをベースとした設計を念頭に置いていること。
機能的ビューではコンポーネント図、情報的ビューではER図やDFDや概念クラス図、並列性ビューではステートマシン図を使うと良いと説明されている。
このあたりの意見は僕も同意するが、注意点はいくつかあると思う。

コンポーネント図は「アジャイルソフトウェア開発の奥義」でも重要視されている。
機能を1つのコンポーネントとみなし、コンポーネント間のインターフェイスを重視する設計は重要だと思う。
一方、コンポーネント図だけでは表現しきれない仕様や要件があり、不十分と感じる。

その点は「システムアーキテクチャ構築の原理」でも、メッセージングのやり取りは記述できないので補足説明や別の図が必要と書かれている。

並列性ビューに出てくるステートマシン図は、より詳しく書いていくと結局、詳細設計レベルになってしまう。
アーキテクチャ設計ではRFPに出てくる要件レベルまでで留めたいので、粒度を揃えるのが難しい場合が多いだろう。

【4】「システムアーキテクチャ構築の原理」を読んでいて思い出すのは、2000年代にソフトウェア・プロダクトラインが流行した頃に読んだ「 実践ソフトウェアアーキテクチャ」に出てくる一節だ。

そのボタンを押したら何が起きるのですか?~アーキテクチャは利害関係者のコミュニケーション手段: プログラマの思索

実践ソフトウェアアーキテクチャの解説記事: プログラマの思索

実践ソフトウェアアーキテクチャ」では、政府のある委員会の2日間に渡る討議の中で、新人のアーキテクトが、政府が作ろうとしているシステムのアーキテクチャをコンサル独自の記法でモデルを描いて委員会の参加者に説明していたところ、委員会の参加者たちは何が問題なのかに初めて気づいた。
そして、委員会の参加者たちは、新人のアーキテクトの説明を途中で止めさせて、システムのアーキテクチャの問題点を活発に議論し始めたという一節だ。
これが意味しているのは、アーキテクトの役割とは、システムのアーキテクチャ設計に関する最終責任者ではなく、各利害関係者の間でシステム要件のトレードオフを考慮させる調停者であることだ。

つまり、アーキテクトの役割はシステム要件を決めることではなく、システム要件のトレードオフを色んなステークホルダーに説明して理解させて、最終的な意思決定を引き出す調停者として振る舞うべきだ、ということ。
この一節は僕が一番好きなところでもある。

システムアーキテクチャ構築の原理」では、アーキテクトがすべてのパースペクティブやビューポイントを理解している全能の神のように思えてしまうが、実際はそうではなく、アカウンタビリティを持つ調停者という観点で捉えると理解しやすいと考える。

気づいた点はまた書き留めていく。

| | コメント (0)

2024/03/03

ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる

ソフトウェア工学の根本問題は何なのだろうか?
僕は、ソフトウェアをいかに部品化して疎結合な構造とし、お互いの相互作用でいかに協調動作する仕組みを作るか、だと思う。
以下、直感的な思考を書き記しておく。

ソフトウェアの歴史をたどれば、構造化プログラミングからオブジェクト指向プログラミングへ発展した経緯を見ると、ソフトウェアの構造とソフトウェアを開発する仕組みをいかに透明化し、コントロールしやすくするか、に力点をおいているように思える。

@sakaba37さんから言われてはっと気づいたことは、ソフトウェアは密結合になりやすいこと。
トランザクションスクリプトのように、ちょっとしたロジックの処理を何も考えずに実装すると、密結合なプログラムになり、スパゲッティになりやすい。

そして、ソフトウェアを開発するプロセスも、ソフトウェアを開発する組織も、ソフトウェア構造を反映してしまうために、密結合なプロセス、密結合な組織になりやすい。

今、クラウドを基盤としたマイクロサービス設計が色々試されている。
マイクロサービス設計では、処理層とデータ層をまとめた一つのサービスを独立した単位とし、それらを協調動作する仕組みを作ろうとする。

しかし、今までのソフトウェアの歴史から類推すると、いかにソフトウェアを疎結合な構造にするか、いかにソフトウェアを管理するプロセスを透明化しコントロールしやすくするか、という根本問題から離れられていないように思える。

実際、マイクロサービスが独立した単位であっても、複数のサービスが協調動作させる仕組みをいかに安定して作るか、API設計や補償トランザクションなど、色々試行錯誤している。
ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析」を読めば、マイクロサービスをいかに安定して設計するか、を試行錯誤していることが分かる。

また、全てのマイクロサービスを横断して管理する仕組みとしてサービスメッシュという概念が導入されているが、それもサービスの耐障害性や可用性を担保するための監視サービス群のようなものだ。
ちょうど、Ciscoのネットワーク機器からなるネットワーク構造をSDN化したときに、データ層とコントロール層に分けて、APIを使ってコントロールしようとする仕組みと同じように思える。

他方、ソフトウェア開発の組織も今はスクラムをベースとしたアイデアに基づき、少人数のスクラムチームで開発するのが、特にマイクロサービス開発では相性がいい。
マイクロサービスでは、データ層も処理層も持つので、開発チームが必要なソフトウェア部品を全てコントロールできるからだ。
また、マイクロサービス同士のやり取りは、スクラムチームが協調動作する仕組みに置き換えられる。
実際、スクラムチームでは、プロダクトバックログというインプットとインクリメントとして付加価値を順次リリースするアウトプットが契約になるが、その中のプロセスは部外者は口出しできない。

つまり、スクラムチームは、まるで1つのソフトウェア部品のように中身はブラックボックス化されており、インプットとアウトプットというインターフェイスが保証されている仕組みと思っていい。
すなわち、スクラムチームという開発組織も、疎結合なソフトウェア部品と同様にみなせる。

そんなことを考えると、僕はクラウドやマイクロサービス設計の経験がないけれど、今までのソフトウェア開発の歴史を踏まえた根本問題から、マイクロサービス設計やその開発プロセスでは、過去の根本問題をどのように解決しようとしているのか、という観点で考えていた。
そして、その考え方から類推されるボトルネックは、昔の技術から現代のアーキテクチャに変わったとしても、症状として現れる事象が変わっただけであって、その本質は変わっていないはずだと思っている。


| | コメント (0)

2024/02/12

アーキテクチャ量子の考え方はソフトウェア工学に物理学アプローチを適用したアイデアではないか

進化的アーキテクチャ」の本を読み直していたら、アーキテクチャ量子の考え方はソフトウェア工学に物理学アプローチを適用したアイデアではないかと気づいた。
ラフなメモ書き。

【1】以前に「進化的アーキテクチャ」の本を読んでいたが、その時はこの本の中身がさっぱり分からなかった。
マイクロサービス設計をコンポーネント分割、モジュール分割のように組み立てたい意図は分かるが、その設計方法や中身が雲のように意味不明だった。

そして、とある勉強会で「ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析」を輪読していた。
この本はマイクロサービス設計の解説なのだが、その中に、アーキテクチャ量子、適応度関数という考え方が出てくる。

アーキテクチャ量子は、これ以上分割できないソフトウェアコンポーネント、みたいなイメージを持っている。
適応度関数は、アーキテクチャを診断するメトリクス、みたいなイメージを持っている。
しかし、ふわふわした抽象的概念であり、すぐに理解しづらい。

なぜ、アーキテクチャ量子、適応度関数のような概念がマイクロサービス設計で必要なのか?

【2】アーキテクチャ量子とは、高度な機能的凝集を持つ独立してデプロイ可能なコンポーネントと定義されている。
なぜ、わざわざ量子みたいな言葉を使う必要があるのか?

進化的アーキテクチャ」では、量子力学のアプローチを使って、モジュール性を説明しようとしている。
物理学では、自然界には4つの力、強い力、弱い力、電磁気力、重力がある。
この概念を流用して、アーキテクチャ量子の言葉の意図は、原子核のような小さな量子では、物理学が言う強い力が働いてバラすことができないこと、つまり、ソフトウェアのコードは組み立て部品のように再利用できる単位に分解できないことを意味しているのだろう。

すなわち、アーキテクチャ量子は再利用可能なソフトウェアコンポーネント、ソフトウェアモジュールの比喩として使っている。

なぜ、わざわざアーキテクチャ量子という新しい言葉を使う必要があるのか?

マイクロサービスはソフトウェアアーキテクチャも含めたレベルでソフトウェアの再利用を目指そうとしている。
つまり、アーキテクチャ量子の考え方を使って、従来からのソフトウェア工学の根本問題、ソフトウェアを再利用できる単位にどのように再構築するか、を考えようとしているのだろう。

アーキテクチャとは、ソフトウェアの中で最も不変な部分に相当するが、ソフトウェアの歴史ではアーキテクチャの範囲がどんどん変わってきている。
再利用の単位が、構造化プログラミング、オブジェクト指向、そしてマイクロサービスへ変遷してきている。
そういう歴史的経緯を踏まえて、アーキテクチャ量子という言葉を新たに用いて、現代風に理解しようとしているのだろう。

【3】アーキテクチャ量子に加えて、適応度関数とは、アーキテクチャが継続的に変化あるいは進化することでどれだけ目的の達成に近づいているか、を計算するための目的関数と定義されている。
なぜ、メトリクスと言わずに、わざわざ適応度関数のような言葉を使うのか?

物理学のアプローチでは、自然界の現象だけでなく、経済や人間の事象に対しても、数式で表現できるはずだ、という設計思想がずっとある。
アーキテクチャ量子のように、ソフトウェアコンポーネントに物理的アプローチを用いたならば、同様に再利用できる単位は何らかの数式で表現できるはずだろう。

その時に、アーキテクチャ量子の診断結果を計測するメトリクスを適応度関数と呼んでいるのではないだろうか。

進化的アーキテクチャ」では適応関数の事例がなくて、抽象的な説明ばかりでイメージづらいが、「ソフトウェアアーキテクチャメトリクス ―アーキテクチャ品質を改善する10のアドバイス」では、適応度関数の具体例が掲載されていて、それでようやく理解できた。

適応度関数は、ユニットテストレベルならばカバレッジや静的コード解析が目標範囲内にあるか評価することに相当するし、統合テストレベルならば、パフォーマンスの計測やAPIテストで目標範囲内にあるか評価することに相当する。
E2Eテストレベルならば、UATで使われる正常業務パターンのスモークテストケース、ビジネス要件やマーケティング要件を評価するメトリクスがあるだろう。

つまり、適応度関数はアーキテクチャが正常であるかを診断するメトリクスとして用いられる。

留意点は、適応度関数はケースバイケースとして色々実現されることだろう。
適応度関数は唯一の正解はなく、システムのアーキテクチャごとに設計されて実装される。
だから、GQMのように、メトリクスが使われる目的や意図が重要になってくる。

【4】アーキテクチャ量子に加えて、適応度関数のような概念を新規に作り出した意図には、物理学アプローチを用いて、マイクロサービス設計のような現代風アーキテクチャを理論化して整理したいことがあるのだろう。

再利用できる単位は、構造化プログラミングでは関数レベルだが、オブジェクト指向プログラミングでは、データと処理がカプセル化されたクラスレベルになった。
今では、マイクロサービスでは、処理を行うサービスとデータを保持するデータベースを一体化したドメインレベルで再利用しようとしている。
つまり、新しい酒は新しい革袋に入れるように、マイクロサービス設計には新しい概念を使うべき、という主張なのだろう。

すなわち、ソフトウェア工学に物理的アプローチを適用したい意図があり、それの一つの例が、アーキテクチャ量子や適応度関数になるのだろう。

そんなことを考えると、「進化的アーキテクチャ」「ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析」の著者は、量子力学などに詳しい物理学の専門家をバックグラウンドに持つソフトウェアアーキテクトなのだろうと推測する。

【5】物理学的なアプローチを自然科学のような自然現象だけでなく、経済現象やソフトウェア工学に適用しようという事例は20世紀後半からよく見られる。
物理学で量子力学や相対性理論が完成した後、物理学が解決すべき問題はかなりなくなってきたという話は昔から聞いていた。
だから、成功の歴史がある物理学のアプローチを使って、自然現象以外の問題に適用して、仕組みをモデル化し、問題を解決しようとする方向性はよく見られる。

たとえば、とある勉強会で、トランスフォーマーのニューラルネットワークの背後に重力の対称性である一般座標変換対称性があると言う話を聞いた。

Xユーザーのakipiiさん: 「トランスフォーマーのニューラルネットワークの背後に重力の対称性である一般座標変換対称性があると言う話を勉強会で聞いた。NNを物理で理解するのは面白いな。Unification of Symmetries Inside Neural Networks: Transformer, Feedforward and Neural ODE https://t.co/ooUEm9bLk1」 / X

この論文では、ニューラルネットワークの背後にゲージ対称性のような仕組みがあるのではと議論しているらしい。
この議論の中で、ある人が話されていた発言がすごく心に刺さった。

「人間が作り出したニューラルネットワークは人間が理解不能な状況になっている。
ニューラルネットワークで起きている座標的なもの、力学的なものを自然界に適用した物理学を使って、ニューラルネットワークの中を研究対象できるのではないか、と思える。
物理学者はこういうものが好き。物理学者は数学を作り出す。」

「ブラック・ショールズ方程式も物理学者が見つけた経済モデル。
自然ではないものに物理学的な思想、物理学的アプローチを適用したものだった。」

今のニューラルネットワークや大規模言語モデルでは、その原理や仕組みはまだ誰も分かっていないまま、Pythonで作られたNNやLLMのライブラリをいかに使って問題解決していくか、みたいなところに走っている気がして、違和感をずっと感じていた。
でも、今までの物理学の知見を使って、NNやLLMの原理を理解しようとする発想は面白いなと思う。

たとえば、経済現象でも、ブラック・ショールズ方程式のような経済学の理論も物理学者がブラウン運動の考え方を使っている。
このブラック・ショールズ方程式により、株式証券の無リスク・ポートフォリオが計算されて、現代の金融取引が成り立っているわけだ。

このように、今までに成功した歴史があり、たくさんの道具やツールが揃っている物理の手法を使うことで、経済現象やニューラルネットワークの仕組みを理解しようとしている。
物理学では現象を数式で説明するので、コンピュータに乗りやすいし、応用がききやすい。

その一連の流れに、ソフト工学に物理的アプローチを適用してみよう、という発想もあろうのだろう、と思っている。
そして、その物理的アプローチはわりと成功する可能性が高いのでは、と思ったりしている。

| | コメント (0)

2024/01/02

マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか

マイクロサービスの設計は理解できていなかったし、今も理解が中途半端。
理解できたことだけをメモする。
ラフなメモ書き。

【1】「ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析」を友人と輪読しているが、まだ理解できたという気がしない。
今までのオンプレ環境で業務系Webシステムの設計や開発をしてきた経験、Java+Oracle+Linuxでベタに開発した経験をベースに理解しようとしていた。

そういう観点で読むと、「8章 再利用パターン」が一番理解しやすい。
なぜならば、コンポーネントやサービスの再利用性は、オンプレ環境のWebシステムであれ、クラウド環境のマイクロサービスであっても、同様の観点が通じるからだ。
たとえば、バージョニング戦略は、まさにソフトウェア構成管理と同じ。
後方互換性を見極める、Javaの非推奨(deprecated)のアノテーションのように廃止されたAPIは使わない、枯れた最新バージョンを使う、定期的にパッチ収集とパッチ適用の運用ルールを定める、とか、どこでも同じ。

しかし、マイクロサービスの本質はそういう所ではないはず。

【2】マイクロサービスを僕が理解できない原因は2つあると思っている。
まず、マイクロサービスを実装したモデルを考えようとすると、AWSサービスを使った実装を考えることが普通。
しかし、AWSサービスに特化しすぎると、AWSはサービスが多すぎて、どの場面にどのサービスを使うと良いのか分からなくて、混乱してしまい、何が重要なのか分からなくなる。

他方、AWSサービスのような具体的なサービスを外して、抽象的なマイクロサービス設計技法を考えると、逆に具体的なイメージが思い浮かばず、ふわふわした議論になってしまう。
オンプレ環境の経験を元に比較理解しようとするだけで、その本質までたどり着けない。

マイクロサービスの直感的イメージは、一昔前のSOAPでやり取りするWebサービスとほぼ同じと思っている。
現在なら、SaaSはほとんどがマイクロサービスで実装されているのではないだろうか。
たとえば、検索サービス、顧客サービス、商品サービス、在庫サービスなど、リソースやイベントの単位で区切られたドメインをマイクロサービスへ分割し、それらの間はRESTでデータをやり取りし協調しながら1つのユースケースを実現しているイメージ。
だから、マイクロサービスだからといって、そんなに難しかったり、高尚な概念でもないはず。

では、現代のクラウド上のマイクロサービス設計では、かつてのオンプレ環境のWebサービスと何が異なるのか?
ここさえ抑えれば理解できる、と思える本質的内容は何なのか?

【3】「絵で見てわかるマイクロサービスの仕組み」を読みながら、理解したことを書いておく。
今の自分のレベルではこれくらい噛み砕いたレベルでないと理解しにくかった。

絵で見てわかるマイクロサービスの仕組み」で自分に響いた内容は3つ。

【4】1つ目は、マイクロサービスは、数秒後から数時間後に動機が取れていればいいとする結果整合性が許容できる場面で活用すべき。
つまり、マイクロサービスではACID特性を厳格に守るのは難しいし、そういう場面では有効とは言えない。

よって、マイクロサービスが使えるユースケースは、業務が並列処理で動作しても良いケース、頻度は少ないが一時的にアクセス数や負荷がかかる時にCPUやメモリを動的に増やすスケールアップやサーバ台数を動的に増やすスケールアウトするケースなどだろう。
すなわち、性能要件を動的に拡張したいケースが当てはまるのではないか。
AWSやAzureのようなクラウドであれば、そういう拡張は、クラウド基盤が提供するマネージドサービスで簡単に実現できる。

一方、デメリットは、ACID特性ではなく結果整合性でしか担保しないので、基幹系システムでは難しいかもしれない。
たとえば、あるマイクロサービスで障害が起きてデータの不整合が発生した時、ロールバックをDBMSやフレームワークではなく、自分たちで作り込む必要があるかもしれない。
絵で見てわかるマイクロサービスの仕組み」では、異常系処理やロールバック処理を補償トランザクションで実現する方法が紹介されていた。
この辺りは実際の実装方法がよく分かっていないが、結局、自分たちでフレームワークを組み込んでいるのと同じような印象を受ける。

【5】2つ目は、コンテナオーケストレーションは、複数コンテナをクラウド基盤のAPIやマネージドサービスで制御する設計思想であること。

絵で見てわかるマイクロサービスの仕組み」では、コンテナ<Pod<ノードの順でグループ化されていた。
すると、複数のコンテナを手動で管理するのは面倒だし、ミスも多くなる。
また、頻度は少ないがアクセス数が一時的に増える場合にスケールアウトするようにコンテナを動的に増やす場合、コンテナのIPアドレスは一時的に付与されるので、管理する手法も特有の考え方が必要になるだろう。
よって、複数のコンテナをAPI経由のプログラムで一括管理したくなる。

そこで、コンテナオーケストレーションという概念で包括的に管理する。
絵で見てわかるマイクロサービスの仕組み」では、コンテナオーケストレーションを適用するユースケースとして、
・コンテナの作成とデプロイ
・負荷に応じたスケールアウトやスケールダウンやロードバランシング
・ホストやコンテナのヘルスチェック
があげられてたい。
つまり、動的にコンテナを作成しデプロイして、負荷に応じてスケールアウト・ダウンし、負荷分散させる。
また、コンテナのヘルスチェックのように、サーバー監視の管理サービスも実現してくれる。

コンテナオーケストレーションの実装例としてKubernetesがあげられている。
Kubernetesの優れた汎用的な機能のおかげで、AWSでもAzureでも一般的なクラウドにもコンテナ群をそのまま移行できる、という発想なのだろう。
コンテナの実装は、yamlやJasonなどでドメイン特化言語のように記載されて実現されるのだろう。
それゆえに、yamlなどのドメイン特化言語で、マイクロサービスのコンテナ群を全て実装すれば、検証環境であれ本番環境であれすぐにクラウド上に実装できるはず。

ではそれで全ての問題が解決するのか?
変化の早いビジネス環境において、マイクロサービスを組み合わせることで即座に稼働しやすいだろうが、複雑性は増すだろう。
数多くのコンテナを協調させながら稼働させるには、コンテナの中身を記載したyamlは相当複雑になるだろう。
一昔前に、Antでビルド&デプロイのタスクを書いていた時、宣言的に書いて楽だなと思っていたのに、環境が増えるごとにIF文がAntタスクに紛れ込んでどんどん複雑化したような経験を思い出す。
たぶん、それに似たような事象がKubernetesでも起きるのではないか、と思ったりする。

【6】3つ目は、サーバレスアプリケーションはBPMNのようなワークフローに並列処理を組み合わせたワークロードみたいなものではないか、と思う。

絵で見てわかるマイクロサービスの仕組み」では、サーバレスアプリケーションの基本アーキテクチャは、BaaSとFaaSの2種類があげられている。
BaaSは外部サードパーティのサービスを使うパターン。
FaaSはビジネスロジックをイベントドリブンで実装するパターン。

BaaSはたとえば、Googleアカウント認証やTwitter認証などの外部認証サービス、PayPalのような外部決済サービスがあげられるだろう。
外部サードパーティサービスの方がセキュリティ要件も性能要件もいいならば、そちらのサービスを利用することで、ユーザの利便性も増すだろう。
他方、ユーザ認証やクレジットカード情報を自社システムに持たないデメリットがあるので、顧客情報をより包括的に収集できないデメリットもあるだろう。

FaaSは、BPMNのようなワークフローに並列処理を組み合わせたワークフローに思える。
マイクロサービスをつないで、イベント駆動でマイクロサービスをキックし、一連の業務が流れる感じ。
その場合、並列処理で動くので、商品を購買している間に、検索したり、在庫に問い合わせたりして並列で動かすケースもあるだろう。

サーバーレスアプリケーションはFaaSを想起させる。
AWSならLambdaになるのだろう。
メリットは、アプリケーション開発者はアプリ層のマイクロサービスの実装だけに特化すれば良く、インフラ基盤は考えなくてもクラウド基盤がマネージドサービス等で勝手に管理してくれる、そういうイメージなのだろう。

他方、開発時のデバッグや障害時の復旧はかなり面倒になることが想像される。
複数のマイクロサービスを通したシステム全体テストをやるには、ローカルPCでは無理で、クラウド上に本番同等の検証環境が必要になるだろう。
その分コストも増える。
また、イベントドリブンで連なる一連のマイクロサービスのうち、途中のマイクロサービスで障害が発生して、データの同期が取れなくなった場合、データのロールバック処理は複雑になるだろう。
本来は、データ復旧や障害復旧もクラウド基盤が勝手に自動で上手くやって欲しいが、手作業で設計して入り組んだ複雑なワークフローになっていると難しいだろう。

そんなことを考えると、全てがバラ色の世界ではないだろうと思う。

【7】マイクロサービス設計は従来のアーキテクチャ設計と何が違うのか?

違いの一つは、マイクロサービス設計では、インフラ基盤をクラウドのマネージドサービスで自動化したり、APIで監視サービスやコンテナオーケストレーションを実装できる点にあるだろう。

つまり、従来のオンプレ環境のインフラ基盤は、アプリ開発者の手によって操作できるようになった点が違いになるだろう。
アプリ層からインフラ層まで全て、アプリ開発者がコントロールできるようになったこと。
そんな開発者はフルスタックエンジニアと呼ばれるのだろう。
また、DevOpsとは、そういうフルスタックエンジニアがアプリ層からインフラ層までコントロールして、開発も運用も一体化するプロセスを指すのだろう。

| | コメント (0)

2023/11/12

「ソフトウェアアーキテクチャ・ハードパーツ」の情報リンク~マイクロサービスの設計技法の課題は何なのか

ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析を読んでいて、まだ中身を理解できていない。
ネット上の感想記事を自分用にリンクしておく。

【参考】
『ソフトウェアアーキテクチャ・ハードパーツ』 - Don't Repeat Yourself

(引用開始)
また、最近話題になっていた『ソフトウェアアーキテクチャの基礎』(以降、「基礎」)を執筆した著者陣が書いたもう一冊の本でもあります。
「基礎」はアーキテクトとしての姿勢や、それぞれのアーキテクチャの簡単な概要が中心でしたが、この本はより実践に近く方法論寄りです。「基礎」が「What」を扱うとすれば、本書は「How」を扱うといった関係性でしょうか。
(引用終了)

(引用開始)
現代ではデータをどのように設計し、分割しつつ整合性を保って保管しておくかといった一連の流れの重要度が増しています。この問題についても本書は拾い上げるよう努力しています。[*1]
従来のアーキテクチャの議論では、マイクロサービスはどう分割するかとか、コードの関心事がどうこうとかそういったアプリケーションに限った範囲が中心だったように私は思っています。が、そうではなくデータをどう分割、配置、保管していくかといった問題についても議論に含めるようにしています。
(引用終了)

『ソフトウェアアーキテクチャ・ハードパーツ』完全に理解した - Mirai Translate TECH BLOG

(引用開始)
一言で言うと
「マイクロサービスの大きさと通信方式をどう決定するか」について書かれた書籍です。
(引用終了)

ソフトウェアアーキテクチャ・ハードパーツ - Forkwell Library #12に参加してきた - 天の月

(引用開始)
レガシーで大規模なモノリシックシステムをどう解決していくか?というのを物語形式で紹介してくれているということです。

ソフトウェアの中でも土台となるような部分の決定は「モノリシックなシステムをどう分解していくか?」で前半部分に表現され、「ソフトウェアアーキテクチャをどう決めるか?」は分散システムで直面する難しい問題をどのように決定するか?で後半部分に表現されているということです。

もう少し具体的に言うと、前半部分は戦術的フォークとコンポーネントベース分解を中心に登場人物がトレードオフ分析を行なっている様が描かれており、後半部分は、粒度分解要因と粒度統合要因のバランスによって決定されるという前提をもとに、分解をどこまでするかが具体的に描かれているそうです。
(引用終了)

「ソフトウェアアーキテクチャの基礎」読書感想

【1】「マイクロサービスの大きさと通信方式をどう決定するか」が根本テーマであるとすれば、マイクロサービスの設計上の課題や留意点がテーマになる。

2020年代の現在では、マイクロサービスの実装はAWSなどのクラウド基盤が前提条件だろう。
AWSならEC2ではなく、CloudFormationを使って各種サービスを組み合わせて一体化したシステム設計をするのではないか。
一方、オンプレ環境のシステムでは、弾力的なスケーラビリティ向上、つまりスケールアップやスケールアウトを動的に変更するのは非常に難しい。
逐一サーバースペックをサイジングしてどれだけのスペックを持つべきか見積もりして導入するまでに非常に手間がかかる。

では、マイクロサービスの落とし穴はどこにあるのか?
マイクロサービスの利点や美味しいメリットを得るにはどんな留意点があるのか?

モノリシックな基幹系システムやモノリシックな巨大なシステムをビジネス上の観点でサービスごとに分割して、分散サービス化した時、それぞれのサービスの粒度は小さくなるので運用保守しやすくなる点もあるだろう。
昨今のDevOpsの観点では、小さな開発チームが設計や開発から運用までを担当する流れなので、チームが担当するシステムのサイズは小さい方が実現しやすい。

一方で、複数のサービスを連携して初めて、顧客が満足する1つのユースケースが成り立つような場合、途中でサービスが停止すると成り立たなくなる。
分散サービスのアイデアは20年以上前のCORBAやEJBからずっと言われていては失敗してきたが、クラウド基盤でようやく実現可能な設計手法になった面もあると思う。
僕はまだAWSやクラウド基盤のことは無知なので、今までのオンプレ環境で構築するシステム設計とは違った観点がマイクロサービスの設計にはあるのだろうと思う。

理解できた内容はBlogに残しておこうと思う。


| | コメント (0)

2023/10/21

概念モデリングや設計原則は進化しているのか

最近、概念モデリングや設計原則の勉強会に参加して色々気づきがあった。
ラフなメモ書き。

【1】「実践UML第3版」を勉強会で読み始めた。
僕は「実践UML第1版」を購入して読んでいた。
思い出せば20年前になるのか。
そこから第2版も買ったし、最近第3版も買ってみた。
中身は変わってきているが、版を重ねるごとにオブジェクト指向設計の内容が洗練されて、RUPという開発プロセスに準じるように設計から実装、移行まで一気通貫する。

2020年代の現在、「実践UML」を再度読んで気づきがいくつかある。

【2】1つ目は、RUPはもう不要と思う。
スパイラル開発プロセスはWF型開発からの脱却という観点で重要だったが、Scrumを中心としたアジャイル開発が全盛の時代だから、わざわざテーラリングが必要な重厚長大なRUPを利用するメリットはないと思う。

【3】2つ目は、モデリングに必要なUMLのダイアグラムの力点が変わっていること。
「実践UML第1版」では、以前は協調図(コラボレーション図)、今のコミュニケーション図がオブジェクト指向設計で重要です、と主張していた。
理由は、コラボレーション図を描くことで、機能をどのクラスに割り当てるべきか、凝集度や結合度、生成などの観点で検討する時に有用だから。
オブジェクトからたくさんの指示が出ていれば責務が多すぎるね、と気づきやすいから、と。
当時の自分はすごく納得した。

実践UML第2版実践UML第3版では、クラス図やシーケンス図で説明する場面が多い。
コラボレーション図の話はなくなっていた。
たぶん、UMLの中でも重要度が下がったためだろう。

しかし、機能の割り当ての考え方は普遍的と思う。

【4】3つ目は、GRASPパターンは「情報エキスパート」パターンが一番大事ということ。
このパターンが「実践UML」の重要ポイント。

機能や責務はどのクラスに割り当てるべきか?
責務の遂行に必要な情報を持っているクラス、すなわち情報エキスパートに責務を割り当てるべきだ。

つまり、責務の遂行に必要な情報を自身のクラスの属性、関連先のクラスから取得した情報を自身のクラスで持ってること。
そして、処理を実行する時に、他クラスへメッセージを投げ出せること。

コミュニケーション図なら、情報エキスパートとなるクラスからメッセージという矢印が出ているだろう。
シーケンス図なら、情報エキスパートとなるクラスからメッセージが出て、他のクラスに処理が委譲されて、階段状の図になっているだろう。

その他のパターンも8つくらいあげられているが、そこまで重要ではないように思う。
生成、疎結合、高凝集度、多相性、コントローラは読めば分かる。
バリエーション防護壁はFacadeやAdapterみたいなもの。
純粋加工物、あるいは人工品は、機能の関連だけで構成するのではなく、ソフトウェアのプログラムの都合上、論理的なオブジェクトをワンクッション挟むようなもの。

【5】4つ目は、概念モデリングとデータモデリングは似ているようでやはり異なることだ。

「実践UML」では、概念モデリングでの注意点がいくつかある。

【6】属性とクラスは区別する。
一般に、ある概念をクラスの属性にするか、クラスで独立させるか、識別は間違いやすい。
「実践UML」の指針では、ある概念Xが現実世界では数値でもテキストでもなければ、Xは概念クラスであり、クラスの属性ではない、と言い切っている。

これは重要と思う。
初心者だった頃、どれをクラスにすべきか迷ってしまう時が多かった。
迷って、概念をクラスの属性にしてしまいがちな時が多い。

例えば、Destination、AirportはFlightに含めるべきか。
それぞれクラスとして独立させて、関連で結ぶべき。

実際は、1つの概念はクラスのロール名としていろんな別名として現れる。
例えば、企業クラスは顧客だったり仕入先だったり、取引先だったり、もしかしたらグループ内企業だったりする。
つまり、企業クラスはいろんなロール名として呼ばれる時がある。

【7】属性にはプリミティブ型を使わず、データ型を使う。
たとえば、属性にはDate型、Number型、String型を使う。
あるいは、Address、Color、PhoneNumber、UPC、SKU、ZIP、列挙型を使う。
区分値は列挙型を使う場合が多いかな。

例えば、会員クラスの会員名、会員IDみたいなものだろう。
でも、同じ会員名であっても、実際の人物は異なるケースもある。
だから、ValueObjectを別で用意して利用する場合もあるだろう。
ドメイン駆動設計なら、ValueObjectをかなり頻繁に使うだろうと思う。

【8】概念クラスの関連付けに外部キーや複合キーを書かない。
概念クラスの関連付けは、属性ではなくクラス間の関連で書く。

この部分がデータモデリングと異なるし、引っかかるところと思う。
一般にオブジェクトには唯一の主キーとなるサロゲートキーが割り当てられる場合が多いだろう。
すると、データモデリングで考えた時、外部キーや複合キーがなく、全てサロゲートキーなので、クラス間の制約条件が分かりにくくなる。
RailsのActiveRecordがそういう例になるだろう。
データモデリングなら、サロゲートキーを使っている場合、外部キーのペアが複合キーの役割を持つので強属性になるような制約をもたせるだろう。

では、概念モデルから実装モデルへ詳細化されていくうちに、関連はどう変わっていくのか?
概念モデルの関連から相手先のロール名が割り当てられて、最終的には関連はどこかのメソッドとして実装されて、そのメソッド内でロール名は変数名と同一視されて利用されるだろうと思う。

【9】概念クラス図でも、関連クラスのように、複合キーを使った事例はある。
しかし、関連クラスを多用すると、クラス図から読み取りにくくなる。
一方、データモデリングの観点では、関連クラスを複合キーを持つクラスと置き換えれば、明確な意味を読み取りやすくなる。

【10】概念モデリングでは、クラス間の関連と多重度でクラス間の制約条件を読み取る場合が多いように思う。
慣れるまで大変だけど。

【11】そんなことを考えてみると、概念モデリングや設計原則は以前よりも変化していないように思う。
UMLが流行していた2000年代からモデリング技法は進化しているのだろうか?

オブジェクト指向設計とデータモデリングの違いは他にも整理してみる。

| | コメント (0)

2023/10/14

パッケージ原則とクラス原則の違いは何なのか

パッケージ原則とクラス原則の違いについて考える時があった。
直感的なラフなメモ。

【参考】
パッケージ設計の原則を本で学ぶ - Qiita

イラストで理解するSOLID原則 - Qiita

パッケージ原則を見ると、パッケージの凝集度3つ、結合度3つの観点に分けられる。
その内容は、クラス原則であるSOLID原則をパッケージ版に拡張したように思える。

実際、単一責任の原則はパッケージの凝集度に関連するし、開放閉鎖原則はパッケージ版も同様だ。
インターフェイス分離の原則やLiskocの置換原則は、パッケージの結合度に関連してくる。

ただし、その違いはある。
1点目は、パッケージやコンポーネントの観点では、リリースできる単位が再利用できる観点と同一になる原則が最も重要になる。
理由は当たり前で、リリースして他ユーザが使えるようにするからには、他の人が再利用できる観点と同一にならざるを得ないから。

リリースモジュールは単独で動くものである一方、クラスは単独では動作できず、複数のクラスを結合して初めて一つの画面や帳票、バッチなどの機能を形成する。
この違いは大きく、再利用の観点も他者に利用してもらえる観点と、他者に読んで保守してもらえる観点の違いになる。

もう1点は、パッケージとクラスを保守する人の単位が異なる点だ。
クラスを修正する人は基本的には1人であり、コードのレビューアも関わるだろうが、1人が責任を負う。
その修正履歴はコミット履歴に残る。

一方、パッケージを保守する単位はチームや部署の単位になる。
普通は、リリースモジュールの単位はサブシステムであるから、システムごとに担当する部署があるだろう。
大規模な基幹系システムを持つ企業であれば、数多くの部署ごとに担当するシステムが異なるだろう。
つまり、サブシステムというリリースモジュールを保守するのは複数人であり、アプリ層だけでなくフロント層、インフラ層など数多くのメンバーが関わって初めて一つのシステムが動く。

すると、システム単位に開発チームが存在するので、コンウェイの法則に従うことになるだろう。
つまり、アーキテクチャ(システム)は組織に従うわけだ。
この特徴により、サブシステム間が部署間の壁となり、IFとなるので、IF連携は認識齟齬が起きやすいリスクが発生しやすい。
部署ごとにシステムが分かれることにより、システムは局所最適化されやすくなる。

そんなことを考えると、パッケージ原則とクラス原則は同じような観点が多い一方、クラス担当者やシステム担当チームの違いを認識することも必要だろうと思う。

| | コメント (0)

2023/05/26

JSTQBのテストプロセスの概念モデルを描いてみた

JSTQB Fondation試験を勉強した時に、JSTQBのテストプロセスの概念モデルを描いてみた。
気づきを書き残す。
まだ理解があやふやなので、間違えていたら後で直す。

【参考】
テストアイテムとは何か?概要や定義、現場での使われ方について解説

【1】JSTQBのテストの専門用語は、普段使っている言葉と意味が違っていたり、別の言葉で置き換えられる時があると分かった。
たとえば、テストレベルはテスト工程のテストプロセス、テストタイプはテストの種類に相当するだろう。

テストオラクル、テストベースなどはJSTQBで初めて知った。
たぶん、テストケースの発生源や出処となる概念を明確に区別すべきという考え方があるのではないか。

テストオラクルの用語定義: プログラマの思索

また、テストプロセスの概念モデルを描いてみて気づいたのは、JSTQBにたくさん出てくるテストの専門用語は、テスト管理ツールやテスト支援ツール、テスト自動化ツールなどのツールで使う場面をかなり意識しているのではないか、と直感している。

たとえば、テストスイートは、一般にテスト自動化ツールに読み込ませるテストケースやテストデータをイメージできる。
テストハーネスはドライバやスタブみたいなものだし、テスト環境そのものも今ならDockerで最初から環境構築を自動化できる。

【2】エラー(誤り) error、欠陥 defect、故障 failureは明確に区別される。

エラー・欠陥・故障の用語定義: プログラマの思索

一般に不具合と言われる事象は故障に相当するだろう。
不具合をバグ、障害と断定しない理由は、実際に調査してみたら、仕様通りで問題ないとか、テスト手順ミスやテスト環境の不備が原因だった、という場合があるからだろう。
不具合は、故障、不正の事象も包み込む曖昧な現象を指す場合が多いと思う。

欠陥があったからといって、故障が発生するわけではない。
欠陥のあるプログラムが実行されて初めて故障が発生する。
欠陥がプログラムに埋め込まれても、テストで発覚せず、運用していても発生しなければ、システムは問題なく動く。
しかし、欠陥そのものは存在しているわけだから、いつかは故障として発生する。
いわゆる潜在バグに相当するのだろう。

欠陥の根本原因の分析はなぜなぜ分析がよく使われるだろう。
しかし、なぜなぜ分析を現場で実際に使ってみると、なかなか効果を出すのが難しい。
メンバの力量にかなり依存するので、原因があらぬ方向に行ってしまいがち。

【3】JSTQBでは、テストチームの役割には、テストマネージャとテスト担当者の2つが少なくとも定義されている。
テストマネージャはテスト計画フェーズで中心的役割を果たす。
テスト実行フェーズ以後の具体的な作業はテスト担当者に任せるようだ。
つまり、テストマネージャはプロジェクトマネージャやストラテジストに近いイメージを持った。

JSTQBのAdvancedLevelはテストマネージャ試験がある。
ただし、業務経験が必須らしい。

【4】テスト管理や品質管理については、TestLinkを試していた頃に随分色々考えていた。

TestLink: プログラマの思索

プログラミングやシステム設計とは異なる考え方を知ったり、試したりするのが面白かった。
残念なのは、テスト管理ツールはほとんどが有償であり、OSSのTestLinkしか試せなかったことだった。

テスト管理ツールTestRail、CAT、QualityForwardの感想: プログラマの思索

テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルのリンク: プログラマの思索

今持っている問題意識は、2023年の現在、ソフトウェアテストを支援するテストツールはどんな方向に進化しようとしているのか、ということ。
上記の記事にも書いたが、日本のIT企業やユーザ企業が考える品質と、欧米企業が考える品質は異なる。
日本人は機能の細かい品質までこだわるが、現代はアジャイル開発が普及して一般的になっていて、その考え方が時代に合わない部分もある。
アジャイル開発に適した品質とは何なのか?
そして、AIなどを使ってもっとテストそのものを進化させることはできるのか?

この辺りは色々考えてみたいと思っている。

| | コメント (0)

2023/05/13

第85回IT勉強宴会の感想~概念データモデルからビジネスモデルを構築すべきという考え方

土曜に開かれた第85回IT勉強宴会で、真野さんがデータモデリングの観点でエンタープライズシステム設計を講演されたのでオンラインで聞いた。
講演内容を知った前提で、感想をラフなメモ書き。

【参考】
概念モデルの効用を知ろう - connpass

概念モデルの効用を知ろう(第88回IT勉強宴会inZOOM/大阪サテライト) | IT勉強宴会blog

第39回IT勉強宴会の感想~花束を作る花屋の業務モデルをT字形ERと三要素分析法で比較する: プログラマの思索

第62回IT勉強宴会のメモ~2人の方法論者によるデータモデリング激レア対談: プログラマの思索

「データモデリング入門-astah*を使って、TMの手法を使う-」はとても良いモデリング資料: プログラマの思索

業務ロジックをデータモデリングはどこまで表現できるか?: プログラマの思索

リソース数がビジネスの可能性に関係する理由: プログラマの思索

【1】講演のメッセージは、DXで新規ビジネスを創出したいなら、概念データモデルを描くことから出発しよう、ということ。

メッセージの背景にある課題は、昨今、IOTやSaaSなどのSoE、既存の業務システムのSoRなど色んなところから数多くのデータがビジネスの副産物として簡単に入手して蓄積できるようになった
そのデータをAIや機械学習に食わせて分析するようにしたい。
しかし、色んな入り口から源泉データが発生し、途中で加工されて雪だるま式に派生データが積み重なり、複雑なトランザクションデータになっている。
そのためにそのデータを利活用しようとすると、派生データを取り除き、源泉データを区別して本来のデータを抽出する仕組みが必要だ、という問題意識。

akipiiさんはTwitterを使っています: 「我々が扱おうとしているのは、大半が加工・集約された派生データである。データがどこで加工されたのか、出処はどこなのかを探ることが重要。源泉データを突き止めるためにデータの系統図、データの変遷をたどるのが必要。イベントを時系列に並べてリソースを抽出する、ということかな? #benkyoenkai」 / Twitter

そこで、SoE領域、SoR領域などの源泉データからどのように加工されてデータ連携基盤ハブにたどり着くのか、をデータモデルの観点から整理分類し、データクレンジングしたきれいなデータをデータ活用基盤へ連携してAIや機械学習に使ってもらうという仕組みにする。

akipiiさんはTwitterを使っています: 「源泉データがレガシーなSoRだったり、SaaSのSoEだったり、データレイクからだったり色々ある。そういう風にデータが時系列で加工されていく過程が見える。 #benkyoenkai」 / Twitter

講演では、製造業のサプライチェーン全てをデータモデル化し、コスト最適化の観点でシミュレーションとして使う事例が紹介されていた。

akipiiさんはTwitterを使っています: 「取引先や原材料、中間加工品の調達関係を描いたデータモデルが必要となる。制約条件は、取引先や原材料、中間加工品の調達関係を描いたデータモデルが必要となること。事業部間のデータ統合ができていることが前提。プロセスの再現だけではデジタルツインは実現できない。 #benkyoenkai」 / Twitter

akipiiさんはTwitterを使っています: 「デジタルツインでは、データ連携基盤Hubが重要。SoRが源泉データ。SoRからデータ連携基盤Hubを経てデータ活用基盤へデータが流れることになる。 #benkyoenkai」 / Twitter

僕の感覚では、雪だるま式に加工されて複雑化したトランザクションデータを時系列に並べて、マスタ(リソース)をトランザクション(イベント)と区別して抽出し、イベントやリソースをそれぞれ管理する仕組みを作る、というように捉えた。
実際の分析手法では、データモデルの正規化も使うし、クラスとインスタンスを区別することでクラスを抽出しロールとしてポリモルフィックに振る舞わせるように整理する。

講演では、顧客というクラスは、顧客、消費者、代理店、法人客というロールがある例が紹介されていた。

akipiiさんはTwitterを使っています: 「データモデリングは分類学である、とデータ総研の方は言っておられた、と。顧客、消費者、代理店、法人客などのロールを分類して、特化・汎化のER図で描く。IDEF1Xなのでオブジェクト指向設計と同じ。パーティモデルの概念と同じ。 #benkyoenkai」 / Twitter

【2】データモデルを作る目的は3つ。

akipiiさんはTwitterを使っています: 「データモデルを作る目的。3つある。ビジネス構成要素や業務ルールを把握する。保有するデータをAI機械学習の入力源にする。新規ITシステム構築に活用する。 #benkyoenkai」 / Twitter

【3】概念データモデルを描くメリットは何か?
メリットは2つある。

1つ目は、ビジネス構成要素を資源(リソース)と活動(イベント)の2種類に整理統合することによって、今後新たなビジネスモデルを生み出す材料として扱えること。

akipiiさんはTwitterを使っています: 「ビジネスの構成要素は資源(リソース)と活動(イベント)からなる。リソースは普通のマスタ、イベントは普通のトランザクションとみなせるね。羽生さんの本ではイベントに注目するとデータモデルを作りやすいと言っていたなあ。時系列に並べれば自然にDFDみたいなER図が描けるから #benkyoenkai」 / Twitter

データモデルのエンティティをイベントとリソースの2種類に整理するアイデアは、T字型ER(旧)や羽生さんのデータモデリング手法でも出てくる。
羽生さん本では、イベントは必ず日付があること、そこからイベントとリソースを区別しましょう、と言っていた。

「データモデリング入門-astah*を使って、TMの手法を使う-」はとても良いモデリング資料: プログラマの思索

業務ロジックをデータモデリングはどこまで表現できるか?: プログラマの思索

ここで、イベントの数とリソースの数を数えて、もしイベントの数がリソースよりも少ないならば、リソースを組み合わせて新たなイベント(トランザクション)を生み出すことで、新たなビジネスモデルを考える切っ掛けの一つになりうる。

リソース数がビジネスの可能性に関係する理由: プログラマの思索

第39回IT勉強宴会の感想~花束を作る花屋の業務モデルをT字形ERと三要素分析法で比較する: プログラマの思索
(引用開始)
リソースの数よりもイベントの数が少ない場合、リソースの組合せで発生する可能性のある対照表というイベントは、その会社の業務として存在していない事実がある。
すなわち、新しい業務を生成することで、新規ビジネスを作り出す根拠になりうる。
(引用修了)

2つ目は、講演では、プロセス指向設計で使われる業務フロー図では、既存の業務フローで業務を入れ替え・削除したり、担当組織を入れ替える程度であって、BPRや業務改善しかできない。
DXで本来やりたい新規ビジネスモデルを生み出すことは、業務フロー図からでは発想できない弱点がある。

akipiiさんはTwitterを使っています: 「データモデルの活用例の1つはDXへの適用。経営者、業務部門、IT部門のコミュニケーションツールとして使う。ビジネス創出のためには業務フローアプローチではBPRや業務改善に留まり、新規ビジネス抽出につながらない。順序入れ替え、組織分担変更のレベルにすぎない #benkyoenkai」 / Twitter

akipiiさんはTwitterを使っています: 「都度受注モデルからサブリスクプション契約モデルへビジネスを変更する。エンティティの置き換えだけでなく、新規イベント、新規リソースの追加が必要になることが明確に分かる。すると、新規イベント、新規リソースを保守管理する組織も必要になるだろう。 #benkyoenkai」 / Twitter

概念データモデルでAsIsモデルを描き、そこからエンティティを出し入れすることで、新規ビジネスモデルを生み出せるはず、と講演では説明されていた。

この部分については、なるほどと納得できる部分もあるが、本当にそうなのかという疑問も生じる。
確かに、講演で例に出た、AsIsの受注契約モデルとToBeのサブスクリプション契約モデルでは、業務フロー図でAsIsからToBeは出てこないだろう。
なぜなら、サブスクリプション契約モデルは誰も知らない初めてのビジネスモデルなので、業務フローをそもそも描くことすら難しい。
どんな業務が必要で、どの組織が業務のどのプロセスを担当して回すのか、そういう具体的な細かい粒度まで落とし込むのは至難の業だ。

しかし、AsIsの受注契約モデルとToBeのサブスクリプション契約モデルでは、概念データモデルを描いてみると構造はかなり違う。
契約エンティティなどの一部のエンティティは同じだが、AsIsモデルでリレーションシップや新たなエンティティをちょっとだけECRSでいじればToBeが出てくる、というのはちょっと無理があると思う。
実際、QAタイムでは、既存のAsIsモデルの概念データモデルでエンティティをECRSで出し入れする程度でToBeモデルが作れるのか、という質問もあった。

概念データモデルで新規ビジネスモデルを描く重要性は理解できるが、具体的なデータモデルを整合性が取れるように生み出すことは、別次元の作業なのだろうと思う。

【4】概念データモデルとオブジェクト指向設計、ドメイン駆動設計の違いは何なのか?

講演で紹介された概念データモデルはIDEF1Xで描かれていた。

ER図 (Entity-relatonship Diagram) | astah* 機能ガイド

IDEF1Xのエンティティ同士の関連線はクラス図と異なるが、多重度を書いたりロールを書いたりするのでクラス図に似ている。
オブジェクト指向設計やドメイン駆動設計が好きな人は、たぶん違和感なくIDEF1Xの概念データモデルを理解できるだろうと思う。

akipiiさんはTwitterを使っています: 「受注出荷のデータモデルをIDEF1XのER図、DFDで描かれた事例。クラス図に読み替えやすい。 #benkyoenkai」 / Twitter

akipiiさんはTwitterを使っています: 「受注出荷モデルの例。受注と出荷の関係が1対1、1対多では何が違うか?受注単位の出荷、一括受注して分割出荷。IDEF1XのER図はクラス図に似てるのでドメイン駆動設計が好きな人は読みやすいと思う  #benkyoenkai」 / Twitter

akipiiさんはTwitterを使っています: 「抽象化したエンティティはロール概念を用いて関連付けることができる。真野さんが説明されるデータモデルはクラス図にそのまま置き換えられるね。 #benkyoenkai」 / Twitter

データモデリングがなかなか普及しない原因の一つは、ドメイン駆動設計が好きな人はデータモデルを読み解きにくい現象が多いのではないか、と推測するので、この辺りは1つのきっかけになるかもしれない。

【4】渡辺さん式データモデルと真野さんの講演で出てくる概念データモデルの違いは何なのか?

真野さんの講演で出てくるデータモデルは概念モデルレベルなので、エンティティ名しか書かれていない例が多い。
一方、渡辺さん式データモデルは、すべての属性を書き出し、関係従属性の意図まで明確に表していて、実際のデータの例も書いているので、より具体的だ。
実装モデルそのものと言っていい。

だから、渡辺さん式データモデルではテーブル仕様書をそのまま出力できるレベルであり、Railsのようなフレームワークを使えばすぐにCRUD画面も作れる。
つまり、どんな画面や帳票が必要で、どんな業務や画面操作でデータが生成されて更新されていくか、というレベルまで全て把握できている。
だから、ローコード開発やノーコード開発と相性がいい。
たぶん、SalesforceやKintoneのようなローコード開発ツールと相性が良いと思う。

akipiiさんはTwitterを使っています: 「真野さんのデータモデルはIDEF1Xで描かれてるので、渡辺さんのER図とは見た目は違う。個人的には、渡辺さんは関係従属性の意図まで明確にしインスタンスも例示するので、より実装モデルに近いと思う。だからローコード開発と相性がいい。 #benkyoenkai」 / Twitter

しかし、関数従属性やキーの種類の理解が深くないと、データモデルを読み解くのは難しいと思う。

再入門:「正規化崩し」としてのサロゲートキー - connpass

(引用開始)
・候補キー(candidate key):レコードを一意に特定するキー。1テーブルに複数存在することがある
・主キー(primary key):代表として定めた候補キー。項目値の変更は許されない
・単独主キー(single primary key):1項目で出来ている主キー
・複合主キー(composite primary key):2つ以上の項目で出来ている主キー
・自然キー(natural key):業務上意識されている候補キー。単独主キーか複合主キーかは問わない
・サロゲートキー(surrogate key):業務上意識されていない単独主キー。代理キーともいう
(引用修了)

サロゲート単独主キー vs 複合主キーの話、予習編 - たなかこういちの開発ノート

アーキテクトは、データモデルから業務フロー図、画面帳票、組織構成までイメージできる能力を求められる。
たとえば、渡辺さんの本を読めば、ほとんどデータモデルばかりでDFDは少しだけしか紹介されていないので、実際にどんな業務フローが必要になってくるのか、は自力で考えなければならない。
渡辺さんの本に出てくるデータモデルでは、複合主キーや外部キー、特に2次識別子(Alternative Key)が巧妙に使われていて、業務ルールや制約条件を表しているので、注意深く読まなければ割と読み落としやすい。

【5】概念データモデルはどの工程で使われて、どんな役割の人が担当すべきなのか?

講演では明示的な説明がなかったように思うが、常識で考えると、企画フェーズや要件定義で概念データモデルが作られる。
担当者はアーキテクトのレベルの人になるだろう。

作られた概念データモデルの粒度は、講演で紹介された粒度ならば、エンティティ名だけでかなり曖昧。
渡辺さん式データモデルの粒度なら、論理モデルまで落とし込む必要がある。
その場合、そこからすぐに実装モデルに置き換えられるから、ローコード開発ツールを使うことを前提にしているだろう

最近はデータモデリングから離れていたので、講演を聞いてすごくワクワクしながら聞いていた。
改めて、データモデリングのテクニックを自分なりに整理してみたいと思う。

| | コメント (0)

より以前の記事一覧