【応用情報技術者試験】システム開発技術を学ぼう！ ~第2章~オブジェクト指向

システム開発技術とは、企業や組織の「業務課題を解決し、効率化する仕組み（システム）」をIT技術を用いて、企画・設計・プログラミング・テスト・運用するまでの一連の技術とプロセスの総称で、具体的には、要件定義、設計、コーディング、テスト、運用・保守などの工程があり、ウォーターフォールやアジャイルといった様々な開発手法が存在します。

画像参照：https://www.co-well.jp/blog/system_dev_flow

オブジェクト指向の概念
UML

オブジェクト指向の概念

オブジェクト指向とは、データ（属性）と処理（メソッド）をひとまとめにした「オブジェクト」という部品を基本単位として、それらを組み合わせてシステムを構築する考え方で、現実世界の「モノ」の概念をプログラムに落とし込み、カプセル化・継承・ポリモーフィズムの原則で、再利用性・保守性・拡張性を高め、効率的な開発を実現します。Java、Python、C++などが代表的な言語で、大規模開発や複雑なシステム構築に適しています。

基本概念

オブジェクト: データ（例：犬の名前）と、そのデータを操作する機能（例：吠える）を一体にしたもの。
クラス : オブジェクトの設計図（ひな型）。「犬」クラスから「チワワ」や「ダックスフンド」などの具体的なオブジェクトが作られる。
プロパティ / 属性 : オブジェクトが持つ性質や状態（例：色、名前）。
メソッド: オブジェクトができる動作や機能（例：走る、鳴く）。
インスタンス : クラスから生成された具体的なオブジェクトの実体。

3大原則

カプセル化: データとメソッドをひとまとめにし、外部から直接データに触れないように隠蔽（データを保護し、部品化を促進）。
継承 : 親クラスの性質（属性・メソッド）を子クラスが受け継ぎ、コードの再利用性を高める。
ポリモーフィズム/ 多態性: 同じ名前のメソッドでも、オブジェクトの種類によって異なる振る舞いをすること（例：「鳴く」で犬は「ワン」、猫は「ニャー」）。

メリットとデメリット

メリット:
- 再利用性・保守性の向上: 部品化により、共通処理の使い回しや変更が容易。
- 開発効率の向上: 共通部品を組み合わせるため、開発がスピードアップ。
- 大規模開発・分業の容易化: システムを部品に分け、複数人での開発がしやすい。
デメリット:
- 設計の複雑さ: 初期設計に時間がかかり、深い理解が必要。
- メモリ使用量: 適切な設計でないと、メモリ使用量が増える場合も。

代表的なオブジェクト指向言語

Java, Python, C++, Ruby, C#, Swift, PHP, JavaScriptなど。

オブジェクト指向は、現実世界の「モノ」の概念をプログラミングに導入し、複雑なソフトウェアを効率的かつ堅牢に開発するための強力な手法として、現代のソフトウェア開発で広く活用されています。

クラス間の関係

プログラミングを進める中で、様々なクラスを定義していくとクラス間に関係性が必要となってきます。クラス間の関係を下記に整理しています。

関係	概要
集約ー分解関係	全体と部分の関係
汎化ー特化関係	親子の上下関係
スーパークラス、親クラス、基底クラス	汎化ー特化関係における上位クラス
サブクラス、子クラス、派生クラス	汎化ー特化関係における下位クラス
インヘリタンス（継承）	上位クラスの構造を下位クラスが引き継ぐこと。
ポリモーフィズム（多態性）	同じ名称のメソッドを呼び出しても、オブジェクトごとに異なる動作を行うこと。

インヘリタンス（継承）

インヘリタンス（継承）とは、主にオブジェクト指向プログラミングにおいて、既存のクラス（親クラス/スーパークラス）の機能（フィールドやメソッド）を新しいクラス（子クラス/サブクラス）が引き継ぎ、再利用できる仕組みで、コードの共通化と効率化を実現します。

目的: コードの重複を減らし、保守性を高める。共通の機能は親クラスにまとめ、子クラスでは固有の機能だけを追加・拡張する。
用語:
- スーパークラス（親クラス/基本クラス）: 継承元となるクラス。
- サブクラス（子クラス/派生クラス）: 継承する新しいクラス。
具体例: 「コンピュータ」クラスの機能（電源オン/オフなど）を「ノートパソコン」クラスが継承し、「キーボード入力」機能などを追加する。
特徴:
- コンストラクタ（初期化処理）は継承されない。
- 言語によっては複数の親クラスから継承する「多重継承」が可能だが、複雑さから「インターフェース」などで代替されることもある。

