区分 環境情報科目
ディプロマ・ポリシーとの関係

カリキュラム・ポリシーとの関係

カリキュラム全体の中でのこの科目の位置づけ

科目の目的
オブジェクト指向において最も重要な概念であるクラスについて、まず、学び、その抽出ができるようにする。その後、オブジェクト指向ソフトウェア開発方法論について、各工程ごとに学んでいく。その過程で、いくつかのソフトウェアツールが使えるようにする。
到達目標
オブジェクト指向において最も重要な概念であるクラスについて、その抽出ができるようにする。その後、オブジェクト指向ソフトウェア開発方法論について、各工程ごとの作業が自らできるようにする。その過程で、いくつかのソフトウェアツールが使えるようにする。
科目の概要
明白ないわゆる「オモチャ」ではないような例を通して、オブジェクト指向ソフトウェア開発の各工程について学んでいく。
まず、クラスとオブジェクトの区別、クラスの抽出、属性・操作、関連、多重度、責務、高凝集・低結合という考え方を一つのシステムに適用し、オブジェクト指向で問題を整理して設計する一連の流れの基礎とする。
次に、表現法であるUMLと、そのモデリングツールであるastah*について学ぶ。
引き続いて、オブジェクト指向のソフトウェア開発に関する各工程の内容を学び、実例に適用していく。
科目のキーワード
クラス、オブジェクト、UML、astah*、ドメイン分析、要求定義、要件定義、基本設計、詳細設計、実装、テスト、JUnit、保守、リファクタリング
授業の展開方法
講義を進めながら、必要に応じて、演習を行う。特に、オブジェクト指向開発方法論に各工程について、いくつかの、それなりに大きな例を通して、演習の対象としていく。
オフィス・アワー
深澤良彰：【前期】月曜4限、火曜4限、水曜4限、木曜2限
【後期】
サスティナブルソフトウェア概論
サステナブル・ソフトウェア論Ⅱ（オブジェクト指向設計）
環境プログラミングⅡ
全科目：月曜4限、火曜4限、水曜4限、木曜4限
山浦恒央：【前期】
サステナブル・ソフトウェア論Ⅰ（ソフトウェア品質）木曜5限
環境プログラミングⅢ（標準API）月曜4限、水曜4限
【後期】木曜5限
科目コード UC4022
学年・期 2年・後期
科目名 サステナブル・ソフトウェア論Ⅱ（オブジェクト指向設計）
単位数 4
授業形態 演習
必修・選択 必修
学習時間
前提とする科目
展開科目
関連資格
担当教員名 深澤良彰・山浦恒央
回主題コマシラバス項目内容教材・教具
1 オブジェクト指向開発方法論の基礎 科目の中での位置付け このサステナブル・ソフトウェアⅡは、サステナブル・ソフトウェア概論、および、サステナブル・ソフトウェアⅠ（品質）に続くものであり、このサステナブル・ソフトウェアⅡ（オブジェクト指向）の初回授業として、この２科目の復習を行う。
ヨリソル上の解説教材
コマ主題細目 ① ソフトウェア開発プロセスとは何か ② ウォーターフォール型ソフトウェア開発 ③ オブジェクト指向手法
細目レベル ① ソフトウェア開発プロセスとは、発注者の要望に沿ったソフトウェアを計画的かつ効率的に開発し、品質を確保するために、一連の工程や手順を明確にしたものです。本章では、これを家の建築に例えて説明しています。家を建てる場合、注文主の希望を聞いた直後に工事を始めるのではなく、希望を具体化し、設計図を作り、それに従って建築し、完成後に検査してから引き渡します。ソフトウェア開発も同様に、大きく「要求定義」「要件定義」「設計」「実装」「テスト」「納品」「保守」という工程を順に進めます。設計は外部設計と内部設計に分けられ、テストについても、単体テスト、結合テスト、システムテスト、運用テストという段階があります。
② 代表的な開発モデルであるウォーターフォール型では、滝の水が上流から下流へ流れるように、要求・要件定義、設計、実装、テストなどの工程を順番に進めます。基本的に前の工程には戻らないことを前提としているため、工程の区切りが明確で、スケジュールや予算を管理しやすく、大きな問題も発生しにくいという利点があります。その反面、すべての工程を順番に進めるためリリースまで時間がかかり、途中で要求や仕様が変更された場合には対応しにくいという欠点があります。そのため、完成させるシステムの姿があらかじめ明確で、仕様変更が少なく、品質を重視する大規模なプロジェクトなどに適しています。
③ 最後に、オブジェクト指向とは、データとそれを操作する処理を一体化した「オブジェクト」を基本単位としてソフトウェアを捉える考え方です。現実世界や業務に存在する対象をオブジェクトとして捉え、それらを適切なクラスに分け、互いに協調させてシステムを構築します。大きな特徴は、分析・設計・実装を同じ「オブジェクト／クラス」という考え方で一貫してつなげられることです。これにより、複雑なシステムを分割して理解しやすくし、変更・再利用・保守もしやすくなります。一方、適切なクラスや責務の分け方には経験が必要であり、設計が不適切であれば、かえってオブジェクト間の関係が複雑になり、変更や再利用が難しくなります。したがって、オブジェクト指向で重要なのは、単にJavaでclassを使うことではなく、システムを適切な責務を持つオブジェクトに分割し、それらを協調させることなのです。
キーワード ① 要求定義、要件定義、設計、実装、テスト、納品、保守 ② ウォーターフォール型、要求・要件定義、設計、実装、テスト ③ オブジェクト指向、オブジェクト、クラス、再利用
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回の授業の復習：今回の授業内容について、サステナブル・ソフトウェア概論で該当するコマについて、復習しておく。
★次回授業の予習：この授業は、オブジェクト指向に関することなので、クラスとオブジェクトについて、学んでおく
2 オブジェクト指向の基礎（クラスとオブジェクト） 科目の中での位置付け 本授業では、その科目名の通り、オブジェクト指向について扱っていく。オブジェクト指向の第一歩は、クラスとオブジェクトを
ヨリソル上の解説教材
コマ主題細目 ① 分類とは ② オブジェクト指向における表現
細目レベル ① まず、「カレー、ラーメン、寿司、ビール、ジュース、アイスクリーム」などを分類する例から、分類の意味を考えます。同じ対象でも、何に注目するかによってさまざまな分類が可能であり、絶対的に正しい分類が一つだけ存在するわけではありません。重要なのは、目的に応じて共通点を見つけ、同じ種類のものとしてまとめることです。分類することで、多数のものを一つ一つ個別に扱う必要がなくなり、複雑な世界を理解しやすくできます。この「共通する特徴を持つものを一つの種類としてまとめる」という考え方が、クラスを理解する出発点となります。

分類には階層性があります。たとえば「飲食物」を「食べ物」と「飲み物」に分け、さらに「飲み物」を「アルコール飲料」と「ノンアルコール飲料」に分け、その下に「ビール」「日本酒」「ジュース」などを置くことができます。上位に進むほど共通点に注目した一般的・抽象的な概念となり、下位に進むほど相違点に注目した個別的・具体的な概念となります。すなわち、「共通点を見ること」が抽象化、「相違点を見ること」が具体化につながります。
② クラスを定義する際には、「何を持っているか」と「何ができるか」という二つの視点で考えます。前者を属性（attribute）、後者を操作（operation）と呼びます。たとえばカレーには、商品名、価格、辛さ、サイズ、トッピングなどの属性があり、辛さを変更する、サイズを変更する、価格を計算するといった操作があります。ここで重要なのは、同じクラスのオブジェクトが同じ「値」を持つ必要はないことです。Aさんのカレーが中辛、Bさんのカレーが辛口でも、どちらも「辛さ」という同じ種類の情報を持っています。クラスは共通する構造を定義し、それぞれのオブジェクトは異なる属性値、すなわち固有の状態を持つのです。

この考え方はJavaにもそのままつながります。「カレーという種類」をclass Curryとして定義し、属性をフィールド、操作をメソッドとして表現します。そしてnew Curry()によって具体的なオブジェクトを生成します。つまり、Javaのclassから考え始めるのではなく、現実の対象を観察し、共通する属性と操作を抽出してクラスを考え、その結果をJavaで表現するという順序が重要です
キーワード ① クラス、オブジェクト、分類、階層性、抽象化、具象化 ② クラス、オブジェクト、インスタンス、属性、操作、フィールド、メソッド
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：多くの自然言語文からクラスとインスタンスが抽出できるようにしておく。
★次回授業の予習：抽出したクラスには、どのような関係があるのかを考えられるようにしておく。
3 オブジェクト指向の基礎（クラスの抽出） 科目の中での位置付け 前回の授業では、クラスとインスタンスの考え方について学んだ。今回の授業では、前回の授業で学んだ分類の考え方に従って、クラス、操作、関連を抽出する方法について学ぶ。
ヨリソル上の解説教材
コマ主題細目 ① クラス抽出の基本的な考え方 ② 操作・関連の候補の抽出 ③ クラス候補の整理
細目レベル ① クラスを発見する最初の手がかりは、要求仕様に登場する名詞です。大学の履修管理ソフトウェアを例にすると、「学生」「科目」「教員」「履修登録」「学籍番号」「氏名」「成績」など、多くの名詞を取り出すことができます。しかし、これらをすべてクラスにするわけではありません。「名詞＝クラス」ではなく、あくまで「名詞＝クラス候補」と考えることが重要です。
クラスか属性かを判断するときには、「それ自体を独立したもの・人・概念として管理したいか」「それ自身が複数の情報を持つか」「それ自身に役割や振舞いがあるか」という視点が有効です。
② 要求仕様の動詞にも注目します。「学生は科目を履修する」「教員は科目を担当する」などの動詞は、操作やクラス間の関係を発見する手がかりになります。ただし、名詞が必ずクラスになるわけではないのと同様に、動詞も必ずメソッドになるわけではありません。まず候補として拾い、その後でシステムにおける意味を考えることが基本です。

さらに重要なのが、「人」や「物」以外もクラスになり得るという点です。
「履修」「予約」「注文」「貸出」「支払い」といった出来事や関係も、それ自体に保存すべき情報があればクラスとして扱うことができます。
③ 要求仕様からクラスを抽出する基本手順は、まず要求仕様を読み、名詞・名詞句からクラスや属性の候補を拾い、動詞から操作や関連の候補を探します。そのうえで、「独立して管理すべき対象か」「別のクラスが持つ情報ではないか」「関係そのものに情報がないか」を検討し、クラス・属性・操作へ整理します。履修管理の例では、この過程からStudent、Course、Teacher、Enrollmentという主要なクラスが導かれます。
キーワード ① クラス、名詞、属性 ② 動詞、メソッド ③ 要求仕様、名詞／名詞句、クラス、動詞、操作、関連
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：与えられた文章から、名詞を頼りにクラスを、動詞を頼りに操作や関連を抽出する練習を繰り返す。
★次回授業の予習：クラス間の抽出の仕方が身に付いたら、それらの間の関連が分かるようにしていく。
4 オブジェクト指向の基礎（クラス間の関連） 科目の中での位置付け これまで、システムに必要なクラスを発見してきました。しかし、クラスを個別に見つけただけでは、システム全体の構造を十分に表すことはできません。クラスを発見した後には、「どのクラスとどのクラスが、どのような意味で関係しているのか」を考える必要があります。
ヨリソル上の解説教材
コマ主題細目 ① クラス同士の関係とその発見 ② 多重度の発見 ③ 「関連」とは
細目レベル ① クラス間の意味のあるつながりを「関連（association）」と呼びます。要求仕様から関連を発見する際には、名詞と名詞を結ぶ「動詞」が重要な手がかりになります。たとえば、履修管理システムの「学生は科目を履修する」という要求からは、Student（学生）とCourse（科目）の間に「履修する」という関連を見つけることができます。同様に、「教員は科目を担当する」からは、Teacher（教員）とCourseの間に「担当する」という関連を発見できます。要求仕様を「誰が、何を、どうするのか」という視点で読むことが、関連を見つける基本となります。
② 関連を考える際には、「一方のオブジェクトに対して、もう一方のオブジェクトがいくつ関係できるのか」を明確にする必要があります。これを「多重度（multiplicity）」と呼びます。基本的な表記として、「1」はちょうど1つ、「0..1」は0または1つ、「」は0以上、「1..」は1以上を表します。
多重度は常識だけで判断するのではなく、要求仕様に基づいて決定することが重要です。また、「反対側の一つから見て、こちら側はいくつあるか」と両方向から読むことで理解しやすくなります。
③ 関連そのものが情報を持つ場合には、その関連を独立したクラスとして考える必要があります。たとえば、学生と科目の「履修」という関係には、履修年度、学期、成績などの情報があります。成績をStudentに持たせると「どの科目の成績なのか」が分からず、Courseに持たせると「誰の成績なのか」が分かりません。そこでEnrollment（履修）をクラスとして独立させ、Student―Enrollment―Courseという構造にします。これにより、「誰が、どの科目を、いつ履修し、どのような成績だったのか」を適切に表現できます。
キーワード ① クラス間の関連、動詞 ② 多重度、1対1、1対多 ③ 関連、クラス
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：クラスが与えられた時に、それらのクラス間の関係を導き出せ、多重度も検出できるようにする。
★次回授業の予習：各クラスについて、そのクラスは何をするクラスなのか（クラスの責務）がわかるようになりましょう。
5 オブジェクト指向の基礎（クラスの責務） 科目の中での位置付け オブジェクト指向ソフトウェア開発技術では、クラスの抽出が最も重要で、かつ、困難である。このクラスの抽出をうまく行うために、本授業では、クラスの責務を考えるべきてあるということを学ぶ。
ヨリソル上の解説教材
コマ主題細目 ① クラスの「責務」とは ② 高凝集を目指した責務分担 ③ 複数クラスの協調から設計原則へ
細目レベル ① これまでの学習では、要求仕様から必要なクラスを抽出し、それぞれの属性や操作、さらにクラス間の関連や多重度について考えてきました。次に重要になるのが、「どのクラスに、どの仕事を担当させるか」という問題です。オブジェクト指向では、クラスを単なるデータの入れ物ではなく、「何を知り、何をするのか」という役割を持つ部品として考えます。この、クラスが責任を持って担当する役割や仕事を責務（responsibility）と呼びます。
責務を決める基本は、その仕事に必要な情報を最もよく持っているクラスに、その情報と関係の深い処理を担当させることです。たとえば履修管理システムでは、学生の氏名変更はStudent、科目名の変更はCourseが担当するのが自然です。一方、「成績」は学生だけの情報でも科目だけの情報でもなく、「ある学生がある科目を履修した結果」です。そのため、成績をEnrollment（履修）が保持し、「成績を登録する」という処理もEnrollmentに担当させると、データと処理の意味が一致します。責務の割当てに迷った場合には、「その仕事に必要な情報を一番持っているのは誰か」「その仕事は誰の仕事と考えるのが自然か」という二つの問いが有効です。
② 巨大なクラスはGod Class（神クラス）と呼ばれることがあり、役割が曖昧になります。その結果、コードが読みにくい、変更の影響範囲が広がる、テストしにくい、再利用しにくいといった問題が生じます。
そこで重要になるのが凝集度（cohesion）です。凝集度とは、一つのクラスに含まれる属性や操作が、どの程度一つのまとまった役割に関係しているかを表す考え方です。関係の深い属性と操作が一つのクラスにまとまっている状態を高凝集（high cohesion）といいます。たとえばStudentに学籍番号、氏名、学年と、履修や成績確認など学生に関係する処理をまとめれば高凝集になります。一方、ホテル予約や給与計算など学生とは関係の薄い処理までStudentに入れれば、凝集度は低くなります。「一つのクラスには、一つのまとまった役割を持たせる」と覚えると分かりやすいでしょう。

