Software Architectureとは?

+4

No comments posted yet

Comments

Slide 1

Software Architectureとは? 2015/01/31 MVP Community Camp 東京会場 尾上 雅則

Slide 2

今回のセッションのスタイル Software Architecture は Infra Architectureなどと同じく System Architectureのサブセットです。 Architecture本来の意味、意義に則って説明していきますが説明時の例はSoftware Architecture固有のものばかりになります。

Slide 3

0.Agenda 自己紹介 Architectureとは? 何故Architectureが気にされるのか? Architecture設計が難しい理由 再考)Architectureとは? Architecture設計の手段 まとめ

Slide 4

1.自己紹介 ・尾上 雅則 (おのうえ まさのり) 31歳 Lifebear.inc CTO Microsot MVP for Visual C#(2012/7~2015/6) Twitter : @ugaya40 フリーランス9年 → ソーシャルゲーム会社 → 現職 C#er WPF4/4.5 MVVM Infrastructure Livet - Author http://ugaya40.hateblo.jp/entry/Livet

Slide 5

2.Architectureとは? Architectureの概要を俯瞰してみる

Slide 6

Architectureとは? IEEE 1471 [ソフトウエア集約システムのアーキテクチャ記述のための推奨指針] アーキテクチャは一つのシステムには必ず一つだけ存在する。 アーキテクチャは一つまたは複数のアーキテクチャ記述であらわされる アーキテクチャ記述は「ステークホルダーの関心ごとに対応するViewPoint(視点)」と「ViewPointをシステムに適用したView」で構成される。 アーキテクチャは「本質的に多面的Viewである」ため、すべてのステークホルダーの関心ごとをとらえた一つのViewが存在することはできない(表せない ・・・普通これ読んでもよくわからないですよね?

Slide 7

Architectureとは? Structure vs Architecture 日本語では単純に「構造」とどちらも訳されがち Structure まさに構造そのもの。ソフトウェアの文脈ではコード成果物 Architecture その構造(Structure)と、その構造(Structure)に至った目的・思想・ルールを内包する

Slide 8

3.何故Architectureが気にされるのか? Architectureを意識することは何を目的としているのか?

Slide 9

ソフトウェア開発の特性 ソフトウェア開発は人間が無手で挑むには複雑すぎる行為 ソフトウェア開発成果物には、いわゆる機能要件と別に「品質(品質特性)」が存在する

Slide 10

品質(品質特性)の例 保守性 無理そうな機能追加がなんとかなってしまうコードベース + ルール ⇔ 簡単なはずの機能追加がいつも事故ってしまうコードベース 役割分担しやすいコードベース ⇔ 職人(属人性の高すぎる人)を生み出しやすいコードベース 見積もりが短くなり機能するコード ⇔ 見積もりが長くなり、事故り、さらに見積もりが長くなるコード

Slide 11

品質(品質特性)の例 他にも例えばISO 9126参照(僕は好きじゃないけど) 要求エンジニアリング入門 第3回 -前田卓雄さんより抜粋 - http://jibun.atmarkit.co.jp/club/print/print.php?url=/lskill01/rensai/req/03/03.html

Slide 12

ソフトウェア開発の特性 「品質(品質特性)」にはISO9126で定義されているようなものだけではなく、実装にかかる時間なども含みます。 まったく同じ「機能要件」を満たしたシステム同士でも生じるこれらの「品質(品質特性)」の差 同じ機能要件を満たしているStructure(構造)に発生する「品質(品質特性)」の差 満たしたい品質特性をどうやって満たすか?これこそがアーキテクチャを意識する動機です。 しかし意識したところでそれを設計し、形にしてメリットを享受するのはすごく難しい アーキテクチャはそもそも非機能要件だとか言われる品質特性に強く寄ったものなのです。

Slide 13

4.Architecture設計が難しい理由 Architectureを意識してメリットを享受するのは何が難しいのか?

Slide 14

シンプルに言えば・・ そもそもゴールがどこか分からないから そしてゴールを定めても行き方がわからないから 下は総合的な技術力で対処できる

Slide 15

品質特性はあくまでも結果 例えば「保守性」を十分に確保する。それどうやるの? オブジェクト指向? 関数型? DRY原則? じゃあそれを意識してどうなったら「保守性」は満たされたと判断できるの? そもそも明確なゴールテープがあるものではない。より遠くに辿りつける場合があるだけ。 そして品質特性同士は時に相反します

Slide 16

シンプルな品質の相反 確実に安全性のために使用性を損なわなければならなくなっていますよね? 品質特性は多くの場合プライオリティ付けが重要になってきます しかしそのプライオリティは簡単には定まりません

Slide 17

品質特性のプライオリティに影響があるもの(1) ・例えば「実装時間効率性 vs 正確性」 どちらも開発者には一般的に重要で両立が常に課題だが ソーシャルゲーム屋さん スピードがそのまま競争力だから圧倒的に「実装時間効率性」重視 メーカー系Sier メーカーに依頼するお客さんの求めるもの、メーカーの名前から来る安心感こそが競争力だから圧倒的に「正確性」重視 ビジネスの形は品質特性のプライオリティに影響を与える

Slide 18

品質特性のプライオリティに影響があるもの(2) それぞれの関心事は? エンドユーザー 直感的かつ正しい動作、パフォーマンス、信頼性、ユーザビリティ、可用性、およびセキュリティ 開発者 必須要件とシンプルかつ首尾一貫したデザインアプローチ、実装・修正の容易さとスピード

Slide 19

品質特性のプライオリティに影響があるもの(2) それぞれの関心事は? プロジェクトマネージャー プロジェクトをトラッキングするに当たっての予測可能性、スケジュール、リソースの生産的利用、および予算 マーケティング担当者 競争力の高い機能、製品化に要する時間、他の製品との位置付け、およびコスト ステークホルダーごとに実は品質特性の関心と要求項目が異なる

Slide 20

同じ方向を向けないステークホルダー達 同じ機能追加に対して 見積もりが短くなるコード(保守性が高いコード) ⇔ 見積もりが長くなるコード(保守性が低いコード) 開発者にとっても、BtoCのビジネスサイドや経営者にとっては常に「見積もりが短くなる方」が正 じゃあメーカー系SIerの収益源と競争力ってなんでしたっけ?彼らには本当はどちらが正しいんでしょう?

Slide 21

同じ方向を向けないステークホルダー達 完璧にレールに乗ったコード 開発者以外にとっては常に正 正確性が高く、見積もりはいつも健全に機能し、予測不可能状態は注意深く回避されている。工学的にも理想的な状態。 でも開発者にとっては悪いとは言わないが刺身タンポポ感。将来的には優秀な開発者を失う理由になりうる

Slide 22

品質特性のプライオリティを左右するもの エンドユーザー要求 ビジネス・組織の形 開発サイドのステークホルダーの関心事 ステークホルダー同士の影響力・力関係 そもそもエンドユーザーもビジネス・組織の形もステークホルダーと言えるので・・

Slide 23

品質特性のプライオリティを左右するもの ステークホルダーの関心事 ステークホルダー同士の影響力・力関係 つまり、、

Slide 24

品質特性のプライオリティを左右するもの つまりステークホルダー同士の品質特性への要求プライオリティの違いと対立こそが、アーキテクチャ設計のゴールの方向決めを難しくしています。

Slide 25

理想のアーキテクト像 全てのステークホルダー(組織・業界・ビジネス部門・チームのメンバー・お客様もろもろ)ごとに異なる要求と品質特性のプライオリティのバランスをとったアーキテクチャの設計を行い、実現可能な形に落とし込む事。 そりゃ難しくて当然です

Slide 26

アーキテクトに求められる事 自らを開発者という枠組みの中にネガティブに閉じ込めようとしている人には決してできない芸当 上流工程が一番偉いぜ、下流なんか知らないぜって人にも決してできない芸当 となると理想的なアーキテクトとは・・・

Slide 27

アーキテクトに求められる事 全てのステークホルダーごとに異なる要求と品質特性のプライオリティのバランスを取り そのアーキテクチャのゴールを高い技術力で実現し(後述)、 結果認められその位置にとどまり続ける事が出きる人 しかし、

Slide 28

アーキテクトに求められる事 しかし決して全てのステークホルダーに決して満点の評価は受けないであろう、報われない人

Slide 29

ここまでのまとめ ArchitectureはStructureと異なり、その構造にいたる目的・思想・ルールを内包する Architectureは品質特性(非機能要件)に強く寄った概念 品質特性は様々なステークホルダーにとって要求優先度が異なり、時には対立する。それに落としどころを付けることで初めてArchitecture設計のゴールが見える IEEE1471に戻ってみましょう

Slide 30

5.再考)Architectureとは? IEEE1471から振り返る

