GLATTS勉強会ブログ

参加者 青木（読み手）、沼田、今井（記）

範囲 pp.183-195

第2部 ソフトウェアアークテクチャのプロセス

13 アーキテクチャ記述を作成する

• 13.3 ISO標準
  • p.183 13.3 l.2
    行末の ‘-‘ は衍字?
• 13.4 アーキテクチャ記述の内容
  • 13.4.1 文書管理
  • 13.4.2 目次
  • 13.4.3 概論と経営陣向け要約
  • 13.4.4 ステークホルダ
  • 13.4.5 一般的なアーキテクチャ原理
  • 13.4.6 アーキテクチャ上の設計判断
  • 13.4.7 ビューポイント
  • 13.4.8 ビュー
  • 13.4.9 品質特性の要約
  • 13.4.10 重要なシナリオ
  • 13.4.11 決定待ちの課題
  • 13.4.12 付録
• 13.5 アーキテクチャ記述を提示する
• 13.6 チェックリスト
• 13.7 ようやく
• 13.8 参考文献

14 アーキテクチャを評価する

• 14.1 なぜ、アーキテクチャを評価するのか?

参加者 今井（読み手）、青木、沼田（記）
範囲 pp.171 – 183

第2部 ソフトウェアアークテクチャのプロセス

12 アーキテクチャモデルの製作

• 12.5 アジャイルチームとのモデル化
  • p.172 l.1
    そうれすれば…（衍字）
• 12.6 チェックリスト
• 3つ目の■
  「完全」しているか、は「完成」しているか、ということ？
• 最後の□
  箇条書きのレベルが他の項目よりひとつ上なのは何故？定量的モデルでも、他の項目をチェックするのでは？
• 12.7 要約
• 12.8 参考文献

13 アーキテクチャ記述を作成する

• 13.1 効果的なアーキテクチャ記述の特性
  • 13.1.1 正確性
  • 13.1.2 十分性
  • 13.1.3 タイムリー性
    • 戦略の次の段落の3行目
      時間をかけられるもの、とは、時間のかかるもの？
  • 13.1.4 簡潔性
  • 13.1.5 明瞭性
  • 13.1.6 通用性
  • 13.1.7 精密性
• 13.2 用語解説

参加者 沼田（読み手）、今井、青木（記）

範囲 pp.160-171

第2部 ソフトウェアアークテクチャのプロセス

12 アーキテクチャモデルの製作

• 12.2 モデルのタイプ
  • 12.2.1 定性的モデル
  • 12.2.2 定量的モデル
  • 12.2.3 スケッチ
• 12.3 モデリング言語
  • 12.3.1 アーキテクチャ記述言語
    • p.164 l.1 「Acme」→The Acme Projectへのリンク
      同じ名前で米国のアニメに出てくる架空の会社の話題になりました。
  • 12.3.2 統一モデリング言語（UML）
  • 12.3.3 実行可能なドメイン特有言語
  • 12.3.4 その他のモデリング言語
• 12.4 効果的なモデルを作成するための指針
  • 12.4.1 モデルに目的を持たせよ
    • p.166 l.3 「形式さ」意味は分かりますが、使わない表現ですね。
  • 12.4.2 モデルを読者に対応させよ
  • 12.4.3 抽象化は慎重かつ的確にせよ
  • 12.4.4 リスクに従って作業を集中させよ
    • p.167 最下行 「モデルリング」→「モデリング」
  • 12.4.5 説明的な名前を選択せよ
  • 12.4.6 用語を定義せよ
  • 12.4.7 わかりやすくせよ
  • 12.4.8 定義された表記法を使用せよ
  • 12.4.9 暗黙のセマンティクスに注意せよ
  • 12.4.10 モデルの妥当性を確認せよ
  • 12.4.11 モデルを持続せよ

参加者 青木（読み手）、沼田、今井（記）

範囲 pp.150-160

第2部 ソフトウェアアークテクチャのプロセス

11 スタイルとパターンを使用する

• 11.5 アーキテクチャスタイルを使用する利点
• 11.6 スタイルとアーキテクチャ記述
  • p.152 下から5行目～
    “テキストの注解”の「注解」とは？ 後ろに“モデルの注釈”とあるから「注釈」の間違い？
    • 辞書によると注釈と同じらしい。
    • 原書では、”textual commentary and model annotation”になっている。
    • この節の最後の“テキストの注釈”は、原書では”textual notes”.
