とはいえ、試験の加点対象になるオマケの課題がまだ９個あって、そのうち３個はできたんだけど、残り６個は仮想マシンで動かさなきゃいけないやつで、この仮想マシンが私の家のネット環境だとオーバーテクノロジーで、まあ、止まる止まる。ぷーあらあら（どせいさん）。みたいな。
で、調べてみたら、オマケを３問やってたった１点の加点ということで、まあ、諦めて（え）、今日の午後は、来月中旬のテスト勉強をしてました。
でも、まあ、残りの６問も気持ちが悪いから、今度気が向いたらネットカフェとかに行ってやってみるかもしれない。
それでは、今までのシステム設計の一ヶ月ちょいの軌跡を振り返ってみましょう。
クラスとインスタンス
クラス図とインスタンス図はデザインがそっくりなので、インスタンスの名前の部分には必ず下線をつけて区別する！
継承
どちらが一般的で、どちらが特殊かを考える。
例えば、正方形は特殊な長方形なので、包含記号を使うと「長方形⊃正方形」となる。論理記号の矢印のデザインは⇒で、クラス図の矢印はチビ太のおでんのようなデザインなのに注意。
ポリモーフィズム
同じ呼び方（メッセージ）の操作で異なる動作をさせること。
例えば、一から作るのではなく、既存のシステムの操作をすこし修正＝上書き（オーバーライド）すれば事足りそうな場合など。
抽象クラス
抽象クラスには実態がないため、例えば「図形」という抽象クラスがあった場合、その具体例であるインスタンスは作れない。
これが、「長方形」や「楕円」などの具体的な図形のクラスではいろいろなインスタンス（いろいろな形の長方形や楕円）が作れる。
関連
多重度が重要。アスタリスクのマークは任意の数。
頻出する関連パターンは「モノ」－「コト」ー「コト」で、多重度は「１対＊」「＊対１」が多い。
特にこの問題が危険。
生徒にとっては、受講できる科目は最大10科目なので、0..10となる。
講義科目にとっては、受講する生徒の数は最大20人なので0..20となる。
依存
依存を示す矢印は点線で、さきっちょは＾で、黒い三角形▲ではないのに注意。
依存するクラスは変更できるが、依存される側を変えると、そいつに依存している奴にも影響が及ぶ。
コンポジション関連
販売伝票の情報から、明細というクラスを作りデータを分ける。
販売伝票に共通するデータは「日時」「支店名」「合計金額」なので、これらは販売伝票のクラスに残す。
それ以外の何を何個買ったかのデータ「商品名」「単価」「数量」「金額」は、明細のクラスに送る。
実装
依存はさきっちょが＾の点線の矢印だったが、実装はさきっちょが△の点線の矢印。
そういや、実習課題で実装の矢印ってあんまり使わなかった気がする。
パッケージ図
関連性の高いデータや操作は一つのパッケージに入れてしまう。
例えば、「マグロ」「カンパチ」「ヒラメ」などのデータは「寿司ネタ」というパッケージに入れるとわかりやすい。
また、パッケージ内のデータは可視性の設定によって、表示・非表示が可能。非表示設定にすると、そのデータは他のパッケージから見えなくなる。
表示は＋のマーク、非表示は～なので注意。
シーケンス図
課題を進めるにつれ最終的にすごい複雑になった奴。
例えばこれ。
ちなみに、シーケンス図の作成には、まずクラス図（設計図）を作成しなければならない。
また、あるクラスの処理は、そのクラスを指すメッセージの矢印によって行われるのに注意（逆に言うとメッセージの矢印に書かれている操作内容は、矢印が刺さっているクラスが持っている！）。
さらに、同期メッセージの矢印の先っちょは▲、非同期メッセージの矢印の先っちょは＾なのも注意する（これを混同すると実行仕様＝活性区間を示す縦長の四角形が連動して勝手に大きくなっちゃう）。
要件定義
要件定義は、顧客と開発者の共同作業で考える。
まず現状を分析し、顧客からシステム要求を聞き、それを元に開発者が分析結果（要件定義書）を提示して、共通理解を図る。
顧客は、依頼者やエンドユーザのことで、これがステークホルダーになると、もう少し広く、開発側も含まれる。
要件定義のうち、必ず搭載すべき機能は機能要件と呼ばれるが、反応速度といったユーザビリティや、故障しにくいといった信頼性、セキュリティなど、顧客の要件にはない機能（性能）である非機能要件が昨今取りざたされている。これは要件定義書に明記されてはいないため、限られた時間と資金の中、顧客の気持ちをどれだけ忖度できるかが、顧客の満足度を高めるという。
ユースケース図
ユーザの要求に、どのようにシステムが対応するかを示す図のこと。
従って、まずアクターを抽出しなければならない。
例えば、コンビニのレジシステムの場合、それを扱うアクターはレジ係と店長（店長もレジは使えるから）であり、お客さんではない。
以下は、学生が図書館で本を借りる際のユースケース図。
なお、「氏名と本のタイトルを確認する」の手順のように、「本を借りる」ときにも「本を返す」ときにも行われるようなものは、〈〈include〉〉の矢印で指し示す。
ER図
マイクル・クライトン先生の緊急救命室ではない。
エンティティ・リレーションシップ・ダイアグラムの略。
エンティティとは実体とか概念のことで、複数の対象物を共通のカテゴリーでまとめた四角形と考えて良い。
これはUMLでいうクラスに相当するため、クラス図をER図に変換することができる。
クラス図との違いは、クラス名（エンティティ名）が四角形の外に追いやられ、１段目のマスにはRDBSのように主キーが入ること。
さらに、「学生」や「本」のように一意（ユニーク）に求められるものは親エンティティ、「貸出」のように様々なパターンがあるものは子エンティティと呼ばれる。
これら親子をつなぐ多重度のマークも覚えなければならない。
鳥の足（クロウズ・フット）のマークは複数という意味。
｜は１つ、○は０つ、エンティティにつながっているという意味。
ちなみに｜と○を合体させると０か１という意味。
また、子エンティティが親エンティティに依存している場合、子エンティティの四角形の角は丸くなる。
