Monthly Archives: 4月 2015

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

Posted on by 0 comment

参加者 青木(読み手)、沼田(記)
範囲 pp.271 – 280

第3部 ビューポイントカタログ

18 情報ビューポイント

  • 18.1 関心事
    • 18.1.9 情報の整合性
    • 18.1.10 情報品質
    • 18.1.11 タイムリー性と待ち時間(レイテンシ)および寿命
      • p.275 戦略の2つめにある「現在性ウィンドウ」とは?
        情報の賞味期限のようなもの?
    • 18.1.12 アーカイブとデータ保存
    • 18.1.13 ステークホルダの関心事
  • 18.2 モデル
    • 18.2.1 静的情報構造モデル
      • 図18-3の本クラスのメソッド欄の枠線がない
      • 図18-3の出版社クラスのメソッドに「()」がついていない

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

Posted on by 0 comment

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

範囲 pp.261-271

第3部 ビューポイントカタログ

18 情報ビューポイント

  • 18.1 関心事
    • 18.1.1 情報の構造と内容
    • 18.1.2 情報の目的と用途
    • 18.1.3 情報所有権
    • 18.1.4 エンタープライズ所有情報
    • 18.1.5 識別子とマッピング
      • 例18.4の終わりのほうの「兄弟の結果はしばしば別人に割り振られ」という表現が分かりにくい。例えば兄の結果が弟の結果とされてしまうことか?
    • 18.1.6 情報セマンティクスの揮発性
    • 18.1.7 情報ストレージモデル
      • 「ACID」は「あしっど」と読むらしい。
    • 18.1.8 情報フロー

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

Posted on by 0 comment

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

範囲 pp.249-260

第3部 ビューポイントカタログ

17 機能的ビューポイント

  • 17.2 モデル
    • 17.2.1 機能的構造モデル(p.249 下、「要素に責務を割り当てる。」~)
      • p.251 l.1 「混合言語」とは何?
        mixed language. 原書では mixed-language と表記されている。ここでは、異なった言語で開発された各分散システム間のインタフェースを定義する言語として、新しく生じた言語というような意味でしょう。
  • 17.3 問題と落とし穴
    • 17.3.1 定義がお粗末なインタフェース
    • 17.3.2 十分に理解されていない責務
    • 17.3.3 機能要素としてモデル化されたインフラストラクチャ
    • 17.3.4 内容を詰め込み過ぎたビュー
    • 17.3.5 要素定義のない図
    • 17.3.6 複数ステークホルダのニーズの折り合いをつける難しさ
    • 17.3.7 不適切なレベルの詳細
    • 17.3.8 「神の要素」
    • 17.3.9 過剰な依存性
  • 17.4 チェックリスト
  • 17.5 参考文献

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

Posted on by 0 comment

参加者 今井(読み手)、青木、沼田(記)
範囲 pp.241 – 249(要素に責務を割り当てる。の手前まで)

第3部 ビューポイントカタログ

