比較的読みやすい英語だったこともあってここまでは英語で読んできたけど、
本格的に時間がないしかといって読むものを減らしたくないのでやむなく日本語で読むことにした。
今日の記事の中にある引用は全てこの書籍の5章から。
要求といえば、機能要求と非機能要求。
これは広く一般的に知られていることだと思う。
ただ、読み進めていくと、もう少し違う分類の仕方をしよう、と提案している。
アーキテクチャ上重要な要求（Architecturally Significant Requirement：ASR）とは、アーキテクチャ構造の選択に強く影響する要求のことをいう。ASRを明らかにするのは、ソフトウェアアーキテクトの責任だ。これを行うには、次の4つの要求分類について考える必要がある。
制約
変更できない設計判断。通常は与えられるものだが、選択することもある品質特性
システムが特定の状況でどのように動作するかを特徴付ける、外部から観察できる性質。
影響を与える機能要求
アーキテクチャにおいて特別な注意を必要とするフィーチャーや機能。
その他の影響を及ぼすもの
時間、知識、経験、スキル、社内政治、あなた自身の余計なバイアス、そして意思決定を左右するその他すべてのもの。
制約は、一旦決定されてしまうと100%交渉不可能となる。制約を受け入れることに慎重になろう。「やらなければならない」と「やらないという正当な理由がない限りこれをやる」の間には大きな違いがある。
整理してみるとこんな感じ。言いたいこと自体を大きく変えているわけではないけど、少しわかりやすくなってる。
その上で、品質特性は次の3つに分けて考えると良いと言っている。
設計時の性質
修正容易性、保守性、再利用性、テスト容易性、製造容易性・製品化までの時間
実行時の性質
可用性、信頼性、パフォーマンス、スケーラビリティ、セキュリティ
概念上の性質
管理容易性、サポート容易性、簡潔さ、学習容易性
日本語だとピンとこないこともあるので、ここは原著を確認した。
次のように分けている。性質は原著ではPropertiesだったらしい。少し後にも繰り返しで、次のように書いてあった。
Design Time Properties | Runtime Properties | Conceptual Properties |
Modifiability Maintainability Reusability Testability Buildability or Time-to-Market | Availability Reliability Performance Scalability Security | Manageability Supportability Simplicity Teachability |
ソフトウェアアーキテクチャを設計するときには、機能、制約、品質特性を区別したほうがよい。
それぞれの原著での英語は次のとおり。
機能：functionality
制約：constraints
品質特性：quality attributes
特性はAttributesだけど、性質はPropertiesだ。
アーキテクチャーそのものというより英語の話だけど、AttributeとPropertyの概念の違いがまだピンとこないなあ。
さっき触れた、一般的な要求の分類の話についても書籍の中で触れられていた。
なかなか味わい深い。
品質特性は非機能要求だ。しかし、品質特性シナリオ（品質要求）には機能的な部分があるため、この用語を使って説明するのはおかしい。品質特性が非機能要求であるというのが理屈に合うのは、システム運用のコンテキストにおいてだけだ。
無邪気に機能以外だから非機能、と思っていると、どちらの色も持つものがパッと現れて逃してしまったり誤った説明になってしまったりするのね。
この品質特性の話については、より掘り下げてあった。
各シナリオには、他の機能と同じように、刺激と応答という機能的な要素がある。品質特性シナリオは、応答測定を使って応答を確認する点が機能要求とは異なる。正しく応答するだけでは不十分ということだ。システムがどう対応するかも重要だ。
うん、全然ピンとこない。図がある。
まだピンとこない。で、例示があったので一つだけ抜き出してみるとよくわかる。
可用性 RFPデータベースが応答しない場合、システムは障害を記録し、3秒以内に古いデータで応答する必要がある。
つまり、単にブラックボックスでAが来たらB、とすればいいわけじゃない性質が品質要求にはあるんだという話だったのね。
あと、ここはこれまで自分が学習してきた点とは少し書き味が違った。
すべての機能要求は、ソフトウェアシステムの成功に不可欠だ。しかし、システムが持つすべての機能が、必ずしもアーキテクチャの上で重要というわけではない。機能要求がアーキテクチャ上の設計判断を促進するとき、それを影響力のある機能要求（influential functional requirement）と呼ぶ。
同じアーキテクチャ要素内に実装される可能性のある機能要求を探す。たとえば、永続性を必要とする機能は1つの分類に属するが、ユーザー操作を必要とする機能は別の分類に属する。
実装が難しそうな機能要求を探す。これらはアーキテクチャにとって重要なものだ。
価値が高く、優先度の高い機能要求を探す。
まあでも、ある面これは当たり前のことだった。
アーキテクチャーはバランスだなんて話もよく耳にするけれど、ステークホルダー間で持つ要求が相反することはよくあるし、その時のバランスの取り方の一つとして、影響力のある機能要求を優先して対応することになるのは至極当然のことだよね。
まだこの章は読み終えていないけど、かなり読み応えがあるというか、アーキテクチャーかくあるべき、みたいな勉強を多少したことがあると、この本はかなりいいなあ。続きが楽しみだ。
ところで、iPadやMacでiBooksに取り込んだ書籍からコピーすると次のような文章が一緒にコピーされる。
著作権保護の観点だよね。無自覚に著作権違反してしまうことを防ぐ良い取り組みだなあ。
Excerpt From
Design It!
Michael Keeling
This material may be protected by copyright.
引用をもっと適切な形でしたいのだけど、物理的な書籍と違って電子書籍ってページ番号がないしLocation(全体の中の位置)も書籍のReaderによって出方が違うし、そうなると、どの書籍から、まではいいとして、それのどこから、っていうのを示しづらい。
法律面もそうだけど、倫理面として、著者が不快に思わない、著者に敬意を払った引用の仕方が大事だと思ってる。
それが電子書籍の場合、どうしたら実現できるのか、もう少し考えてみないといけないかもしれない。