オーバーライド

オーバーライドとは、親クラス（スーパークラス）で定義されたメソッドを、それを継承した子クラス（サブクラス）で同じ名前・引数で再定義し、動作を上書き（変更・拡張）する機能です。これにより、ポリモーフィズム（多態性）を実現し、同じメッセージ（メソッド呼び出し）でもオブジェクトの種類によって異なる動作をさせたり、既存コードの再利用性と保守性を高めたりします。

ポイント

継承関係：親クラス（スーパークラス）と子クラス（サブクラス）の間で発生します。
メソッドの再定義：親クラスのメソッド（名前、引数の数・型、戻り値の型）と完全に同じシグネチャ（定義）で、子クラスで新しい処理を記述します。
動作の上書き：親クラスのメソッドの代わりに、子クラスで定義したメソッドが呼び出されるようになります。
目的：子クラス固有の機能が必要な場合や、親クラスの機能を特定の状況に合わせて変更・拡張したい場合に利用します。

オーバーロードとの違い

オーバーライド: 親クラスのメソッドを子クラスで上書きする（名前・引数は同じ）。
オーバーロード: 同じクラス内で引数の異なる同名メソッドを複数定義する（メソッド名が同じで引数が違う）。

例え話

親クラス「動物」に「鳴く」メソッドがあるとする。
子クラス「犬」と「猫」が「動物」を継承する。
「犬」クラスで「鳴く」メソッドを「ワンワン」とオーバーライドする。
「猫」クラスで「鳴く」メソッドを「ニャーニャー」とオーバーライドする。
動物 animal = new 犬(); animal.鳴く(); とすると「ワンワン」と鳴き、animal = new 猫(); animal.鳴く(); とすると「ニャーニャー」と鳴く、といった動作が実現できます。

メリット

柔軟な拡張: 共通のインターフェース（メソッド名）で、オブジェクトごとに異なる振る舞いをさせられる（ポリモーフィズム）。
コードの再利用性・保守性向上: 既存の機能を最小限の変更で利用しつつ、必要な部分だけカスタマイズできる。

注意点

メソッド名、引数の数・型、戻り値の型は、親クラスと同じである必要があります（言語によっては例外あり）。

オブジェクト指向プログラミングにおいて、継承とオーバーライドは、柔軟で保守しやすいシステムを構築するための重要な概念です。

ポリモーフィズム（多態性）

ポリモーフィズムとは、オブジェクト指向プログラミングにおける「多態性」を意味し、異なるクラスのオブジェクトが同じ名前のメソッド（関数）を持ち、呼び出されたときにそれぞれのクラスに応じた異なる処理を実行する仕組みです。これにより、コードの共通化、再利用性、拡張性が向上し、同じ操作で多様な振る舞いを実現できるため、柔軟で保守性の高いシステム設計が可能になります。

仕組みと具体例

共通のインターフェース: 異なるクラスが共通のメソッド名（例: draw()、attack()）を持ちます。
異なる実装: 各クラスはそのメソッドを自分自身の役割に合わせて個別に実装します（例: Circleクラスは円を描画、Squareクラスは四角形を描画する）。
動的な振る舞い: プログラムは、オブジェクトの実際の型（実行時）に応じて適切なメソッドを呼び出します。これにより、同じコードで多様な結果を得られます。

メリット

コードの簡潔化と再利用: 型ごとに異なる関数を定義する必要がなくなり、共通のインターフェースで処理できます。
拡張性の向上: 新しいクラスを追加しても、既存のコードを変更せずに柔軟に対応できます。
保守性の向上: 変更が必要な箇所が限定され、システム全体が理解しやすくなります。

UML

UML（Unified Modeling Language：統一モデリング言語）とは、ソフトウェアの構造や振る舞いを視覚的に表現するための標準化された図法（モデリング言語）で、オブジェクト指向開発で使われ、クラス図やシーケンス図など様々な図でシステムの設計を「見える化」し、開発者間のコミュニケーションを円滑にし、認識のズレを防ぐ役割を果たします。

主な特徴