17 機能的ビューポイント

  • 17.2 モデル
    • 17.2.1 機能的構造モデル
      • p.242の最後の2行
        ステレオタイプの表記が<<ではなく_になっているのは対応する文字がなかった?
      • 図17.1
        • 右下のコンポーネント「アラームイニシエータ変量」は「アラームイニシエータ」の間違い?
        • 変量レポートのインタフェースのタグ付き値のはじめの{はおそらくひとつ余分
      • 例17.2
        4つの外部エンティティと記されているが、Stock Inventoryは?と思ったら、図17.3を見ると、既存のものだからexternalとついているが、外部エンティティではなかった。
      • 図17.3
        破線枠内右上は顧客管理インタフェースではなくカタログ管理インタフェースの間違いだろう。

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

Posted on by 0 comment

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

範囲 pp.228-241

第3部 ビューポイントカタログ

16 コンテクストビューポイント

  • 16.2 モデル
    • 16.2.1 コンテクストモデル (p.228 下から2行目から)
    • 16.2.2 相互作用のシナリオ
  • 16.3 問題と落とし穴
    • 16.3.1 欠けているまたは正しくない外部エンティティ
    • 16.3.2 見逃している暗黙の依存性
    • 16.3.3 いい加減または不正確なインタフェース記述
    • 16.3.4 不適切な詳細レベル
    • 16.3.5 スコープのずれ
    • 16.3.6 暗黙または当然と考えられるコンテクストやスコープ
    • 16.3.7 入り組み過ぎている相互作用
    • 16.3.8 専門用語の使い過ぎ
  • 16.4 チェックリスト
  • 16.5 参考文献

17 機能的ビューポイント

  • 17.1 関心事
    • 17.1.1 機能的能力
    • 17.1.2 外部インタフェース
    • 17.1.3 内部構造
    • 17.1.4 機能的設計理念
      • 表17-1の関心事の分離に「モノシリック」とあるが「モノリシック」が正しい。英語ではmonolithic。
    • 17.1.5 ステークホルダの関心事

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

Posted on by 0 comment

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

範囲 pp.219-228

第3部 ビューポイントカタログ

16 コンテクストビューポイント

  • 16.1 関心事
    • 16.1.1 システムスコープと責務
    • 16.1.2 外部エンティティの識別と使用されるサービスおよびデータ
      • p.221 item 5
        「共有メッセージ交換機器」って何?
    • 16.1.3 外部エンティティの性質と特徴
    • 16.1.4 外部インタフェースの識別と責務
    • 16.1.5 外部インタフェースの性質と特徴
    • 16.1.6 その他の外部依存性
      • p.224 図16-1
        この図での実線矢印と破線矢印の違いは何?
    • 16.1.7 システムが環境に与える影響
    • 16.1.8 全体としての完全性と整合性および統一性
  • 16.2 モデル
    • 16.2.1 コンテクストモデル (p.228 下から3行目まで)
      • p.228 図16-2 顧客アクターのノート内
        製品データベースのノートとあわせると
        「ステレオタイプで示した」 → 「ステレオタイプアイコンで示した」
        だろう。

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

Posted on by 0 comment

参加者 今井(読み手)、沼田(記)
範囲 pp.204 – 217

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

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

  • 14.4 ソフトウェアライフサイクルの中での評価
    • 図14-3
      スケルトンシステムが破線のように描かれているのは、開発が進むにつれて実装されていくことを表しているのだろう。
    • p.205 ●プレゼンテーションの説明
      提案アーキテクチャとは?提案するアーキテクチャということ?
  • 14.5 既存システムのアーキテクチャの妥当性を確認する
  • 14.6 評価の結果を記録する
  • 14.7 評価アプローチを選択する
  • 14.8 チェックリスト
    • 表14-1
      プロジェクト環境の規模とリスクが異なる各パターンに提案されている評価アプローチを見ると、稼働するシステムに発展するスケルトンシステムがすべてに含まれている。スケルトンシステムは有効なのだろう。
  • 14.9 要約
  • 14.10 参考文献

第3部 ビューポイントカタログ

15 ビューポイントカタログ概論

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

Posted on by 0 comment

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

範囲 pp.195-204

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

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

  • 14.2 評価のテクニック
    • 14.2.1 プレゼンテーション
    • 14.2.2 フォーマルレビューと構造化ウォークスルー
    • 14.2.3 シナリオ使用による評価
      • p.197-198 ATAM, SAAMは何の略?
        • ATAM: Architecture Trade-off Analysis Method
        • SAAM: Software Architecture Analysis Method
    • 14.2.4 プロトタイプと構想実証システム
      • p.200
        実際、プロトタイプでも見せると、もう出来ていると思われることが多い。プロトタイプとはどういうものか、目的は何か、目的を果たしたら廃棄しなければならないものということ、はっきりさせておかないと。
    • 14.2.5 スケルトンシステム
  • 14.3 シナリオベース評価手法
    • 14.3.1 アーキテクチャを中心としたアクティビティ
      • p.202 l.3
        本文では「ビジネスドライバを提示する」、図14-1では、「ビジネスドライバを理解する」。「提示する」と「理解する」ではちょっと違うような。
    • 14.3.2 ステークホルダを中心としたアクティビティ
      • p.204
        p.201の図14-1には、UMLアクティビティ図の終了ノードがないなぁ。