モデリングコンテスト

オブジェクト倶楽部が開催しているモデリングコンテストに参加してみます。 でも、めんどくさくなって途中で投げ出すかもしれません。

2005/02/02

とりあえず、基本的なユースケース図を書いたので掲載します。

利用者側とは、業務システムを利用する人達のことです。営業が受注内容を入力するとか、開発が進捗を管理するとか、製造が在庫管理や出荷報告をする、などが一般的に考えられそうです。

運営者側とは、まさに業務システムを運営・保守する人達のことでしょう。人事異動をシステムに反映したり、開発案件を登録したり、新製品や部品の追加や製造中止などを反映する、などが考えられます。



2005/02/04

上のユースケースについて少々補足します。お題の「観点」では、「費用」が重視されています。業務システムを運営する上で、利用者側の費用(利用するための作業工数)は見えにくいのですが、非常に大きなファクターです。

一般的には利用者側の人数は非常に多く、利用する上で分かりにくいとか反応が遅いなどの理由で使いにくい要素があると、直接的に作業工数に跳ね返ってきます。一方、運営者側の作業工数は、その人達だけが消費します。

さて、今日は違う観点でのユースケースを書こうかと思いましたが、配置図を書くことにしました。上で書いたユースケースとは何の関連もありませんが、とりあえずお題から見えている範囲を分かりにくくならない程度で表現してみました。

お題の「観点」には、「費用」と「可用性」が求められているので、システムを構成するソフトウェア・ハードウェアをどうするのかは、注意する必要があります。3番目は調達のための作業なので、システム構成が決まれば自ずと決まってきます。

業務システムのクライアントには何種類もの記述がありますが、ひとつの見方としては社内インフラに接続するものと、社外インフラからルータなどを経由して業務システムに接続する2種類が考えられます。その観点で書いた配置図です。接続可能性を検討する場合には、この分類は重要です。

同様に、業務システムサーバ内部のコンポーネントを記述のとおりに分類しています。これらコンポーネントも、保守可能性や費用(運用費・保守費)を検討する場合に重要な判断材料です。

ユースケース図と配置図により、ヒトとモノに費用がかかることが見えてきました。



2005/02/07

今日はユースケースをもう少し分析してみます。こんなにのんびりしていたら、設計モデルまで行き着かないかもしれませんが、とりあえず気にしないことにします。

さて「お題」の観点を読み返してみます。

最初に挙げられた「機能に対する費用の管理」は、最終的には経営にかかわる人達のための観点と思われますが、一次的には情報をまとめるのは業務システム運営者のための観点といえます。 2番目の運用状況の確認と調達にかかわる作業の把握は、主に業務システム運営者のための観点です。

「お題」に書かれている観点からは、日常業務の支援を受ける人達のための要求はなく、業務システムを運営する側のための要求のみが挙げられていると言えるでしょう。

これを元に、ユースケースを書き直してみます。

なんだか大まかな機能要件が見えてきました。XPだったら、それぞれの機能要件をひとつのイテレーションに対応させて、プロジェクトを開始できそうに思えます。



2005/02/08

さて、再び配置図です。一般的な企業を考えてみます。既に開発向け業務システムと営業向け業務システム、総務向け業務システムが稼動していると仮定します。一般的には、これらの業務システムが一括して導入されることはありません。ここでは、すべてが全く別々のシステムとして稼動していたと仮定します。

その様子を配置図にすると、以下のように表現できるでしょう。

業務システムクライアントのノードは、ひとつだけで表現してあります(単なる手抜き)。

せっかく配置図を書いたので、簡単な分析モデルレベルのクラス図に落とし込んでみました。

システムの目的は、運用コストや運用状況、調達コストなどを知ることです。一方、開発・営業・総務などの既存の各業務システムは勝手に動作していると思われます。これらの既存業務システムに対して、これらの情報を取得するための共通のインタフェースを定義し、Adapter パターンを使用してやるとなんとなくうまくいきそうです。



2005/02/10

8日に書いたクラス図ではパッケージの命名や構成がいまいち良くない気がしたので、多少変更しました。(思考の過程が分かるよう、8日の分もそのまま残しておきます。)

