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

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

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

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

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

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

@hiranabe さん記事を理解したうえで「ビューとビューポイントの違いは何？」の意見に対する私なりの回答は以下の通り。 ・ビュー＝ステークホルダーの横断的関心事をシステム観点で記述した内容。 ・ビューポイント＝横断的関心事。ユーザ観点。 ・パースペクティブ＝主に非機能要求。システム観点。

— akipii (@akipii) May 6, 2024

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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