Slide 31

IEEE 1471 [ソフトウエア集約システムのアーキテクチャ記述のための推奨指針] アーキテクチャは一つのシステムには必ず一つだけ存在する。 アーキテクチャは一つまたは複数のアーキテクチャ記述であらわされる アーキテクチャ記述は「ステークホルダーの関心ごとに対応するViewPoint(視点)」と「ViewPointをシステムに適用したView」で構成される。 アーキテクチャは「本質的に多面的Viewである」ため、すべてのステークホルダーの関心ごとをとらえた一つのViewが存在することはできない(表せない

Slide 32

IEEE 1471 (1) アーキテクチャは一つのシステムには必ず一つだけ存在する。 そのStructureに至った目的・思想・ルールを包括してArchitectureというので、Architectureの定義からくるルールですね、これ。シンプル。

Slide 33

IEEE 1471 (2) アーキテクチャは一つまたは複数のアーキテクチャ記述であらわされる

Slide 34

IEEE 1471 (3) – ViewPointとView アーキテクチャ記述は「ステークホルダーの関心ごとに対応するViewPoint(視点)」と「ViewPointをシステムに適用したView」で構成される。

Slide 35

IEEE 1471 (3) – ViewPointとViewの例 プロジェクトマネージャーの例 関心事 : 「プロジェクトをトラッキングするに当たっての予測可能性、スケジュール、リソースの生産的利用、および予算に関心がある」 関心事から生まれた今回の要求 : 分散拠点開発だからクリティカルパスを見える化し、減らしたい(ViewPoint) クリティカルパス法に可視化と整理の結果並列実装可能な設計を要請(Viewとその適用結果)

Slide 36

IEEE 1471 (3) – ViewPointとViewの例 クリティカルパス法 Wikipedia – クリティカルパス法より抜粋

Slide 37

IEEE 1471 (3) – ViewPointとViewの例 開発者の例 関心事 : 「必須要件とシンプルかつ首尾一貫したデザインアプローチと、修正の容易さに関心がある」 関心事から生まれた今回の要求 : できる限りトランザクションが入れ子にならないようにデータアクセス部分を注意深く共通化したい(ViewPoint) CRUD図を利用した共通化整理とその結果(Viewとその適用結果)

Slide 38

IEEE 1471 (3) – ViewPointとViewの例 CRUD図 What is CRUD Matrix?– http://www.isanalisti.net/2011/10/what-is-crud-matrix/より抜粋

Slide 39

IEEE 1471 (4) アーキテクチャは「本質的に多面的Viewである」ため、すべてのステークホルダーの関心ごとをとらえた一つのViewが存在することはできない(表せない

Slide 40

IEEE 1471 (4) プロマネと開発者の例から結局できた構造は・・

Slide 41

IEEE 1471 (4) リポジトリパターン

Slide 42

IEEE 1471 (4) プロマネと開発者の例から結局できた構造は・・ 同じ成果物なのに別々の意図が反映されている DBはリポジトリパターンによるアクセス(DB設計の遅れをクリティカルパスにしないために) しかし各リポジトリのクラス分割単位には開発者がトランザクションが入れ子にならないように注意深く精査した結果になっている。 プロジェクトマネージャーの関心事も開発者の関心事も含めた一つのViewは存在できないのがわかる。あるのはコードだけで、それはArchitecture記述ではなくStructureである

Slide 43

IEEE 1471 (4) その成果物のコードだけを見ても、この場合にリポジトリパターンを適用するメリットがわからないし、また多くの場合クラスの分割単位に隠された意図も理解できない コードからアーキテクチャは見えない

Slide 44

IEEE 1471 StructureはArchitectureの影 構造そのものに至る目的・思想・ルールを包括するものだからStructureはその背景にあるArchitectureに対してある程度必然性がある これが何を表すかというかと コードを書く前のいわゆる設計書はアーキテクチャ記述である(ViewPointがあってからのViewである) コードから起こした設計書は、ただの構造分析書であり、それはアーキテクチャ記述ではない

Slide 45

ここまでのまとめ ArchitectureはStructureと異なり、その構造にいたる目的・思想・ルールを内包する Architectureは品質特性(非機能要件)に強く寄った概念 品質特性は様々なステークホルダーにとって要求優先度が異なり、時には対立する。それに落としどころを付けることで初めてArchitecture設計のゴールが見える

Slide 46

ここまでのまとめ しかしArchitectureそのものを表す手段はなく、アーキテクチャ記述の集合という形でしか定義できない アーキテクチャ記述は、各ステークホルダーの関心事からくる欲求をViewPointとし、それをViewに落としたものである。 アーキテクチャ記述はStructureから推察することはできない。

Slide 47

6.Architecture設計の手段 複雑なArchitecture設計と戦うための武器とは?

Slide 48

Architecture設計の手順 品質特性の整理・プライオリティの設計 (ゴールの設定) それに基づいた関心ごとの分離の繰り返し そしてSoftwareArchitectureの場合はそれを支える プログラミング言語・パラダイムへの理解と知識 各実装要素技術への細やかな知識・あるいは知識へのインデックス Architecture Pattern/Structure Patternについての知識 によってより遠くの存在しないゴールテープまでたどり着けるようになる

Slide 49

6-1.品質特性の整理 様々なステークホルダーに対応する様々な視点から導き出される、 品質特性のプライオリティに落としどころを付ける プライオリティ付けに必要な一覧は慣れないうちは、足りないものではあるがIOS9126とか使うのもいいかもしんない

Slide 50

6-1.品質特性の整理 ステークホルダーに重みの違いがあることに注意! 例えば、ビジネス的な視点から満たされるべき品質特性は絶対に最大優先度で無視できない

Slide 51

6-1.品質特性の整理 何かの品質特性がゼロではそもそもそのシステムの価値がなくなることが多い

Slide 52

6-1.品質特性の整理 アーキテクチャ設計の責任者(いわゆるアーキテクト)こそは、まずはこのバランスを決定的に取る必要がある。 以降はそれを指針として、様々な手段や要素技術が持つ様々なメリット・デメリットの重みづけをさばいていく。

Slide 53

6-2.関心事の分離 – ゴールに向かう手段 「関心事の分離」とは複雑さへのアプローチ 複雑 – 「物事の事情や関係がこみいっていること。入り組んでいて、簡単に理解・説明できないこと。一面的ではないこと。また、そのさま。」 デジタル大辞泉 http://kotobank.jp/word/%E8%A4%87%E9%9B%91 ソリューションは当たり前の事だけれども整理・細分化 ソフトウェア工学に限らず、他の工学分野でも重要な設計思想とされている

Slide 54

6-2.関心事の分離 – ゴールに向かう手段 「関心事の分離」は容易に手でもてあそべるサイズになるまで繰り返す 対象のアプリケーションが十分小さかったり単純ならば 関心事の分離を行う動機がありません。 アプリケーション アプリケーション

Slide 55

6-2.関心事の分離 – ゴールに向かう手段 アプリケーションにはいろいろな形(要件・要求)があるので「関心事の分離」を行った後の分離された数・形は当然それぞれ異なるもの。 アプリケーション アプリケーション アプリケーション

Slide 56

6-2.関心事の分離 – ゴールに向かう手段 関心事の分離には設計パターン、特にArchitecturePatternと呼ばれるものが有用です

Slide 57

6-2.関心事の分離 – ArchitecurePattern アプリケーション Presentation MVC系 Repository Repository Pattern

Slide 58

6-2.関心事の分離 – ArchitecurePattern アプリケーション Presentation MVC系 Repository Repository Pattern 例えばこんな分割、どこがArchitecturePatternといわれる部分でしょうか?

Slide 59

6-2.関心事の分離 – ArchitecurePattern オレンジ色の矢印で示された一刀一刀、関心事を分離する視点そのものがいわゆるArchitecture Patternです。切った(分離した)結果が設計パターンではないのです。 アプリケーション Presentation Repository

Slide 60

6-2.関心事の分離 – ゴールに向かう手段 ViewPointとViewのセットであるアーキテクチャ記述の集合としてのアーキテクチャ。視点の反映の集合であるアーキテクチャ。 その視点に則って、その視点を実現するために切っていくパターンをArchitecture Patternと呼ぶのは自然な話です。 GoFのデザインパターンなどはStructure Patternとでも呼ぶべきもので構造自体を定義しています。毎回同じ形を目指すもので、分解後の形が毎回異なる=視点こそがパターンであるArchitecture Patternとは異なるものだと考えています。

Slide 61

6-2.関心事の分離 – ゴールに向かう手段 分離していった欠片は、その欠片に期待されている「役割」を持つ場合があり、そしてまたシステム全体の品質特性のプライオリティと紐づいている。そこに要素技術をあてはめていく。 この考え方が シンプルで単機能なDBアクセス⇔複雑で多機能なアクセス みたいな一見対立軸にありどちらにもデメリットを主張できるものに決定を下す時に明確な基準を与えます

Slide 62

アーキテクチャ設計の手段まとめ 品質特性の整理・プライオリティの設計 (ゴールの設定) それに基づいた関心ごとの分離の繰り返し そしてSoftwareArchitectureの場合はそれを支える プログラミング言語・パラダイムへの理解と知識 各実装要素技術への細やかな知識・あるいは知識へのインデックス Architecture Pattern/Structure Patternについての知識

Slide 63

まとめ

Slide 64

Architectureとは? ArchitectureはStructureと異なり、その構造にいたる目的・思想・ルールを内包する Architectureは品質特性(非機能要件)に強く寄った概念 しかしArchitectureそのものを表す手段はなく、アーキテクチャ記述の集合という形でしか定義できない アーキテクチャ記述は、各ステークホルダーの関心事からくる欲求をViewPointとし、それをViewに落としたものである。 アーキテクチャ記述はStructureから推察することはできない。

Slide 65

Architecture設計のゴールの策定 品質特性は様々なステークホルダーにとって要求優先度が異なり、時には対立する。それに落としどころを付けることで初めてArchitecture設計のゴールが見える

Slide 66

Architectに求められる事 全てのステークホルダー(組織・業界・ビジネス部門・チームのメンバー・お客様もろもろ)ごとに異なる要求と品質特性のプライオリティのバランスをとったアーキテクチャの設計を行い、実現可能な形に落とし込む事。

Slide 67

Architecture設計の手段 品質特性の整理・プライオリティの設計 (ゴールの設定) それに基づいた関心ごとの分離の繰り返し そしてSoftwareArchitectureの場合はそれを支える プログラミング言語・パラダイムへの理解と知識 各実装要素技術への細やかな知識・あるいは知識へのインデックス Architecture Pattern/Structure Patternについての知識

Slide 68

ご清聴ありがとうございました!

Summary: MVP Community Camp 2015 東京会場

Tags: architecture

URL: