Monthly Archives: 7月 2015

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

Posted on by 0 comment

参加者 今井(読み手)、青木、沼田(記)
範囲 pp.521 – 537(p537は表30-3のみ)

第4部 パースペクティブカタログ

29 その他のパースペクティブ

  • 29.5 規則パースペクティブ
    • 29.5.5 問題と落とし穴
    • 29.5.6 チェックリスト
    • 29.5.7 参考文献
  • 29.6 使用性パースペクティブ
    • 29.6.1 ビューの適用可能性
    • 29.6.2 関心事
    • 29.6.3 アクティビティ:使用性パースペクティブを適用する
    • 29.6.4 アーキテクチャ戦術
    • 29.6.5 問題と落とし穴
    • 29.6.6 チェックリスト
    • 29.6.7 参考文献

第5部 すべてを1つにまとめる

30 ソフトウェアアーキテクトとして仕事をする

  • 30.1 プロジェクトライフサイクルにおけるアーキテクチャ
    • 30.1.1 小規模で低リスクのプロジェクトにおけるアーキテクチャ
    • 30.1.2 アジャイルプロジェクトにおけるアーキテクチャ
    • 30.1.3 計画駆動プロジェクトにおけるアーキテクチャ

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

Posted on by 0 comment

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

範囲 pp.510-521

第4部 パースペクティブカタログ

  • 29.3 国際化パースペクティブ
    • 29.3.1 ビューの適用可能性
    • 29.3.2 関心事
      • Unicodeは2バイト文字のセットではありません。例えばUTF-8の場合は最大1文字6バイトになります。
    • 29.3.3 アクティビティ:国際化パースペクティブを適用する
    • 29.3.4 アーキテクチャ戦術
      • 英語キーボードでもOSが対応していれば漢字入力はできます。
    • 29.3.5 問題と落とし穴
    • 29.3.6 チェックリスト
    • 29.3.7 参考文献
  • 29.4 配置場所パースペクティブ
    • 29.4.1 ビューの適用可能性
    • 29.4.2 関心事
    • 29.4.3 アクティビティ:配置場所パースペクティブを適用する
    • 29.4.4 アーキテクチャ戦術
    • 29.4.5 問題と落とし穴
    • 29.4.6 チェックリスト
    • 29.3.7 参考文献
  • 29.5 規則パースペクティブ
    • 29.5.1 ビューの適用可能性
    • 29.5.2 関心事
      • 医療行為で使用したレントゲンはフィルムでの保存が義務づけられているようです。
      • マイクロフィッシュ→コトバンクへのリンク
    • 29.5.3 アクティビティ:規則パースペクティブを適用する
    • 29.5.4 アーキテクチャ戦術

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

Posted on by 0 comment

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

範囲 pp.502-510

第4部 パースペクティブカタログ

29 その他のパースペクティブ

  • 29.1 アクセシビリティパースペクティブ
    • 29.1.3 アクティビティ:アクセシビリティパースペクティブを適用する
    • 29.1.4 アーキテクチャ戦術
    • 29.1.5 問題と落とし穴
    • 29.1.6 チェックリスト
    • 29.1.7 参考文献
  • 29.2 開発リソースパースペクティブ
    • 29.2.1 ビューの適用可能性
    • 29.2.2 関心事
    • 29.2.3 アクティビティ:開発リソースパースペクティブを適用する
    • 29.2.4 アーキテクチャ戦術
    • 29.2.5 問題と落とし穴
      • p.508 item 7
        例として挙げられている「生産的作業が可能なのは週最大約4日」は、一日8時間のうち、生産的作業は6.4時間くらいだという場合の例だろうか。
    • 29.2.6 チェックリスト
    • 29.2.7 参考文献
  • 29.3 国際化パースペクティブ

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

Posted on by 0 comment

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

第4部 パースペクティブカタログ

28 発展性パースペクティブ

  • 28.4 アーキテクチャ戦術
    • 28.4.5 ソフトウェアへのバリエーションポイント組み込み
    • 28.4.6 標準の拡張ポイントの使用
    • 28.4.7 信頼できる変更の実現
    • 28.4.8 開発環境の保存
  • 28.5 問題と落とし穴
    • 28.5.1 誤った次元の優先順位づけ
    • 28.5.2 決して起こらない変更
    • 28.5.3 重要な品質特性に対する発展性の影響
    • 28.5.4 特定のハードウェアやソフトウェアに対する過大な依存
    • 28.5.5 失われた開発環境
    • 28.5.6 その場しのぎのリリース管理
  • 28.6 チェックリスト
    • 28.6.1 要求把握のためのチェックリスト
    • 28.6.2 アーキテクチャ定義のためのチェックリスト
  • 28.7 参考文献

29 その他のパースペクティブ

  • 29.1 アクセシビリティパースペクティブ
    • 29.1.1 ビューの適用可能性
    • 29.1.2 関心事

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

Posted on by 0 comment

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

範囲 pp.479-490

第4部 パースペクティブカタログ

28 発展性パスペクティブ

  • 28.1 ビューの適用可能性
  • 28.2 関心事
    • 28.2.1 製品管理
    • 28.2.2 変更の規模
    • 28.2.3 変更の次元
    • 28.2.4 変更の可能性
    • 28.2.5 変更の時間的尺度
    • 28.2.6 変更の対価を払う時期
    • 28.2.7 外部要因がもたらす変更
    • 28.2.8 開発の複雑さ
    • 28.2.9 知識の保存
    • 28.2.10 変更の信頼性
  • 28.3 アクティビティ:発展性パースペクティブを適用する
    • 28.3.1 発展性ニーズの特徴づけ
      • p.485 l.10 誤字?
        必要労力初期システム開発労力の → 必要労力初期システム開発労力の
    • 28.3.2 現在の発展性容易度評価
    • 28.3.3 発展性トレードオフの検討
    • 28.3.4 アーキテクチャの再作成
  • 28.4 アーキテクチャ戦術
    • 28.4.1 変更の阻止
    • 28.4.2 拡張可能なインタフェースの作成
      • p.488 item1あたり
        Javaであれば従来の個別引数は残しておいて、必要になれば追加引数をもった関数や、Employeeを引数にした関数をオーバーロードすれば、既存の部分は変更しなくてもすむし、IDEをつかえば比較的容易に変更もできると思う。
    • 28.4.3 変更を容易にする設計テクニックの適用
    • 28.4.4 メタモデルベースのアーキテクチャスタイル適用

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

Posted on by 0 comment

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

第4部 パースペクティブカタログ

27 可用性とレジリエンスパースペクティブ

  • 27.4 アーキテクチャ戦術
    • 27.4.5 フォールトトレラントソフトウェアの選択または作成
    • 27.4.6 障害に備えた設計
    • 27.4.7 コンポーネント複製の許容
    • 27.4.8 トランザクションの整合性緩和
    • 27.4.9 バックアップと災害回復の解決策識別
  • 27.5 問題と落とし穴
    • 27.5.1 単一の故障個所
    • 27.5.2 カスケード障害
    • 27.5.3 過負荷による使用不可
    • 27.5.4 野心的すぎる可用性要求
    • 27.5.5 効果のないエラー検出
    • 27.5.6 コンポーネントレジリエンスの課題見積り
      • p.474 この節の1行目
        レジリエントでは?(衍字)
    • 27.5.7 見過ごされるグローバルな可用性要求
    • 27.5.8 互換性のないテクノロジー
  • 27.6 チェックリスト
    • 27.6.1 要求把握のためのチェックリスト
    • 27.6.2 アーキテクチャ定義のためのチェックリスト
  • 27.7 参考文献

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

Posted on by 0 comment

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

範囲 pp.458-467

第4部 パースペクティブカタログ

27 可用性とレジリエンスパースペクティブ

  • 27.3 アクティビティ:可用性とレジリエンスパースペクティブを適用する
    • 27.3.3 プラットフォーム可用性の見積り
      • p.458 「MTBF=経過時間÷故障回数」とあるが、分子に修理時間は含まれないので「MTBF=稼働時間÷故障回数」が適切。
    • 27.3.4 機能的可用性の見積り
    • 27.3.5 要求に対しての評価
    • 27.3.6 戦術を適用したアーキテクチャ再作成
  • 27.4 アーキテクチャ戦術
    • 27.4.1 フォールトトレラントハードウェアの選択
      • p.465 l.1 「単一ディスク障害(RAID5の場合) または複数ドライブ障害(」とあるが、ディスクとドライブは同じ意で使用しているのか?
    • 27.4.2 高可用性クラスタ化とロードバランシングの使用
    • 27.4.3 トランザクションの記録
    • 27.4.4 ソフトウェア可用性解決策の適用

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

Posted on by 0 comment

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

範囲 pp.447-458

第4部 パースペクティブカタログ

26 パフォーマンスとスケーラビリティパースペクティブ

  • 26.5 問題と落とし穴
    • 26.5.10 不注意なリソースの割り当て
    • 26.5.11 ネットワーク起動とプロセス内起動の相違無視
  • 26.6 チェックリスト
    • 26.6.1 要求把握のためのチェックリスト
      • p.448 26.6.1 最後 脱字
        コンテキス → コンテキス
    • 26.6.2 アーキテクチャ定義のためのチェックリスト
  • 26.7 参考文献

27 可用性とレジリエンスパースペクティブ

  • 27.1 ビューの適用可能性
  • 27.2 関心事
    • 27.2.1 サービスのクラス
    • 27.2.2 計画停止時間
    • 27.2.3 計画外の停止時間
    • 27.2.4 修理の時間
    • 27.2.5 災害回復
  • 27.3 アクティビティ:可用性とレジリエンスパースペクティブを適用する
    • 27.3.1 可用性要求の把握
    • 27.3.2 可用性スケジュールの作成
      • p.457 図27-2
        オンラインサービスは3行にわけ、報告書作成サービスは1行で表現しているのは何か意味があるのか?