用語(5)
構造化手法
処理(機能)に着目し、システムを段階的に細かい機能へ分割して設計する手法。
構造化手法は、システムを「何をするか(処理・機能)」に注目してとらえ、大きな機能を小さな機能へと段階的に分けていく(機能分割する)設計の考え方です。処理の流れやデータの流れを整理しながら、上位から下位へと細分化します。
試験では、データと処理を一体としてまとめるオブジェクト指向との違いが問われます。構造化手法は「処理(機能)中心」、オブジェクト指向は「データと処理をまとめたオブジェクト中心」と対比して覚えるのがポイントです。DFD(データフロー図)などの図法と結び付けて出題されることもあります。
たとえ料理の作業を「下ごしらえ→調理→盛り付け」と作業手順(処理)ごとに分けて整理するイメージ。やるべき仕事の流れに沿ってどんどん細かい作業へ分解していきます。
記憶フック構造化手法といえば処理(機能)中心に段階的な機能分割
オブジェクト指向
データとその処理(操作)を一体化した「オブジェクト」を単位として設計する考え方。
オブジェクト指向は、関連するデータ(属性)とそれを扱う処理(操作・メソッド)をひとまとめにした「オブジェクト」を基本単位としてシステムを構築する考え方です。共通の性質をひな型として定義した「クラス」から、実体である「オブジェクト」を生成します。
試験では、カプセル化(データと処理をまとめ内部を隠す)、継承(共通の性質を引き継ぐ)、多態性(同じ指示で対象ごとに異なる動作)といった基本特徴が問われます。処理中心の構造化手法と対比され、部品の再利用や保守のしやすさが利点とされる点も頻出です。
たとえ「自動車」という設計図(クラス)から、実物の車(オブジェクト)を作るイメージ。車は色や速度(データ)と、走る・止まる(処理)を一体で持ち、設計図を引き継いで新型(継承)も作れます。
記憶フックオブジェクト指向といえばデータと処理をまとめたオブジェクト中心(カプセル化・継承・多態性)
ユースケース
利用者(アクター)から見たシステムの使い方・機能を表した記述。
ユースケースは、システムを使う人や外部システム(アクター)が、システムを通じてどんなことを達成できるかを、利用者の視点でまとめたものです。要求を整理する分析段階で、「誰が」「何をするか」を明確にするために使われます。
試験では、UMLのユースケース図として、アクター(人型)とユースケース(楕円)で機能を表現する記法が問われます。内部の処理手順ではなく「外から見た機能・利用シナリオ」を表す点が、他の図との違いとして重要です。
たとえATMの使い方を「客が:お金を下ろす・預ける・残高を見る」と利用者目線で一覧にしたもの。機械の内部の仕組みではなく、利用者が何をできるかを並べたイメージです。
記憶フックユースケースといえば利用者(アクター)視点で見たシステムの使い方
UML
オブジェクト指向設計を図で表現するための標準化された統一モデリング言語。
UML(Unified Modeling Language、統一モデリング言語)は、オブジェクト指向に基づくシステムの構造や振る舞いを、決められた記法の図で表すための標準的なモデリング言語です。クラス図・ユースケース図・シーケンス図など複数の図を用途に応じて使い分けます。
試験では、UMLが特定の製品やプログラミング言語ではなく「図で設計を表す共通の表記ルール」である点が問われます。ユースケース図もUMLに含まれる図の一つであり、オブジェクト指向開発で広く使われる標準記法だと押さえましょう。
たとえ建築の設計図に共通の製図ルールがあるように、ソフトの設計を誰が見ても同じように読める「共通の図の書き方ルール」がUMLです。
記憶フックUMLといえばオブジェクト指向設計の標準モデリング図(クラス図・ユースケース図など)
リバースエンジニアリング
既存の製品やプログラムを解析し、その仕様や設計情報を取り出す技法。
リバースエンジニアリングは、すでにある製品・ソフトウェア・実行プログラムなどを分析して、内部の構造・仕様・設計情報を後から取り出す技法です。設計書が残っていない既存システムの理解や、保守・再構築のために使われます。
試験では、設計から製品を作る通常の流れ(フォワードエンジニアリング)とは逆向き、つまり「成果物から設計へさかのぼる」点が問われます。古いシステムの仕様を復元する目的が典型例で、リエンジニアリング(再構築)の前段階として登場することもあります。
たとえ完成した料理を食べて分析し、レシピ(材料・手順)を推定して書き起こすイメージ。出来上がったものから作り方をさかのぼって解き明かします。
記憶フックリバースエンジニアリングといえば既存成果物から設計情報を逆に取り出す