視覚化と標準化: 複雑なシステムを「図」で表現することで、言葉だけでは伝わりにくい情報を明確にし、誰にでも理解しやすくします。
オブジェクト指向: オブジェクト指向の考え方に基づき、システムを構成する要素（オブジェクト）とその関係性をモデル化します。
豊富な図の種類: システムの「構造」を表す「構造図」（クラス図など）と、「振る舞い」を表す「振る舞い図」（シーケンス図、ユースケース図など）に大きく分かれ、目的に応じて使い分けます。
コミュニケーションの促進: 開発チーム、営業、ユーザーなど、システムに関わる様々な人が同じ設計図を見て共通認識を持つことで、手戻りや誤解を防ぎます。
標準化団体OMGが管理: Object Management Group（OMG）によって標準化・管理されており、業界の共通言語となっています。

主なUML図の例

ユースケース図: ユーザーとシステムとのやり取り（何ができるか）を表現。
クラス図: システムの静的な構造、クラスとそれらの関係性を表現。
シーケンス図: オブジェクト間のメッセージのやり取り（時間的な流れ）を表現。
アクティビティ図: 処理の流れやワークフローを表現。

UMLを使うことで、要件定義から設計、実装の各段階で、より正確で効率的なシステム開発が可能になります。

ユースケース図

ユースケース図とは、UML（統一モデリング言語）の一つで、システムが「何ができるか（機能）」を「アクター（利用者や外部システム）」の視点から分かりやすく可視化する図です。システムの「ユースケース（利用目的や機能）」とアクターの相互関係を示し、要件定義フェーズで顧客や開発者間の共通認識を形成し、システムの全体像を把握するために使われます。

画像参照：https://it-koala.com/usecasediagrams-1832

主な構成要素

アクター : システムを利用する人間、組織、または他のシステム。人型アイコンで表現されます。
ユースケース: アクターがシステムを利用して達成する機能や目的（例：「商品を検索する」「会員登録する」）。楕円形で表現されます。
システム境界 : システムの範囲を示す長方形の枠線。
関連 : アクターとユースケースを結ぶ実線。

目的とメリット

ユーザー視点の可視化: 開発者だけでなく、ITに詳しくない人でも直感的に理解できる。
要件の明確化・共有: システムが提供すべき機能を明確にし、関係者間で共通認識を持つ。
コミュニケーション円滑化: 顧客の要求を具体的に把握し、議論を促進する。
開発のガイドライン: システム開発の初期段階で、実装すべき機能の方向性を示す。

具体的な活用例

ECサイトで「商品を検索する」「カートに入れる」「決済する」といった一連の流れを図示する。
ATMで「入金する」「出金する」「残高照会する」といった利用シーンを整理する。

クラス図

クラス図とは、UML（統一モデリング言語）の一つで、オブジェクト指向システムを構成するクラス（設計図）とその属性・操作、そしてクラス同士の関係性（関連・継承・集約など）を視覚的に表現する図です。システムの「静的な構造」を示し、設計段階での可視化や関係者間の共通認識形成、コードの実装ガイドとして非常に重要で、文字ベースの仕様書よりも分かりやすいのが特徴です。

画像参照：https://cacoo.com/ja/blog/how-to-write-class-diagram/

主な要素

クラス: 長方形で表現され、上部にクラス名、中段に属性（データ）、下段に操作（メソッド）を記述します。
属性: クラスが持つデータ（例: 名前、年齢など）。
操作: クラスが実行できる処理（例: getName(), setAge()など）。
可視性: 属性や操作の公開範囲（+公開、-private、#protectedなど）。
関係線: クラス間の関係を示す線（関連、集約、汎化（継承）、依存など）。

できること・使われる場面

システムの構造を可視化: システムがどんな部品（クラス）でできていて、どう繋がっているかを一目で把握できる。
設計の明確化: 設計の抜け漏れを防ぎ、開発者が実装する際の具体的な設計図となる。
コミュニケーションの円滑化: 開発者だけでなく、非技術者を含む関係者全員の共通認識を作る。
オブジェクト指向プログラミングの設計: JavaやC#などの言語でクラスを定義する際の設計に利用される。

線形の意味

クラス図で使用される線形にはそれぞれ意味があります。下記キャプチャにて意味の説明をきさしていますのでご確認ください。

画像参照：https://cacoo.com/ja/blog/how-to-write-class-diagram/

コンポジット

「集約」は「全体と部分」の関係で、部分が複数の全体に共有されたり、独立して存在できる（ライフサイクルが異なる）関係を指し、白抜きのひし形で表現されますが、コンポジットは集約のより強い形式で、部分（子）はただ一つの全体（親）に属し、親が消滅すると子も連鎖的に消滅する関係（ライフサイクルが一致）を指し、黒塗りのひし形で表現されます。つまり、コンポジットは「全体が部分の生成・削除の権利を持つ」という点で集約と異なります。

