概要

データ指向アプローチ(Data Oriented Approach)とは、業務で扱うデータの構造や流れに着目し、システム設計を行う手法であり、企業で扱うデータの統一的なデータベースを作り、一元化することで個々のシステム設計をシンプルにするというアプローチです。

モデリング手法

 DOAでは、まず業務で扱うデータ全体をERモデル(Entity-Relationship model)によってモデル化し、それを正規化してRDB(リレーショナルデータベース)を設計します。
個々のシステムはこのデータベースを中心に設計されます。

利点

DOAは、統一的なデータベースを中心にして各部署のシステムが設計されるため、データの整合性・一貫性が保たれ、システム間のやりとりが容易になります。
また、業務内容の変更によりシステム改変が必要になった時も、データベースの構成が定まっているため、POAよりも改変が容易になります。

欠点

DOAは、データとプログラムが切り離されているため、一度モデリングしたデータ構造を変更すると，関連するプログラムを特定するのが極めて難しいことです。
このため，システムの追加・修正の際にデータ構造を変更する必要があると，多大な手間と時間が掛かります。

このトピックは準備中です。

ソフトウェア工学が扱う対象の基本的な構成要素は，プロダクト (product) とプロセス (process) です。
プロダク トとはエンジニアリングの過程で生成される中間製品や文書を含めたすべての生産物を指し、プロセスはプロダ クトを生み出す工程です。

これらの作業をスムーズに行えるようにするための各種の方法・手順・手段を纏めて、なんらかの原理や観点に基づいて統合した知的体系として定義されるのは、ソフトウェア開発方法論のことです。

開発技法

ソフトウェア開発技法は、ソフトウェアを開発する技術方法やテクニックのことです。 
以下の表でソフトウェア開発の局面別の技法を示します。

局面技法要求要求定義技法分析分析技法設計ソフトウェア設計技法実装プログラミング技法検証ソフトウェア検証技法 プロセスモデル

ソフトウェア開発プロセスは、ソフトウェアをどのように作り上げるかについて，手順や工程、成果物、進め方に関する基本的な考え方を定義したものです。ウォーターフォール型、反複型などが挙げられます。 
ソフトウェア開発プロセスは、ソフトウェア開発モデルと呼ばれることもあります。

このトピックは準備中です。

コンポーネントベース開発(Component-Based Development,CBD)とは、ソフトウェアを機能又はその他何かの単位で部品に分割し、得られたソフトウェア部品を組み合わせることによって開発を進めるソフトウェア開発方法です。

クラスライブラリやフレームワークに代表されるオブジェクト指向(OOA)が効果的な再利用を実現できなかったことから、 それらの研究を継承・発展させる形で登場してきたコンポーネント指向ソフトウェア開発は、以下のような効果をもたらすと期待されています。

開発効率性
既存のコンポーネントを再利用することで、 目的とするソフトウェアの開発期間を短縮し、 開発コストを削減することができます。適応性 
構成する個々のコンポーネントの置換・修正作業によって、ソフトウェア全体の要求仕様や運用環境の変化に対応することができます。信頼性 
信頼性の高いコンポーネントを組み合わせることで、 ソフトウェア全体について一定以上の信頼性が得られます。位置透過性 
インタフェースと実装の分離に基づき、コンポーネントを分散オブジェクトとすることで、 ネットワーク上におけるコンポーネント群の配備状況を意識する必要が減少されます。

本トピックは、まずコンポーネントの定義を明確にして、それからコンポーネント指向開発の説明を展開します。 

コンポーネントとは

コンポーネントというのは、部品、成分、構成要素などの意味をもつ英単語(Component)です。その意味で様々な分野で使われていますので、ITの分野では、システム・コンポーネントや、ハードウェア・コンポーネント、ソフトウェア・コンポーネン、ネットワーク・コンポーネントトといった場面があります。  ほかに意味の似た単語に「モジュール」(module)がありますが、違いとしては、「モジュールには、他の部品への接合部の仕様が標準化され、容易に追加や交換ができるような構成要素といった意味合いが込められることが多いのに対し、コンポーネントは単純に要素や部品一般のことを指すことが多い」とされています。。

ソフトウェア分野のコンポーネントとは、ある機能を実現するために部品化されたソフトウェア又はその構成要素のことで、ソフトウェア・コンポーネント(Software Component)の略です。

ソフトウェア分野で「モジュール」もよく使われますが、両者の違いとしては以下の見解が一般的です。

コンポーネント：それだけで完結した部品モジュール：粒度が少し高い部品を構成するための内部要素

規模の大きさではなく枠組みとしては「コンポーネント＞モジュール」の感じです。

コンポーネントの見方

コンポーネントには、実装部品とサービス部品の二つの見方があります、  前者は、GUI部品やEJBなどのプログラムに組み合わせて使うものを指し、後者は、業務機能やWebサービスなど必ずしも実装の実体とは限らないロジックプロセスの処理単位を指します。  下記の表にて各視点からふたつの見方の違いを説明します。

視点1:配置/ランタイム視点2:静的に/動的に視点3:物理/論理実装部品配置モデルのシステム構成要素静的なアーキテクチャモデルのシステム構成要素物理構成要素サービス部品ランタイムモデルのシステム構成要素動的なアーキテクチャモデルのシステム構成要素論理構成要素 コンポーネントの技術

コンポーネントの実装技術はいかのようなものがあげられます、カッコ内にあるのはそのコンポーネント技術を開発した会社又は組織の名称です。

OSGI组件模型J2EE组件模型(Sun Microsystems社、現在はOracle社)COM组件模型(Microsoft社)NWDI组件模型(SAP社)VCL(CLX)组件模型(Borland社、現在はMicro Focus社)

概要

プロセス指向アプローチ(Process Oriented Approach,POA)は、データの「入力」、「加工」、「出力」という3つのまとまりから成る「処理」に重点を置いたアプローチです。
ただし、データを完全に無視しているわけではなく、POAでは、システムを構成する処理と処理の間をデータが通過していくと考え、データを処理の附属的な存在と捉えています。

モデリング手法

POAの代表的な表記法であるDFDは、構造化分析で有名なトム・デマルコ氏が提唱した表記法です。
DFDは「データの流れ図」という意味だが、実際にはシステムを構成する「処理」の構造に着目しています。

例えば、販売管理システムのDFDは、下記の図のように記述できます。

「顧客」というデータの発生源（源泉と呼ぶ）から生じた「注文」データが、「受注」→「在庫チェック」→「出荷」→「請求」という処理をたどって加工されながら流れていきます。
「受注」と「在庫チェック」という処理を実施するために、「顧客マスタ」と「商品マスタ」というファイル（データ）が参照されます。
ただしPOAでは、あくまでシステムの主役が「処理」であるため、これらのデータが一元管理されているわけではなく、システムごとに用意する必要があります。

利点

POAは、業務の手順や工程を図などに書き表して定義し、それに合わせてソフトウェアやシステムの挙動を決定していく。現実の手順に基いてシステムの動作を考えるため分かりやすく、設計工程を比較的容易に素早く進めることができます。

欠点

POAは、業務内容を中心に設計されるため、各部署の業務内容に応じて独立したシステムになることが多く、システム間のやりとりが複雑になるという問題点がありました
また、システムが業務内容に強く依存しているため、業務内容が変更になった時には、システムの大幅な改変が必要です。