Pegaでの基本の基本のコンセプトとしては、ルールとクラスがあります。
ルール
Pegaでは、公式的に「ルール」を以下のように定義しています。
A rule is a named business object that defines the behavior of part of an application。 ルールは、アプリケーションの一部の動作を定義する名前付きビジネスオブジェクトです。
すこし分かりにくいかもしれませんが、言い換えてみると、Pegaでのルールは、UIやデータモデル、ロジックなどPegaアプリケーションを構成する各々の部品です。
Javaなどのオブジェクト指向言語を使って開発されるアプリケーションのクラスや、SAP開発でのリポジトリオブジェクト(開発オブジェクト)に相当するものです。
Pegaは、ノンコーディング開発を謳っているため、コーディング上の用語を使用せずに、アプリケーションの各部品はそれぞれアプリケーションの一部の規則を定めているということから、「ルール」という名前を付けたでしょう。
ルールタイプ
ルールタイプはルールが所属しているタイプを定めております。Pegaでは多数のルールタイプが提供されており、その中に最も典型のは、画面のブロックを表すセクションや、ビジネスケースを表すケースタイプがあります。
ルールセット
ルールの開発とリリースを管理するには、ルールセットと呼ばれるグループにルールをまとめます。
ルールセットは名前(例：Pega-LP-ProcessAndRules:)とバージョン(例：07-10-01)で識別されます、ルールセットの内容を更新するには、新しいルールセットのバージョンを作成します。
レコード
アプリケーションを構成する各ルールは、それぞれのルールタイプのインスタンスとして作成されます。このルールタイプのインスタントはPegaでレコードとよばれます。
レコードは①ID、②ルールタイプ、③適用先のクラス(後続で説明)、④ルールセットの四つにより、Pegaシステム内にユニークで識別されます。
クラス
Pegaでは、公式的に「クラス」を以下のように定義しています。
A class groups a collection of rules or other objects. Each class defines capabilities (rules that include properties, activities, and HTML forms) that are available to other, subordinate classes, or to instances of the class。 クラスは、ルールまたは他のオブジェクトの集まりをグループ化したものです。各クラスは、他の下位クラス、 またはそのクラスのインスタンスで使用可能な機能（プロパティ、アクティビティ、およびHTMLフォームを 含むルール）を定義します。
(クラスの分類)
クラスは大きく下記の二つに分類することができます。
- concrete class
具象クラス。 - abstract class
抽象クラス
具象クラスは、インスタンスをデータベースに格納できます。対照的に、抽象クラスは通常、インスタンスを持たない、持つにしてもデータベースへの格納がなく、メモリ上の保持のみになります。
(クラスの階層)
Pegaではクラスに他のクラスを含めることもできます。
別のクラスを含むクラスは、親クラスと呼ばれ、別のクラスに含まれるクラスは、子クラスと呼ばれます。この親子関係によってPegaアプリケーションを構成する各クラスは一つのツリー構造で管理することができます。
各クラスの名前には、頭に親クラスの名前と区切り文字のハイフン（-）をふくめていますので、名前からクラス階層内でのクラスの位置を識別することができます。
(クラスの継承)
Pegaでクラスの間にルールを継承するには、パターン継承とダイレクト継承という2つの方法があります。
- パターン継承
パターン継承はクラス階層に則った親クラス(ビジネス上の関係を持ち、同じアプリケーションのクラスが多い)のルールをアクセスや上書きできます。 - ダイレクト継承
ダイレクト継承は、ダイレクトとして指定された親クラス(機能上の関係を持ち、別アプリケーションのクラスが多い)のルールをアクセスや上書きできます。
継承を通じてルールを再利用しようとすると、Pegaでは最初にパターン継承で(デフォルト、クラスの定義画面で変更可能)指定される親クラスから検索されます。その検索で見つからない場合に、ダイレクト継承で指定される親クラスが新たなパターン継承検索のベースとなって検索されます。このプロセスは、クラス階層の最後のクラスが検索されるまで繰り返されます。この最後のクラスを、最終ベースクラス、または@baseclassと呼びます。@baseclassを検索してもルールが見つからないと、ペガからエラーが返されます。
ソフトウェア工学が扱う対象の基本的な構成要素は，プロダクト (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社)
概要
データ指向アプローチ(Data Oriented Approach)とは、業務で扱うデータの構造や流れに着目し、システム設計を行う手法であり、企業で扱うデータの統一的なデータベースを作り、一元化することで個々のシステム設計をシンプルにするというアプローチです。
モデリング手法
DOAでは、まず業務で扱うデータ全体をERモデル(Entity-Relationship model)によってモデル化し、それを正規化してRDB(リレーショナルデータベース)を設計します。
個々のシステムはこのデータベースを中心に設計されます。
利点
DOAは、統一的なデータベースを中心にして各部署のシステムが設計されるため、データの整合性・一貫性が保たれ、システム間のやりとりが容易になります。
また、業務内容の変更によりシステム改変が必要になった時も、データベースの構成が定まっているため、POAよりも改変が容易になります。
欠点
DOAは、データとプログラムが切り離されているため、一度モデリングしたデータ構造を変更すると，関連するプログラムを特定するのが極めて難しいことです。
このため，システムの追加・修正の際にデータ構造を変更する必要があると，多大な手間と時間が掛かります。
概要
プロセス指向アプローチ(Process Oriented Approach,POA)は、データの「入力」、「加工」、「出力」という3つのまとまりから成る「処理」に重点を置いたアプローチです。
ただし、データを完全に無視しているわけではなく、POAでは、システムを構成する処理と処理の間をデータが通過していくと考え、データを処理の附属的な存在と捉えています。
モデリング手法
POAの代表的な表記法であるDFDは、構造化分析で有名なトム・デマルコ氏が提唱した表記法です。
DFDは「データの流れ図」という意味だが、実際にはシステムを構成する「処理」の構造に着目しています。
例えば、販売管理システムのDFDは、下記の図のように記述できます。
「顧客」というデータの発生源（源泉と呼ぶ）から生じた「注文」データが、「受注」→「在庫チェック」→「出荷」→「請求」という処理をたどって加工されながら流れていきます。
「受注」と「在庫チェック」という処理を実施するために、「顧客マスタ」と「商品マスタ」というファイル（データ）が参照されます。
ただしPOAでは、あくまでシステムの主役が「処理」であるため、これらのデータが一元管理されているわけではなく、システムごとに用意する必要があります。
利点
POAは、業務の手順や工程を図などに書き表して定義し、それに合わせてソフトウェアやシステムの挙動を決定していく。現実の手順に基いてシステムの動作を考えるため分かりやすく、設計工程を比較的容易に素早く進めることができます。
欠点
POAは、業務内容を中心に設計されるため、各部署の業務内容に応じて独立したシステムになることが多く、システム間のやりとりが複雑になるという問題点がありました
また、システムが業務内容に強く依存しているため、業務内容が変更になった時には、システムの大幅な改変が必要です。
ウォータフォールモデルは、古くから利用されているシステム開発モデルで、ほとんどの開発プロジェクトでこのモデルが使用されるほど広く普及していました。
このモデルは、ソフトウェアの各開発工程を上流から下流まで段階的に区切りながら、流れ落ちる滝のように見立てています。
特徴
ウォータフォールモデルは、原則的に手前の工程に遡ることができないので、以下のような特徴をもっております。
- 開発工程を明確に区切って、各工程毎に厳密な確認と検証を行う
- 各工程の成果物を文書にきちんと纏めて、そのアウトプットを次の工程のインプットにする
利点
ウォータフォールモデルの利点は、管理と工数見積もりがやりやすいところです。
- 開発管理がやりやすく、特に大規模なソフトウェア開発に適している
- 工数見積もりがやりやすい、特に人月ベースの契約受注プロジェクトに適している
- 業務コンサルタント、システムエンジニア、プログラマ、テスタによる分業体制が確立しているため、 参加者が担う役割は固定的で考える事が少ない
- 要員の調達が比較的に容易に行えるため、特に労働集約型ビジネスモデルに適している
欠点
ウォータフォールモデルの欠点は、コストが高く品質管理がしにくいところです。
- ソフトウェアの実物を見られるようになるまでの時間が長い
- 設計と設計の成果物の検証とも机上レベルでしかできず、品質が担保しにくい
- 問題の早期発見が難しく、遅れるほど解決のコストが大きくなる
- 価値が少ないドキュメント作成にもやたら工数がかかる
このためウォータフォールモデルを採用するほとんどの開発プロジェクトでは、前工程の完了要件（要件定義局面であれば、要件定義書などの成果物の完成）を徹底して品質を高め、後戻りの発生率を可能な限り低下させるとともに、後戻りが発生する場合は変更管理によって公式に決定し、後戻りや横展開を確実にフォローするように工夫しております。
モデリングするには、モデリング言語を使用します。
モデリング言語は、ルールの一貫したセットで定義された構造によって情報、知識あるいはシステムを表現するため使われるあらゆる人工言語のことです。
モデリング言語は図式またはテキスト形式であり得ます。
- 図式モデリング言語
図式モデリング言語は、概念を表す名前を持つシンボルと、そのシンボルを結合しその関係を表現するライン、及び制約を表現する様々な図式表記を持つダイアグラム技術を使います。 - テキスト形式モデリング言語
テキスト形式モデリング言語は通常、コンピュータが解釈可能な表現にするパラメータによって達成される標準化されたキーワードを使います。
モデリングを行う手法としては、分類や分割、階層化といった方法があります。これも人間が世界を認識するための基本手法です。
- 分類
分類とは、事物や現象を、何らかの基準に従って区分することによって体系づけることです。
例えばある企業の人事システムでは、従業員を職位に従って、一般社員、係長、課長、部長、社長に分類することがあります。 - 分割
分割とは、複雑なものをより簡単な構成要素に分けることです。
システムを複数のサブシステムに分けたり、業務を複数の機能に分けたりします。 - 階層化
階層化とは、システムを互いに独立している複数の階層に分けて分析、設計及び実装のことです。
モデリングとは、業務の流れやシステムの構成、といった、論理世界にしか存在しないものを可視化するための技法です。
モデリングは、記号を使ってモデルを作成することによって、問題点の洗い出しや理解の深まり、人間同士間の認識共有を図ります。
なお、業務やシステムを視点に分けてモデリングすることによって、複雑なものを単純化にして人間に理解しやすくすることができます。
人間同士の認識共有
ソフトウェアシステム開発に関わる人間は主に、ソフトウェアシステムを利用する「ユーザ」とソフトウェアを開発する「エンジニア」に大別することができますので、人間同士間の認識共有も、ユーザとエンジニア間の認識共有とエンジニア同士間の共有に分けることができます。
- ユーザとエンジニア間の認識共有
ソフトウェア開発では、ビジネスによる要件とシステムによる実装の間には大きな溝があります。エンジニアが直接自分が欲しいと思うソフトウェアを書く場合は、そのようなことはないかもしれません。
しかし、ソフトウェアのことを知らないユーザからの依頼によってソフトウェアの開発を行う場合には、当然この溝は非常に大きなものになります。
この溝を埋めるために用いる技術が「モデル」です。モデルを仲介して要件と実装の間の溝を埋めます。 - エンジニア同士間の認識共有
ごく小さいソフトウェアは一人で作り上げることもあるかもしれませんが、殆どの場合はチーム合同の作業になります、なかでは何百人、何千人のエンジニアが同時に開発を行うプロジェクトも少なくありません。
そこで分析や設計、実装、テストなどの作業を別々の人に担当してもらうのは殆どですので、モデルを通じて、エンジニア同士間の認識共有を図ります。
複雑なものを単純化
業務やシステムは複雑で，そのまま理解することは通常、人間にとっては難しいものです。
着目する視点を分けてモデリングすることによって、業務やシステムを単純化し，理解しやすくします。ただし，業務やシステム自体が単純になったわけではなく，単に着目する部分を絞っているだけです。
モデルは、図や表等でものごとを単純化して表現したものであり、以下のように様々な視点から分類することができます。
- 言語・表記法
- 対象
- 領域・局面
- 静的か動的か
- 論理か物理か
本トピックでは、各視点からのモデルの分類をそれぞれ説明します。
言語・表記法による分類
モデリング技法は、その仕様や成果物を言語・表記法としてまとめて公開されます。 以下によく使用されているモデリング言語・表記法を取り上げます。
| No. | 言語 | 説明 | SubNo. | 表記法 | 説明 |
|---|---|---|---|---|---|
| 1 | UML | Unified Modeling Language 統一モデリング言語 | - | - | - |
| 2 | BPMN | Business Process Modeling Notation ビジネスプロセスモデリング表記法 | - | - | - |
| 3 | ERD | Entity-Relationship Diagram 実体関連図 | 1 | IDEF1X | - |
| 2 | IE表記 | - | |||
| 4 | DFD | Data Flow Diagram データフロー図 | 1 | Yourdon&Coad記法 | - |
| 2 | Gane&Sarson記法 | シンボルは4つのみ | |||
| 5 | FlowChart | 流れ図 | - | JIS. X. 0128. -1988 | - |
モデリング技法は、基本的に形式化されたシステム言語を使用してモデルを記述しますが、UMLのユースケースのように自然言語で記述されるモデルもあります。
対象による分類
モデリング対象によって、モデルを以下のように分類することができます。
| No. | 対象 | UML2.0 | BPMN | ERD | DFD | 流れ図 |
|---|---|---|---|---|---|---|
| 1 | ビジネス | アクティビティ図
ユースケース図 コミュニケーション図 クラス図 オブジェクト図 | ○ | ○ | ○ | ○ |
| 2 | 組織 | クラス図
配置図 | × | ○ | × | × |
| 3 | データ | クラス図
オブジェクト図 パッケージ図 | × | ○ | × | × |
| 4 | システム | コンポーネント図
パッケージ図 クラス図 オブジェクト図 配置図 アクティビティ図 シーケンス図 コミュニケーション図 | × | ○ | ○ | ○ |
| 5 | プログラム | クラス図
コンポジット構造図 オブジェクト図 パッケージ図 アクティビティ図 ステートマシン図 シーケンス図 コミュニケーション図 | × | ○ | ○ | ○ |
領域・局面による分類
モデルの種類としては、「問題領域(problem domain)」モデルと「解決領域(solution domain)」モデルの二つに大別することができます。
- 問題領域モデル
「何(what)」をするのかをモデル化したものです。 - 解決領域モデル
その「何」をどう実現するのかをモデルしたものです
問題領域モデルと解決領域モデルは、目的に応じてさらに細分化されます。
| 領域 | モデル |
|---|---|
| 問題領域 | ドメイン分析モデル |
| 要求分析モデル | |
| 解決領域 | システム分析モデル |
| 設計モデル | |
| 実装モデル |
- ドメイン分析モデル
現実世界をモデリングしたモデルです。 - 要求分析モデル
やりたいことをモデリングしたモデルです。 - システム分析モデル
プログラミング言語や実行環境といった実現方法に依存しない、ITシステムとして本質的なレベルでの解決方法をモデリングしたモデルです。 - 設計モデル
プログラミング言語や実行環境を前提に具体的な実現方法をモデリングしたモデルです。 - 実装モデル
プログラミング言語などによる実装を指します。
静的か動的かによる分類
モデルを静的モデルと動的モデルに分類することができます。
- 静的モデル
静的な構造に関するモデルです。 - 動的モデル
動的挙動に関するモデルです。
| No. | 区分 | UML2.0 | BPMN | ERD | DFD | 流れ図 |
|---|---|---|---|---|---|---|
| 1 | 静的モデル | クラス図
コンポジット構造図 コンポーネント図 配置図 オブジェクト図 パッケージ図 | × | ○ | × | × |
| 2 | 動的モデル | アクティビティ図
ユースケース図 ステートマシン図 相互作用概要図 シーケンス図 コミュニケーション図 タイミング図 | ○ | × | ○ | ○ |
論理か物理かによる分類
モデルを論理モデルと物理モデルに分類することができます。
- 論理モデル
概念上のモデルやプログラム内に存在するオブジェクトに対するモデルです。 - 物理モデル
ファイルやノードなど具体的に扱うことができるリソースに対するモデルです。
| No. | 区分 | UML2.0 | BPMN | ERD | DFD | 流れ図 |
|---|---|---|---|---|---|---|
| 1 | 論理モデル | クラス図
コンポジット構造図 コンポーネント図 オブジェクト図 パッケージ図 その他振る舞いを表現する図 | ○ | ○ | ○ | ○ |
| 2 | 物理モデル | コンポーネント図
配置図 その他振る舞いを表現する図 | ○ | ○ | ○ | ○ |
コンピュータを構成する回路や装置などの物理的実体をハードウェア(Hardware)と呼ぶのに対し、ソフトウェア(Software）とは、そのハードウェアの上で動作して何らかの処理を行うプログラムのことです。
ソフトウェアにはさまざまな分類方法があります。
レイヤから分類
- 基本ソフトウェア
ハードウェアの基本的な制御を行い、ハードウェアの資源を有効活用するとともに、多くのソフトウェアが共通して利用する基本的な機能などを実装して、システム全体を管理するソフトウェアです。
主にOSのことを指しており、例えば、Windows、Unix、Linux、Android、iOSなどがあります。 - ミドルウェア
基本ソフトウェアと応用ソフトウェアの中間に位置し、OSの上に動作して応用ソフトウェアに対してOSよりも高度で具体的な機能を提供します。
データベース管理システム(Oracle、SQLServer…)、アプリケーションサーバ(Websphere、Webogic…)などがあります。 - 応用ソフトウェア
ユーザの利用目的に応じて作られたソフトウェアであり、アプリケーションソフトウェアとも呼ばれます。
Officeや会計ソフト、グループウエアなどがあります。
役割にようる分類
- 基盤ソフトウェア
企業などのソフトウェアシステムをサポートするために必要な共通機能を提供するものです。
例えば、OS、データベース、メールサーバ、ネットワーク管理、セキュリティ管理などがあります。 - ユーティリティーソフトウェア
コンピュータ上で機能する、補助的な機能を提供するソフトウェアであり、ツールソフトウェアや単にユーティリティーとも呼ばれます。
ファイルエディタや圧縮ツール、画像編集ツールなどがあります。 - 情報処理ソフトウェア
情報システムを構成するソフトウェアです。 - 組込ソフトウェア
産業機器や家電製品などに内蔵され、特定の機能を実現するための組み込みシステムで動作するソフトウェアです。 - ゲームソフトウェア
コンピュータゲームのソフトウェアのことです。 - …
ビジネス形態による分類
- 市販ソフトウェア
ソフトウェア開発に携わっている企業および会社が有料で販売しているソフトウェアです。一般販売しているため、OSやOfficeといった、広く利用できる汎用的なものが多い。
販売形態については、昔から主流だったパッケージ販売(量販店などの店頭で、記憶メディアに記録され、包装されたパッケージの状態で販売する）や、インターネットが普及してからのダウンロード販売、SaaS・クラウドが発展してからのサービス販売などがあります。 - 自社開発ソフトウェア
自社が使用するソフトウェアを自社で開発することです。 - オーダー生産ソフトウェア
自社が使用するソフトウェアの開発をベンダに委託することです。 - フリーソフトウェア
無料で提供されるソフトウェアであり、オンラインで配布されることが多い。 - シェアソフトウェア
無料な試用期間を設けて、試用期間後でも継続的な使用する場合は有償になるソフトウェアであり、フリーソフトウェアと同じ、オンラインで配布されることが多い
工学(Engineering)とは、主に数学、化学、物理をベースとする自然科学などの知識を応用して、実用的な技術発見や製品開発などを研究対象とする学問の総称です。
工学と対照的には、理学(Science)、医学(Medicine)、農学(Agriculture)などの分類があります。
工学の分類
工学には様々な分類がありますが、以下はその代表的な一部です。
- 建築工学
- 機械工学
- システム工学
- 情報工学
- 電子工学
- 鉄道工学
- コンピュータ工学
工学の共通点
工学の共通点としては、以下のような作業を共有していることです。
- モデリング
なにが問題で，どんなものを作るべきかを明確にするため、対象領域を分析して，モデル化する技術が重要です - 仕様
工学はきちんとした仕様を明確しなければなりません - 成果物
工学はなんらかの成果物を作成しています - 設計
工学の核は設計技術です。 - 検証
成果物が仕様に満たしているかどうかを検証しなければなりません
ソフトウェア工学
ソフトウェア工学(Software Engineering)とは、ソフトウェア開発を研究対象とする工学で、ソフトウェアを効率的に設計、開発するための手法に関する学問、もしくはそのための技術のことをいいます。
情報システムとは
ソフトウェア業界の仕事は、情報システム開発が大半を占めているため、ここで情報システムのことを特別に取り上げて説明します。
情報システム(Information System)とは、情報を適切に保存・管理・流通するための仕組みやシステムのことです。言葉の意味からすれば、コンピュータを使わなければならないことはないですが、現代ではほとんどの場合、情報システムは「コンピュータ情報システム」の略として用いられています。
情報システムは、ハードウェア、ネットワーク、ソフトウェアを組み合わせて構成されたシステムであるため、ソフトウェアを含めているイメージですが、情報システム構築時は、構成要素のハードウェアは調達するものであり、開発する必要なのはソフトウェア部分のみですので、情報システムの開発=情報システムにおけるソフトウェアシステム開発として、ソフトウェア工学の最も重要な一大分野になっております。
ソフトウェアのライフサイクル
全てのソフトウェアにはライフサイクルがあります。
ほとんどの場合、ソフトウェアは、「企画」→「開発」→「運用」→「廃棄」からなるライフサイクルをたどると考えれ、ソフトウェア工学の研究対象は主にそのなかの「開発」になります。 ソフトウェアにはリニュアルやバージョンアップがよくあるものですが、ライフサイクルからみれば、新旧バージョンを別々のソフトウェアととらえることができます。
ソフトウェアの品質
ソフトウェアの品質特性は大きく６つに分類され、それぞれの英語の頭文字をとってFRUEMP特性とも呼ばれています。- 機能性
必要な機能を満たしているかということです。 - 信頼性
指定された条件の下で正しく動くかということです。 - 使用性
使いやすさを表します。 - 効率性
スピードとサイズに関する性能です。 - 保守性
修正のしやすさです。 - 移植性
実行する環境の移行のしやすさを表します。
プロジェクト管理
ソフトウェアプロジェクト管理 (Software Project Management) は、ソフトウェアプロジェクトを計画し導く技術です。
プロジェクト管理の一分野として、ソフトウェアを開発するための組織、チーム、個人のあり方、つまり人間の問題を取り扱うため、「もの」が取り扱う対象のソフトウェア工学の分野には分類されません。
スコープ（scope）とは日本語にすると“有効範囲”を表します。つまり、変数のスコープは変数が使える有効範囲のことを指します。
スコープの分類
スコープは、主に以下のように分類することができます。
- グローバル・スコープ (global scope)
- ファイル・スコープ (file scope)
- ローカル・スコープ (local scope)
- 静的なローカル・スコープ (static local scope)
- インスタンス・スコープ (instance scope)
- クラス・スコープ (class scope)
- クロージャ・スコープ (ｃlosurel scope)
- スレッドローカル・スコープ (threadlocal scope)
グローバル・スコープ
グローバル(global)は、日本語にすると”大域”を表し、グローバル・スコープ(global scope)は、プログラムの「全体」から見えるスコープのことです。このスコープに属する変数はグローバル変数といわれます。BASICのような単純な言語ではグローバル・スコープしか存在しない場合があります。Pythonのようなグローバル変数の書き換えが簡単には行えない言語も存在する。
ファイル・フスコープ
ファイル・フスコープ(file scope)は、グローバル・スコープと似ていますが、プログラムを記述したファイルの内側でのみ参照できるスコープです。プログラムが複数のファイルから構成される場合は他のファイルから参照することはできません。
ローカル・スコープ
ローカル(local)は、日本語にすると”大域”を表し、ローカル・スコープ(local scope)は、ある関数やブロックの範囲内に限定されたスコープのことです。
何を持って範囲を与えるかは言語により様々だが、一般に入れ子のローカル・スコープは外側を参照できるのが普通です。このとき兄弟関係にあるスコープは見えない。変数宣言が必要な言語の場合は宣言文以降にスコープが制限される場合が多い。
- 関数の先頭で纏めて宣言しなければならない
例：Pascal、Delphi - 関数のどこでも宣言でき、関数全体で有効
例:Javascript - 関数のどこでも宣言でき、宣言以降の関数全体で有効
例：ABAP - 関数のどこでも宣言でき、宣言のブロックの中にのみ有効
例：C、C++
インスタンス・スコープ
インスタンス・スコープ (instance scope)は、クラスベースのオブジェクト指向言語で、各インスタンス毎に割り当てられた変数が所属メソッド(メンバ関数)からのみ参照されるスコープのことです。いわゆるカプセル化はこれを指します。。保護されない変数の場合は、クラス定義が見えていてオブジェクトにアクセスできる場合は直接参照できます。C言語の構造体参照なども一種のインスタンススコープです。
クラス・スコープ
クラス・スコープ (class scope)は、 クラスベースのオブジェクトト指向言語で、あるクラスの定義全体から参照できるスコープのことです。インスタンス・スコープと異なり変数が共有されますので、ある種の制限されたグローバル・スコープと考えることができます。クラス・スコープをもたない言語の場合でも、ファイル・スコープを用いることで同様の機構を実現できる場合があります。
クロージャ・スコープ
クロージャ・スコープ (closurel scope)
スレッドローカル・スコープ
スレッドローカル・スコープ(threadlocal scope)は、同じスレッドしか参照できないスコープのことです。マルチスレッド・プログラミングではよく使われます。
各言語の実装
以下の表で各主流言語のスコープ実装状況を示します。
| 言語 | グローバル・スコープ | ファイル・スコープ | ローカル・スコープ | 静的なローカル・スコープ | インスタンス・スコープ | クラス・スコープ | クロージャ・スコープ | スレッドローカル・スコープ |
|---|---|---|---|---|---|---|---|---|
| ABAP | ○ | × | ○ | × | ○ | ○ | × | × |
| Basic | ○ | × | × | × | × | × | × | × |
| C | ○ | ○ | ○ | ○ | × | × | × | ○ |
| Cobal | ○ | × | × | × | × | × | × | × |
| C++ | ○ | ○ | ○ | ○ | ○ | ○ | × | ○ |
| C# | × | × | ○ | × | ○ | ○ | × | ○ |
| Delphi | ○ | × | ○ | × | ○ | ○ | × | ○ |
| Fortran | ○ | × | ○ | ○ | × | × | × | × |
| Java | × | × | ○ | × | ○ | ○ | × | ○ |
| JavaScript | ○ | × | ○ | × | × | × | × | × |
| Pascal | ○ | × | ○ | × | × | × | × | ○ |
| Perl | ○ | × | ○ | × | ○ | ○ | × | ○ |
| PHP | ○ | × | ○ | × | ○ | ○ | × | × |
| Python | ○ | × | ○ | × | ○ | ○ | ○ | ○ |
| Ruby | ○ | × | ○ | × | ○ | ○ | ○ | ○ |
| VB | ○ | × | × | × | × | × | × | × |
| VB.net | ○ | × | × | × | × | × | × | ○ |
| VC++ | ○ | × | × | × | × | × | × | ○ |
| VC++.net | ○ | × | × | × | × | × | × | ○ |