依存

「依存」とは、あるクラスが他のクラスの機能やインスタンスを一時的に利用する「弱い」関係性のことで、一方のクラス（クライアント）が変更されると、もう一方のクラス（サプライヤ）にも影響が及ぶ可能性があることを示します。図では、点線と矢印（サプライヤ側を指す）で表現され、「ヴァイオリニストがヴァイオリンを弾く」ように、メソッドの引数や戻り値、または一時的な生成などで使われる関係性です。

実現

共通操作を定義したクラスと個別動作を定義したクラス間の関係を「実現」と言います。

誘導可能性

クラス間の関連において、どちらのクラスから相手のクラスを参照（操作）できるか、その参照の「方向性」を示すものです。単方向の参照（片方からもう片方へ）を矢印で示し、双方向の場合は矢印なし、または「×」で片方の参照が不可能であることを示して表現され、システム実装時のオブジェクト間の依存関係を明確にするために重要です。

画像参照：https://cacoo.com/ja/blog/how-to-write-class-diagram/

シーケンス図

シーケンス図とは、UML（統一モデリング言語）の一つで、システム内のオブジェクト（部品）同士がメッセージをやり取りする処理の流れを「時間軸」に沿って視覚的に表現した図です。誰が、いつ、誰に、何を送るか、という処理の順序や流れを明確にし、システムの動作を直感的に理解できるようにするため、設計段階での仕様確認や顧客への説明、保守運用時の仕様把握などに用いられます。

画像参照：https://product.strap.app/magazine/post/knowhow_sequence

主な特徴と目的

時系列での表現: 縦方向に時間が流れ、メッセージ（処理要求）が上から下へ順に流れていきます。
相互作用の可視化: オブジェクト（例：ユーザー、サーバー、データベースなど）がどのように連携して機能を実現するかを示します。
明確な記号: オブジェクトは「ライフライン」と呼ばれる縦線で、メッセージは矢印で表現され、特定のルールに従って描かれます。
ユースケースの具体化: ある機能（ユースケース）を実現するための具体的な処理手順（シナリオ）を明確にできます。

主な構成要素

ライフライン: 相互作用に関わるオブジェクトやコンポーネントを表す縦線。
メッセージ: オブジェクト間で送受信される情報（処理要求やデータ）を表す矢印。
複合フラグメント: 繰り返しや条件分岐（if文など）といった制御構造を示す枠。

メリット

処理のロジックが明確になり、開発者間の認識齟齬を防ぐ。
顧客への説明資料として、システムの動作イメージを共有しやすい。
既存システムの仕様を分析し、保守・運用時に参照するドキュメントとなる。

どのような時に使うか

システムの設計（詳細設計）段階。
顧客やチームメンバーに処理の流れを説明する際。
既存システムの仕様を分析・理解する際。

アクティビティ図

アクティビティ図とは、UML（統一モデリング言語）の1つで、業務やシステムの処理手順、ワークフローの流れを視覚的に表現する図です。フローチャートに似ていますが、条件分岐（デシジョン）や並行処理（フォーク・ジョイン）などをより詳細に記述でき、開始から終了までの一連のアクション（行動）を「アクション」と「フロー」でつなぎ、業務プロセス全体の流れやロジックを関係者間で共有・理解するために使われます。

画像参照：https://cacoo.com/ja/blog/what-is-activity-diagram/

主な特徴と用途

処理の流れの可視化: 特定の業務やシステムが「何をして」「どのように進むか」を分かりやすく図示します。
UMLの「振る舞い図」: ユースケース図などと同様に、システムの動的な振る舞いをモデル化します。
フローチャートの拡張: 逐次的な流れだけでなく、並行処理やデータフローも表現できます。
活用シーン: システム開発前の要件定義、分析・設計フェーズでのロジック定義、ビジネスプロセスの改善、クライアントとの認識合わせなどに利用されます。

主な要素

開始ノード: 黒丸で示され、プロセスの始まりを表します。
アクション（行動）: 角丸四角形で示され、最小の動作単位です。
フロー（流れ）: 矢印でアクション間の依存関係を示します。
終了ノード: 丸に×印で示され、プロセスの終了を表します。
制御フロー/オブジェクトフロー: 制御の流れ（アクションの順序）やオブジェクト（データ）の流れを示します。
スウィムレーン（分割領域）: 縦または横に図を分割し、どの担当者（人やコンポーネント）がどの処理を行うかを示せます。