• 11.7 デザインパターンと言語イディオムを適用する
• 11.8 チェックリスト
• 11.9 要約
• 11.10 参考文献

12 アーキテクチャモデルの製作

• 12.1 モデルが重要な理由

参加者 今井（読み手）、青木、沼田（記）
範囲 pp. 138 – 150

第2部 ソフトウェアアークテクチャのプロセス

10 シナリオを特定して使用する

• 10.6 シナリオを適用する
  • 10.6.3 シミュレーション
  • 10.6.4 プロトタイプ実装テスト
  • 10.6.5 完全なライブテスト
• 10.7 シナリオの有効活用
  • 10.7.1 集中するシナリオセットを特定すること
  • 10.7.2 異なったシナリオを使用すること
  • 10.7.3 シナリオは早期に使用すること
  • 10.7.4 システム品質シナリオの使用を含めること
  • 10.7.5 障害時シナリオの使用を含めること
  • 10.7.6 ステークホルダを緊密に参加させること
• 10.8 チェックリスト
• 10.9 要約
• 10.10 参考文献

11 スタイルとパターンを使用する

• 11.1 デザインパターンを導入する
• 11.2 スタイル、パターン、イディオム
  • 11.2.1 アーキテクチャスタイル
  • 11.2.2 ソフトウェアデザインパターン
  • 11.2.3 言語イディオム
  • 11.2.4 スタイルとパターンおよびイディオムを使用する
• 11.3 パターンとアーキテクチャ戦術
• 11.4 アーキテクチャスタイルの例

参加者 沼田（読み手）、今井、青木（記）

範囲 pp.126-138

第2部 ソフトウェアアークテクチャのプロセス

9 ステークホルダを特定して参加させる

• 9.6 ステークホルダの責務
• 9.7 チェックリスト
• 9.8 要約
• 9.9 参考文献

10 シナリオを特定して使用する

• 10.1 シナリオのタイプ
• 10.2 シナリオの用途
• 10.3 シナリオを特定して優先順位を付ける
• 10.4 シナリオをとらえる
  • p.133 例10.1の１行目「作るステム」→「作るシステム」
• 10.5 何が良いシナリオを構成するか
• 10.6 シナリオを適用する
  • 10.6.1 紙のモデル
  • 10.6.2 ウォークスルー

参加者 青木（読み手）、沼田、今井（記）

範囲 pp.114-126

第2部 ソフトウェアアークテクチャのプロセス

8 関心事、原理、決定

• 8.8 チェックリスト
  • p.114 8.8 6項目目 誤字
    スコープは、簡潔性を明瞭性および網羅性と → スコープは、簡潔性と明瞭性および網羅性と
    簡潔性 対 (明瞭性、網羅性) と言いたいのであれば「を」でいいのかも。
• 8.9 要約
• 8.10 参考文献

9 ステークホルダを特定して参加させる

• 9.1 ステークホルダの選出
• 9.2 ステークホルダのクラス
  • 9.2.1 取得者
  • 9.2.2 評価者
  • 9.2.3 コミュニケータ
  • 9.2.4 開発者
  • 9.2.5 保守管理者
  • 9.2.6 製作エンジニア
    • p.121
      開発者との違いは？
      → 開発者はシステム構築、配置。製作エンジニアはシステム構築などを行う、環境の設計、配置、管理。
  • 9.2.7 供給者
  • 9.2.8 支援スタッフ
  • 9.2.9 システム管理責任者
  • 9.2.10 テスタ
  • 9.2.11 ユーザ
• 9.3 実例
• 9.3.1 既製パッケージの配置プロジェクト
• 9.3.2 ソフトウェア製品開発プロジェクト
• 9.3.3 提携開発
• 9.4 代理ステークホルダ
• 9.5 ステークホルダグループ

参加者 今井（読み手）、青木、沼田（記）
範囲 pp. 104 – 114

第2部 ソフトウェアアークテクチャのプロセス

8 関心事、原理、決定

• 8.4 妥当な関心事とは
• 8.5 アーキテクチャ原理
  • 8.5.1 優れた原理とは
  • 8.5.2 独自の原理を定義する
• 8.6 アーキテクチャ上の判断
  • 8.6.1 アーキテクチャ上で重大な判断
• 8.7 原理を使って関心事と判断を結び付ける