まず、業務システムを対象としていますので、全体のパッケージは「業務システム」が適切だと思います。そこで、「業務システム」パッケージが全体を含む構成としました。業務システムパッケージが、各部門別業務システムパッケージを含むパッケージ構成にしています。サブパッケージにすることで、業務パッケージで作成した汎用的なクラス群を、それぞれのパッケージで自由に拡張できます。

また、8日のクラス図には「業務システム運用管理システム」などというややこしい名前のパッケージがありました。考えてみれば、このパッケージは業務システムの運用者向けの業務システムであると言えます。従って、「運用向け業務システム」と名称を変更し、これも業務システムパッケージのサブパッケージにしました。

あと、「集計」という責任が曖昧なクラスがありましたが、こんなクラスはきっと不要ですので削除しました。適切なコントローラクラスがその責務を負うことになるでしょう。運用コスト、調達コスト、運用状況の各クラスは、業務システムパッケージ内に作成しておくと、各サブパッケージで使えそうです。運用コスト、調達コスト、運用状況のクラスについては、そういう情報が取れるようにしておけばいいということにしておき、詳細は後で考えることにします。

業務システムを運用する側にとっては、なんらかのビューによって運用コスト・運用状況・調達コストを知りたいのでしょう。それらの値は、業務システム管理インタフェースを実装した、各部門別業務システム管理から取得し、運用者向けのビューを作るようにします。(運用向けコントローラパッケージと運用向けビューパッケージには、各種リクエストに対応した作られたコントローラクラスとビュークラスが含まれることになります。)

運用者向けに何らかの GUI(ビュー)が提供されることでしょう。運用向けコントローラが運用向けビューからのリクエストに応じて、新たなビューを作成して返すように動作するのが一般的です。リクエストを受けた運用向けコントローラは適切なビューを生成するために、業務システム管理インタフェースから必要な情報を取得します。

必要なな情報を取得するために、各部門別業務システム管理は次のように構造になっているとよさそうです。開発向け業務システム管理を例にします。

運用コストや調達コストは、発生するさまざまなコスト明細のコレクションクラスにします。コストのコレクションクラスやコスト明細は、外部からの変更を受けられないよう、Immutable にするべきでしょう。そうすることにより、コスト明細を外部に対して、安全に公開できます。コスト明細や運用状況の詳細がデータベースに格納されているのであれば、運用コスト、調達コスト、運用状況の各クラスは、データベースの Wrapper クラスとして振る舞うとよいのではないでしょうか。

あと、運用状況のモデル化を少し考えてみましたが、一般的なモデル化は難しいですね。

結局、最初のころにハードウェアだミドルウェアだインフラだとか配置図で分類しましたが、上のクラス図の中では調達コストや運用コストに含まれるコスト明細のひとつのインスタンスとして表現することになりました。

そうそう、コストを管理するには、予算と実績が大切でした。運用コスト、調達コストは、予算と実績に分けた方がよさそうです。それに伴って、業務システム管理が持つメソッドも、予算と実績を別々に取得できるようにすべきでしょうね。アップロードした後、見直していてそれを思い出したのですが、今日のところはめんどうなので図を更新しないでおきます。



2005/02/14

10日の図を書いた後で思ったのですが、コストを管理するとなると、会計のやり方にならわないとシステムとしてあまり意味がなさそうに思います。残念ながら会計の知識がないので、ちらっとぐぐってみました。すると、勘定科目というのと、その属性というのが重要らしいことが分かりました。つまり、コストの属性として、勘定科目と属性があった方がよさそうです。属性とは、資産・負債・収益・費用・資本の5区分があるようです。また、参照したページでは予算にはまったく触れられていませんでした。思いつきで追加しようとした予算に関する話はなかったことにします。

それらの新しい情報を取り入れて、クラス図を部分的に書き換えてみます。業務システム管理インタフェースを実装する部門別の業務システム管理クラスは、きっと部門に共通の部分があるでしょうから、抽象クラスをひとつ間に挟むようにします。

最初はコスト明細として命名していたクラスは、勘定科目に命名しなおしています。

残念ながら、ここまで更新したところで時間切れとなりました。まだまだ抽象的で実装から程遠いモデルですね。まあ、とりあえず参加することに意義があるってことで、ここで終わりにします。

ここまで読んでいただき、ありがとうございます。




HOME お勧め書籍 / Profile / リンク