System-analysis-and-design-object-oriented-approach

提供:Dev Guides
移動先:案内検索

オブジェクト指向アプローチ

オブジェクト指向のアプローチでは、情報システムの構造と動作をデータとプロセスの両方を組み合わせた小さなモジュールにキャプチャすることに焦点が当てられています。 オブジェクト指向設計(OOD)の主な目的は、システムの分析と設計をより使いやすくすることで、品質と生産性を向上させることです。

分析フェーズでは、オブジェクト指向モデルを使用して、問題と解決策の間のギャップを埋めます。 システムが継続的な設計、適応、およびメンテナンスを受けている状況で良好に機能します。 問題領域内のオブジェクトを識別し、データと動作の観点から分類します。

オブジェクト指向モデルは、次の点で有益です-

  • 低コストでシステムの変更を容易にします。
  • コンポーネントの再利用を促進します。
  • コンポーネントを統合して大規模システムを構成する問題を簡素化します。
  • 分散システムの設計を簡素化します。

オブジェクト指向システムの要素

オブジェクト指向システムの特徴を見てみましょう-

  • オブジェクト-オブジェクトは問題のドメイン内に存在するものであり、データ(属性)または動作によって識別できます。 すべての有形のエンティティ(学生、患者)と一部の無形のエンティティ(銀行口座)はオブジェクトとしてモデル化されます。
  • 属性-オブジェクトに関する情報を記述します。
  • 動作-オブジェクトができることを指定します。 オブジェクトに対して実行される操作を定義します。
  • クラス-クラスはデータとその動作をカプセル化します。 類似した意味と目的を持つオブジェクトは、クラスとしてグループ化されます。
  • メソッド-メソッドはクラスの動作を決定します。 それらは、オブジェクトが実行できるアクションにすぎません。
  • メッセージ-メッセージは、あるオブジェクトから別のオブジェクトへの関数またはプロシージャの呼び出しです。 これらは、メソッドをトリガーするためにオブジェクトに送信される情報です。 基本的に、メッセージは、あるオブジェクトから別のオブジェクトへの関数またはプロシージャの呼び出しです。

オブジェクト指向システムの機能

オブジェクト指向システムには、以下で説明するいくつかの優れた機能が付属しています。

カプセル化

カプセル化は、情報を隠すプロセスです。 これは、プロセスとデータを単一のエンティティに単純に組み合わせたものです。 オブジェクトのデータはシステムの他の部分から隠されており、クラスのサービスを通じてのみ利用可能です。 システムの他の部分に影響を与えることなく、オブジェクトが使用するメソッドを改善または変更できます。

抽象化

これは、オブジェクトを指定するために必要なメソッドと属性を取得または選択するプロセスです。 ユーザーの視点から見たオブジェクトの本質的な特性に焦点を当てています。

関係

システム内のすべてのクラスは互いに関連しています。 オブジェクトは孤立して存在するのではなく、他のオブジェクトとの関係で存在します。

オブジェクトの関係には3つのタイプがあります-

  • 集約-全体とその部分の関係を示します。
  • 関連付け-これでは、1つのクラスが別のクラスと連携してタスクを実行したり、1つのクラスが他のクラスに作用するなど、何らかの方法で2つのクラスが関連付けられます。
  • 一般化-子クラスは親クラスに基づいています。 2つのクラスが似ているが、いくつかの違いがあることを示しています。

継承

継承は、既存のクラスの属性や操作を継承することで、既存のクラスからサブクラスを作成できる優れた機能です。

多態性と動的バインディング

多態性とは、さまざまな形をとる能力です。 オブジェクトと操作の両方に適用されます。 ポリモーフィックオブジェクトとは、スーパークラスまたは親クラス内で真のタイプが隠れるオブジェクトです。

ポリモーフィック操作では、オブジェクトのクラスによって操作が異なる場合があります。 共通のプロパティのみを知ることで、異なるクラスのオブジェクトを操作できます。

構造化アプローチ対 オブジェクト指向アプローチ

次の表は、オブジェクト指向アプローチが従来の構造化アプローチとどのように異なるかを説明しています-

Structured Approach Object Oriented Approach
It works with Top-down approach. It works with Bottom-up approach.
Program is divided into number of submodules or functions. Program is organized by having number of classes and objects.
Function call is used. Message passing is used.
Software reuse is not possible. Reusability is possible.
Structured design programming usually left until end phases. Object oriented design programming done concurrently with other phases.
Structured Design is more suitable for offshoring. It is suitable for in-house development.
It shows clear transition from design to implementation. Not so clear transition from design to implementation.
It is suitable for real time system, embedded system and projects where objects are not the most useful level of abstraction. It is suitable for most business applications, game development projects, which are expected to customize or extended.
DFD & E-R diagram model the data. Class diagram, sequence diagram, state chart diagram, and use cases all contribute.
In this, projects can be managed easily due to clearly identifiable phases. In this approach, projects can be difficult to manage due to uncertain transitions between phase.

統一モデリング言語(UML)

UMLは、プロセス、ソフトウェア、およびシステムをモデル化して、システムアーキテクチャの設計を表現できるビジュアル言語です。 これは、技術設計者が開発者と通信できるようにするオブジェクト指向の方法でシステムを設計および文書化するための標準言語です。

