リポジトリリポジトリ(Repository)リポジトリ(Repository)は1980年代にCASEツールを統合するために登場しました。リポジトリ登場の背景からその現在まで、ソフトウェアエンジニアリングの歴史を振り返りながら、リポジトリを解説します。関連製品(WEBアプリケーション開発ツール)高品質・高機能なWEBアプリケーションを高速開発。生産性は、COBOLの約3倍、Javaフレームワークの5~10倍を実現。対象は、情報共有ツールから業務システムまで多岐にわたる。表す言葉で、一般用語としては、さまざまなデータ、情報、知識や成果物を蓄積するデータベースやアーカイブを指します。世の中には○○リポジトリ、××リポジトリといった分野別の大規模知識データベースやソフトウェアアーカイブが存在します。Subversion)、GitHubのようなバージョン管理機能を持つソースコード管理システムなどが有名です。ソフトウェアエンジニアリングの世界では、リポジトリは情報システムの開発工程にかかわる情報、さらには開発工程だけでなく、プロジェクト計画、プロジェクト管理、保守、運用などソフトウェアのライフサイクル全般にわたる情報を定義、蓄積し、管理するための機能やメカニズムを指します。Dictionary)を統合するものとして登場しました。これをCASEリポジトリといいます。その後、リポジトリの概念は企業全体、ソフトウェア・ライフサイクル全体に拡張されていきました。ページの先頭へリポジトリ(Repository)の歴史的背景リポジトリは1980年代後半、それまでの構造化手法、インフォメーション・エンジニアリング(データ中心アプローチ)、データディクショナリ、CASEツールというソフトウェアエンジニアリング技術の進展の中で登場しました。そこで、リポジトリを理解するために、1960年代後半から1990年代初めまでのソフトウェアエンジニアリング事情を振り返ってみましょう。Engineering」という同名の国際会議が開催されてからと言われています。同会議はNATOの科学委員会が主催し11カ国が参加しました。当時世界では、1964年にリリースされたIBMの最初の汎用コンピュータSystem/360上で大規模なシステム開発が始まっていました。複雑化するシステム開発に対し、システムの信頼性を確保しつつ納期通りにリリースすることが困難になり、軍事的にも大きな問題となっていたのです。同会議ではこれを「ソフトウェア危機」と呼びました。構造化手法の広まり1970年代には「構造化手法」が花開きます。構造化手法とは開発技術者個人の知識と技量への依存を極力排除し、開発チーム全体で理解して実行できる工学的な方法論に則って開発を行おうというものです。A.Dijkstra)による「GOTOステートメントは有害だ」という議論から始まりました。GOTOステートメントの使用密度が高いほどプログラムの品質が低下するというのです。3つの組み合わせだけでプログラムを構築することが推奨されます。「構造化定理」はこの3つの制御だけでいかなるフローチャートも表現できることを数学的に証明しました。Myers)により、アプリケーション機能を階層的に配置された独立性が高く理解しやすいモジュールに細分化していく構造化設計が完成します。大きなプログラムをシンプルな構造の小さなモジュールに分割して構築することで、見通しをよくして開発やテストを簡単にしようというのです。Diagram)、さらに状態遷移図などにより上流工程の構造化分析まで広がりました。それまで、プログラマやSE個人の職人芸だったソフトウェア開発を、論理的、工学的なものに変えようというこの試みは世界中広く普及しました。ところが、構造化手法にも弱点がありました。構造化手法はアプリケーション単位に、1出力データ、2入力データ、3処理の順に注目します。1目的とする画面、帳票、ファイル出力を実現するためには、2どのような入力データが必要で、3どのように処理するのが最も効率がいいかという観点で最適化します。このようにしていくと、アプリケーション毎に最適化されたデータベースが次々に構築され、アプリケーション間でデータの重複が発生します。製品名や価格などがあちらこちらの場所に違う名称、場合によっては違う桁数でコピーされるのです。システム保守に伴う機能追加の中でコピーは繰り返され、中には使われなくなるものも多く発生しました。データが重複すれば、その整合性を維持確認するプログラムも余計に必要になります。データとプログラムは増え続け、システム保守にかかる工数が膨れ上がっていったのです。Chen)のE-Rモデルに関する論文が発表されました。Base)が市場に出てきました。Approach)が広まりました。Engineering)といいます。Martin)が体系にまとめました。インフォメーション・エンジニアリングでは企業戦略に基づき、ビジネス分析、システム設計、システム構築というようにトップダウンでデータやプロセスを捕捉していきます。その中でデータモデリングも提案されています。日本のデータ中心アプローチの手法としては1975年に椿正明氏がTH法を発表したのが始まりです。その後、佐藤正美氏がT字形ER手法(現在のTM)、渡辺幸三氏が三要素分析法など独自の手法を発表しました。それぞれ手法は違いますが、データベースを個々のアプリケーションとは独立させ、体系化していく点では共通しています。Dictionary)を搭載したデータベース製品が登場するようになりました。データディクショナリはデータベースのスキーマやデータ項目を一元管理する機能です。データディクショナリは製品毎に仕様が異なっていたため、企業レベルでデータ項目を一元管理できません。System)を発表しました。Architecture)などにつながっていきます。Engineering)ツールが登場します。各工程をひとつのプラットフォーム上で一貫してコンピュータで支援することにより、情報の一貫性を保ち、データの二重入力をなくし、製造の自動化につなげようとするものです。CASEツールは当初GUIを駆使してさまざまなダイアグラムを作成するツール、プログラムを自動生成するツールなど、個別の開発支援ツールでした。それがCASEの思想に基づいて統合されていったのです。CASE)は統合されませんでした。上流と下流でCASEツールが別々に分かれていたため、開発に関する情報伝達も分断されていました。そこで、ソフトウェア・ライフサイクルの全工程を支援できる統合CASEツールを実現するために、既存のCASEツールを統合することが考えられました。この時、CASEツールを統合するための最も重要なピースがリポジトリだったのです。1989年IBM社は多くのCASEツールを統合する統合CASEツールとしてAD/Cycleを発表しました。AD/Cycleの中でリポジトリはCASEツールを統合する中心的な役割を担っていました。IBMのリポジトリは独自仕様でDB2上に保持され、DB2のデータディクショナリも統合しました。DB2で稼働するリポジトリにより、各社とアライアンスを結びAD/Cycleを広めていきます。Dictionary/Repository)というリポジトリを発表、こちらはオープンアーキテクチャーでデータディクショナリ部分はANSI/IRDSに準拠した内容でIBMに対抗しました。CASEツールは1990年代初めにピークを迎えますが、その後、クライアントサーバシステムの台頭によりメインフレーム上で稼働するAD/Cycleや大規模なCASEツールは衰退し、それに伴いCASEリポジトリも姿を消していきました。Control)、すなわち成果物の構成管理、バージョン管理ツールにその後姿を変えてRational製品群に投入されていきました。ページの先頭へリポジトリの構成リポジトリに保持される情報リポジトリ(CASEリポジトリ)は各種CASEツールを統合し、ソフトウェア・ライフサイクルで必要な多岐に渡る情報を保持し整合性を維持します。CASEツールのソフトウェア・ライフサイクルは大きく4つに分かれています。保守段階リポジトリはソフトウェア・ライフサイクルの各工程で作成されるデータモデルやプロセスモデルの構成要素を保持し、整合性を維持します。計画段階では、トップダウン手法により企業モデルを作成し、そこからビジネスプロセスとビジネスデータを捕捉しダイアグラム形式で登録します。分析・設計段階では計画段階で捕捉したデータとプロセスをさらに階層的に細分化していきます。業務分析やプロトタイピング手法によるボトムアップ手法により現場レベルのデータとプロセスも捕捉していきます。これらを突き合わせて全体のプロセスモデルとデータモデルを作成します。製造段階ではデータベースを物理実装し、プログラムソースコードの自動生成機能を活用してプログラム開発を進めます。保守段階では機能追加・変更に伴い、上記の情報に追加・変更を加えていきます。リポジトリはこの各工程における情報の構成要素に加えて、それら構成要素間の関連を保持しています。組織モデルにおける組織の階層構造やプロセスモデルにおけるDFDや機能階層図の関係線など、さまざまなダイアグラムの構成要素間の関連も保持しているのです。することによって、リポジトリ内の情報の一貫性、完全性を保証しているのです。上記の変更・追加リポジトリの定義(リポジトリ・メタモデル)リポジトリはソフトウェア・ライフサイクルにおける情報の構成要素や構成要素間の関連を保持し、複数のCASEツールやデータディクショナリを統合しますが、それらの情報は、例えば上流のCASEツールと下流のCASEツールが同じ情報を理解できるように再構成可能でなければなりません。リポジトリはさまざまなダイアグラムを保持しますが、図をビットマップ等のイメージとして保持するのではなく、そのダイアグラムに含まれるオブジェクトやオブジェクト間の関連として保持します。ダイアグラムの意味を保持するのです。することによって、さまざまなCASEツールに対しそのツールが理解できるビューを提供します。このリポジトリに保持される構成要素や関連の保持形態を定義しているのがリポジトリ・メタモデルです。ところで、メタモデルとは何でしょうか。データモデルを例にしてみましょう。32(歳)」というのはデータです。属性名をメタデータと言います。「メタ」というのは、ある情報を1段抽象化した情報を指します。メタデータを集めて構造化したものをデータモデルと呼んでいますが、エンティティの構成やエンティティ間のリレーションシップ表現方法など、データモデルの形式を表す情報をメタモデルと呼びます。リポジトリはさまざまなメタデータを集めたメタデータベースとも言われます。それを定義しているのがリポジトリ・メタモデルです。多くのリポジトリ・メタモデルはE-Rモデルで記述されています。中にはオブジェクト指向モデルを併用しているものもあります。E-Rモデルとは情報をエンティティとその関連を表すリレーションシップで記述していく方法です。データモデルのER図もE-Rモデルのひとつです。組織モデルにおいて、組織の部署間の関係や、部署と従業員の関係はエンティティとリレーションシップで表現されます。プログラムとサブプログラムの関係、プロセスのプロセス間の関係もエンティティとリレーションシップで表されます。エンティティやリレーションにはさまざまな種類がありそれを「タイプ」といいます。このように、E-Rモデルは応用範囲の広いモデリング手法です。E-Rモデルはさまざまなモデル記述に活用され、その格納先としてリレーショナルデータベースが採用されていたため、多くのリポジトリ・メタモデルはE-Rモデルで記述されていました。本来、CASEツールではソフトウェア・ライフサイクルの上流で入力した情報を下流で再入力することなしに利用することが可能です。あった場合でも、全体の整合性が保たれるようになっています。ところが、多くのCASEツールは上流CASEツールと下流CASEツールに分断され、場合によってはベンダーも異なっていました。保守工程を専門に扱うCASEツール、リエンジニアリングを専門行うCASEツールなどさまざまなCASEツールが存在していました。これらのCASEツールを統合するための中核的な機能がリポジトリです。リポジトリには、複数のCASEツール間で情報を橋渡しするとともに、全体整合性を保つ機能が求められます。従って、リポジトリにおいては、登録データの完全性を保つ検査機能が非常に重要です。検査機能では、大きく3つの観点から情報を検査します。1メタモデルの定義やルールに合致しているか、すなわち、エンティティやオブジェクトのタイプや属性がルールに則しているか、リレーションシップのタイプやカーディナリティ(1対1、1対多、多対多)がルールに則しているかをチェックします。次に、2個別のダイアグラムのその記述ルール、例えばDFDならその記述ルールに合致しているかをチェックします。最後に3ダイアグラム間や工程間で情報の一貫性が保たれているかをチェックします。構成管理機能では主にバージョン管理と変更管理を行います。バージョン管理はリポジトリ内の複数の構成要素のセット、すなわち複数のソフトウェアバージョンを保持し管理する機能です。これにより複数バージョンの開発を同時並行で進めることが可能になります。変更履歴を記録します。変更履歴には監査で利用できるように操作者や操作時間などの情報も同時に記録されます。その変更が及ぼす影響範囲を示し、必要な更新に漏れがあれば警告し、場合によっては自動更新します。画面やデータ項目が削除された場合に、関連ずる情報の画面やデータ項目を削除する等です。構成管理機能は任意のバージョンを整合性のとれた状態で再現することを可能にします。リポジトリが持つ主な情報管理機能を下記にまとめます。E-Rモデルでメタモデルを定義し保存する機能。必要に応じてE-Rモデルで表示する機能。メタモデルを拡張する機能。製品によってはオブジェクト指向でのメタモデル拡張機能を持つ。各CASEツール、リエンジニアリングツール等がリポジトリにアクセスするためのインターフェース(ビュー)の提供。現在、ITの世界でリポジトリと言えば、CVS、SVN、GitHub等のソースコードのバージョン管理システムやオープンソースソフトウェアのアーカイブを思い浮かべる人が多いでしょう。ように、リポジトリを頂点に企業のさまざまな情報を統合し、ソフトウェア開発、保守・運用を支援するという流れは下火になりました。Planning)に引き継がれていきました。A.Zachman)が1987年に発表したザックマンFrameworkに始まり、その後改良を経て1990年頃から普及が始まりました。EAは1ビジネス、2データ、3アプリケーション、4テクノロジーの4つの観点で企業の情報システム全体を可視化し最適化しようとするものです。リポジトリよりも広い範囲を対象にしています。Reengineering)が流行した1990年頃から急速に普及しました。ERPは経理システム、人事システム、生産管理システム、販売管理システムなど企業のほとんどの基幹システムを統合されたひとつのアーキテクチャーで実現します。EAを実現する手っ取り早い方法です。/ローコード開発のような分野で、リポジトリからプログラムの自動生成を行うようなツールが数多く存在します。IT技術者が不足する中、デジタルトランスフォーメーションで増大するソフトウェア開発要求に対応するために、短期間でソフトウェアをリリースできる手段が従来に増して求められているのです。関連記事データモデリング佐藤正美氏、若手エンジニアにデータモデリングを語る!https://www.sei-info.co.jp/it-keyword/data_modeling.htmlローコードプラットフォームローコードプラットフォームとは?https://www.sei-info.co.jp/it-keyword/lowcode-platform.htmlローコード開発ローコード開発ツール「楽々Framework3」とは?https://www.sei-info.co.jp/framework/reason/low-code-development-tools.html基幹システム基幹システムとERPhttps://www.sei-info.co.jp/it-keyword/enterprise-system.htmlページの先頭へ関連製品(WEBアプリケーション開発ツール)高品質・高機能なWEBアプリケーションを高速開発。生産性は、COBOLの約3倍、Javaフレームワークの5~10倍を実現。対象は、情報共有ツールから業務システムまで多岐にわたる。