DOA+とは 研究報告書 記事 コンソーシアムの目的 会　則 組　織 活動案内 入会のご案内 お問合せ 個人情報保護 第１分科会 第２分科会 第３分科会 会員情報の確認と変更 今後の課題（前提の検討）   2003年12月12日 株式会社エス・ディー・アイ　佐藤　正美 　1970年代・1980年代・1990年代は、それぞれ、特徴あるＩＴソリューションを提示してきた時代でした （1970年代には構造化手法、1980年代にはＲＤＢ、1990年代にはウェッブが提示されました）。2000年代も、はや、半ばを迎えようとして、ＲＤＢとウェッブとの接続が論点になっています。2000年代が、振り返ってみて、「ＩＴ空白の時代」にならないように、ＲＤＢとウェッブを接続するソリューションの提示ができるコンソーシアムでありたい、と思っております。 　そのために、まず、コンソーシアムのなかで検討すべき、「今後の課題」として、データベースに関与するシステム構築の前提を検討してみます。 　以下に、プレゼンテーションのなかで言及した中味をまとめました。 [ プレゼンテーションの趣旨 ] まず、システム構築方法の変遷を、1970年代から10年単位に鳥瞰して、それぞれの時代が遺した問題点を提示する。 （１）1970年代には、（狭義の）ソフトウェア・エンジニアリングが整えられた。 　　（狭義の）ソフトウェア・エンジニアリングは、以下の３点を特徴とする。 　　　�@ システム構築過程を「waterfall」モデルとして考え、SDLC は、以下の４つの 　　　　工程に区切って管理する。この考えは、プロジェクト管理にも適用されている。 　　　　- 分析工程 　　　　- 設計工程 　　　　- 製造工程 　　　　- 保守工程 　　　�A それぞれの工程では、「構造化手法」が使われた。構造化手法として、 　　　　Yourdon 法、DeMarco 法、Jackson 法、Warnier 法などが提示された。 　　　�B SDLC は、例えば、経理システム開発プロジェクト、生産管理システム開発 　　　　プロジェクトなどのように、アプリケーション単位に導入された。 　　なお、1970年代（および1980年）には、以下の論文あるいは言語が提示されていた。 　　　　- セット・アット・ア・タイム法（RDB） 　　　　- ER(Entity-Relationship)モデル 　　　　- OO(Object-Oriented)言語 [ SIMULA67, SmallTalk-80 ] （２）1970年代が遺した大きな問題点として、以下の３点を指摘できる。 　　　�@ 低い生産性 （人手不足）-- ISAM・VSAM・HDB(chained)・NDB・3GL。 　　　　[ 物理的な構造を知らなければプログラムを作成できない。] 　　　　[ データベース設計は、アプリケーション・データベースであった。] 　　　�A データの重複 　　　　[ 70％のデータ重複、20倍のデータ名重複、90％の無駄プログラム] 　　　�B 多大な投資と低いメンテナンス性 　　　　[ ＩＴ投資の80％がメンテナンスとして費消されていた。] （３）1980年代には、インフォメーション・エンジニアリングが導入された。 　　インフォメーション・エンジニアリングは、以下の３点を特徴とする。 　　　�@ ＩＲＭの導入（DD/DS） 　　　�A SDLC のなかに、ビジネス・モデル（Enterprise Business Model）が導入された。 　　　�B ＲＤＢの導入（データ正規形、サブジェクト・データベース） 　　データ重複の排除やメンテナンス性の向上には貢献した。 （４）生産性を改善するために、4GL やSDLC の自動化（CASE）が導入された。 （５）1980年代が遺した大きな問題点として、以下の３点を指摘できる。 　　　�@ SDLC の断層を解消できなかった。 　　　�A データ定義に多大な時間を費消して、生産性が改善できなかった。 　　　�B DD/DS を構築できなかった。 （６）1990年代には、C/S や PC/LAN が導入された。 　　　�@ C/S の延長線上に WWW が導入された。 　　　�A PC/LAN の延長線上に インターネットが導入された。 　　　　[ インターネットは、イントラネットにも流用された。] 　　　�B システム構築方法は、プロトタイプを前提にした　RAD が導入された。 　　　　[ RAD： Rapid Application Development ] 　　　�C Java が普及して、OO(Object-Oriented)が再考され、UML（1997）が提示された。 （７）1990年代が遺した大きな問題点として、以下の２点を指摘できる。 　　　�@ RDB と OOP との接続。 　　　�A 「再利用」を謳っているが、「再利用」を実現できていない。 　以上、時代の流れを鳥瞰したなかで、いまだ、ソリューションを提示できていない点を 以下に列挙する。 　　　�@ SDLC の断層 　　　�A RDB と OOP の融合 　そして、あいもかわらず、以下の目的が実現されていない、、、 　　　�@ 生産性向上（短納期化の対応） 　　　�A メンテナンス向上（波及分析） 　1980年代の調査数値として、以下が報告された。 　　　�@ データ・ストーレッジのなかの70％は重複データである。 　　　�A １つのデータに対して、（平均）20個の [べつべつな] 名称が付けられている。 　　　�B プログラムのソース・コードの 90％が無駄である。 　　　�C コンピュータ投資のなかで、80％がメンテナンス費用である。 　さて、調査後 20年の間に、これらの数値は、どの程度、改善されたのか。 次ぎに、SDLC が内包している問題点を提示する。 （１）SDLC の断層は、1980年代半ばに、CASE のなかで論点になった。 　　�@ I-CASE(Integrated CASE)は、SDLC をシームレスに接続した（例えば、IEF）。 　　�A C-CASE(Component CASE)は、それぞれの工程を自動化することを目的として、 　　　リポジトリを中継点にして、SDLC の接続を狙った（例えば、AD/Cycle、IRDS）。 （２）SDLC のなかに断層があるので、以下の問題点が起こっている。 　　�@ それぞれの工程のなかで使われている方法を接続する（翻訳する）のは、 　　　ＳＥの力量とされている [ 属人性を払拭できない ]。 　　�A ドキュメントが、それぞれの工程を遡及して同期的に更新されていない。 　　　例えば、プログラム仕様書と実際のソース・コードが一致していない。 　　�B エンジニアにとって唯一の真実は、実際に稼働しているオブジェクト・コードで 　　　ある。SDLC の断層があるかぎり、プログラムがシステム構築の中心点とされ、 　　　上流工程（分析・設計）は、下流工程に対して設計図として作用しない。 　　　したがって、DFD も DOA も OOA・OOD もプログラムに対して強制力はない。 　　　[ 設計図を無視して、プログラムを作成することができる。] （３）SDLC の断層があるかぎり、工程間のつなぎは、ＳＥの力量に委ねられている。 　　この断層を解消しないかぎり、システムの品質は、数人のＳＥの力量に委ねられて 　　しまい、揺らいでしまう。 （４）SDLC の断層を解消するには、以下の４つの やりかた がある。 　　�@ アプリケーション・パッケージを導入する。 　　�A Java 版の I-CASE を使う（I-CASE がSDLCの断層を解消したことは実証済み）。 　　�B DD/DS を使う。 　　�C C-CASE ではあるが、設計ツールと製造ツールが１つの方法論で接続されている。 （５）アプリケーション・パッケージ（例えば、ERPパッケージ）は、以下の点を 　　目的として導入される。 　　�@ 短納期化 　　�A 標準化（複数のノードが同じシステムを使うことができる） 　　　アプリケーション・パッケージは、「最大公約数的な」汎用性を実現しているので、 　　システム化したい「すべての」機能が搭載されている訳ではない。そのズレに対して、 　　DOA+ は、どのようなソリューションを提示できるのか、という点を検討したい。 （６）Java 版の I-CASE は、「DOA+OOP」の接続を実現することができるか。 （７）DD/DS は、（データ構造および）アルゴリズムに対して「active」になれるか。 　　もし、アルゴリズム（プログラム構成）に対して、「active」に作用することができる 　　なら（あるいは、数多くの「パターン」を用意することができるなら）、DD/DS は 　　ソース・コードを自動生成することができる。つまり、DD/DS がフレームワークと 　　して作用することができる。 （８）C-CASE であっても、設計ツールと製造ツールが、１つの同じ方法を前提にして、 　　接続されていれば、I-CASE と同じことになる。 次ぎに、業務分析が内包している問題点を提示する。 （１）ＳＥは、業務を完全に解析することが できるのだろうか。 　　すなわち、数十人のエンドユーザの仕事を、わずか、数ヶ月のあいだに、観察し面談 　　しながら「理解」して、仕事の手順 （手続き） を詳細に記述して、それを１つの 　　体系として まとめることができるのだろうか。ザッとした （おおまかな） 解析は、 　　解析に値しない。 （２）事業のなかで使われているデータの意味を一般化 （共有） するためには、それに 　　先立つ膨大な使用例 （事実） が前提となる。しかじかのデータが、かくかくの仕事 　　のなかで使われ、事業のなかで、しかじかの意味を付与されて伝達されている事態を 　　観察して、以下の２点を、いかにして実現するのか。 　　（１） 網羅性 （記述されている事態には漏れがない、ということ） 　　（２） 完全性 （記述されている体系が「正しい」ことを検証できる、ということ） 　　　網羅性は、作業日報を使って、エンドユーザの作業と労働時間を計量すれば、保証 　　できる。作業日報を使えば、網羅性を保証できる、ということは、業務分析は、ＳＥ 　　がやらなくてもよい、ということになる。 　　　業務分析は、例えば、外注のＳＥが、クライアントの事業を知らないので、事業の 　　おおまかな中味を知るために実施するＳＥの教養にすぎないのか。 （３）たとえば、１０人のＳＥが、それぞれ、ＤＦＤを使って、１つの（同じ）事業を 　　記述したとする。おそらく、１０通りのＤＦＤが作成される、そのなかのどれが 　　正しい記述なのか。 　　 （４）ＳＥが事業を理解しようがしまいが、事業は、実際に おこなわれているし、ＳＥ 　　が理解できた点のみ記述されても、「事業に役立つ」ことを目的としているシステム 　　は事業と懸け離れてしまう。 （５）「構造」というのは、「モノ」と「関係」から構成されるが、もし、事業のなかで 　　起こっている事態 [ 事業のなかで おこなわれている仕事 ] そのものを対象にした 　　ら、「モノ」として、どういう集合を形成すればよいのか、という初めの時点で、 　　躓いてしまう。 　　　だから、「私には、或るモノが見えるが、あなたには、それが見えない」という 　　不意打ちが起こってしまい、それぞれのＳＥが、それぞれの感想文を綴ることに 　　なってしまう。ＳＥが事業を理解しようがしまいが、事業は、実際に おこなわれて 　　いるし、事業は１人のＳＥの価値観では揺らがない。 （６）いずれにしても、「モノ」と「関係」を記述するには、事業のなかで起こっている 　　事態そのものを対象にすれば、収拾がつかない。 　　「事実」の記述として、どのような対象を選べば、網羅性と完全性を保証できるのか 　　という点について、DOA+ は、どのようなソリューションを提示できるのか。 最後に、データ設計が内包している問題点を提示する。 （１）セット・アット・ア・タイム法（Codd, E.F. 氏が提示した やりかた、端的に 　　RDB の「view」と思ってよい）には、以下の２つの弱点があった。 　　�@ 「関係（テーブル）」の順序対（並び）（*） 　　�A 属性値（tuple）のnull 値 　（*）ここでいうデータの「並び」とは、tuple の属性値の並びではなくて、TABLE と 　　　して生成される「関係（テーブル）」（主体？）の「並び」をいう。 　　　数理モデルは、関数を使ってデータを並べるが、事業のなかで使われるデータには、 　　並びが大切なデータ--例えば、（出荷、請求）という並びと、（請求、出荷）という 　　並びでは、「意味」がちがう--と、並びが論点にならないで「構成」が論点になる 　　データ--例えば、（部門、従業員）という並びと、（従業員、部門）という並びでは、 　　「意味」が同じ [ 配属という意味]--がある。 　　　数理モデルと意味論を、いかに融合するか、という点について、DOA+ は、どの 　　ようなソリューションを提示できるのか。 （２）データ構造は、「モノ（entity）」と「関係」から構成されるが、データ正規形は、 　　以下の諸点を保証していなければならない。 　　�@ データ集合を生成するための判断規準 　　�A 正しいデータ集合であるかどうかの検証基準 　　�B 関係を生成するための判断規準 　　�C 関係が網羅されているかどうかの検証基準 　　　DOA+ は、以上の諸点に関して、どのような方法を提示できるのか。 （３）業務分析と同じように、データ設計においても、以下の２点は保証されなければ 　　ならない。 　　�@ 網羅性（データの定義、validation-rule） 　　�A 検証可能性（完全性） 　　　完全性というのは、作図されたデータ構造のなかのデータ集合は、いくつかの 　　選ばれた公理（前提）から、「すべて」、導出される、ということである。 　　　したがって、「不意打ちがない」。 （４）事態は「事実」ではない。「事実」は１つの判断である。「事実」が１つの判断で 　　あるかぎり、事象を、どうのようにして形式化するか、という点は、エンジニアの 　　価値観に委ねられる。しかし、形式化された構造が、１人のエンジニアの価値観を 　　回避するためには、理論的な整合性がなければならない。理論的な整合性があれば、 　　ほかの人たちも、合意することができる。 　　　その意味のおいて、エンジニアは「理論」に精通していなければならない。 　　　なぜなら、我流を回避するために。 （５）データ構造がアルゴリズムに対して設計図として作用するのなら、以下の２点を 　　どのようにして保証するのか。 　　�@ null 値を回避する。 　　�A nested-IF を排除する（cyclomatic complexity の回避）。 （６）設計には、概念設計と物理設計がある。 　　�@ 概念設計の代表的手法には、ＥＲモデルと意味論データモデル（ＳＤＭ）がある。 　　　物理設計論としては、関係データベース・モデルがある。 　　�A ＥＲモデルは、以下の２つの概念を使う（Chen, P., 1976）。 　　　- 主体集合（主体型、entity） 　　　- 関連集合（関連型、relationship） 　　　[ 和集合・共通集合が記述できないし、属性値として主体がとれない。] 　　�B 意味論データモデルは、以下のような概念を使う。 　　　- 汎化（generalization）と特化（specification）[ is-a 関係 ] 　　　- 集約（aggregation）と分解（partitioning）[ part-of 関係 ] 　　　- 抽象化（abstraction）と具体化（instantiation）[ instance-of 関係 ] 　　�C 関係データベース・モデルは、以下の概念を使う（Codd, E.F., 1970）。 　　　- 集合（set） 　　　- 関係（relation） 　　　[ 主体は記号化されている、という前提に立っている。たとえば、「従業員」の 　　　　集合の代わりに、従業員番号の集合、「部門」の集合の代わりに部門コードの 　　　　集合というふうに考える。] （６）ERDから関係スキーマを生成するやりかたが使われてきた。 　　いっぽうでは、ERDの改善版やセット・アット・ア・タイム法の改善版も提示され 　　てきた（たとえば、TH法やＴ字形ＥＲ手法など）。 　　いずれにしても、データとアルゴリズムは切り離されていた。 　　いっぽうでは、内部状態をもつオブジェクト概念が提示され、メッセージを送れば、 　　オブジェクトが演算をする、というオブジェクト主導の手法がある。オブジェクトの 　　集まりをクラスという。 （７）事務系・基幹系のシステムがデータベースとして RDB を前提にしているなら、 　　データ集合はセット概念を使うことになる。 　　　いっぽう、RDB を使ったウェッブのシステム構築では、アルゴリズムはOOP を 　　前提にしている。したがって、アルゴリズムはクラス概念を使う。そのために、 　　クラス図を作成する。 　　　ＲＤＢを使ったウェッブのシステム構築を前提にすれば、主体（entity）概念と 　　セット概念とクラス概念が論点になる。entity 概念とセット概念（RDB）とクラス 　　概念（OOP）を、どのようにして接続すればよいのか、という点に関して、DOA+ は、 　　どのようなソリューションを提示できるのか。 　　�@ UML ＋ OOP 　　�A [ DOA と UML の相克 ] + OOP 　　�B DOA + OOP 　　　UML が事務系・基幹系のなかで有効かどうか、という点は、UML のエンジニア 　　たちが論点としているから、DOA+ では、（OOP を対象にして、）以下の２点が論点 　　になる。 　　�@ DOA+ とUML の融合はできるのか。 　　�A DOA+ は、直接に、OOP と接続できるのか。