③ すべての仕事を一つのクラスだけで完結させる必要はありません。ホテル予約システムでは、Hotelが複数の客室と予約を調べて空室を検索し、Roomが客室自身の情報を提供し、Reservationが宿泊日や人数、予約料金を管理します。このように、大きな仕事を意味のある小さな責務に分割し、それぞれのクラスが自分の責務を果たしながら協力することが、オブジェクト指向の基本的な考え方です。これは複雑な問題を小さな問題に分ける「分割統治」にもつながります。
したがって、よいクラス設計とは、各クラスについて「何を知り、何をするクラスなのか」を明確に説明でき、その役割に関係する属性と操作が適切に集められている設計です。設計するときには、「必要な情報を誰が持つか」「この仕事は本当にこのクラスの仕事か」「クラスの役割を一言で説明できるか」を繰り返し確認することが重要です。こうしてクラス内部を高凝集にした後は、さらにクラス同士の依存関係を小さくする「低結合」へと考え方を発展させていきます。
キーワード ① クラス、責務、responsibility ② 神クラス、影響範囲、凝集度、コヒージョン ③ 分割統治、依存関係
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：要求仕様が与えられたときには、さまざまなクラス分けが存在します。その中で、良いクラス分けか悪いクラス分けかが分かるようにしてください。
★次回授業の予習：今回学んだ凝集度に対する概念として独立性という概念があるので、その概要について理解しておいてください。
6 オブジェクト指向の基礎（クラスの独立性） 科目の中での位置付け オブジェクト指向設計におけるクラスの独立性について、特に「結合度」と「低結合」を中心に学ぶ。前回扱った高凝集がクラスの「中」を整える考え方であるのに対し、低結合はクラスとクラスの「間」を整える考え方である。重要なのは、必要な相手とは協力しながら、必要以上に相手へ依存しないことである。
ヨリソル上の解説教材
コマ主題細目 ① 変更の影響から見た結合度 ② 低結合な設計の実現 ③ 設計原則としての高凝集・低結合
細目レベル ① ソフトウェアは完成後も、制度変更、利用者からの要望、不具合修正などによって繰り返し変更される。そのため、設計では現在正しく動作することだけでなく、「一つの変更がどこまで他のクラスへ影響するか」を考える必要がある。あるクラスが他のクラスの内部データや実装方法を詳しく知っていると、相手の変更に伴って自分自身も修正しなければならなくなる。このようなクラス同士の依存の強さを結合度（coupling）という。相手の内部事情への依存が大きい状態が強い結合であり、必要な機能だけを利用し、内部事情への依存を必要最小限にした状態が低結合（low coupling）である。
② 低結合を実現する重要な考え方が、「知る」から「頼む」へという転換である。例えば履修管理システムで、RegistrationがStudentやCourseから学年、定員、履修条件などのデータを取得し、自分で履修可能かを判断すると、RegistrationはCourseの内部事情を知りすぎることになる。そこで、履修条件を最もよく知るCourse自身にcanRegister(student)という操作を持たせ、Registrationは「この学生は履修可能か」とCourseに問い合わせる。このように「データをください。判断は私がします」ではなく、「必要な判断をしてください。結果を教えてください」とすることで、Course内部の履修条件が変更されても、その影響をCourse内部に閉じ込めやすくなる。
この考え方はカプセル化や情報隠蔽とも深く関係する。フィールドをprivateにしてgetterを用意しただけでは、必ずしも良い設計とはいえない。多数のgetterを通じて内部データを取り出し、外部のクラスが本来そのクラスが行うべき処理まで担当すれば、内部構造への強い依存は残る。重要なのは、内部データを隠すだけでなく、そのデータと密接に関係する処理も適切なクラスに任せることである。
③ 高凝集と低結合は表裏一体の設計原則である。関係の深い情報と処理を一つのクラスにまとめれば、そのクラスは高凝集になる。同時に、他のクラスは内部情報を詳しく知る必要がなくなり、低結合になりやすい。つまり「自分の責務は自分で果たし、他クラスの責務はそのクラスに依頼する」という適切な責務分担が両者を実現する。
低結合によって変更の影響を局所化できれば、修正漏れや副作用、新たなバグを減らしやすくなり、保守性だけでなく、テスト容易性、再利用性、理解しやすさ、分担開発のしやすさも向上する。ただし、低結合とはクラス同士の関係をなくすことではない。システムを実現するために必要な協力関係は維持しながら、「何を依頼するか」という公開された操作だけを共有し、「内部でどのように実現するか」は相手に任せることが重要である。
キーワード ① 責務、高凝集、結合度、低結合、変更の伝搬、依存、高結合 ② カプセル化、情報隠蔽 ③ 仕様変更、影響の局所化、公開された操作、インタフェース、テスト、再利用、独立性、責務分担
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：実際のソフトウェアでは複数のクラスが情報をやり取りし、互いに仕事を依頼しながら機能を実現するため、クラス間の関係を考えてください。
★次回授業の予習：次回は、第２回から第６回までの総復習なので、対応する回の解説教材を読んで、理解しておいてください。
7 オブジェクト指向の基礎（まとめ） 科目の中での位置付け 第2回から第6回までに学んだオブジェクト指向の基礎を振り返り、それらを一連の考え方として整理したうえで、映画館チケット予約システムを使った総合演習を行う。
ヨリソル上の解説教材
コマ主題細目 ① 第２回から第６回までのまとめ ② 映画館チケット予約システムを使った総合演習 ③ 今後の授業の進め方
細目レベル ① 第2回から第6回では、オブジェクト指向の基本を段階的に学んだ。まず、同じ種類の具体的なものに共通する属性と操作をまとめたものがクラスであり、その具体的な一つ一つがオブジェクトであることを確認した。次に、要求仕様から名詞や動詞を手がかりとしてクラス・属性・操作・関連の候補を抽出し、「その情報は誰のものか」を考えながらクラスを発見する方法を学んだ。さらに、クラス間の意味のあるつながりを関連、一方のオブジェクトに対して相手がいくつ関係できるかを多重度として表現した。また、各クラスが「何を知り、何をするか」という責務を明確にし、関係の深い属性と操作をまとめる高凝集、他クラスの内部事情に必要以上に依存しない低結合を学んだ。よい設計とは、各クラスが自分の責務を担当し、必要最小限の知識で他のクラスと協力する設計である。
② これまでの知識を統合するため、映画館チケット予約システムを題材に総合演習を行う。要求仕様から、映画番号、タイトル、上映時間、上映日時、スクリーン番号、顧客番号、予約番号、座席番号など、システムが管理すべき情報を抽出し、関係の深い情報をまとめてクラスを発見する。ここで重要なのが「映画」と「上映」の区別である。映画は作品そのものだが、上映は「その映画を、いつ、どこで上映するか」という出来事であり、一つの映画に複数の上映が存在する。また、座席番号は顧客や上映だけの属性ではなく、「誰が、どの上映の、どの座席を予約したか」を表す予約の情報として扱う。こうして、基本構造として「顧客―予約―上映―映画」が導かれる。この演習を通じて、目に見える人や物だけでなく、「予約」「上映」のような出来事や関係もクラスになり得ることを理解する。
③ 今後は、これまで学んだオブジェクト指向の基礎を、実際のソフトウェア開発工程へ発展させる。その導入としてモデル変換を学ぶ。Javaでは、人間が書いたソースコードをjavacがバイトコードへ変換し、さらにJITコンパイラが実行環境に適した機械語へ変換する。この「ある表現を別の表現へ自動変換する」という考え方を上流工程へ広げ、設計モデルからソースコードなどを生成する考え方へつなげる。さらに、今後の共通例題として遠距離バス予約システムを使用する。このシステムでは、バス会社が路線、便、バス、シートクラスなどを管理し、乗客が出発地・到着地・乗車日から便を検索して予約・確認・キャンセルを行う。「路線」と「便」を区別するなど、これまで学んだクラス抽出や関連、責務などを活用しながら、今後の分析・設計・実装へと学習を発展させていく。
キーワード ① クラス、オブジェクト、属性、操作、クラス抽出、関連、多重度、責務、高凝集、低結合、カプセル化、情報隠蔽 ② モデル変換、バイトコード、JITコンパイラ ③ 遠距離バス予約システム、路線、便、シートクラス
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：映画チケットの予約システムの仕様からクラス、それらのあいだの関係、多重度などが抽出できるようにしておこう。
★次回授業の予習：次回は統一モデリング技法（UML）について学ぶので、どのような図表が含まれるのかの予習を希望する。
8 UMLとastah* 科目の中での位置付け ソフトウェア開発では、「どのような手順で開発するか」「その結果をどのように表現するか」「その作業を何で支援するか」という三つを区別して考えることが重要である。本授業では、それぞれを開発プロセス、表記法、ツールとして整理する。
ヨリソル上の解説教材
コマ主題細目 ① 開発プロセスと表記法とツール ② 統一モデリング言語UML ③ モデリングツールastah*
細目レベル ① 開発プロセスとは、ドメイン分析、要求定義、要件定義、基本設計、詳細設計、実装、テスト、保守といった作業を、どのような順序で進めるかを定めたものである。一方、表記法は、分析や設計によって得られた結果を一定のルールで表現するためのものであり、本講義ではオブジェクト指向の標準的な表記法であるUML（Unified Modeling Language：統一モデリング言語）を用いる。さらに、UMLに従った図を実際に作成・管理するためのツールとしてastah*を利用する。したがって、「開発プロセス＝何をどんな順番で考えるか」「UML＝考えた結果をどんなルールで表すか」「astah*＝その表現を何を使って作成・管理するか」という違いを理解する必要がある。
② UMLは、ソフトウェアの構造や振舞いを視覚的に表現するための標準的なモデリング言語である。同じシステムでも、クラスの構造、利用者から見た機能、オブジェクト間のやり取り、処理の流れなど、着目する側面によって適切な図は異なる。そのため、一つの図ですべてを表現するのではなく、目的に応じて複数の図を使い分ける。UMLは、異なっていたオブジェクト指向モデリング手法を統一する形で、James Rumbaugh、Grady Booch、Ivar Jacobsonらを中心に整備され、OMGによって標準化された。UMLの図は、大きく構造モデル（静的モデル）と振舞いモデル（動的モデル）に分けて理解できる。構造モデルは、システムを構成する要素とその関係を、いわば「静止画」として表現する。これに対して振舞いモデルは、時間の経過に伴うシステムの動きを表現する。
③ 本講義で使用するastah*について説明している。Astah*は単なる作図ソフトではなく、図中の要素を「モデル」として一元管理できることが特徴である。同じモデル要素を複数の図で利用している場合、一か所の変更を他の図にも反映できる。また、図形や線の配置を自動的に調整できるため作図作業の負担を減らせる。さらに、クラス図からJavaやC++のコードの骨組みを生成したり、既存のJavaコードからクラス図を生成したりするリバースエンジニアリングも可能である。このようにastah*を利用することで、UMLを「絵」として描くだけではなく、分析・設計・実装へとつながるモデルとして扱うことができる。
キーワード ① 開発プロセス、表記法、UML、モデリング ② 構造モデル、振舞いモデル、クラス図、ユースケース図、シーケンス図、ステートマシン図、アクティビティ図 ③ astah、モデル変換、リバースエンジニアリング
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：UMLの主要な図式の名称とどのようなことを表現できるのかについて学んでおきましょう
★次回授業の予習：モデリングツールの機能について学んでおきましょう。
9 astah*とその使用法 科目の中での位置付け UMLによる分析・設計を実際の作業につなげるため、モデリングツールastahの基本的な考え方と操作方法を学ぶ。astahはUMLなどを用いてモデルを作成・編集・管理するための「ツール」である。したがって、astah*の操作方法だけを覚えるのではなく、「何をモデル化するのか」「なぜその操作を行うのか」を理解することが重要である。
ヨリソル上の解説教材
コマ主題細目 ① astah*を使う準備 ② astah*の基本操作 ③ UMLモデルの作成 ④ モデルの管理と実装へ
細目レベル ① astahの大きな特徴は、画面上の図形を単なる「絵」ではなく、意味を持ったモデル要素として管理する点にある。例えば、PowerPointで「学生」と書いた四角形を作成しても、それは単なる図形にすぎない。一方、astahで作成した「学生」は「クラス」というモデル要素として認識され、属性や操作、他のクラスとの関係などを設定できる。また、一つのシステムに関するモデル要素や複数のUML図は、一つのプロジェクトとしてまとめて管理する。
クラス図では、クラス名だけでなく属性や操作を入力する。ここではJavaで学んだ**情報隠蔽（カプセル化）**との関係が重要となる。内部の属性は原則としてprivateとし、外部から必要な場合にはpublicな操作を通してアクセスさせる。UMLではprivateを「-」、publicを「+」で表すため、これらの記号を単に暗記するのではなく、オブジェクト内部のデータを適切に保護するという設計上の意味を理解する必要がある
② 実際の操作では、画面移動、線の形の変更、画像としてのコピー、属性・操作の追加、図形の整列などの機能やショートカットを利用すると効率よく作業できる。また、astah*ではDeleteキーとCtrl+Dの違いに注意する必要がある。Deleteは現在の図から表示を取り除くだけでモデル要素自体は残るのに対し、Ctrl+Dはモデル要素そのものを削除する。これは、「図」とその背後に存在する「モデル」が別のものであることを理解する重要な例でもある。
③ 演習では、「大学の履修管理システム」という同じ題材について、クラス図、ユースケース図、シーケンス図の三種類を作成する。クラス図では「学生」「科目」「履修」をクラスとして抽出し、属性、関連、多重度を表現する。ユースケース図では、「学生」「教員」をアクターとし、「科目を検索する」「履修登録する」「成績を登録する」など、利用者から見たシステムの機能を表現する。さらにシーケンス図では、「履修登録する」という処理について、学生、履修登録画面、履修管理、科目、履修などの間で、どのようなメッセージがどの順番でやり取りされるかを表現する。つまり、クラス図は静的な構造、ユースケース図は利用者から見た機能、シーケンス図は相互作用の時間的な順序を表す。同じシステムであっても、一つの図ですべてを表現するのではなく、目的に応じて複数の図を使い分けることがUMLモデリングの基本である。
④ モデルとプログラムとのつながりを学ぶ。詳細なクラス図はJavaのクラス構造と対応させることができ、astahではクラス図からJavaやC++のソースコードの骨組みを生成するコード生成が可能である。反対に、既存のJavaコードからクラス図を作成して構造を理解するリバースエンジニアリングも行える。こうしたモデル変換を通じて、分析・設計で作成したモデルを実装へつなげることができる。astahを利用する際に最も重要なのは、きれいな図を描くことや操作を暗記することではなく、「何をモデル化したいのか」「その図で何を伝えたいのか」を考えながら、分析・設計の結果をモデルとして適切に表現・管理することである。
キーワード ① UML、astah、モデリングツール、モデル、モデル要素、プロジェクト ② クラス図、属性、操作、可視性、情報隠蔽（カプセル化） ③ 多重度、ユースケース図、アクター、シーケンス図 ④ 相互作用、モデル要素の再利用、モデル変換、コード生成、リバースエンジニアリング
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：みなさんは、これからもいといとなソフトウェアツールを使っていくと思います。単に操作を覚えるだけでなく、その意味も考えるようにしましょう。今回はastah*を例にして。
★次回授業の予習：次回からソフトウェア開発のライフサイクルに沿って、どのような工程が存在し、その意味を思い出しておいて下さい。
10 ドメイン分析（１） 科目の中での位置付け ソフトウェア開発では、いきなり画面やプログラムを設計するのではなく、まずソフトウェアが対象とする業務・問題領域である「ドメイン」を理解することが重要である。ドメイン分析では、現在の業務にどのような人・物・情報・出来事が存在し、それらがどのように関係しているのかを整理し、業務状況から概念モデルを作成する。
ヨリソル上の解説教材
コマ主題細目 ① 多段階変換によるソフトウェア開発 ② 動的側面のモデリング：プロセス図 ③ 静的側面のモデリング：オブジェクト図 ④ 静的側面のモデリング：クラス図
細目レベル ① ソフトウェア開発では、いきなり画面やプログラムを設計するのではなく、まずソフトウェアが対象とする業務・問題領域である「ドメイン」を理解することが重要である。本資料では、開発を「概念モデル→要求モデル→分析モデル→設計モデル→実装モデル」という多段階のモデル変換として捉え、その出発点にドメイン分析を位置づけている。オブジェクト指向による概念モデルでは、業務を「動的側面」と「静的側面」の二つから捉える。動的側面は、業務の中で「何が、どのような順序で行われるか」という業務プロセスであり、プロセス図によって表現する。一方、静的側面は「どのようなものや概念が存在し、それらがどのような関係にあるか」という業務の構造であり、具体的なインスタンス間の関係をオブジェクト図、一般化された概念間の関係をクラス図によって表現する。
② 動的側面のモデル化には、Eriksson-PenkerのUML拡張プロセス図を用いる。プロセスとは、情報やリソースを入力として受け取り、それらを別の情報やリソースへ変換する作業であり、プロセス図では「プロセス」「情報」「物理的リソース」「人々」「ゴール」などを表現する。履修管理業務では、学生、教員、教務担当者を主要な関係者とし、「開講科目登録」「授業検索」「履修登録」「履修取消」「成績登録」「成績確認」などのプロセスを整理する。これにより、「誰が」「何を入力し」「どの作業を行い」「何を出力するのか」を明確にできる。
③ 静的側面では、まず具体的なシナリオからオブジェクトを発見する。たとえば、学生の田中太郎が特定年度・学期の授業を履修し、教員がその履修に成績を登録する場面を考える。そこから「学生」「教員」「科目」「開講科目」などのクラスを抽出する。ただし、文章中の名詞を機械的にすべてクラスにするのではなく、具体的なオブジェクトを分類し、共通する性質を持つものをクラスとして抽象化する。この考え方は、具体的な世界からオブジェクトを見つけ、同じ種類をまとめてクラスを発見し、さらに関係自体に重要な情報があればそれもクラスとして捉えるという、ドメイン分析の重要な思考過程を示している。
④ クラス図では、クラス、属性、操作に加えて、関連、多重度、誘導可能性、汎化・特化、実現、集約、コンポジット、依存、インターフェースなどを用いて静的構造を表現する。最後に概念モデルをレビューし、主要な概念と関係が網羅されているか、実装方法に引きずられていないか、クラス名が明確か、関連や多重度が業務の実態を正しく表しているかを確認する。最終的には、作成したモデルを顧客と確認し、開発者と顧客の間に対象業務についての共通理解を形成することがドメイン分析の重要な目的である。
キーワード ① ドメイン分析、ドメイン、業務状況、モデル変換、概念モデル、要求モデル、分析モデル、設計モデル ② 業務プロセス、プロセス図、Eriksson-PenkerのUML拡張プロセス図、プロセス ③ オブジェクト、オブジェクト図、インスタンス、リンク、シナリオ、抽象化、一般化 ④ クラス、クラス図、属性、操作、関連、関連クラス、多重度、誘導可能性、汎化、特化、実現、集約、コンポジット、依存
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：ドメイン分析の必要性について理解し、その結果をプロセス図、オブジェクト図、クラス図として表現できるようにする。
★次回授業の予習：第9回の授業で学んだastah*でクラス図、オブジェクト図、プロセス図が描けるようにしておく。
11 ドメイン分析（２） 科目の中での位置付け 前回のドメイン分析（１）の知識を深め、実際に、自らドメイン分析ができる人材をなるようにする。
ヨリソル上の解説教材
コマ主題細目 ① 業務世界の理解～ドメイン分析とヒアリング～ ② 業務の具体的把握～プロセス図とオブジェクト図～ ③ 具体例から業務構造へ～ドメインクラス図の作成～
細目レベル ① ドメイン分析では、ソフトウェアの画面やデータベース、プログラム構造を考える前に、対象となる現実の業務世界そのものを理解することが重要である。本資料では遠距離バス予約業務を題材とし、乗客、便、バス、座席、予約、運賃などの概念がどのような意味を持ち、互いにどう関係し、どのような業務ルールが存在するかをヒアリングによって明らかにする。質問は「何があるのか」「それらはどう関係しているのか」「どんなルールがあるのか」という三つの観点から行う。一方、スマートフォンへの対応や検索結果の表示件数などは要求定義、画面配置やデータベース、プログラミング言語などは設計・実装で検討する事項であり、ドメイン分析とは区別する必要がある。重要なのは、質問が必要か不要かではなく、「どの工程で扱う質問なのか」を判断することである。分からない事項について推測で補うのではなく、追加ヒアリング事項として残す姿勢も重要となる。
② ヒアリングで得られた業務知識を具体的なモデルとして整理するため、まずプロセス図によって「業務では何が行われているか」を明らかにする。文章中の動詞に着目し、「便を探す」「便・座席を選ぶ」「予約する」「予約を確認する」「予約をキャンセルする」などの活動を抽出する。各プロセスについて、Goal（目的）、Input（入力）、Process（活動）、Output（出力）、Resource（資源）を整理すると、業務活動と情報の流れが把握しやすくなる。さらに、プロセスを成立させるために必要な具体的な「もの」に注目し、オブジェクト図へ進む。たとえば「山田太郎がMB101便の3A席を予約し、予約番号R0001が発行された」という具体例から、山田太郎、MB101、3A、R0001、BUS-01などをオブジェクトとして抽出し、それらの関係を確認する。具体例を用いることで、「便」と「バス」のような似ているが異なる概念を明確に区別でき、後のクラス図を適切に作るための土台となる。
③ オブジェクト図で具体的な対象と関係を確認した後、それらに共通する種類を抽象化してクラス図を作成する。たとえば「山田太郎」「佐藤花子」は「乗客」、「R0001」「R0002」は「予約」、「MB101」「MB201」は「便」というクラスとしてまとめられる。次に、氏名、便番号、出発日時、予約番号、確定運賃など、各クラスが持つ情報を属性として整理する。また、オブジェクト間の具体的な関係を抽象化し、「乗客―予約」「予約―便」「予約―座席」「便―バス」「バス―座席」「座席―座席種類」などのクラス間の関連を導く。さらに、一人の乗客が何件の予約を持てるかなど、関連するオブジェクト数を多重度として表現する。ただし、多重度は常識や思い込みで決めるのではなく、ヒアリングや業務ルールを根拠とし、判断できない事項は追加ヒアリングとする。このように、ヒアリング、プロセス図、オブジェクト図を経てクラス図へ進むことで、現実の業務に根拠を持ったドメインモデルを構築できる。
キーワード ① ドメイン分析、ドメイン、対象世界、業務世界、ヒアリング、業務概念、関係、業務ルール、ドメインルール ② プロセス図、プロセス、Goal、Input、Process、Output、Resource、業務活動、情報の流れ、オブジェクト図、オブジェクト ③ クラス図、ドメインクラス図、クラス、抽象化、属性、関連、多重度、オブジェクト、業務ルール、ドメインモデル、追加ヒアリング
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：前回の授業で学んだドメイン分析の価値、考え方について、学んでおくこと。
★次回授業の予習：次回は、ユーザの要求について扱うので、何らかのソフトウェアについて、その要求を考えてみること
12 要求定義（１） 科目の中での位置付け いよいよ具体的なソフトウェア開発に取り掛かる。この第一歩が、要求定義です。まずは、要求定義で必要な概念を明らかにします。
ヨリソル上の解説教材
コマ主題細目 ① 要求定義の基礎 ― ソフトウェア要求とステークホルダー ② 要求の明確化 ― ヒアリング・文書化・検証 ③ 要求のモデル化 ― ユースケースとアクティビティ図
細目レベル ① 要求定義では、顧客やユーザがソフトウェアに何を求めているのかを明らかにし、システムが実現すべき機能、性能、品質などを要求として整理する。要求に誤りがあると、その影響は設計、実装、テストなど後工程まで及ぶため、開発の早い段階で正しく捉えることが重要である。また、要求を考える際には、実際にシステムを利用するユーザだけでなく、開発を発注する顧客、システムを管理する管理者、開発者、要求を整理・分析するアナリストなど、さまざまなステークホルダーを考慮する必要がある。立場によって求めるものが異なるため、要求には抜け、矛盾、不明確さ、ユーザの真のニーズとの不一致が生じる可能性がある。要求工学は、このような要求を適切に獲得・記述・検証・管理するための技術体系である。要求定義では、実装方法であるHOWを先に考えるのではなく、まず利用者に何を提供すべきかというWHATを明確にすることが基本となる
② 要求定義は、顧客の要望をそのまま記録する作業ではなく、ヒアリング、文書化、検証・修正、モデル化を繰り返しながら、システムが実現すべき内容を明確にしていく工程である。本資料では大学の履修管理システムを例に、まず顧客から「どのような問題をシステムによって解決したいか」を聞き出し、「開講科目を登録する」「開講科目を検索する」「履修登録する」という主要な機能要求へ整理している。要求は第三者が読んでも同じ意味に解釈できるよう具体的に文書化する必要がある。しかし、最初に作成した要求が完全とは限らない。たとえば、学生が正確な科目コードや科目名を知らない場合を考慮して検索条件を見直したり、該当する科目が存在しない場合や定員に達している場合の振る舞いを追加したりする必要がある。このように、実際の利用場面を想定して要求の抜けや不明確さ、ユーザニーズとの不一致などを発見し、顧客と確認しながら修正することが重要である。
③ 文書化・検証された要求は、システムの機能や振る舞いを分かりやすく表す要求モデルへ整理する。本資料では、ユースケース図、ユースケース記述、アクティビティ図を用いる。ユースケース図は、システムを利用するアクタと、アクタがシステムを使って達成したい機能との関係を示すものであり、画面やボタンではなく利用者にとって意味のある機能単位で捉える。ユースケース記述では、ユースケース名、アクタ、目的、事前条件、事後条件、基本系列、代替系列などを記述し、アクタとシステムの具体的なやり取りを明確にする。さらに具体的な人物や値を用いたシナリオによって、要求が実際にどのように実行されるかを確認する。アクティビティ図では、処理の流れ、条件分岐、担当者などを図式化し、スイムレーンによってユーザとシステムの責任分担を明確にする。また、ゴール指向分析を利用して上位の目的を下位ゴールへ分解することで、要求の抜けや対立を検討することもできる。
キーワード ① 要求定義、ソフトウェア要求、要求工学、ステークホルダー、ユーザ、顧客、開発者、管理者、アナリスト、ユーザニーズ、機能、性能、品質、抜け、矛盾、不明確さ、WHAT、HOW、要求モデル ② 要求定義の手順、要求ヒアリング、要求の文書化、要求の検証、要求の修正、機能要求、履修管理システム、開講科目、科目検索、履修登録、定員、要求の抜け、矛盾、不明確さ、ユーザニーズ、システム化範囲 ③ 要求モデル、ユースケース図、ユースケース、アクタ、システム境界、ユースケース記述、目的、事前条件、事後条件、基本系列、代替系列、シナリオ、アクティビティ図、アクション、条件判断、スイムレーン、ゴール指向分析
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：自分で何らかのアプリケーションを想定し、そのアプリケーションを開発する時の要求定義をしてみること
★次回授業の予習：実際の複雑なアプリケーションにおける要求も考えてみよう。
13 要求定義（２） 科目の中での位置付け 要求定義をするにあたり、アクターとユースケースを発見し、ユースケースを詳細化し、アクティビティ図で処理の流れを明確にするという各段階を理解すること
ヨリソル上の解説教材
コマ主題細目 ① アクターとユースケースの発見 ② ユースケース記述による要求の詳細化 ③ アクティビティ図による処理の流れと要求の検証
細目レベル ① 要求定義では、要求仕様の文章から、まず「誰がシステムを利用するのか」を考え、システム外部の利用者や関係者をアクターとして発見する。本資料では「学園祭の入場受付システム」を例とし、事前に入場登録を行う「来場者」と、当日にQRコードを読み取って入場を確認する「受付スタッフ」という二つのアクターを抽出する。ここで重要なのは、アクターを特定の人物ではなく、システムに対する「役割」として捉えることである。次に、それぞれのアクターが「システムを使って何をしたいのか」という目的に着目し、「入場登録をする」「入場を確認する」というユースケースを発見する。こうして、アクターとユースケースの関係をユースケース図として表現することで、システムに必要な機能と、それを利用する役割を大づかみに整理できる。要求文から機械的に機能名を拾うのではなく、「誰が？」から「何をしたい？」へ進むことが、要求を利用者の目的に基づいて整理する基本となる。
② ユースケース図によってアクターと必要な機能を整理しても、それだけでは各機能が具体的にどのように実行されるのかは分からない。そこで、ユースケース記述を用いて、アクターとシステムの具体的なやり取りを詳細化する。「入場を確認する」というユースケースでは、受付スタッフがQRコードを読み取り、システムが登録情報を検索し、登録済みであることを確認して「入場可能」と表示し、最後に来場者を「入場済み」として記録する流れを基本フローとして記述する。また、QRコードが無効な場合など、正常に処理できない場合については代替フローとして整理する。さらに、「同じQRコードを2回使用したらどうするか」と検討することで、「使用済みの場合の処理」という当初の要求文にはなかった要求も発見できる。このようにユースケース記述は、単に既存の要求を詳しく書くためだけでなく、要求の曖昧さや不足を発見するためにも利用できる。「誰が？」→「何をしたい？」→「具体的にどうする？」という順序で考えることが重要である。
③ ユースケース記述で明らかにした処理を、さらに流れとして視覚化するためにアクティビティ図を用いる。ユースケース図が「誰が、何をしたいのか」を表すのに対し、アクティビティ図は「処理や作業がどのような順序で進むのか」を表す。「入場を確認する」の例では、QRコードの読み取り、登録情報の検索、登録確認、入場可能の表示、入場済みとしての記録という一連の処理を、開始・終了、アクティビティ、矢印などを用いて表現する。さらに、無効なQRコードや、すでに使用済みのQRコードを考慮すると判断ノードによる条件分岐が必要となり、図を作成する過程で不足していた要求を発見できる。また、スイムレーンを用いて「受付スタッフ」と「システム」を分ければ、それぞれが担当する処理を明確にできる。したがってアクティビティ図は単なる作図手法ではなく、処理の順序、条件分岐、担当を整理し、要求の曖昧さや抜けを検証する手段として重要な役割を持つ。
キーワード ① 要求定義、要求仕様、アクター、役割、ユースケース、目的、ユースケース図、システム境界、機能要求 ② ユースケース記述、ユースケース名、アクター、事前条件、事後条件、基本フロー、代替フロー、要求の詳細化、要求の不足、要求の曖昧さ ③ アクティビティ図、処理の流れ、アクティビティ、判断ノード、条件分岐、基本フロー、代替フロー、スイムレーン、責任分担、要求の検証、要求の抜け
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：ユースケース図、ユースケース記述、アクティビティ図の書き方を習得しておくこと
★次回授業の予習：実際に演習を行うので、演習内容について理解しておくこと
14 要求定義（３） 科目の中での位置付け 前回、前々回で学んだ要求定義の内容を比較的大きな実例に対して適用し、理解を深める。
ヨリソル上の解説教材
コマ主題細目 ① 初期資料の分析と要求の発見 ② アクターとユースケースによる要求の具体化 ③ アクティビティ図による可視化と要求の検証
細目レベル ① 要求定義では、顧客から与えられた文章をそのまま仕様とするのではなく、そこから要求の材料を取り出し、何が事実として示され、何がまだ決まっていないのかを整理する必要がある。本演習では遠距離バス予約システムを題材に、初期資料から「誰が」に当たる主体、「検索する」「予約する」「管理する」などの行為、「二重予約できない」「座席数は車両定員を超えない」などの制約を読み取る。その際、「利用者がしたいこと」「バス会社が管理したいこと」「守らなければならない制約」を区別して整理することが重要である。また、資料に書かれている事実、そこから合理的に読み取れること、資料だけでは判断できないことを混同してはならない。特に、判断できない事項を開発者が推測して仕様化するのではなく、「顧客への確認事項」として残すことが要求定義の重要な姿勢となる。要求定義は一方向に進める作業ではなく、後の検討で疑問が生じれば前の成果物へ戻り、段階的に要求を明確化していく。
② 初期資料から要求の材料を整理した後は、「誰がシステムを利用するのか」という問いからアクターを発見し、その役割が「システムを使って何をしたいのか」を考えてユースケースを抽出する。アクターは特定の人物や組織そのものではなく、システムの外部から情報を入力したり結果を受け取ったりする「役割」として捉える。したがって、乗客や運行管理者などはアクター候補となるが、システム内部で管理されるバス、便、座席などはアクターではない。次に、アクターの目的を「便を検索する」「予約する」などの動詞句で表し、ユースケース図としてシステム全体の機能を整理する。さらに「予約する」を取り出し、事前条件、トリガー、基本フロー、代替・例外フロー、事後条件をユースケース記述として具体化する。正常な処理だけでなく、二重予約、キャンセル、予約番号の紛失などの例外を検討することで、要求の抜けや曖昧さを発見し、資料から判断できない事項を顧客への具体的な質問へ変換していく。
③ ユースケース記述によって明らかにした処理は、アクティビティ図を用いることで、処理の順序や条件分岐として視覚的に確認できる。アクティビティ図では、ユースケース記述の基本フローを「開始→行動→判断→行動→終了」という流れとして配置し、例外が発生する箇所には判断ノードと条件を加える。「予約する」の場合は、便の選択、座席の選択、乗客情報の入力、座席の予約可否確認、運賃の確定、予約の登録、予約番号の発行などを表し、予約できない場合の分岐も明確にする。必要に応じて乗客とシステムのスイムレーンを設ければ、「誰が何を行うのか」も確認できる。完成後は、ユースケース図、ユースケース記述、アクティビティ図を相互に照合し、図にはあるが記述にはない処理や、例外フローにあるのに図にはない分岐などの不整合を探す。これら三つは別々の成果物ではなく、同じ要求を異なる視点から表現したものであり、モデルを作ること自体ではなく、モデルを使って要求の抜け、曖昧さ、矛盾を発見することが目的である。
キーワード ① 要求定義、初期資料、要求、事実、利用者の目的、管理対象、業務上の制約、要求の曖昧さ、顧客への確認事項 ② アクター、役割、ユースケース、ユースケース図、ユースケース記述、事前条件、トリガー、基本フロー、代替フロー、例外フロー、要求の漏れ、顧客への確認事項 ③ アクティビティ図、ユースケース記述、基本フロー、例外フロー、開始ノード、終了ノード、アクション、判断ノード、条件分岐、制御の流れ、スイムレーン、要求モデル、整合性、要求の検証、要求の抜け、要求の曖昧さ
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：今回の演習結果を再度検証し、その本質を理解してください。
★次回授業の予習：次回は、この３回学んだ要求分析に対して、システム的な見方を入れていきますので、それが何かはみておいてください。
15 要件分析（１） 科目の中での位置付け 要求定義では、利用者や顧客の視点から「システムで何を実現するか」というWHATを、ユースケース図、ユースケース記述、アクティビティ図などによって明らかにした。要件定義では、これらの要求モデルを出発点として、「その機能を実現するためにシステム内部に何が必要か」を考え、分析モデルへ具体化していく。
ヨリソル上の解説教材
コマ主題細目 ① 要求モデルから分析モデルへ ― ロバストネス分析 ② オブジェクト間の協力の明確化 ― 相互作用の分析 ③ 分析結果の統合 ― 分析レベル・クラス図への展開
細目レベル ① 要求定義では、利用者や顧客の視点から「システムで何を実現するか」というWHATを、ユースケース図、ユースケース記述、アクティビティ図などによって明らかにした。要件定義では、これらの要求モデルを出発点として、「その機能を実現するためにシステム内部に何が必要か」を考え、分析モデルへ具体化していく。ただし、この段階ではJavaのクラスやデータベースなど具体的な実装方法はまだ決定しない。そのための方法がロバストネス分析であり、必要な役割をboundary、control、entityの三つに分類する。boundaryはアクタとシステムの窓口、controlはユースケース全体の処理を調整する役割、entityはシステムが記録・参照・更新する業務上の情報を表す。「履修登録する」の例では、履修登録画面がboundary、履修登録処理がcontrol、学生・開講科目・履修がentityとなる。この分類によって、画面、業務処理、業務情報の責任を分け、要求から設計へ一気に飛ばずに、システム内部で必要となる役割を段階的に明らかにできる。
② ロバストネス分析によってboundary、control、entityの候補を発見しても、それだけではユースケースを実現できるかどうかは分からない。そこで、オブジェクトがどのような順序で協力するのかを相互作用として分析する。相互作用では、「誰が、誰に、何を依頼するのか」をメッセージとして表し、ユースケース記述の基本系列や代替系列を一文ずつ読み替えていく。「履修登録する」では、学生が履修登録画面を通じて科目を指定し、画面が履修登録処理へ処理を依頼する。履修登録処理は、学生、開講科目、履修などのentityへ必要な確認や更新を依頼し、最後に結果を画面へ返す。この関係をコミュニケーション図として表現し、メッセージ番号によって処理順序を示す。基本的にはactor→boundary→control→entity、そしてcontrol→boundaryという責任の受け渡しを考える。また、定員超過や二重登録などの代替系列についても相互作用を確認することで、誰が条件を判断し、どのように利用者へ結果を返すのかを明確にし、要求の不足や曖昧さを発見できる。
③ 要件定義では、一つのユースケースだけでなく、「履修登録する」「開講科目を検索する」など複数のユースケースについてロバストネス分析と相互作用の分析を行い、その結果をシステム全体の分析モデルへ統合する。各コミュニケーション図に登場したオブジェクトを集め、同じ業務概念を表すものを整理することで、分析レベル・クラス図を作成する。たとえば「開講科目」は複数のユースケースに登場しても、ユースケースごとに別のものとせず、共通するentityとして統合できるかを検討する。また、コミュニケーション図でオブジェクトが受信したメッセージは、そのオブジェクトが担う責務を示すため、クラスの操作候補を考える手掛かりとなる。ただし、この操作はJavaのメソッドとして確定したものではない。完成した分析モデルは要求モデルと照合し、基本系列・代替系列を説明できるか、役割分担やメッセージ順序に矛盾がないか、要求にない機能を追加していないかを確認する。疑問が生じた場合には要求定義へ戻り、顧客や利用者への確認を通じて要求と分析モデルの双方を修正していくことが重要である。
キーワード ① 要求定義、要件定義、システム分析、要求モデル、分析モデル、ロバストネス分析、boundary、control、entity、アクタ、役割、責任分担、WHAT、内部構造 ② 相互作用、コミュニケーション図、オブジェクト、メッセージ、送信元、受信先、actor、boundary、control、entity、履修登録、基本系列、代替系列、処理順序、責任、登録結果、要求の曖昧さ ③ 分析モデル、分析レベル・クラス図、コミュニケーション図、クラス、オブジェクト、メッセージ、操作、責務、統合、boundary、control、entity、要求モデル、整合性、代替系列、要求の曖昧さ、要求定義、基本設計
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：ロバストネス分析によってboundary、control、entityの候補を発見することをさまざまな例で体験しておくこと
★次回授業の予習：今回学んだ結果を文書としてまとめるのは、どのような形式がのぞましいのかを考えておくこと。
16 要件分析（２） 科目の中での位置付け 前半の学園祭入場受付システムによる要件具体化と、後半の高速バス予約システムによるシステム分析演習を通して、要件分析の本質を理解する
ヨリソル上の解説教材
コマ主題細目 ① 要求から要件へ ― UMLによる要件の具体化 ② 要求から内部構造へ ― ロバストネス分析と相互作用 ③ 相互作用からクラス構造へ ― 分析結果の統合
細目レベル ① 要件定義では、顧客や利用者が「こうしたい」と望む要求を出発点として、システムが満たすべき機能や条件を、顧客と開発者が確認できる具体的な要件へ変換する。学園祭入場受付システムの例では、まず「誰がシステムを使うのか」という問いから、来場者と受付スタッフをアクターとして発見する。次に、それぞれがシステムを利用して何を達成したいのかを考え、「入場登録をする」「QRコードを表示する」「入場を確認する」などのユースケースを抽出する。さらに、ユースケース記述によって事前条件、基本フロー、代替・例外フロー、事後条件を具体化し、アクティビティ図によって処理の順序、条件分岐、担当を可視化する。この過程では、無効なQRコード、QRコードの再利用、通信障害など、元の要求では明確でなかった状況が発見される。資料だけでは判断できない事項は開発者が勝手に決めず、顧客への確認事項とすることが重要であり、UMLは要件を表現するだけでなく、曖昧さや不足を発見して要件を洗練するための手段として活用される。
② 要件定義をシステム分析として進める段階では、要求定義で明らかにした「利用者が何をしたいか」から一歩進み、その機能を実現するためにシステム内部でどのようなオブジェクトが必要で、それらがどのように協力するかを考える。高速バス予約システムの「予約する」を例に、まずユースケース記述を読み、必要なオブジェクトを発見してactor、boundary、control、entityの役割に分類する。乗客はactor、予約画面はboundary、予約処理はcontrol、乗客・便・座席・座席種類・予約などはentityとして整理される。次に、ユースケース記述を「誰が、誰に、何を頼むか」というメッセージへ読み替え、予約画面から予約処理、さらに座席、便、座席種類、予約へと処理を依頼する関係をコラボレーション図で表現する。この相互作用を考えることで、「追加料金は誰が保持するのか」といった疑問から新たなクラスの必要性に気づく場合もある。したがって、クラスの発見と相互作用の分析を行き来しながら、要求を実現するための責任分担を具体化することが重要となる。
③ 個々のユースケースについてオブジェクトと相互作用を分析した後は、その結果を統合してシステム全体の分析レベル・クラス図へ発展させる。「予約する」の分析では、各オブジェクトが受け取るメッセージから、「予約可能か確認する」「基本運賃を取得する」「追加料金を取得する」「予約を登録する」など、そのクラスが持つべき操作の候補を導く。同じ分析手順を「予約内容を確認する」「便を検索する」「予約をキャンセルする」「便を管理する」「座席を管理する」「車両を管理する」などのユースケースにも適用し、必要なクラスや操作を発見する。複数のユースケースで同じentityが登場する場合は、それらを共通のクラスとして統合し、クラス間の関係や多重度も確認する。最終的には、要求仕様、ユースケース記述、オブジェクト、ロバストネス分析、コラボレーション図、操作、分析レベル・クラス図が相互に対応していることを確認する。この段階で得られるクラスや操作は実装上のJavaクラスやメソッドとして確定したものではなく、要求を実現するために必要な構造と責務を分析した結果であり、具体的な実現方法は次の基本設計以降で決定する。
キーワード ① 要求、要件、要件定義、UML、アクター、役割、ユースケース、ユースケース図、ユースケース記述、アクティビティ図、基本フロー、代替フロー、例外フロー、QRコード、判断ノード、スイムレーン、要件の曖昧さ、不足要件、顧客への確認事項 ② 要件定義、システム分析、ユースケース記述、オブジェクト、actor、boundary、control、entity、ロバストネス分析、相互作用、メッセージ、コラボレーション図、コミュニケーション図、責任分担 ③ 分析レベル・クラス図、クラス、操作、責務、受信メッセージ、コラボレーション図、コミュニケーション図、ユースケース、entity、クラス間の関係、多重度、分析結果の統合、要求仕様、基本設計
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：今回実施した演習の内容を見直し、何を習得することによって要件定義が可能となるのかについて学ぶこと
★次回授業の予習：次回からは設計の授業となる。要件定義で扱うことと基本設計で扱うことの差を考えておくこと
17 基本設計の目的と設計原則 ― 要件から責務へ 科目の中での位置付け 基本設計の考え方を理解し、システム全体の構造を決め、ユースケースをクラスの協調へ具体化して評価するという基本設計の流れを理解し、要件分析から詳細設計へ進む流れを理解する
ヨリソル上の解説教材
コマ主題細目 ① 基本設計の目的と設計原則 ― 要件から責務へ ② システム全体の構造設計 ― アーキテクチャと多層化 ③ ユースケースの実現と設計評価 ― 相互作用からクラス構造へ
細目レベル ① 基本設計は、要件分析で明らかにした「システムとして何が必要か」を、品質要求や実装上の制約を考慮しながら「どのような構造で実現するか」へ具体化する工程である。単に分析モデルをプログラムへ置き換えるのではなく、実装・テスト・保守まで見通し、変更の影響が広がりにくいソフトウェアの骨格を決めることが重要となる。履修管理システムでは、「履修登録する」という一つの要求にも、学生との画面上のやり取り、処理全体の進行、定員・二重登録・履修上限などの業務ルール、データの保存・取得といった性質の異なる責務が含まれる。そこで、要求から必要な責務を発見し、性質ごとに分離したうえで適切な層やクラスへ割り当てる。設計では、抽象化と詳細化によって段階的に具体化し、モジュール化、関心事の分離、情報隠蔽、高凝集・低結合を意識する。関係の深い責務をまとめ、変更理由の異なる責務を分け、部品間を必要最小限の依存関係で結ぶことによって、理解・変更・テスト・保守のしやすい構造を目指す。
② 個々のクラスを設計する前に、システム全体をどのような主要部分に分け、それぞれにどの責務を持たせ、どの方向に依存させるかを決める必要がある。この基本構造がソフトウェアアーキテクチャである。アーキテクチャは好みで選ぶのではなく、主要機能、品質要求、技術制約、運用条件などのアーキテクチャドライバを考慮して決定する。履修管理システムでは、画面の変更容易性、履修ルールのテスト容易性、アクセス集中への対応などが構造上の重要な判断材料となる。本資料では多層アーキテクチャを採用し、ユーザインタフェース層、処理制御層、業務層、データアクセス層の4層に責務を分ける。UI層は利用者との入出力、処理制御層はユースケース全体の進行、業務層は履修制度に関する判断、データアクセス層はデータの保存・取得を担当する。さらに、Domainが特定の画面技術に依存しないよう依存方向を整理することで、画面、業務ルール、データ保存方式などを独立して変更しやすくする。多層化の目的は層数そのものではなく、責務と依存関係を明確にして変更の影響を局所化することにある。
③ システム全体のアーキテクチャを決めた後は、その構造の中で個々のユースケースをどのように実現するかを具体化する。「履修登録する」では、分析モデルの履修登録画面、履修登録処理、学生、開講科目、履修などを、EnrollmentUI、EnrollmentControl、Student、CourseOffering、Enrollment、EnrollmentRepositoryなどの設計要素へ対応付ける。そしてユースケースの各ステップに含まれる責務を分解し、シーケンス図を用いて、どのオブジェクトがどの順序で誰に処理を依頼するかを具体化する。定員超過や二重登録、履修上限超過などの代替系列も設計対象とし、業務上の判断と利用者への表示を異なる責務として扱う。シーケンス図で受信したメッセージはクラスの操作候補となり、設計レベル・クラス図へ反映する。さらに、関連するクラスをパッケージとして整理し、循環依存などを避けながらシステム全体の依存関係を整える。最後に、UI変更、履修ルール変更、アクセス集中、DB変更などの変更シナリオを用いて、変更の影響が局所化され、高凝集・低結合が実現されているかを評価し、必要に応じて設計を見直す。
キーワード ① 基本設計、要件分析、What、How、責務、抽象化、詳細化、モジュール化、関心事の分離、情報隠蔽、凝集度、結合度、高凝集、低結合、変更容易性 ② ソフトウェアアーキテクチャ、アーキテクチャドライバ、品質要求、機能要求、技術制約、運用制約、多層アーキテクチャ、ユーザインタフェース層、処理制御層、業務層、データアクセス層 ③ ユースケース実現、分析モデル、設計モデル、追跡可能性、設計クラス、設計レベル・クラス図、操作、パッケージ、循環依存、変更シナリオ、設計評価責務分担、シーケンス図、相互作用、メッセージ、代替系列、
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：各種のソフトウェアアーキテクチャについて調べ、その特徴について理解しておくべきこと
★次回授業の予習：基本設計の結果を表現する図式について、あらかじめ学んでおきましょう。
18 基本設計（２） 科目の中での位置付け 分析モデルをそのままコードへ写すのではなく、品質要求や変更容易性・テスト容易性を考えながらクラスを追加・再配置し、責務、依存方向、相互作用を具体化した設計モデルへ変換することを学ぶ
ヨリソル上の解説教材
コマ主題細目 ① 分析モデルから設計モデルへ ― アーキテクチャと責務の具体化 ② ユースケースの実現設計 ― シーケンス図・クラス図・状態図 ③ 設計の統合と評価 ― システム全体の設計モデルへ
細目レベル ① 基本設計では、要件分析で得られたBoundary・Control・Entityや分析レベル・クラス図をそのまま実装へ移すのではなく、変更容易性、テスト容易性、実装容易性などを考慮して設計モデルへ変換する。本演習では遠距離バス予約システムをUI、Application、Domain、Data Sourceの4層に分け、各クラスの責務と依存方向を整理する。UIは利用者との入力・表示、Applicationはユースケース全体の進行、Domainは予約・便・座席などの業務情報と業務ルール、Data Sourceはデータの保存・取得を担当する。また、高凝集・低結合、関心事の分離、適切な依存方向を設計の基本原則とし、画面表示、業務判断、データ保存など、変更理由の異なる責務を分離する。さらに、分析モデルには十分現れていなかったRepositoryなどのクラスを設計上必要な要素として追加する。重要なのは分析モデルを機械的にJavaクラスへ変換することではなく、「どこに置くか」「何を担当させるか」「誰に依存させるか」を設計上の理由とともに決めることである。
② システム全体の構造を決めた後は、個々のユースケースについて、オブジェクトがどのように協調して機能を実現するかを具体化する。「遠距離バスを予約する」では、分析モデルの予約画面、予約処理、乗客、便、座席、座席種類、予約を、それぞれReservationUI、ReservationControl、Passenger、BusTrip、Seat、SeatType、Reservationなどの設計要素へ対応付け、さらに保存・検索を担当するReservationRepositoryを追加する。次にシーケンス図を用いて、予約入力、予約可能性の確認、基本運賃・追加料金の取得、予約生成、保存、結果返却という呼出し順序を具体化する。ControlからUIへ表示を命令するのではなく、処理結果を戻り値として返し、UI自身が表示する構造にすることで双方向依存を避ける。シーケンス図で受信したメッセージはクラスの操作として設計レベル・クラス図へ反映する。また、Reservationのように時間とともに状態が変化する重要なオブジェクトについては、ステートチャート図を用いて「予約手続中」「有効」「キャンセル済」などの状態と遷移を整理し、三つのUML図の整合性を確認する。
③ 個々のユースケースについて基本設計を行った後は、それぞれの成果を統合し、遠距離バス予約システム全体として一貫した設計モデルを構築する。本演習では、「便を検索する」「予約をキャンセルする」「車両を管理する」「座席を管理する」「便を管理する」などをグループごとに設計し、UI、Application、Domain、Data Sourceへの配置、Repositoryの追加、依存方向、シーケンス図、設計レベル・クラス図などを作成する。統合時には、同じ意味のクラスが別名で重複していないか、一つのクラスへ責務が集中していないか、層間の依存方向が一貫しているか、Entity間の関連や多重度が分析モデルと矛盾していないかを確認する。また、クラス図・シーケンス図・ステートチャート図を突き合わせ、メッセージ、操作、状態遷移が相互に対応しているかを検証する。さらに、UI変更、DB製品変更、料金計算変更などの変更シナリオを用いて、変更の影響が特定の層やクラスへ局所化されているかを評価する。この評価を通じて、高凝集・低結合や関心事の分離が実際の設計として実現できているかを確認し、必要に応じて設計を修正する。
キーワード ① 基本設計、分析モデル、設計モデル、アーキテクチャ、4層アーキテクチャ、高凝集、低結合、関心事の分離、依存方向、責務、変更容易性、テスト容易性、追跡可能性 ② シーケンス図、メッセージ、戻り値、双方向依存、設計レベル・クラス図、操作、正常系列、代替系列、ステートチャート図、ステートマシン図、状態、状態遷移 ③ 設計レベル・クラス図、シーケンス図、ステートチャート図、整合性、関連、多重度、依存関係、変更シナリオ、設計評価、高凝集、低結合、変更の局所化
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：第17回で学んだ基本設計の考え方を今回のような実例を用いて、作業をしてみてください。
★次回授業の予習：次回は、詳細設計を学びます。サステナブルソフトウェア概論の詳細設計を読んでみてください。
19 詳細設計（1） 科目の中での位置付け クラスの構造を実装可能な形にし、振舞い・異常系・状態を具体化し、変更・テストを意識して設計を仕上げるという基本設計から実装への流れを明確に理解する
ヨリソル上の解説教材
コマ主題細目 ① クラス構造の詳細化 ― 実装可能なデータと関連の設計 ② 振舞いの詳細化 ― メソッド・例外・状態・アルゴリズム ③ 変更・テストを考慮した詳細設計 ― 依存関係と品質の確認
細目レベル ① 詳細設計は、基本設計で決めたアーキテクチャ、主要クラス、依存関係、相互作用を保ちながら、各クラスをJavaで実装できる粒度まで具体化する工程である。単にクラス図をコードへ置き換えるのではなく、属性の型、初期値、nullの可否、値の範囲、可視性、コンストラクタ、生成条件などを決定し、オブジェクトが常に正しい状態を保てるようにする。フィールドは原則privateとし、すべての属性に機械的にgetter/setterを設けるのではなく、業務上意味のある操作を公開することでカプセル化を実現する。また、クラス図の関連をJavaの参照やコレクションへ変換し、1対多ではList、Set、Mapなどを目的に応じて選択する。双方向関連についても、クラス図に関連線があるという理由だけで両方向の参照を持たせず、実際のユースケースやシーケンス図から必要性を判断する。さらに、オブジェクトの同一性と等価性を明確にし、equalsやhashCodeへの影響も考慮する。このように、正しい状態をどのクラスが責任を持って維持するのかを具体化することが、クラス内部とクラス間関係の詳細設計の中心となる。
② クラスの構造を具体化した後は、オブジェクトがどのように振る舞い、互いに協調するかを実装可能な形へ詳細化する。基本設計のシーケンス図で交換されていたメッセージをメソッドの候補とし、メソッド名、引数、戻り値、副作用、事前条件、事後条件、例外などを決定する。特に、成功・失敗だけをbooleanで返すのではなく、定員超過、二重登録、履修上限超過などを区別できる結果型を設けるなど、呼び出し側が適切に処理できる仕様を考える必要がある。また、正常系だけでなく、存在しないID、DB接続失敗、入力形式不正などの異常系について、どの層で検出し、どのような形で上位へ伝えるかを設計する。さらに、Enrollmentの「登録済」「取消済」「修了」のように状態によって許される操作が変化する場合には、状態と状態遷移を明確にし、不正な状態を表現できないようenumなどを利用する。最後に、「履修可能か確認する」といった抽象的な処理を具体的な処理手順へ分解し、必要に応じて擬似コードを用いて、実装者が迷わない粒度までアルゴリズムを明確化する。
③ 詳細設計では、機能を実装できるだけでなく、変更しやすくテストしやすい構造にすることも重要である。たとえばEnrollmentControlが特定のデータベース実装へ直接依存すると、DB変更や単体テストが困難になるため、EnrollmentRepositoryをインタフェースとして定義し、実際のDBアクセス実装とテスト用実装を差し替えられるようにする。この考え方は依存関係逆転の原則につながる。また、日時にはLocalDateTime、コレクションにはList・Set・Mapなど、信頼できる標準ライブラリを適切に再利用する。設計を評価する際には、SOLIDを単なる規則として適用するのではなく、責務が混在していないか、拡張時に大量の修正が必要にならないか、具体的なDB実装へ強く依存していないかなどを考えるための問いとして利用する。さらに、変更容易性、テスト容易性、性能、セキュリティ、信頼性、並行性などの非機能要求もクラス設計へ反映する。詳細設計で定めた事前条件、事後条件、不変条件、例外、状態遷移はそのまま単体テストの観点となり、設計とテストを結び付けることで実装前に責務や依存関係の問題を発見できる。
キーワード ① 詳細設計、基本設計、クラス、属性、型、可視性、カプセル化、private、コンストラクタ、不変条件、双方向関連、同一性、等価性 ② 振舞い、シーケンス図、メッセージ、メソッド仕様、引数、戻り値、副作用、事前条件、事後条件、契約、結果オブジェクト、例外、エラー処理、正常系、異常系、状態、状態遷移 ③ インタフェース、依存関係、変更容易性、テスト容易性、性能、セキュリティ、信頼性、並行性、非機能要求、単体テスト、境界値、設計レビュー
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：基本設計で決めた「ソフトウェア全体の構造」を、実装担当者が大きな追加判断をしなくてもコードへ落とせる「各部品の仕様」へ変換することの様相を理解してください。
★次回授業の予習：さまざまな練習問題について、詳細設計を試みてください。
20 詳細設計（2） 科目の中での位置付け 基本設計を実装可能なクラス構造へ具体化し、オブジェクトの協調と振舞いを具体化し、複数の設計図を照合して実装へつなぐという前回学んだ詳細設計の考え方を演習を通して身につける
ヨリソル上の解説教材
コマ主題細目 ① 基本設計から実装可能なクラス設計へ ② オブジェクトの協調と振る舞いの詳細化 ③ 設計レビューと要求から実装への接続
細目レベル ① 詳細設計では、基本設計で決めたアーキテクチャ、責務、依存関係を保ちながら、Javaプログラマが重要事項を推測せずに実装できる粒度までクラスを具体化する。本資料では、遠距離バス予約システムをUI、Application、Domain、Data Sourceの4層に分け、それぞれをJavaのパッケージへ対応させる。詳細クラス図では、クラス名だけでなく、属性の型、private・publicなどの可視性、関連オブジェクト、メソッド名、引数、戻り値まで明確にする。たとえばReservationには予約番号、予約日時、運賃、予約状態、乗客、便、座席などを持たせ、状態には任意の文字列ではなくReservationStatusというenumを利用する。また、保存・検索の責務はRepositoryへ分離し、interfaceとして操作を定義することで、ApplicationやDomainを特定のDB製品やSQLから切り離す。詳細設計では、コードのすべてを事前に記述するのではなく、業務ルール、状態、責務、依存関係など、実装品質を左右する重要な設計判断を明確にすることが重要である。
② クラスの内部構造を決めた後は、要求された機能を複数のオブジェクトがどのように協調して実現するかを具体化する。「遠距離バスを予約する」という要求は、詳細設計ではReservationControlのreserve()を中心とした具体的なメソッド呼出しへ変換される。まずReservationRepositoryで同じ便・座席に有効な予約が存在しないか確認し、空席であればBusTripから基本運賃、Seatを通してSeatTypeから追加料金を取得し、運賃を計算する。その後Reservationを生成・保存し、処理結果をUIへ返す。この呼出し順序はシーケンス図で表現し、図中のメッセージが詳細クラス図のメソッドと対応していることを確認する。また、「定員を超えて座席を追加できない」といった業務ルールは、その判断に必要な情報を持つDomainクラス自身に置くことを基本とする。さらに、アクティビティ図でメソッド内部の分岐や処理手順を確認し、ステートマシン図によってReservationのACTIVEからCANCELEDへの状態遷移を設計する。このように静的なクラス構造だけでなく、処理順序、分岐、状態変化まで具体化することで実装可能な振舞いを明確にする。
③ 詳細設計は、個々の図を完成させれば終了するのではなく、複数の設計成果物を相互に照合し、矛盾や責務の誤りがないかをレビューする必要がある。シーケンス図でメッセージを受け取るクラスには対応するメソッドがクラス図に存在し、クラス図の関連や依存関係は実際の呼出しと整合していなければならない。また、ステートマシン図の状態はenumなどのクラス設計と対応し、状態遷移を起こすイベントはメソッドとして表現される必要がある。アクティビティ図の分岐や処理順序についても、シーケンス図と矛盾していないか確認する。レビューでは、DomainからData Sourceへの不適切な依存、クラス図に存在しない操作の呼出し、要求にない状態遷移などを発見して修正する。さらに、キャンセル可能期限、存在しない予約番号への対応、管理機能の権限など、設計技術だけでは決められない事項は設計者が独断で決定せず、「要求確認待ち」として要求側へ戻す。こうして、要求、要件分析、基本設計、詳細設計を追跡可能な形でつなぎ、実装者が迷わずJavaコードへ移行できる状態にすることが詳細設計の最終的な役割である。
キーワード ① 詳細設計、基本設計、Java、4層構造、パッケージ、詳細クラス図、属性、型、可視性、引数、戻り値 ② オブジェクト協調、振舞い、業務ルール、Domain、シーケンス図、メッセージ、メソッド、アクティビティ図、分岐、ステートマシン図 ③ 設計レビュー、整合性、クラス図、シーケンス図、アクティビティ図、ステートマシン図、メソッド、状態、依存関係、業務ルール、要求確認、未確定要求、追跡可能性
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：詳細設計を単に「基本設計をもっと詳しく書くこと」と考えるのではなく、要求や基本設計で決めた責務・構造を維持しながら、実装時に必要となる重要な判断をコードを書く前に明確にすることを再度体感してみること
★次回授業の予習：次回からは、実装の説明に移るので、Javaの文法書に目を通しておくこと
21 実装（１） 科目の中での位置付け 「Javaで動くプログラムを書くこと」そのものではなく、詳細設計で決めた責務、カプセル化、依存方向、オブジェクト間の協調を壊さずにJavaコードとして表現する実装の基本について学ぶ
ヨリソル上の解説教材
コマ主題細目 ① 詳細設計からJavaコードへ ― クラス・関連・カプセル化の実装 ② 責務とオブジェクト協調の実装 ― シーケンス・状態・Repository ③ 良い実装の評価 ― 設計整合性・トレーサビリティ・コードレビュー
細目レベル ① 実装は、詳細設計で決めたクラス、責務、相互作用を、設計意図を保ったままJavaコードとして実現する工程である。実装時に一から設計し直すのではなく、UMLクラス図のクラスをclass、属性をフィールド、操作をメソッド、関連をオブジェクト参照やコレクションへ対応させ、設計とコードの対応関係を確認しながら進める。本資料ではInside-Outの考え方に基づき、まずStudent、Enrollment、CourseOfferingなど比較的安定したDomainを実装し、その後Application、UIへ進む。フィールドをprivateにするのは単にデータを隠すためではなく、状態変更をそのオブジェクト自身のメソッドへ集約し、不正な状態を防ぐためである。たとえばEnrollmentの状態は外部から直接変更させず、cancel()を通して変更する。また、クラス図の1対1や多対1の関連はオブジェクト参照、1対多の関連はListなどのコレクションとして具体化する。ただし、多重度を機械的に特定のデータ構造へ変換するのではなく、順序、重複、検索方法などの仕様に応じて適切な実現方法を選ぶことが重要である。
② オブジェクト指向の実装では、処理を一つのControlやmainへ集めるのではなく、「この処理は誰の仕事か」を考え、詳細設計で決めた責務分担をコードでも維持する必要がある。たとえば開講科目の定員判定は、定員や現在の履修状況を知るCourseOffering自身に担当させ、外部のApplicationが内部データを取り出して判定しないようにする。また、シーケンス図の矢印はJavaではオブジェクト間のメソッド呼出しとして実装する。EnrollmentControlはユースケース全体の進行を調整し、Repositoryによる既存履修の確認、CourseOfferingへの登録可能性の問い合わせ、Enrollmentの生成・保存などを順に行う。一方、履修状態などの業務知識はDomainに保持する。ステートマシン図で示されたREGISTEREDからCANCELEDへの遷移は、EnrollmentStatusというenumとcancel()の処理として実現する。さらにRepositoryをinterfaceとして実装することで、Applicationを具体的な保存方法から切り離し、最初はListやMapによるメモリ保存を利用しながら、将来RDBへ変更しても業務ロジックへの影響を抑えられる構造とする。
③ ソフトウェア工学における実装では、「コンパイルできた」「実行できた」だけで完成とはいえない。要求された機能を正しく実現しているか、詳細設計で決めたクラス、属性、メソッド、関連、相互作用がコードへ反映されているか、責務やカプセル化が守られているか、さらに変更容易性やテスト容易性が確保されているかを確認する必要がある。その際に重要なのがトレーサビリティである。たとえば「同じ学生が同じ開講科目を二重登録できない」という要求は、基本設計の履修可能判定、詳細設計のEnrollmentRepository.findActive()、実装のEnrollmentControl.register()、さらに二重登録を確認するテストまで追跡できることが望ましい。また、コードレビューでは「動くか」だけでなく、「この仕事をこのクラスに担当させてよいか」を問い、状態管理が外部へ漏れていないか、一つのクラスへ責務が集中していないかを確認する。単一責任、情報隠蔽、高凝集・低結合、依存の抽象化などの設計原則をコードでも維持することで、変更・テスト・保守のしやすい実装につなげる。
キーワード ① 実装、詳細設計、Java、Inside-Out、Domain、Application、UI、UML、クラス図、class、フィールド、メソッド、可視性、private、カプセル化、責務、オブジェクト参照、関連、多重度 ② 責務分担、オブジェクト協調、シーケンス図、メッセージ、メソッド呼出し、業務ルール、ステートマシン図、状態遷移 ③ 設計整合性、要求との整合、トレーサビリティ、コードレビュー、責務、カプセル化、単一責任、情報隠蔽、高凝集、低結合、変更容易性、テスト容易性、依存の抽象化、要求、基本設計、詳細設計、実装、テスト、リファクタリング、保守
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：実際に作成したJavaプログラムのテスト／デバッグを試みてみよう。
★次回授業の予習：次回は実装についての演習を行うので、あらかじめ簡単な例でOKなので、自ら演習をしてみよう。
22 実装（２） 科目の中での位置付け 「Javaで動くプログラムを書くこと」そのものではなく、詳細設計で決めた責務、カプセル化、依存方向、オブジェクト間の協調を壊さずにJavaコードとして表現することを実感する。
ヨリソル上の解説教材
コマ主題細目 ① 詳細設計からJavaコードへ ― クラス・関連・カプセル化の実装 ② 責務とオブジェクト協調の実装 ― シーケンス・状態・Repository ③ 良い実装の評価 ― 設計整合性・トレーサビリティ・コードレビュー
細目レベル ① 実装は、詳細設計で決めたクラス、責務、相互作用を、設計意図を保ったままJavaコードとして実現する工程である。実装時に一から設計し直すのではなく、UMLクラス図のクラスをclass、属性をフィールド、操作をメソッド、関連をオブジェクト参照やコレクションへ対応させ、設計とコードの対応関係を確認しながら進める。本資料ではInside-Outの考え方に基づき、まずStudent、Enrollment、CourseOfferingなど比較的安定したDomainを実装し、その後Application、UIへ進む。フィールドをprivateにするのは単にデータを隠すためではなく、状態変更をそのオブジェクト自身のメソッドへ集約し、不正な状態を防ぐためである。たとえばEnrollmentの状態は外部から直接変更させず、cancel()を通して変更する。また、クラス図の1対1や多対1の関連はオブジェクト参照、1対多の関連はListなどのコレクションとして具体化する。ただし、多重度を機械的に特定のデータ構造へ変換するのではなく、順序、重複、検索方法などの仕様に応じて適切な実現方法を選ぶことが重要である。
② オブジェクト指向の実装では、処理を一つのControlやmainへ集めるのではなく、「この処理は誰の仕事か」を考え、詳細設計で決めた責務分担をコードでも維持する必要がある。たとえば開講科目の定員判定は、定員や現在の履修状況を知るCourseOffering自身に担当させ、外部のApplicationが内部データを取り出して判定しないようにする。また、シーケンス図の矢印はJavaではオブジェクト間のメソッド呼出しとして実装する。EnrollmentControlはユースケース全体の進行を調整し、Repositoryによる既存履修の確認、CourseOfferingへの登録可能性の問い合わせ、Enrollmentの生成・保存などを順に行う。一方、履修状態などの業務知識はDomainに保持する。ステートマシン図で示されたREGISTEREDからCANCELEDへの遷移は、EnrollmentStatusというenumとcancel()の処理として実現する。さらにRepositoryをinterfaceとして実装することで、Applicationを具体的な保存方法から切り離し、最初はListやMapによるメモリ保存を利用しながら、将来RDBへ変更しても業務ロジックへの影響を抑えられる構造とする。
③ ソフトウェア工学における実装では、「コンパイルできた」「実行できた」だけで完成とはいえない。要求された機能を正しく実現しているか、詳細設計で決めたクラス、属性、メソッド、関連、相互作用がコードへ反映されているか、責務やカプセル化が守られているか、さらに変更容易性やテスト容易性が確保されているかを確認する必要がある。その際に重要なのがトレーサビリティである。たとえば「同じ学生が同じ開講科目を二重登録できない」という要求は、基本設計の履修可能判定、詳細設計のEnrollmentRepository.findActive()、実装のEnrollmentControl.register()、さらに二重登録を確認するテストまで追跡できることが望ましい。また、コードレビューでは「動くか」だけでなく、「この仕事をこのクラスに担当させてよいか」を問い、状態管理が外部へ漏れていないか、一つのクラスへ責務が集中していないかを確認する。単一責任、情報隠蔽、高凝集・低結合、依存の抽象化などの設計原則をコードでも維持することで、変更・テスト・保守のしやすい実装につなげる。
キーワード ① 実装、詳細設計、Java、Inside-Out、Domain、Application、UI、UML、クラス図、class、フィールド、メソッド、可視性、private、カプセル化、責務、オブジェクト参照、関連、多重度 ② 責務分担、オブジェクト協調、シーケンス図、メッセージ、メソッド呼出し、業務ルール、Domain、Application、ステートマシン図、状態遷移 ③ 設計整合性、要求との整合、トレーサビリティ、コードレビュー、責務、カプセル化、単一責任、情報隠蔽、高凝集、低結合、変更容易性、テスト容易性、依存の抽象化、要求、基本設計、詳細設計、実装、テスト、リファクタリング、保守
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：さまざまな例について、実装を試みること
★次回授業の予習：次週からはテストについて扱う。サステナブル・ソフトウェア概論のテストについてめを通しておくこと
23 テスト（１） 科目の中での位置付け テストケースは思いつきで選ぶのではなく、要求・仕様・状態・プログラム構造・設計モデルを根拠として選ぶことの重要さを実感する
ヨリソル上の解説教材
コマ主題細目 ① ソフトウェアテストの基礎 ― 根拠を持ったテストケース設計 ② オブジェクト指向プログラムのテスト ― 状態・協調・継承を確認する ③ 設計モデルからテストへ ― テストケース設計とJUnitへの接続
細目レベル ① ソフトウェアテストは、プログラムを一度実行して「動いた」と確認するだけの作業ではなく、ソフトウェアを実行して欠陥を発見し、要求や設計に対して正しく作られているかを確認する活動である。人的過誤、欠陥、故障、エラーを区別するとともに、「正しくソフトウェアを作れているか」を確認するVerificationと、「正しいソフトウェアを作れているか」を確認するValidationという二つの視点を持つ必要がある。現実にはすべての入力値、状態、実行経路を試すことは不可能なため、テストケース自体を設計し、重要な欠陥を発見しやすいケースを効率的に選択する。テストは単体・結合・システム・受け入れという工程、動的・静的という実行の有無、ブラックボックス・ホワイトボックスというケース選択の根拠から分類できる。ブラックボックステストでは、同値分割、境界値分析、エラー推測、デシジョンテーブルなどを用い、仕様上同じ扱いとなる値や、条件が切り替わる境界を重点的に選ぶことで、少ないケースから効果的に欠陥を発見することを目指す。
② オブジェクト指向プログラムでは、個々のメソッドについて入力と出力を確認するだけでは十分ではない。オブジェクトは内部に状態を持ち、メソッドの実行によってその状態が変化するため、同じメソッドでも実行前の状態によって結果が異なる場合がある。SeatClassの例では、空席数10からdecrementVacancy()を実行した場合だけでなく、最後の1席である1から0への変化や、すでに0の状態で実行しても0のままであることまで確認する必要がある。また、ホワイトボックステストでは、命令網羅、分岐網羅、条件網羅などを用いて内部構造を確認し、if文のtrue側とfalse側の双方を通るケースを選択する。さらに、オブジェクト指向では複数のオブジェクトが協調して機能を実現するため、シーケンス図を根拠として呼出し順序や情報の受け渡しもテスト対象となる。依存先をスタブやモックへ置き換えれば、対象クラスの責務に集中した単体テストが可能になる。継承を利用する場合には、サブクラスが親クラスの契約を満たしているか、ポリモーフィズムによる動的束縛が期待どおりに機能するかも確認する。
③ テストコードを書く前には、まず「何を試すか」「どの状態から始めるか」「何を操作するか」「どの結果を期待するか」を整理し、根拠のあるテストケースを設計する必要がある。SeatClassでは、無効値、境界値、通常値、状態遷移、分岐などの観点を組み合わせ、初期空席数－1、0、1、100や、2→1、1→0、0→0といったケースを選択する。また、これまで作成した設計モデルはテスト設計の重要な根拠となる。クラス図からはクラス・属性・操作・関連、シーケンス図からはオブジェクト間の呼出し順序や引数、ステートマシン図からは状態・イベント・状態遷移、ユースケースからは利用者視点の機能全体を読み取ることができる。これにより、メソッド、状態変化、オブジェクト間の協調、ユースケース全体という4段階でテストを考え、単体テストから結合・システムテストへ視野を広げられる。JUnitは、こうして人が設計したテストを繰り返し自動実行し、期待値と実際値を比較するための道具であり、テストケースそのものを自動的に考えてくれるものではない。
キーワード ① ソフトウェアテスト、テストケース、人的過誤、欠陥、故障、エラー、Verification、Validation、検証、妥当性確認、単体テスト、結合テスト、システムテスト、受け入れテスト、動的テスト、静的テスト、ブラックボックステスト、ホワイトボックステスト、同値分割、境界値分析、エラー推測、デシジョンテーブル ② オブジェクト指向テスト、状態、状態遷移、SeatClass、空席数、decrementVacancy、ホワイトボックステスト、命令網羅、分岐網羅、条件網羅、カバレッジ、単体テスト、オブジェクト協調、相互作用、シーケンス図、スタブ、モック、継承、ポリモーフィズム、動的束縛 ③ テストケース設計、SeatClass、無効値、境界値、通常値、状態遷移、クラス図、シーケンス図、ステートマシン図、ユースケース、設計モデル、トレーサビリティ、メソッド、オブジェクト協調、単体テスト、結合テスト、システムテスト、JUnit、テスト自動化
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：オブジェクト指向と言っても、メソッドの中では、オブジェクト指向の特殊性は存在しない。つまりこれまでの知識で十分に対応可能であることを実感しておいてください。
★次回授業の予習：次回はテストの自動化を扱いますので、テストのメンドクササを感じておいてください。
24 テスト（２） 科目の中での位置付け 。「何をテストするか、どの結果を期待するか」を考えるのは人間であり、JUnitはそのテストを何度でも同じ条件で実行し、自動判定するための仕組みを理解する。
ヨリソル上の解説教材
コマ主題細目 ① JUnitによる単体テストの基礎 ― テストを自動化する ② テストケースのJUnit実装 ― 正常系・異常系・境界値・状態遷移 ③ JUnitを開発・保守に生かす ― 回帰テストとトレーサビリティ
細目レベル ① JUnitは、Javaプログラムのテストを自動化するためのテストフレームワークである。手作業では、プログラムを実行し、表示された結果を人間が期待結果と比較して合否を判断するが、JUnitでは期待値をテストコードとして記述し、実際値との比較と合否判定を自動化できる。重要なのは、JUnit自身が「何をテストすべきか」や「正しい答えは何か」を考えるわけではなく、要求仕様や詳細設計を根拠として人間が設計したテストケースを、繰り返し実行可能なプログラムにする点である。JUnitは特にクラスやメソッドを対象とする単体テストで利用され、EclipseではJUnit 5を用いてテストクラスを作成・実行できる。基本となる@Testはテストメソッドを指定し、assertEquals()などのアサーションによって期待値と実際値を比較する。さらに、テストコードをArrange（準備）、Act（実行）、Assert（確認）の三段階で整理すると、「どのような前提で、何を実行し、何を確認しているのか」が明確になり、読みやすく保守しやすいテストを作成できる。
② JUnitを利用する際には、前回設計した正常値、異常値、境界値、状態遷移などのテストケースを、そのまま実行可能なテストコードへ変換する。正常系では、たとえば複数の科目を登録した後の合計単位数が期待値と一致することをassertEquals()で確認する。一方、「同じ科目を二重登録できない」のような異常系では、例外が発生すること自体が正しい結果となるため、assertThrows()を用いて期待する例外を確認する。定員30人の科目では、通常の1人目だけでなく「30人目は登録できる」「31人目は登録できない」という条件の切り替わる境界の両側をテストすることで、比較演算子の誤りなどを発見しやすくなる。また、オブジェクト指向プログラムでは状態遷移も重要であり、ReservationがACTIVEからcancel()によってCANCELEDへ変化することなどをJUnitで確認する。テストが増えた場合は@BeforeEachを利用して共通の準備処理を整理し、各テストを独立した状態から実行する。JUnitはテストケースを考える道具ではなく、人間が設計した重要なケースを正確かつ繰り返し実行するための道具である。
③ JUnitの価値は、個々のテストを自動実行できることだけでなく、要求、詳細設計、実装、テストを対応付け、ソフトウェアの変更後にも同じ確認を繰り返せる点にある。たとえば「同じ科目を重複して履修できない」という要件は、Student.register()で重複を確認する詳細設計、重複時にIllegalStateExceptionを発生させる実装、同じ科目を2回登録するテストケース、assertThrows()によるJUnitテストへとつながる。この対応関係を保つことで、テストが失敗した際に、どの要求や設計上の約束が満たされていないかを追跡できる。また、仕様変更後には新しい機能だけを確認するのではなく、既存のテストもすべて再実行し、以前正常だった機能が壊れていないことを確認する。この回帰テストにおいて、自動テストは変更に対する安全網として機能する。さらに、テストを意図的に成功・失敗・再成功させる「緑→赤→緑」の演習を通じて、自動テストが欠陥を継続的に検出する仕組みを理解する。テストを実装より先に記述する考え方は、Red→Green→Refactorを繰り返すテスト駆動開発（TDD）への入口にもなる。
キーワード ① JUnit、JUnit 5、JUnit Jupiter、単体テスト、自動テスト、テストフレームワーク、Eclipse、テストクラス、@Test、assertEquals、期待値、実際値、アサーション、Arrange、Act、Assert、AAA、手作業テスト、テスト自動化 ② テストケース、JUnitコード、正常系、異常系、境界値、assertEquals、assertThrows、例外、二重登録、定員、境界値テスト ③ 回帰テスト、Regression Testing、トレーサビリティ、要求仕様、詳細設計、実装、テスト設計、JUnit、仕様変更、自動テスト、再実行、安全網、Green、Red、Refactor、テスト駆動開発、TDD、保守、変更容易性、テストコード
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：いつでもJUnitを使うことができるので、環境プログラミングで作成したプログラムをテストしてみてください。
★次回授業の予習：次回の授業から保守に移ります。サステナブル・ソフトウェア概論の保守の授業を復習してみてください。
25 保守（１） 科目の中での位置付け 「ソフトウェアは必ず変更される」ことを前提として設計・実装することを体感して、この変更にどのように備えるのかを学んでください。
ヨリソル上の解説教材
コマ主題細目 ① ソフトウェア保守の基礎 ― 4種類の保守と変更容易性 ② オブジェクト指向と保守性 ― 責務・カプセル化・高凝集・低結合 ③ ソフトウェア変更の実践 ― 影響分析と回帰テスト
細目レベル ① ソフトウェア保守とは、完成したプログラムの不具合を修理することだけではなく、運用開始後も業務、制度、利用者の要望、実行環境などの変化に対応し、ソフトウェアを継続して利用できるように修正・適応・改善する活動全体を指す。保守は、発見された不具合を直す「修正保守」、OS・データベース・外部APIなど周囲の環境変化へ対応する「適応保守」、新しい要求への対応や機能・性能・使いやすさを改善する「完全化保守」、将来の問題や変更困難を防ぐため内部構造を改善する「予防保守」の4種類に分類できる。特に適応保守と完全化保守は、変更の内容が似ていても、その契機が外部環境の変化なのか利用者の新しい要求なのかによって区別する。また、保守性を考えるうえでは変更容易性が重要であり、一つの要求変更に対して修正箇所を小さな範囲へ限定できる構造が望ましい。同じ業務ルールを複数箇所へ重複して記述するのではなく、その知識を適切な場所へ集約することで、修正漏れや矛盾を防ぎ、長期的に変更しやすいソフトウェアを実現できる。
② オブジェクト指向における責務分担、カプセル化、高凝集・低結合、ポリモーフィズムは、単なるプログラミング上の技法ではなく、将来の変更による影響を小さくして保守性を高めるための重要な考え方である。クラスの責務を考える際には、「何をするクラスか」だけでなく「どのような理由で変更されるか」に注目し、変更理由の異なる処理を一つのクラスへ集中させないことが重要となる。また、カプセル化はフィールドをprivateにするだけではなく、データに関する規則や判断もそのデータを持つクラスへ集め、変更を内部へ閉じ込める考え方である。関連するデータと処理をまとめる高凝集と、クラス間の不要な依存を減らす低結合によって、一つの変更が多数のクラスへ連鎖することを防ぎやすくなる。さらに、ポリモーフィズムやインタフェースを利用すると、呼び出し側が具体的な種類を判定する大きな条件分岐を減らし、新しい種類を既存コードの大幅な変更ではなく新しいクラスの追加によって実現できる場合がある。これにより、既存部分への変更を抑えながら機能を拡張でき、変更容易性と保守性の向上につながる。
③ 実際の保守では、変更要求を受けたからといって、すぐにソースコードを書き換えるのではなく、まず変更がシステムのどこへ影響するかを調査する必要があり、この作業を影響分析と呼ぶ。影響分析では、要求・要件の変更点、影響を受ける画面や機能、データやクラス、変更・追加が必要なメソッド、既存テストへの影響、新しく必要となるテストなどを確認する。たとえば履修管理システムに「科目ごとの定員」を追加する場合、Courseに定員属性を追加するだけではなく、履修登録処理、画面表示、データ保存、定員超過時のエラー処理、境界値テストなどまで影響する可能性がある。変更後には、新しく追加・修正した機能をテストするだけでなく、以前正常に動作していた機能が壊れていないことを確認するため、既存テストを再実行する回帰テストが必要となる。JUnitなどによってテストが自動化されていれば、多数の既存テストを短時間で繰り返し実行できる。したがって保守では、「変更要求→影響分析→設計・コードの変更→変更部分のテスト→回帰テスト」という流れを守り、変更の影響を把握しながら安全にソフトウェアを進化させることが重要である
キーワード ① ソフトウェア保守、修正保守、適応保守、完全化保守、予防保守、不具合、外部環境、新しい要求、リファクタリング、保守性、変更性、変更容易性、変更の局所化、修正漏れ ② オブジェクト指向、保守性、責務、責務分担、変更理由、カプセル化、情報隠蔽、高凝集、低結合、依存関係、変更の局所化、ポリモーフィズム、多態性、継承、is-a関係、インタフェース、interface、動的束縛、条件分岐、変更容易性、拡張性 ③ ソフトウェア変更、変更要求、影響分析、要求、要件、クラス、メソッド、データ、テスト、変更範囲、履修管理システム、定員、境界値テスト、回帰テスト、リグレッションテスト、自動テスト、変更の影響、保守プロセス、ソフトウェア進化
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：さまざまな例題ソフトウェアに対して、変更対象となる原因を考え、変更を加えてみよう。
★次回授業の予習：次回は、遠距離バスの予約システムを例題にして学ぶので、この予約システムの仕様に目を通しておこう。
26 保守（２） 科目の中での位置付け 変更要求を受けてすぐコードを修正するのではなく、「現行仕様を理解する → 差分を明確にする → 影響を追跡する → 責務を検討する → 変更する → 新規テストと回帰テストで確認する」という保守の思考過程を身につけてください。
ヨリソル上の解説教材
コマ主題細目 ① 保守の出発点 ― 現行仕様とベースラインの把握 ② 変更要求への対応 ― 差分・影響・責務・テストの分析 ③ 変更結果の評価 ― 保守性・トレーサビリティ・リファクタリングへの接続
細目レベル ① 保守では、新規開発のように「これから何を作るか」だけを考えるのではなく、すでに運用されているシステムが何を保証しており、そのうち何を守りながら変更するのかを把握することが出発点となる。本演習では、高速バス予約システムの正式な要求仕様を現行システムの基準とし、便検索、乗客情報登録、座席予約、重複予約防止、予約確認、キャンセル、車両管理、便管理などの既存機能を確認する。特に、座席番号と座席クラス、便の運賃と座席クラスごとの運賃など、仕様上区別すべき概念や未確定事項を明確にする必要がある。また、変更前の状態をベースラインとして整理し、同一便・同一座席の重複予約を防ぐこと、予約番号によって予約を追跡できること、キャンセル後に座席が再び予約可能になることなど、変更後も維持すべき保証を明確にする。さらに、Passenger、Bus、BusTrip、Seat、Reservationなどの責務や関係を現行仕様から再構成することで、後の変更要求がどのクラスや機能へ影響するかを判断するための土台を作る。
② 現行仕様を把握した後は、座席変更、割引制度、キャンセル料という三つの変更要求を順に加え、それぞれについて現行仕様との差分と影響範囲を分析する。座席変更では、予約番号と便を維持したまま座席だけを変更し、旧座席を解放して新座席を確保する必要があるため、ReservationやSeat、画面、データ保存、既存の予約・キャンセル処理まで影響を確認する。また、変更可能期限、異なる座席クラスへの変更、運賃差額、同時操作など、要求だけでは決められない事項を確認事項として抽出する。学生割引・シニア割引では、学生であることや年齢など新しい情報をどこで管理し、割引計算をどのクラスの責務とするかを検討する。将来の割引追加も考え、料金規則を画面や長い条件分岐へ散在させないことが重要となる。キャンセル料では、既存のキャンセル機能を維持しながら日数に応じた料金規則を追加し、7日前・6日前・2日前・1日前などの境界値をテストする。各変更では、新機能を確認する新規テストと、従来の保証が壊れていないことを確認する回帰テストの双方を設計する。
③ 複数の変更要求を重ねた後は、機能が動作するかだけでなく、システムが次の変更にも対応しやすい構造を維持しているかを評価する必要がある。座席変更、割引、キャンセル料を追加すると、Reservationなど一つのクラスへ状態管理、料金計算、割引、キャンセル料、座席変更などの異なる責務が集中する可能性がある。そのため、高凝集・低結合、カプセル化、テスト容易性、変更容易性の観点から、変更理由の異なる責務が適切に分離されているかを確認する。また、変更要求を要求・要件、設計・クラス、実装箇所、テストまで追跡するトレーサビリティを確保し、「このメソッドはどの要求のために存在するのか」「この要求はどのテストで確認されるのか」を双方向に説明できる状態を目指す。保守を続けると、長大なメソッド、一つのクラスへの責務集中、料金計算などの重複、他クラスのデータを過度に取得する処理といったCode Smellが現れることがある。こうした兆候を発見し、外部から見た振舞いを変えずに内部構造を改善することが、次のリファクタリングへとつながる。
キーワード ① ソフトウェア保守、現行仕様、要求仕様、ベースライン、既存機能、既存保証、便検索、乗客情報、予約、予約番号、重複予約防止、キャンセル、座席番号、座席クラス ② 変更要求、差分分析、影響分析、座席変更、学生割引、シニア割引、キャンセル料、Reservation、Seat、料金計算、割引、支払運賃、業務ルール、責務分担、確認事項、境界値、データ整合性、新規テスト、回帰テスト ③ 保守性、変更容易性、高凝集、低結合、カプセル化、テスト容易性、責務、責務集中、変更の局所化、トレーサビリティ、変更要求、要求、設計、実装、テスト、Code Smell、コードのにおい、リファクタリング、重複、長大メソッド、回帰テスト
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：現実のソフトウェアの保守の内容を理解し直してみよう。
★次回授業の予習：次回は、リファクタリングについて扱う。機能を変えずに表現を変えるとは何かを学んでおこう。
27 保守（リファクタリング） 科目の中での位置付け リファクタリングは「動かないプログラムを直すこと」でも「コードをきれいに整形すること」でもなく、現在の振舞いを維持したまま、将来の変更を安全かつ小さな範囲で行えるよう内部構造を改善することであることを学んでください。
ヨリソル上の解説教材
コマ主題細目 ① リファクタリングの基礎 ― Code Smellを発見する ② 処理と責務の分割 ― Extract MethodとExtract Class ③ 責務の重複と配置を改善する ― Duplicate CodeとFeature Envy
細目レベル ① リファクタリングとは、利用者から見たソフトウェアの外部的な振舞いを変えずに、内部構造を改善することである。現在正しく動作しているプログラムであっても、運賃制度、キャンセル規則、画面、外部サービスなどが将来変更されることを考えると、「どこを直せばよいか分かりやすい構造」にしておくことが保守上重要となる。リファクタリングの目的は単にコードを短くしたり見た目をきれいにしたりすることではなく、責務を整理し、変更の影響を局所化して修正漏れや副作用を減らすことである。その手掛かりとなるのがCode Smellであり、今すぐバグではないものの、将来の変更や理解を難しくする可能性のあるコード上の兆候を指す。本資料では、Long Method、Large Class、Duplicate Code、Feature Envyを中心に扱う。一つのメソッドが多くの処理を担当している、一つのクラスが異なる仕事を抱えている、同じ処理が複数箇所に存在する、他クラスのデータばかり使って処理している、といった兆候を発見し、「この処理は何をしているのか」「この仕事は本当にこのクラスの責務なのか」と問い直すことがリファクタリングの出発点となる。
② Code Smellを発見した後は、処理や責務を適切な単位へ整理する。Long Methodに対する代表的なリファクタリングがExtract Methodであり、長いメソッドの中から「座席確認」「料金計算」「予約処理」「確認通知」など意味のある処理のまとまりを取り出し、それぞれに名前を付けて独立したメソッドとする。これにより、処理の流れをメソッド名から把握でき、変更要求が来たときに調査すべき場所も分かりやすくなる。しかし、メソッドを分割しただけでは、その処理を担当するクラスが適切とは限らない。そこで、一つのクラスが多くの責務を抱えるLarge Classに対してExtract Classを適用する。たとえばReservationが予約管理、運賃計算、キャンセル料計算、決済、通知まで担当している場合、FareCalculator、CancellationPolicy、PaymentService、NotificationServiceなどへ責務を分離する。これによって、運賃制度の変更はFareCalculator、キャンセル規則の変更はCancellationPolicyというように、変更理由と変更箇所を対応させやすくなる。結果として各クラスの凝集度が高まり、異なる機能間の結合が弱くなり、将来の変更による影響を小さな範囲へ閉じ込められる。
③ 保守性を低下させる別の典型的なCode Smellとして、Duplicate CodeとFeature Envyがある。Duplicate Codeは、同じ、または類似した処理が複数箇所に重複して存在する状態である。たとえば合格判定の条件が複数メソッドに書かれていると、合格基準を変更する際にすべての箇所を修正する必要があり、修正漏れによる不整合が起こりやすい。共通部分をExtract Methodなどによって一か所へまとめれば、変更箇所を局所化できる。一方、Feature Envyは、あるメソッドが自分のクラスよりも他のクラスのデータを多く利用し、そのデータに関する重要な判断まで行っている状態である。ReservationがBusTripの運賃、出発地、到着地などを何度も取得して料金を計算しているなら、その処理をBusTrip側へMove Methodすることを検討する。これは、単にgetterを使わないという話ではなく、「その処理は誰の情報に最も関心を持っているか」「誰の責務とするのが自然か」を判断することである。データを外へ取り出して判断するより、対象オブジェクト自身へ仕事を依頼するTell, Don't Askの考え方も、カプセル化、高凝集・低結合、変更容易性を高めるうえで重要となる。
キーワード ① リファクタリング、Refactoring、外部的振舞い、内部構造、保守、保守性、変更容易性、変更の局所化、Code Smell、臭いのあるコード ② Extract Method、メソッドの抽出、Long Method、処理の分割、メソッド名、責務、Extract Class、クラスの抽出、変更理由、責務分担、高凝集、低結合、変更の局所化、保守性 ③ Duplicate Code、重複コード、共通化、Extract Method、Feature Envy、他クラスへの横恋慕、Move Method、メソッドの移動、BusTrip責務、カプセル化、データ、処理、高凝集、低結合、変更容易性、保守性
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：授業で学んだリファクタリングをさまざまなクラスに適用してみよう。
★次回授業の予習：次回かた、総合演習です。これまでの内容をしっかりと振り返ってみてください。
28 総合演習（１） 科目の中での位置付け 今回および次回の総合演習では、レストラン注文システムを題材として、一連の作業ができるようにする今回は、ドメイン分析、要求分析、要件分析という三つの工程を一続きで学習する。
ヨリソル上の解説教材
コマ主題細目 ① 総合演習の目的とドメイン分析 ② 要求分析とユースケースの作成 ③ 要求の曖昧さの発見と要件の具体化 ④ 要求と要件の対応付けと総合演習のまとめ
細目レベル ① 今回の総合演習では、レストラン注文システムを題材として、ドメイン分析、要求分析、要件分析という三つの工程を一続きで学習する。これらの工程では、同じ要求仕様を扱いながらも、着目する視点が異なる。ドメイン分析では「業務世界に何があるか」、要求分析では「誰が何をしたいか」、要件分析では「システムは何ができなければならないか」を明らかにする。今回は設計に入る前の「何を実現するか（What）」を対象とし、具体的な実現方法（How）は次回扱う。
レストラン注文システムでは、客がテーブルを利用し、メニューから複数の料理を選択して数量を指定し、注文する。システムは注文番号、注文日時、利用テーブル、料理と数量を管理し、合計金額を計算する。
ドメイン分析では、要求仕様から業務上重要な用語を抽出し、その意味を整理する。さらに、概念、属性、関係を区別する。例えば、価格は料理の属性であり、座席数はテーブルの属性である。一方、数量は料理そのものではなく、特定の注文に含まれる料理についての情報である。このため、「注文明細」という概念を導入する必要がある。
最後に、テーブル、注文、注文明細、料理の関係と多重度を整理し、ドメインモデルを作成する。この段階では実装を考えず、業務世界の構造を正しく理解することが重要である。
② 要求分析では、ドメイン分析によって整理した業務上の概念から視点を移し、システムの利用者が何を実現したいのかを明らかにする。ドメイン分析が「注文」「料理」「テーブル」などの概念を扱うのに対し、要求分析では「メニューを見る」「料理を注文する」といった利用者の目的を中心に考える。
レストラン注文システムでは、各テーブルに注文用タブレットが設置され、客自身が操作することを前提とする。このため、主なアクターは「客」となる。客の目的として、メニューの閲覧、料理の注文、注文内容の確認、支払金額の確認などが挙げられる。一方、合計金額の計算や注文日時の記録は、利用者の目的を実現するためのシステム内部の処理として区別する。
次に、利用者の目的をユースケースとして整理し、アクターとの関係をユースケース図に表す。ユースケースは個々のボタン操作ではなく、利用者にとって意味のある目的の単位で設定する。
さらに、「料理を注文する」というユースケースについて、アクター、目的、事前条件、基本フロー、事後条件を記述する。基本フローでは、料理の選択、数量の指定、注文内容と合計金額の表示、注文の確定、注文情報の記録までを整理する。また、数量が0の場合や注文確定前の取り消し、確定ボタンの二重操作など、代替フローや例外フローについても検討する。
③ 要求分析では、要求仕様に記載された内容を整理するだけでなく、記載されていない事項や曖昧な点を発見することも重要である。レストラン注文システムでは、追加注文を認めるか、注文後のキャンセルを可能にするか、売り切れた料理をどう扱うか、会計機能を含めるか、料理の登録や価格変更を誰が行うかなどを確認する必要がある。これらは開発者が勝手に決めるのではなく、要求元に確認すべき事項である。
要件分析では、利用者の「～したい」という要求を、システムが満たすべき具体的で確認可能な条件に変換する。例えば、「料理を注文したい」という要求から、料理の選択、数量指定、複数種類の指定、注文確定などの機能要件を導き出す。また、注文番号の付与、注文日時の記録、注文内容の保存、合計金額の計算なども機能要件として整理する。
データ要件では、テーブル、料理、注文、注文明細について管理する情報を明確にする。さらに、番号の一意性、価格が0以上であること、注文数量が1以上の整数であることなどの制約を設定する。
非機能要件では、性能、操作性、可用性、セキュリティ、信頼性などの品質を扱う。「高速に応答する」「使いやすい」といった曖昧な表現ではなく、具体的にテストできる条件として記述することが重要である。
④ 要件分析の最後には、利用者の要求と、それを実現するために定義した要件との対応関係を確認する。レストラン注文システムでは、「メニューを見たい」という要求に料理一覧や料理情報の表示機能を対応させ、「料理を注文したい」という要求に料理の選択、数量指定、注文確定、注文情報の記録などの機能を対応させる。また、「注文内容を確認したい」「支払金額を知りたい」という要求についても、注文内容の表示や合計金額の計算・表示に関する要件と対応付ける。
このような要求と要件の対応表を作成することで、利用者の要求を満たす要件が不足していないか、逆に必要のない要件が追加されていないかを点検できる。これはトレーサビリティの基本的な考え方につながる。
今回の演習では、ドメイン分析によって業務世界の概念と関係を整理し、要求分析によって利用者の目的とユースケースを明らかにし、要件分析によって具体的な機能、データ、制約、品質条件を定義するという一連の流れを学習する。
提出用ワークシートでは、重要語の抽出、ドメインモデルの作成、ユースケース図とユースケース記述の作成、要求の曖昧点の発見、各種要件の整理、要求と要件の対応確認を行う。これらの成果物は次回の設計工程の基礎となり、画面、クラス、メソッド、データ構造、Javaコード、テストなど、具体的な実現方法を検討する際に活用される。
キーワード ① ドメイン分析、要求分析、要件分析、WhatとHow、要求仕様、重要語の抽出、概念、属性、関係 ② 要求分析、利用者の目的、アクター、ユースケース、ユースケース図、ユースケース記述、内部処理、事前条件、基本フロー、事後条件、代替フロー、例外フロー ③ 要求の曖昧さ、要求の不足、要件分析、機能要件、データ要件、制約、非機能要件、一意性、数量制約、性能、操作性、可用性、セキュリティ、信頼性、テスト可能性 ④ 要求と要件の対応、要求－要件対応表、トレーサビリティ、要件の抜け、不要な要件、ドメインモデル、ユースケース図、ユースケース記述、機能要件、データ要件、非機能要件
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：レストラン注文システムを題材として、ドメイン分析、要求分析、要件分析という三つの工程を理解する
★次回授業の予習：要件分析の次の基本設計からの工程について理解をしておく。
29 総合演習（２） 科目の中での位置付け 前回の総合演習で扱ったドメイン分析・要求分析・要件分析から、具体的なプログラムの実現へとつながる構成として、設計 → 実装 → テスト → 保守について学ぶ。
ヨリソル上の解説教材
コマ主題細目 ① 基本設計と詳細設計によるシステムの具体化 ② 詳細設計に基づくJavaプログラムの実装 ③ ソフトウェアテストと品質の確認 ④ ソフトウェア保守と変更に強い設計
細目レベル ① 基本設計では、要件分析で明らかにした内容を実現するために、システム全体をどのような仕組みにするかを決定する。レストラン注文システムを例に、メニュー画面、注文入力画面、注文確認画面、注文完了画面を設計し、それらの関係を画面遷移図で表す。また、メニュー表示、注文入力、合計金額計算、注文登録などの機能を整理し、テーブル、料理、注文、注文明細を管理するデータ構造を設計する。さらに、MVCを用いて、画面表示、操作の受付、業務処理の役割を分担する。基本設計では、個々のプログラムの詳細ではなく、システムの大きな構造を明確にすることが重要である。
詳細設計では、基本設計で決定した構造を、プログラムとして実装できる水準まで具体化する。Dish、OrderItem、Orderなどのクラスについて、属性、メソッド、責務、クラス間の関係を定義する。例えば、料理の価格はDishが保持し、価格と数量から求める小計はOrderItemが計算し、注文全体の合計金額はOrderが計算する。このように、必要な情報を持つクラスに適切な責務を割り当てる。さらに、詳細クラス図やシーケンス図を作成してオブジェクト間の協調を表現し、メソッド仕様や疑似コードによって処理内容を明確にする。これにより、要件から実装へ至る設計の具体化を理解する。
② 実装では、詳細設計で決定したクラス、属性、メソッド、オブジェクト間の関係や協調を、Javaプログラムとして具体化する。重要なのは、単に動作するプログラムを作ることではなく、設計で決めた責務や構造を正しくコードに反映することである。レストラン注文システムでは、依存関係の少ないDishから実装を始め、OrderItem、Orderへと進める。属性をprivateにし、コンストラクタで初期値を設定することで、カプセル化を実現する。
OrderItemには料理と数量を保持させ、小計を計算するgetSubtotal()を実装する。一方、Orderには複数のOrderItemをListで保持させ、calculateTotal()によって注文全体の合計金額を計算する。これにより、クラス図の関連や多重度、シーケンス図のメッセージの流れがJavaコードに対応することを確認する。また、注文数量が1以上であるという制約を入力チェックとして実装し、不正な値に対して例外を発生させる。
MVCを採用する場合には、ControllerやViewに業務計算を集中させず、Modelに適切な責務を持たせる。さらに、命名規則などのコーディング規約を守り、コードレビューによって責務分担、重複、可読性、設計との整合性を確認する。実装中に設計上の問題が見つかった場合には、設計書も修正することを学ぶ。
③ テストでは、実装したソフトウェアが設計どおりに動作し、要求や要件を満たしているかを確認する。単にプログラムを実行するのではなく、テスト対象、入力条件、期待結果を事前に定め、実行結果と比較して合否を判定することが重要である。テストは、単体テスト、結合テスト、システムテスト、受入テストという段階に分けて考える。
単体テストでは、OrderItemの小計計算やOrderの合計金額計算など、個々のクラスやメソッドの動作を確認する。正常な入力だけでなく、数量が0や負数の場合などの異常系も調べ、特に許容値の境界付近を確認する境界値テストを行う。また、JUnitを利用して、準備、実行、確認という手順でテストを自動化する。
結合テストでは、Controller、Order、OrderItem、Dishなどのクラスが、シーケンス図で設計したとおりに連携するかを確認する。システムテストでは、画面操作から注文登録までの一連の処理を確認し、要件とテストケースの対応表を作成する。受入テストでは、利用者が本来実現したかった目的を達成できるかを確認する。さらに、不具合の原因調査、修正後の回帰テスト、非機能要件の確認を通して、品質保証の考え方を学ぶ。最後に、開発工程とテスト工程の対応をV字モデルとして理解する。
④ 保守では、完成して運用されているソフトウェアに対して、不具合の修正、新しい機能の追加、業務や環境の変化への対応などを行う。ソフトウェアは完成すれば終わりではなく、利用され続ける中で変更が必要になる。レストラン注文システムでは、料理へのアレルギー情報の追加を例として、変更要求の確認、要件の見直し、影響分析、設計変更、実装修正、テストという一連の作業を学ぶ。
影響分析では、変更がドメインモデル、要件、画面設計、データ設計、クラス図、Javaコード、テストにどのような影響を及ぼすかを調べる。このとき、要求からテストまでの対応関係を示すトレーサビリティが役立つ。また、料理に関する情報をDishに集約しておけば、変更の影響を限定しやすいことから、高凝集、低結合、カプセル化、情報隠蔽、単一責任の重要性を理解する。
さらに、割引クーポンや学生割引などの機能追加を通して、変更に強い設計を検討する。不具合修正では原因を調査し、修正後には既存機能が壊れていないことを回帰テストで確認する。複雑になったコードは、動作を変えずに内部構造を改善するリファクタリングによって整理する。最後に、修正保守、適応保守、完全化保守、予防保守を学び、分析から保守までのソフトウェア開発工程全体を振り返る。
キーワード ① 基本設計、詳細設計、画面設計、画面遷移図、機能設計、データ設計、ドメインモデル、データモデル、ER図、MVC、クラス図、クラスの責務、属性、メソッド、シーケンス図、オブジェクト間の協調、疑似コード、トレーサビリティ ② 実装、Java、ソースコード、詳細設計、クラス、属性、メソッド、コンストラクタ、カプセル化、情報隠蔽、オブジェクト参照、List、責務分担、コーディング規約、コードレビュー ③ ソフトウェアテスト、品質保証、テストケース、期待結果、単体テスト、結合テスト、システムテスト、受入テスト、正常系、異常系、境界値テスト、JUnit、自動テスト、シーケンス図、非機能要件、性能テスト、セキュリティテスト、トレーサビリティ、要件－テスト対応表、不具合、回帰テスト、V字モデル ④ ソフトウェア保守、変更要求、影響分析、要件変更、設計変更、トレーサビリティ、アレルギー情報、機能追加、割引クーポン、高凝集、低結合、カプセル化、情報隠蔽、単一責任、変更容易性、不具合修正、回帰テスト、JUnit、リファクタリング、修正保守、適応保守、完全化保守、予防保守、ポリモーフィズム
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：設計 → 実装 → テスト → 保守という開発工程の流れを学び直しておく。
★次回授業の予習：この講義で学んだすべての工程の内容について理解しておく。
30 総復習 科目の中での位置付け この授業で学んだことを最後の授業でまとめる。
ヨリソル上の解説教材
コマ主題細目 ① オブジェクト指向の基礎 ② 上流工程 ③ 下流工程
細目レベル ① 同じ種類のオブジェクトに共通する属性と操作を定義したものがクラスであり、そのクラスに属する具体的な存在がオブジェクトであることを確認しました。次に、要求仕様に含まれる名詞や名詞句からクラスや属性の候補を、動詞から操作や関連の候補を抽出し、独立して管理すべき情報や役割を考慮してクラスを決定する方法を復習しました。また、クラス間の意味のあるつながりを関連として表し、多重度によってオブジェクト間の数量的な関係を明確にする方法を確認しました。さらに、各クラスに適切な責務を割り当て、関係の深い情報と処理をまとめる高凝集と、他のクラスの内部構造への依存を抑える低結合の重要性を学びました。続いて、宅配便の集荷・配送管理システムを題材とした総合演習を通して、クラスの抽出、属性・操作の決定、関連と多重度の設定、責務の割当てを実践しました。最後に、Javaのコンパイル処理を例としてモデル変換の考え方を紹介し、今後の授業で扱う長距離バス予約システムの要求仕様を確認しました。これらを通して、オブジェクト指向の基本概念が相互に関連し、理解しやすく変更に強いソフトウェアの設計につながることを学びました。
② ドメイン分析、要求分析、要件分析の三つの工程を一続きで学習した。まず、ドメイン分析では、要求仕様から業務上重要な用語を抽出し、概念、属性、関係を整理した。次に、要求分析では、ユースケースとして整理した。さらに、ユースケース図とユースケース記述を作成し、基本フローだけでなく、代替フローや例外フローも検討した。続く要件分析では、利用者の要求を具体的で確認可能な条件に変換し、機能要件、データ要件、制約、非機能要件を明確にした。最後に、要求と要件の対応表を作成し、要件の抜けや不要な要件の有無を確認することで、トレーサビリティの重要性を学んだ。これらを通して、設計に入る前に「何を実現するか」を明確にし、次の設計工程へつなげる一連の流れを理解した。
③ 基本設計、詳細設計、実装、テスト、保守という一連のソフトウェア開発工程を学習した。基本設計では、要件を実現するための画面構成、画面遷移、機能構成、データ構造を検討し、MVCによる役割分担を整理した。詳細設計では、クラスの属性、メソッド、責務、関連を具体化し、クラス図やシーケンス図を用いてオブジェクト間の協調を明確にした。実装では、詳細設計をJavaコードに変換し、カプセル化や責務分担を守りながら、注文内容の管理や合計金額の計算を実現した。また、例外処理、コーディング規約、コードレビューを通して、保守しやすいプログラムの重要性を確認した。テストでは、単体テスト、結合テスト、システムテスト、受入テストを実施する考え方を学び、正常系、異常系、境界値を考慮したテストケースの作成やJUnitによる自動テストを検討した。さらに、要件とテストの対応関係を確認し、V字モデルの考え方を理解した。保守では、アレルギー情報や割引機能の追加を例に、変更要求の分析、影響範囲の特定、設計・実装の修正、回帰テストを学んだ。また、高凝集、低結合、リファクタリングが変更容易性を高めることを確認した。これらを通して、要求から設計、実装、テスト、保守までを一貫して捉えることの重要性を学んだ。
キーワード ① オブジェクト指向、クラス、オブジェクト、インスタンス、分類、抽象化、属性、操作、クラス抽出、要求仕様、関連、多重度、クラス図、責務、責務分担、高凝集、低結合、カプセル化、情報隠蔽、分割統治、 ② ドメイン分析、要求分析、要件分析、要求仕様、概念、属性、関連、多重度、注文明細、ドメインモデル、アクター、ユースケース図、ユースケース記述、機能要件、トレーサビリティ ③ 基本設計、詳細設計、画面遷移図、MVC、クラス図、シーケンス図、責務分担、Java、カプセル化、単体テスト、結合テスト、V字モデル、影響分析、回帰テスト、リファクタリング
コマの展開方法 社会人講師 AL ICT PowerPoint・Keynote 教科書
コマ用オリジナル配布資料 コマ用プリント配布資料 その他 該当なし
小テスト 「小テスト」については、毎回の授業時間内にヨリソル上において、当該コマの小テスト（範囲度表示付き）を実施する。
復習・予習課題 ★今回授業の復習：オブジェクト指向ソフトウェア開発のすべての工程を見直す。
履修判定指標
履修指標履修指標の水準キーワード配点関連回
オブジェクト指向の基礎 オブジェクト指向の基礎に関する履修判定指標
【★やさしい】
・オブジェクト指向の基本的な考え方と、その目的について理解している。
・クラスとオブジェクトの違いについて理解している。
・クラスの属性と操作について理解している。
・抽象化と具体化の考え方について理解している。
・要求仕様からクラスを抽出する基本的な方法について理解している。
・クラス間の関連と多重度について理解している。
・クラスの責務について理解している。
・高凝集と低結合の基本的な考え方について理解している。
【★★普通】
・与えられた要求仕様から、適切なクラス、属性、操作を選択できる。
・クラスとオブジェクトの具体例を区別できる。
・クラス間の関連を理解し、適切な多重度を判断できる。
・各クラスが持つべき属性や担当すべき責務を判断できる。
・高凝集と低結合の観点から、クラス設計の適切さを判断できる。
・クラス図に表されたクラス、属性、操作、関連、多重度の意味を理解できる。
【★★★難しい】
・与えられた要求仕様に対して、クラスとして独立させるべき概念と、他のクラスの属性とすべき情報を適切に判断できる。
・複数のクラス間の関係を分析し、関連そのものを独立したクラスとして扱う必要があるかを判断できる。
・与えられた要求仕様に基づいて、クラス間の適切な関連と多重度を判断できる。
・複数のクラス設計案から、責務分担が適切で、高凝集・低結合の原則に沿った設計を選択できる。
・仕様変更がクラス間に及ぼす影響を考慮し、変更容易性の高い設計を選択できる。
※いずれも選択肢のなかから正しいものを選択できること。 		オブジェクト指向、クラス、オブジェクト、インスタンス、抽象化、具体化、属性、操作、クラス抽出、要求仕様、クラス図、関連、多重度、関連クラス、責務、責務分担、高凝集、低結合、カプセル化、変更容易性 10 1,2,3,4,5,6,7
UMLとastah* 【★やさしい】
・UMLの目的と基本的な役割について理解している。
・UMLで表現できるシステムの静的側面と動的側面について理解している。
・UMLの代表的な図の種類と、それぞれの用途について理解している。
・クラス図の基本的な構成要素について理解している。
・クラス図におけるクラス、属性、操作、関連、多重度の表記方法について理解している。
・astah*の目的と基本的な機能について理解している。
・astah*を使用してUMLの図を作成できることを理解している。
【★★普通】
・システムの分析や設計の目的に応じて、適切なUMLの図を選択できる。
・与えられたクラス図から、クラス間の関連や多重度を正しく読み取ることができる。
・クラス図における関連、集約、コンポジション、汎化の違いを理解している。
・ユースケース図、アクティビティ図、シーケンス図の基本的な意味を理解している。
・astah*を使用して、クラス、属性、操作、関連を含む基本的なクラス図を作成できる。
・astah*で作成したクラス図に対して、クラスの追加・修正や関連・多重度の設定ができる。
【★★★難しい】
・与えられた要求仕様に対して、システムの構造や振る舞いを表現するために適切なUMLの図を選択できる。
・複数のクラス図を比較し、クラス間の関連、多重度、汎化などが適切に表現されているものを判断できる。
・与えられた要求仕様から、クラス、属性、操作、関連、多重度を適切に設定したクラス図を作成できる。
・クラス図とシーケンス図の対応関係を理解し、オブジェクト間の協調が適切に表現されているかを判断できる。
・astah*を使用して作成したUMLの図について、要求仕様との不整合や表記上の誤りを発見し、適切に修正できる。 		UML、モデリング、静的モデル、動的モデル、クラス図、クラス、属性、操作、関連、多重度、集約、コンポジション、汎化、ユースケース図、アクティビティ図、シーケンス図、astah*、モデル作成、図の編集、モデルの整合性 10 8,9
ドメイン分析 【★やさしい】
・ドメイン分析の目的とソフトウェア開発における役割について理解している。
・ドメイン分析と要求分析、要件分析との違いについて理解している。
・ドメインモデルの目的と基本的な役割について理解している。
・要求仕様から業務上重要な用語を抽出する方法について理解している。
・ドメイン分析における概念、属性、関連の違いについて理解している。
・ドメインモデルにおけるクラスとクラス間の関連について理解している。
・クラス間の多重度の基本的な意味について理解している。
【★★普通】
・与えられた要求仕様から、業務上重要な概念を抽出できる。
・抽出した用語を、独立した概念とその属性に適切に分類できる。
・与えられた業務の説明から、概念間の関連を発見できる。
・業務上の制約に基づいて、概念間の適切な多重度を判断できる。
・複数の概念の間に生じる出来事や関係を、独立した概念として扱う必要があるかを判断できる。
・与えられたドメインモデルから、業務上の概念とその関係を読み取ることができる。
【★★★難しい】
・与えられた要求仕様から、業務上必要な概念、属性、関連、多重度を適切に抽出し、ドメインモデルを構成できる。
・複数のドメインモデルを比較し、業務の実態や要求仕様をより適切に表現しているモデルを判断できる。
・概念間の関連が持つ情報に着目し、新しい概念を導入する必要性を判断できる。
・要求仕様に含まれる曖昧さや不足を発見し、ドメインモデルを完成させるために確認すべき事項を判断できる。
・ドメインモデルと設計段階のクラス図やデータモデルとの違いを理解し、実装上の都合を持ち込まずに業務世界を適切にモデル化できる。
※いずれも選択肢のなかから正しいものを選択できること。 		ドメイン分析、ドメイン、業務理解、要求仕様、ドメインモデル、概念、概念抽出、用語集、属性、属性値、関連、多重度、クラス、クラス候補、関連クラス、業務ルール、制約条件、概念間の関係、要求の曖昧さ、概念モデル 10 10,11,28,30
要求定義 【★やさしい】
・要求分析の目的とソフトウェア開発における役割について理解している。
・ドメイン分析、要求分析、要件分析の違いについて理解している。
・要求分析では、システムの利用者が「誰で、何をしたいのか」を明らかにすることを理解している。
・アクターの意味と役割について理解している。
・ユースケースの意味と目的について理解している。
・ユースケース図の基本的な構成要素と表記方法について理解している。
・ユースケース記述の目的と基本的な構成について理解している。
・ユースケース記述における事前条件、事後条件、基本フローの意味について理解している。
【★★普通】
・与えられた要求仕様から、システムのアクターを適切に抽出できる。
・利用者の目的とシステム内部の処理を区別できる。
・与えられた要求仕様から、利用者の目的に対応するユースケースを抽出できる。
・ユースケース図におけるアクターとユースケースの関係を適切に判断できる。
・与えられたユースケースについて、事前条件、事後条件、基本フローを適切に判断できる。
・ユースケース記述における基本フロー、代替フロー、例外フローの違いを理解し、具体例を適切に分類できる。
・要求仕様に含まれる曖昧な点や不足している事項を発見できる。
【★★★難しい】
・与えられた要求仕様に対して、適切なアクターとユースケースを抽出し、システムの利用目的を正しく表現したユースケース図を選択できる。
・複数のユースケース図を比較し、システムの範囲、アクター、ユースケースの設定が適切なものを判断できる。
・与えられた要求仕様から、基本フロー、代替フロー、例外フローを適切に整理したユースケース記述を選択できる。
・複数のユースケース記述を比較し、利用者の目的、処理の流れ、事前条件、事後条件が適切に表現されているものを判断できる。
・要求仕様の曖昧さや不足がシステムの機能や利用方法に及ぼす影響を考慮し、要求元に確認すべき事項を適切に判断できる。
・要求分析の結果と要件分析との関係を理解し、利用者の要求を具体的なシステム要件へつなげるために必要な情報を判断できる。 		要求分析、要求仕様、利用者の目的、システム境界、アクター、ユースケース、ユースケース図、ユースケース記述、アクターとユースケースの関連、事前条件、事後条件、基本フロー、代替フロー、例外フロー、正常系、異常系、システム内部処理、要求の曖昧さ、要求の不足 10 12,13,14,28,30
要件定義 【★やさしい】
・要件分析の目的とソフトウェア開発における役割について理解している。
・ドメイン分析、要求分析、要件分析の違いについて理解している。
・利用者の要求とシステムが満たすべき要件との違いについて理解している。
・機能要件と非機能要件の意味と違いについて理解している。
・データ要件と制約条件の基本的な考え方について理解している。
・性能、操作性、可用性、セキュリティ、信頼性などの非機能要件について理解している。
・要件を具体的で確認可能な表現にする必要性について理解している。
・要求と要件の対応関係を確認する目的について理解している。
【★★普通】
・与えられた要求仕様から、システムに必要な機能要件を抽出できる。
・与えられた要件を、機能要件、データ要件、非機能要件に適切に分類できる。
・利用者の要求を、システムが満たすべき具体的な要件に変換できる。
・システムで管理すべきデータ項目と、それらに対する制約条件を判断できる。
・与えられた非機能要件について、適切な品質特性を判断できる。
・「高速に応答する」「使いやすい」などの曖昧な要件を、具体的でテスト可能な表現に修正できる。
・要求と要件の対応表から、要求を実現するために必要な要件を確認できる。
・要件の記述に含まれる曖昧さや不足を発見できる。
【★★★難しい】
・与えられた要求仕様に対して、必要な機能要件、データ要件、非機能要件を適切に抽出し、体系的に整理できる。
・複数の要件記述を比較し、具体性、明確性、検証可能性の観点から適切なものを判断できる。
・与えられた業務上の制約から、データの一意性、値の範囲、データ間の整合性などに関する適切な要件を判断できる。
・与えられたシステムの利用目的や運用条件に応じて、必要な非機能要件とその評価基準を適切に判断できる。
・要求－要件対応表を分析し、要求に対応する要件の不足や、要求に根拠を持たない不要な要件を発見できる。
・要求の変更が既存の要件に及ぼす影響を考慮し、追加・修正が必要な要件を判断できる。
・要件分析の成果物が基本設計やテストにどのようにつながるかを理解し、設計や検証の基準として適切な要件を判断できる。
※いずれも選択肢のなかから正しいものを選択できること。 		要件分析、要求仕様、要求と要件の違い、機能要件、非機能要件、データ要件、制約条件、性能、操作性、可用性、セキュリティ、信頼性、一意性、データ整合性、要件の明確性、検証可能性、テスト可能性、要求－要件対応表、トレーサビリティ、要件の網羅性 10 15,16,28,30
基本設計 【★やさしい】
・基本設計の目的とソフトウェア開発における役割について理解している。
・要件分析、基本設計、詳細設計の違いについて理解している。
・基本設計では、要件を実現するためのシステムの大まかな仕組みを決定することを理解している。
・画面設計の目的と基本的な考え方について理解している。
・画面遷移図の目的と基本的な表記方法について理解している。
・機能設計の目的とシステムを機能に分割する考え方について理解している。
・データ設計の目的と基本的な考え方について理解している。
・ドメインモデルとデータモデルの違いについて理解している。
・MVCの基本的な構造とModel、View、Controllerの役割について理解している。
・基本設計の主な成果物について理解している。
【★★普通】
・与えられた要件から、システムに必要な画面を抽出し、それぞれの役割を判断できる。
・与えられた利用者の操作手順から、適切な画面遷移を判断できる。
・与えられた要件に基づいて、システムを適切な機能に分割できる。
・与えられた要求仕様やドメインモデルから、システムで管理すべきデータ項目とデータ間の関係を判断できる。
・ER図に表されたエンティティ、属性、関連の意味を理解できる。
・システムの主要なクラスと、それぞれの大まかな責務を判断できる。
・MVCにおけるModel、View、Controllerの適切な役割分担を判断できる。
・要件と基本設計の対応関係を確認し、要件が設計に反映されているかを判断できる。
【★★★難しい】
・与えられた要件に対して、画面構成、画面遷移、機能構成を適切に組み合わせた基本設計を選択できる。
・複数の画面遷移図を比較し、利用者の操作手順や要件に適合したものを判断できる。
・複数の機能分割案を比較し、機能間の役割分担や独立性の観点から適切な設計を判断できる。
・与えられた要件に基づいて、データ間の関連や多重度を適切に表現したデータモデルを選択できる。
・複数のクラス構成案を比較し、主要クラスの責務やクラス間の協調が適切なものを判断できる。
・MVCの観点から、画面表示、操作の受付、業務処理が適切に分離されたシステム構造を判断できる。
・与えられたユースケースに対して、複数の機能や主要クラスが協調する処理の大まかな流れを判断できる。
・要件と基本設計の対応表を分析し、設計への反映漏れや不適切な設計要素を発見できる。
・基本設計と詳細設計の役割の違いを理解し、基本設計段階で決定すべき事項と詳細設計で具体化すべき事項を適切に判断できる。
※いずれも選択肢のなかから正しいものを選択できること。 		基本設計、要件分析、詳細設計、画面設計、画面一覧、画面遷移図、機能設計、機能分割、機能構成図、データ設計、データモデル、ER図、エンティティ、関連、多重度、クラス構造、クラスの責務、MVC、システムアーキテクチャ、トレーサビリティ 10 17,18,29,30
詳細設計 【★やさしい】
・詳細設計の目的とソフトウェア開発における役割について理解している。
・基本設計、詳細設計、実装の違いについて理解している。
・詳細設計では、基本設計で決定した仕組みを実装可能な水準まで具体化することを理解している。
・クラス、属性、メソッド、責務の基本的な意味について理解している。
・クラス間の関連と多重度について理解している。
・詳細クラス図の目的と基本的な表記方法について理解している。
・シーケンス図の目的と基本的な構成要素について理解している。
・オブジェクト間のメッセージとメソッド呼び出しの関係について理解している。
・メソッド仕様における引数、戻り値、処理内容の意味について理解している。
・MVCにおけるModel、View、Controllerの役割分担について理解している。
【★★普通】
・与えられた基本設計から、実装に必要なクラスを抽出できる。
・各クラスが保持すべき属性と、そのデータ型を適切に判断できる。
・各クラスの責務に基づいて、必要なメソッドを判断できる。
・与えられたクラス図から、クラス間の関連、多重度、属性、メソッドを正しく読み取ることができる。
・メソッドの目的に応じて、適切な引数と戻り値を判断できる。
・与えられた処理について、オブジェクト間のメッセージの流れをシーケンス図から読み取ることができる。
・クラス図とシーケンス図の対応関係を理解し、メソッドの呼び出し関係を判断できる。
・与えられた処理について、適切なアルゴリズムや疑似コードを選択できる。
・入力値の制約に対して、適切な入力チェックや例外処理の方法を判断できる。
・MVCに基づいて、各クラスをModel、View、Controllerに適切に分類できる。
【★★★難しい】
・与えられた基本設計に対して、クラス、属性、メソッド、関連、多重度を適切に定義した詳細クラス図を選択できる。
・複数のクラス設計案を比較し、責務分担、高凝集、低結合の観点から適切な設計を判断できる。
・与えられた機能について、必要な情報を持つクラスに適切なメソッドを割り当てることができる。
・複数のシーケンス図を比較し、オブジェクト間の協調やメソッドの呼び出し順序が適切なものを判断できる。
・クラス図とシーケンス図を比較し、メソッドの不足や呼び出し関係の不整合を発見できる。
・与えられた要件に基づいて、メソッドの引数、戻り値、処理手順、例外処理を適切に定義したメソッド仕様を判断できる。
・複数のアルゴリズムや疑似コードを比較し、要件や制約を正しく実現できるものを判断できる。
・MVCの観点から、画面処理と業務処理が適切に分離され、クラス間の責務分担が明確な設計を判断できる。
・基本設計と詳細設計の対応関係を確認し、必要な機能や処理が詳細設計に適切に反映されているかを判断できる。
・仕様変更が発生した場合に、クラス間の依存関係や責務分担を考慮し、変更の影響を小さくできる詳細設計を選択できる。
※いずれも選択肢のなかから正しいものを選択できること。 		詳細設計、基本設計、詳細クラス図、クラス、属性、データ型、メソッド、クラスの責務、責務分担、関連、多重度、シーケンス図、メッセージ、オブジェクト間の協調、メソッド仕様、引数、戻り値、疑似コード、例外処理、MVC 10 19,20,29,30
評価方法 大学の評価基準の通り
評価基準 評語
    学習目標をほぼ完全に達成している・・・・・・・・・・・・・ S (100～90点)
    学習目標を相応に達成している・・・・・・・・・・・・・・・ A (89～80点)
    学習目標を相応に達成しているが不十分な点がある・・・・・・ B (79～70点)
    学習目標の最低限は満たしている・・・・・・・・・・・・・・ C (69～60点)
    学習目標の最低限を満たしていない・・・・・・・・・・・・・ D (60点未満)
教科書 なし
参考文献 なし（必要と思ったら、遠慮なく尋ねてください）
実験・実習・教材費 なし