ObjectSquare [1999 年 8 月号]

[トレーニングの現場から] 第3回 - OOAの視点について -


■ はじめに

「えーっと、これは顧客IDをデータベースに問い合わせにいって、注文の外部キーに顧客IDを入れて、、、ビューを作っておいたらいいな・・・ あ、そうか今は分析をやっているんだった。つい、データベース設計をやってしまっているぞ・・・」

「このデータの整合性チェックはどこのデータと整合性をとればいいでしょうねぇ。サーバーはどこにあるんですか?ロックの仕組みを考えないといけないから、クライアントマシンは本社限定ということにしておこうか・・・」

「リストボックスから種別を選択して、いやまてよ、ラジオボタンにしておこう。デフォルトは、何にしようか?、あ、そうか、ユーザーインターフェースの細かいことを考えるのは別の作業だったな。」

一体なんの話しだろう、と皆さんは思われたかもしれません。OOADトレーニングの最初の演習を始めてしばらくすると漏れ聞こえてくる声です。

■視点って何?

UMLでは、ビューや視点という言葉をよく使います。
視点とは一体何でしょうか。
例えば、エンドユーザの視点、分析者の視点、設計者の視点、実装者の視点、といった使い方をします。視点とは、システムを眺めるテーマを指します。

注意
リレーショナルデータベースでもビューという用語を使います。これはデータの見方あるいは切り口とての機能ですが、UMLで使用しているビューとは、システムを眺める切り口を指しています。

システムはシステムに関わる様々な立場の人の視点によって構築され、検証されなければなりません。

視点は、特定の活動に対するテーマを表します。

■何故視点が必要か?

システム構築には様々な技術要素が必要とされます。それら一つ一つに対処していくための視点が必要となります。システム作りは、様々な視点で照らし合わせて構築、検証されていきます。つまりテーマ毎に作業を分類し、そのテーマについての専門的活動が必要なのです。UML表記法を用いて様々な図を作成していきますが、それぞれの図には視点があるのです。

家を作ろうと思ったら設計図は1枚では足りません。構造を表す図はもちろんのこと、配管図、電気系統図、外観図など、様々な設計図が必要です。システムもこれと同じく様々な視点から眺められ、図として表現されなければなりません。そして、それぞれの図は専門的な視点から作成されるのです。

注意
視点を持つ専門家は、実際の人間を指しているとは限りません。システム開発において、重要な視点をチーム全体の中で誰かがきちんととらえておくようにすればいいのです。

システム構築作業ではテーマを設定し、そのテーマについて検討するという作業の積み重ねが必要なのです。視点を設定し活動を始めたら、その視点に注力します。

■OOA(オブジェクト指向分析:ObjectOrientedAnalysis)の視点は何をするのか?

OOAの視点が何をするのか?を考える前に、視点のセットには何があるか見てみますと、

が1回のイテレーション(開発サイクル)であげられている基本的な活動です。

注意
イテレーションは、システム開発の中で複数回繰り返される開発のサイクルを指しています。

要求定義から始まり徐々に抽象度の高い活動から具体的な活動へと移行していきます。抽象度の高い活動において全体的な整合性を十分確認するのです。

OOAの視点というのは、要求機能を理解することを目的としています。OOAの視点はお客様がどういったシステム仕様を期待しておられるかを見ます。具体的な活動としては、理解した内容をオブジェクト指向のモデルで表現することです。

システム開発者が理解しているシステム要件がお客様の要求と一致しているかどうかを、オブジェクト指向モデルによってお客様に検証していただくことです。OOAの活動は、エンドユーザ、ドメインの専門家、システム開発者が共通のボキャブラリを 築きシステムについての共通の理解に達することを目指しています。ですので、この段階にお客様とシステム開発者が共通の理解を持たないままに設計・実装に進んでいくと、結果は火を見るより明らかです。

仕様の理解を目的としている場面で、実装の話を持ち込むということは、ユーザを疎外することになり、お客様の要求仕様に対してシステム開発者が勝手な実装上の配慮を混在させる危険が あります。

システムが期待されることを理解する段階において、データベースのキー設計に注力する必要はありません。仕様を把握した後に、データベース戦略を考えるデータベースチームが取り組めばいいのです。

それぞれの視点でモデルをしっかりと作成・検証したあとで、モデルの調整作業を行っていきます。

OOAは、システムが要求されていることを押さえてモデルに表す活動です。

注意
データベースのことを考えてはいけないということではありません。注意しておかなければならないのは、視点に注意を保持するということです。

■トレーニングでは

要求定義、OOA、OOD(ObjectOrientedDesign=オブジェクト指向設計)に分けて実習します。

演習で扱う問題が限定された小さいものであることもあり、開発経験を積んでおられる方は、最初(要求定義やOOA)の演習で、「設計や実装についてはフェーズを分けて考えるのです」と 制限されると、隔靴掻痒の感を覚えられるようです。

■実際の開発では

作業をどの程度厳密に分けるかは、開発目的、内容、開発規模、開発チーム構成、企業風土などの要因を考慮してバランスを決定します。

「経験の豊かな開発者からなるしっかり結束したチームによって開発される探求的な色合いをもったアプリケーション」(*1 P91)の場合、作業を分割することは不適切な場合もあるでしょう。

それに対して、「何箇所かに分散した大所帯の開発チームによって開発される非常に複雑な プロジェクト」(*1 P91)で作業を大雑把にしておくと無秩序状態に陥り プロジェクトのリスクは極大化します。

とはいえ、システム開発において、作業を分割して1つ1つを検証しつつ進める 開発方式(管理された繰り返し開発)は、非常に有効であることが広く認められています。

■まとめ

トレーニングに来られるお客様が経験してこられているシステム開発、あるいは、これから取り組んでいかなければならないシステム開発は、様々なパターンが あると思われます。それぞれのパターンに応じた活動の仕方というものがあるでしょう。

トレーニングでは、視点を分ける意味や利点、他の視点との関係を理解していただき、意識的に演習を実践してみることをお勧めしております。視点を厳密に分けて活動をすることの特徴をトレーニングで理解していただき、実際の開発で適用するかどうかを考えていくことがいいのではないでしょうか。


次回は皆さんのモデル紹介その1です。

お楽しみに。


*1オブジェクトソリューション
Grady Booch著、アジソンウエスレイ
以上


© 1999 OGIS-RI Co., Ltd.
Prev Index Next
Prev. Index Next