Monthly Archives: 3月 2015

「ソフトウェアシステムアーキテクチャ構築の原理 第2版」第17回(3/31)

Posted on by 0 comment

参加者 青木(読み手)、沼田、今井(記)

範囲 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 なぜ、アーキテクチャを評価するのか?

「ソフトウェアシステムアーキテクチャ構築の原理 第2版」第16回(3/24)

Posted on by 0 comment

参加者 今井(読み手)、青木、沼田(記)
範囲 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 用語解説

「ソフトウェアシステムアーキテクチャ構築の原理 第2版」第15回(3/20)

Posted on by 0 comment

参加者 沼田(読み手)、今井、青木(記)

範囲 pp.160-171

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

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

  • 12.2 モデルのタイプ
    • 12.2.1 定性的モデル
    • 12.2.2 定量的モデル
    • 12.2.3 スケッチ
  • 12.3 モデリング言語
    • 12.3.1 アーキテクチャ記述言語
    • 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 モデルを持続せよ

「ソフトウェアシステムアーキテクチャ構築の原理 第2版」第14回(3/17)

Posted on by 0 comment

参加者 青木(読み手)、沼田、今井(記)

範囲 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 モデルが重要な理由

「ソフトウェアシステムアーキテクチャ構築の原理 第2版」第13回(3/13)

Posted on by 0 comment

参加者 今井(読み手)、青木、沼田(記)
範囲 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 アーキテクチャスタイルの例

「ソフトウェアシステムアーキテクチャ構築の原理 第2版」第12回(3/10)

Posted on by 0 comment

参加者 沼田(読み手)、今井、青木(記)

範囲 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の1行目「作るステム」→「作るシステム」
  • 10.5 何が良いシナリオを構成するか
  • 10.6 シナリオを適用する
    • 10.6.1 紙のモデル
    • 10.6.2 ウォークスルー

「ソフトウェアシステムアーキテクチャ構築の原理 第2版」第11回(3/6)

Posted on by 0 comment

参加者 青木(読み手)、沼田、今井(記)

範囲 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 ステークホルダグループ

「ソフトウェアシステムアーキテクチャ構築の原理 第2版」第10回(3/3)

Posted on by 0 comment

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

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

8 関心事、原理、決定

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