新しい発見&注意点メモ

RUPをおこなうには経験者が必要。さもなければ必ず失敗するとか。聞いた話だが、アメリカではプロジェクトのメンバーの60%が経験者でなければいけないといわれているらしい。

アーキテクチャのベースライン: アプリケーション固有、ビジネス固有のコンポーネントの基盤となるアーキテクチャ(プラットホームとかフレームワークとか永続化メカニズムとか？)
FURPS: 品質テストの対象(Functionality, Usability, Reliability, Performance, Supportablity)
レグレッションテストの自動化: OO開発の命
チームベースのプロセス: 誰が、いつ、何を、どのように行うかを定義したもの
反復開発: 反復単位ごとの最初にUserと要求を確認し、最後にUserと評価を行う。マイルストーンごとの期日の延期は絶対に行なってはいけない。期日に間に合わない原因を調査し次回に生かすべき。
サブシステム: 一般的にソフトウェア開発で使用される「サブシステム」とは異なる。インターフェースを実現するパッケージのこと。参考-http://www.atmarkit.co.jp/farc/rensai/redge22/redge22.html
コンポーネント: サブシステムを具現化したもの
関連: 自分自身にむけられた関連は入れ子構造をあらわしたものではないことに注意
多重度: 集約を表すとき「全体」は「部分」からみて2以上になることもある。一方、コンポジションでは必ず1となる。多重度は省略しないで必ず書くべし。
汎化: UMLで表現される場合、「継承」ではなく「汎化」である
ユースケースとアクター: システムに関係ないものは必要ない。
シナリオ: ユースケースのインスタンス。基本フローと代替フローがある。代替フローとしては、基本フローの異形（条件分岐）、特異なケース（ループ）、例外的なフローがある。条件分岐やループ処理は基本フローに含めてしまう場合もある。
アクティビティ図: RUPの場合は補助的に使う（それほど使わない）。同期バーに囲まれた処理は順序性がないことを示す。
補足仕様書: FURPSについて記述する。またユースケースモデルに記載しないものも（ログイン、メインメニューなど）ここに記載する。
分析と設計の違い: 分析ではwhatに着目して機能要件を実現することに焦点をあて、設計ではhowに着目して機能外要件の実現も目指す。
アーキテクチャ: 要求を実現するために必要なソフトウェアの構造(レイヤ構造、クラス構造、オブジェクト構造)、メカニズム、(設計、実装に対する)制約
ユースケースの実現: ユースケースモデルを設計モデルにマッピングすること
モデルの規模: ビジネスモデル>ドメインモデル>分析モデル>設計モデル
分析クラス: バウンダリクラスとエンティティクラスが直接関係することはあり得ない。同様にバウンダリクラス同士が直接関係することもありえない。
バウンダリクラス: アクターとユースケースの対ごとに１つ
コントローラークラス: ユースケースごとにひとつ
エンティティクラス: アクターは含めないこと
相互作用図: 分析段階ではシーケンス図、設計段階ではコラボレーション図を使う人が多い。シーケンス図はシナリオと対比しやすい。どちらにしても相互作用図はシナリオの数だけ漏れなく必要。
集約と関連: UML上は区別できるが実装では区別ない。ただグルーピングを区別する際の目印となるので明確に区別したほうがよい。
分析で使用する関係: 使用するのは汎化、集約、関連の3つ。コンポジションや依存は分析段階では使用しない。
VOPC: View Of Participants Classの略。VOPCには責務のないものは含めない、外部システムは含めない、一時的に存在するようなものは含めない。クラス名称は要求仕様と言葉の一貫性を保つべき。できるだけ現実世界とマッピングすべき。