これは、Object Management Groupによって作成および配布される一連の仕様として定義されます。 UMLは拡張可能でスケーラブルです。

UMLの目的は、分析から実装までのあらゆるシステム開発プロジェクトをモデル化するのに十分な豊富なオブジェクト指向用語と図表化技術の共通語彙を提供することです。

UMLはで構成されています-

  • -プロセス、システム、またはその一部の図的表現です。
  • 表記-コネクタ、シンボル、メモなどの図で一緒に機能する要素で構成されます。

クラスのUML表記の例

クラス表記

インスタンス図-UML表記

UML表記法

オブジェクトに対して実行される操作

次の操作がオブジェクトに対して実行されます-

  • コンストラクタ/デストラクタ-クラスの新しいインスタンスを作成し、クラスの既存のインスタンスを削除します。 たとえば、新しい従業員を追加します。
  • クエリ-値を変更せずに状態にアクセスすると、副作用はありません。 たとえば、特定の従業員の住所を検索します。
  • 更新-1つまたは複数の属性の値を変更し、オブジェクトの状態に影響します。たとえば、従業員の住所を変更します。

UMLの使用

UMLは次の目的のために非常に便利です-

  • ビジネスプロセスのモデリング
  • システムアーキテクチャの説明
  • アプリケーション構造の表示
  • システム動作のキャプチャ
  • データ構造のモデリング
  • システムの詳細な仕様を作成する
  • アイデアのスケッチ
  • プログラムコードの生成

静的モデル

静的モデルは、システムの構造特性を示し、そのシステム構造を記述し、システムを構成する部分を強調します。

  • クラス名、属性、メソッド、署名、パッケージを定義するために使用されます。
  • 静的モデルを表すUML図には、クラス図、オブジェクト図、ユースケース図が含まれます。

動的モデル

動的モデルは、システムの動作特性、つまり外部イベントに応答してシステムがどのように動作するかを示します。

  • 動的モデルは、必要なオブジェクトと、メソッドとメッセージを介してどのように連携するかを特定します。
  • システムのロジックと動作を設計するために使用されます。
  • UMLダイアグラムは、シーケンス図、コミュニケーション図、状態図、アクティビティ図などの動的モデルを表します。

オブジェクト指向システム開発のライフサイクル

それは3つのマクロプロセスで構成されています-

  • オブジェクト指向分析(OOA)
  • オブジェクト指向設計(OOD)
  • オブジェクト指向実装(OOI)

オブジェクト指向ライフサイクル

オブジェクト指向システム開発活動

オブジェクト指向システムの開発には、次の段階が含まれます-

  • オブジェクト指向分析
  • オブジェクト指向設計
  • プロトタイピング
  • 実装
  • 増分テスト

オブジェクト指向分析

このフェーズでは、システム要件を決定し、システム要件を理解して*ユースケースモデル*を構築します。 ユースケースは、ユーザーとコンピューターシステム間の相互作用を説明するシナリオです。 このモデルは、システムのユーザーニーズまたはユーザービューを表します。

また、アプリケーションを構成するクラスと、問題ドメイン内の他のクラスとの関係を識別することも含まれます。

オブジェクト指向設計

このフェーズの目的は、分析フェーズ、ユーザーインターフェイス、およびデータアクセス中に識別されるクラス、属性、メソッド、および構造を設計および改良することです。 このフェーズでは、要件の実装をサポートする追加のクラスまたはオブジェクトも識別および定義します。

プロトタイピング

プロトタイピングにより、システムの一部の機能を実装することがどれだけ簡単か難しいかを完全に理解できます。

また、ユーザーにデザインの使いやすさと有用性についてコメントする機会を与えることができます。 さらに、ユースケースを定義し、ユースケースのモデリングをはるかに簡単にすることができます。

実装

コンポーネントベース開発(CBD)または高速アプリケーション開発(RAD)のいずれかを使用します。

コンポーネントベースの開発(CBD)

CODDは、CASEツールなどのさまざまな技術を使用したソフトウェア開発プロセスへの工業化されたアプローチです。 アプリケーション開発は、カスタム開発から、相互に動作するビルド済み、テスト済み、再利用可能なソフトウェアコンポーネントのアセンブリに移行します。 CBD開発者は、コンポーネントを組み立てて完全なソフトウェアシステムを構築できます。

迅速なアプリケーション開発(RAD)

RADは、従来の方法で通常可能であったよりも高速にアプリケーションを構築するために使用できるツールとテクニックのセットです。 SDLCに代わるものではなく、プロセス記述に重点を置いており、オブジェクト指向アプローチと完全に組み合わせることができるため、SDLCを補完します。

そのタスクは、Visual Basic、パワービルダーなどのツールを使用して、ユーザー要件設計を迅速かつ段階的に実装することです。

増分テスト

ソフトウェア開発とテストを含むすべてのアクティビティは、反復プロセスです。 したがって、製品が完全に開発されて初めてテストを待つと、費用のかかる事態になる可能性があります。 ここでは、開発のさまざまな段階で製品がテストされる段階的なテストが行​​われます。