無差別に技術をついばむ鳥

この記事はネタつつき21−アクセス指向分析（AOA）の続きです。念のために再度書いておきますが、これも知的遊戯であって実務的なものではありません。前置きは此れぐらいにして続きを書きます。
分析が終わったら次は設計です。設計段階ではオブジェクト指向設計と同じく、システム上での実現方法を考えます。ただしOMTなどと違って、アクセス指向設計はあくまでも技術的ジョークなので特別な図は使用しません。流石に新しい図まで考える事はしませんでした。ということで、アクセス指向設計ではOMTやUMLなどの既存の図を書きながら考えを纏めます。ここで実際の図をお見せしたいところですが、このブログには容量制限がありますので少々分かりにくくなるかもしれませんが文章で書きます。ごめんね。
今回も引き続き本屋の例を挙げつつ説明します。さて、インドリは何をしているでしょうか？早速観察してみましょう。

インドリはまだアクセス分析を続けていました。「えっと、顧客の販売動向を考えようと思ったら、天気オブジェクトが必要ピヨ。天気オブジェクトがあるって事は、季節オブジェクトもあって・・・」

あれ？分析が明後日の方向に行ってしまいました。アクセス指向分析の危険なところは、あまりにも無差別に考えるとオブジェクトを手繰り寄せる作業に終わりが無いことです。そういう時は冷静な人が突っ込みを入れるか、定期的にエンドユーザーに点検してもらいましょう。

ドリィちゃん「ちょっと待ってぇ！気象学はうちの店と関係ないでしょ！」
インドリ「はっ！そうだね♪じゃあ設計をするピヨ♪」
漸く設計を始めたインドリは、テスター体質のドリィちゃんの突っ込みを受けつつ、設計図を描き始めました。

それではアクセス指向設計のポイントを説明します。アクセス指向ではやはりアクセスを重視しし、何のオブジェクトが何からアクセスされるか考えます。ではインドリの観察に戻りましょう・・・

インドリ「ピヨッと・・・実際にシステムを作るとなると、本オブジェクト・売上オブジェクト・会社オブジェクトとかは永続的データにしたいのでDBMSが必要ピヨ♪」
ドリィちゃん「で？どのようにしてアクセスするの？」
インドリ「じゃあボクのマイPCで・・・」
ドリィちゃん「ちょっと待ちなさいぃ！会計係は私だし、鳥はうっかり者だから私がチェックできるように、クライアント・サーバー環境にしなさいぃ。」
インドリ「えぇー！という事は、データベースサーバを立てて、LANを通じてボクとドリィちゃんのPCからつなげるようにするピヨ。」
ドリィちゃん「お待ち！それじゃあ、足元がお留守よ！万が一スタッフが給与を改ざんしたらどうするの？」
インドリ「そんな奴雇った覚えないピヨ。でもそんな事言われたら気になるなぁ・・・万引きの件もあるし。じゃあ、ファイアーウォールとか機材を導入して、権限の検討をするピヨ♪」
ドリィちゃん「権限については私に任しなさい♪無欲な鳥は考えが甘いからね！物事はわるーく考えないとねぇぇぇ。」
インドリ「こわっ！鳥肌が立ったピヨ！あれ？ボクは鳥だからそれは何時もの事ピヨ。」


この様にして、どのようにアクセスするのか、誰がアクセスすのか、開発作業の担当者の三つを決めます。さらに、セキュリティについて考えるためにアクセスシナリオを考えます。この時重要なのは性悪説で考えるという点です。自分の仲間を疑うのは気持ちのいい行為ではありませんが、セキュリティはその様に考えないと意味が無い技術なので非常に重要です。
以上の作業が終わったら後は、各担当が適切な設計を行います。例えば、データベース部門ではE-R図を用いてデータの正規化などを行い、ネットワーク部門ではネットワークの設計を行います。でもこのままでは各部門の連携が取れませんので各部門のアクセス接点を予め決めておきます。そうする事により、専門家による作業効率のUPとチームワークによる作業孤立UPの両方を図れます。
全ての部門の作業が終わったら、全情報がアクセスできるのか図などでチェックします。この時どこからもアクセスできない情報がある場合は無駄情報だと思ってよいでしょう。以上で設計はおしまいです♪次はいよいよ実装段階です♪お楽しみに♪

トラックバックURL

FC2ブログユーザー専用トラックバックURLはこちら