コンピュータ技術者のための無料情報倉庫です

ソフトウェア設計者向け情報

7.クラス解説
・・・ユースケースと同時に作成を開始するダイアグラム・・・

　クラス図は、システムの設計作業の開始とほぼ同時に作成を開始します。 その後の工程を通じて、徐々に詳細化されていき、最終的にはシステムの詳細を明示するダイアグラムなのです。 （著者の経験では、ほとんどの開発作業で利用されています。）
　古くは、著者がコンピュータについて勉強を始めた40年以上前から存在しており、メーカーや開発業者ごとに名称や表示方法が異なっていました。 UMLの誕生で書式が統一されたのは、全てのコンピュータ技術者にとって大変喜ばしいことでした。

7-1.二種類のクラス図

　UML以降のクラス図は、システム構造の静的配置を求めるクラス図、および、各クラスの動的関連を重視するロバストネス図の2種類に大別されます。 この2種類の表現方法は、静的配置と動的関連という全く異なるアプローチですが、ユーザに対して説明する内容は全く同じである（UML上では表示方法の差異と定義）と理解してください。 静的配置を模索する「概要クラス図」は、システム動作の概要を検索する「概要ユースケース図」と同時に進行します。 相互に「インプット情報」となり、更新されていくのが一般的です。 （業務の内容に詳細な知識を持つメンバーがそろえば、先に、概要クラス図を作成してから、クラスごとにユースケースを調べていくような開発パターンも有望です。）
これに対し、「バストネス図」はユースケースに対しての正当性検証の傾向が強く、一部の例外を除いて、ユースケースのブラッシュアップ時に作成されていきます。 （別項目として解説します。）

【著者注】
　クラス図とロバストネス図では使用される場面が異なる可能性が大きいと考えています。 ロバストネス図の作成から設計に入る場合もありましたが、 対象の業務知識があるシステム設計経験の豊富なメンバーで開始する場合に限られると想定しています。 　また、クラス図を抽象クラスとインスタンス（実現クラス）で示すものを「オブジェクト図」、 クラスをその集まりで表現する場合は「パッケージ図」という呼称を使用する場合があります。

7-2.概要クラス図

　概要クラス図とは、システムを構成する「機器」「情報」および「行為：人格的有意的な働き。 目的と動機が明らかで、手段その他についての思慮・選択を経て決意された自覚的な活動」を表現するものです。 設計者にとって有益なのは、システム全体を表現する概要クラス図を作成することによって、 ユーザとの間でシステムの構成について、「もの」と「こと」の「共通なイメージ」を創出するこが可能であることです。 したがって、多くのシステム開発で、概要UCの抽出において、概要クラス図の作成が「同時に実施する作業」となります。 ちなみに、UML以前でも、「静的概観図」や「システム鳥瞰図」などの名称で概要クラス図と同質の資料が作成されていました。 （メーカーやベンダー、あるいはユーザ単位で記述ルールが異なるという問題はありました。） 概要クラス図を作成する作業の目的は、旧来より、ユーザに開示して「システムの概要」を説明可能にすることであるのです。 概要クラス図は、計画段階（基本計画書やシステム仕様書）の作成段階では、ユーザとのコミュニケーションを図る、システムの構造を検討するうえで最も重要なドキュメントになります。 概要UCがシステムの作業を記述するのと同様に重要な項目なのです。 さらに、当然の帰結ですが、この2項目は、概要設計以降の作業における開発で、必要な「既存情報」となります。

7-3.概要クラスの抽出手順

　概要UCから必要な情報を抽出し3種類のクラスを導き出します。 業務に精通している技術者が設計する場合は、概要ユースケース作成は省略して概要クラス図を作成する場合もあります。 しかし、著者の経験では、概要UCからのクラス抽出が、より効率的で過誤が少ないようです。
1.バウンダリーの抽出
　ユースケースにおけるアクター（ユーザや他のシステム）が、対象システムと交信するためのクラスが必要です。 具体的には、対人用の入力画面や、システム間を接続する通信機構などがバウンダリーとして抽出されていきます。
2.コントロールの抽出
　バウンダリーから情報を受けて処理を実行する、すなわちユースケースを実現するためのクラスが必要です。 具体的には、システムの処理を記述するクラスがコントロールとして抽出されていきます。
3.エンティティの抽出
　バウンダリーを通過する情報とコントロールの処理結果の情報を保管するためのクラスが必要です。 具体的には、システムで使用する情報を蓄積するクラスがエンティティとして抽出されていきます。

7-4.目安としての粒度（リュードと読みます。鉱物学からの転用）

　設計作業で、最も困難な作業は、ユースケース、クラス抽出の「粒度」の統一かもしれません。 粒度は鉱物を粉末にしたときの粒の大きさですが、システム開発者は「記述の大きさ」の基準としてこの言葉を借用しています。 粒度の基準は、厳密に定義する方法がありません。 しかしながら、その目的は、簡単に定義することが可能です。
�@　概要設計においては、システムの持つ機能に合わせて設計項目を記述する。
�A　詳細設計においては、プログラムの果たすべき役割に合わせて設計項目を記述する。
設計時の粒度の均一化は、設計者が複数であれば必ず問題になります。 均一化は簡単そうで難しいものです。粒度の考え方については、次項にて紹介いたします。

付記：オブジェクト指向の導入とシステムの開発費用について
オブジェクト指向開発が主流になって、システムの開発費用が大幅に減少しています。 （すなわち、オブジェクト指向の目標が達成されています。） 著者は、この20年ほどの間に大規模な「財務システム」の設計に2度参加しています。 20年ほど前には700億円規模であったのが、最近では100億円をはるかにしたまわっていました。 開発規模や要求仕様が異なるので単純な比較はできませんが、原因は二つ明白にあげることが可能であると感じています。 第一は、機器やOSの進歩で、必要なインフラ分野のコストが半分以下になったと考えられます。 （あるいは、三分の一以下かもしれません。）
第二は、ツールの発展とクラスの継承理論によって、プログラムの製造量が減少したことがあげられます。 ほとんどの開発現場では、プログラマーは「機械語」の内容に考慮する必要がなくなっています。 クラス継承による作業の合理化とともにシステム開発業界にとっては好ましい結果と思います （・・・設計者の技術力育成の面では？ですが。） クラス分析が関与していますが、クラス分析の詳細は、後に記述します。

クラス概要-以上

お問い合わせについて

▲ページトップに戻る