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

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

8.粒度解説
・・・設計する対象の「大きさ」を揃える・・・

　オブジェクト指向開発からは、若干逸脱します。
　粒度は、元々鉱物学の用語で、粒の大きさの尺度です。 コンピュータ業界では、対象となる思考物の大きさの単位として借用しています。 概要設計までの粒度の考慮対象は、作業の起点となるユースケースやクラスが主になります。 ここでは、設計書の各項目の大きさをできるだけ均一化し、後の作業を容易に分割し実施すること （製造工程から保守工程までを容易にすること）を目的としています。
　したがって、小規模システムの設計では、粒度の統一を作業項目としない場合が多く見受けられます。 また、マイクロ機器などでは、完成まで粒度が重要な条件要因です。
粒度は、設計上の理論の問題ではなく、作業場の「整理」の問題と考えてよいでしょう。 粒度の考慮がなされていない設計書は、項目別にページ数が大きく異なります。 （著者の経験では、最少項目5ページ、最大項目400ページなどという設計書も存在しました。 巨大粒度を担当する技術者は、まず、ため息ですね。） したがって、本稿は、OODテーマを実務という別の次元から支援する考え方として、重要と思われる事項として取り上げておきます。

8-1.不揃いの原因

　初期の設計作業のインプット情報は、業務の仕様書もしくは、システム計画書といった「業務」の内容単位に記述される情報となります。 おおむね、人間（もしくは、関連するグループ単位）の作業記述となっています。 ここでは、記述の目標は、作業の達成目標として記述されるため、粒度のばらつきが大きく発生してしまいます。
つまり、「数分で完了する作業なのか、数日を要する作業なのか」、 「一人で実施可能な作業なのか複数の人員を必要とする作業なのか」、 もしくは「１種類の作業なのか、多くのバリエーションを持つ作業なのか」という、 「作業の大きさ」の問題点が記述されることを前提要件としていないことが原因なのです。 特に、処理のバリエーションの増加に関しては、設計作業とは関連しない、 業務の目的志向の増加（動作環境の変化の発展）に起因するのが一般的です。
したがって、対象業務の長期継続化とともに、業務内容が多様化し一部のユースケースは巨大化するという事態が発生します。

8-2.不揃い発生のパターン

　例として取り上げるのは、料金の支払いです。 一般に、請求書を受領する（ユースケース1）と、料金を支払う（ユースケース2）が発生することになります。 ここまでが、従来からの「業務」内容単位の基本形となります。 しかし、近年では、料金の支払い方法も多様化し、いくつかの方法から選択してユースケース2を実行するこが可能になっています。 つまり、ユースケース2は、複数のユースケースの集合体であり、ユースケース1とは異なる粒度となってしまったのです。 このような場合には、ユースケース1の粒度をもとに、ユースケース2は、いくつかのユースケースに分解し、ユースケース1と粒度を接近させます。 こうして、粒度を均一化したユースケース群は、「カプセル化と共通化」を施すことによって、修正や新規項目の追加に対して大きな利便性を提供してくれるようになるのです。 あるいは、粒度をそろえることが、カプセル化への道程となっていると考えることもできます。

8-3.カプセル化と共通化

　カプセル化は、簡単に表現することが可能です。 カプセル化対象となるユースケースは、入力および出力のためのユースケースを除いて、 他のユースケースとは全く無関係に存在するものです（単独の役割）。
同様に、共通化とは、入力や出力を制御するユースケースのように、 他の多くのユースケースから独立して切り離された「機能」を持つユースケースのことです（共通の役割）。 日付を管理するプログラムなどが一般的です。
不揃い発生のパターンにおいて記述した、粒度の調整が役立つもう一つの効果です。 粒度を揃えたユースケースに対してカプセル化と共有化を実施すると以下のように整理することが可能になります。 「支払い実施」のUCは、単独の役割を持つ「カプセル化」されたユースケースとなります。

8-4.結論

　仮の結論です。（現在は、著者の独善、かつ、変更の可能性もあります。）
　業務を表すユースケースの一部は巨大化したユースケースになります。 これらは、分解し、多くの多様化したユースケースの集合として定義をし直すことが重要です。 システムの構築上は、一つの業務の内容をただ一つのユースケースとして記述する必要はありません。 問題が発生するのは、はユーザへの業務の確認時であり、 「分割して確認」することをユーザに認識いただく努力が必要になるだけと考えています。 （業務マニュアルの章立ては、エンドユーザの業務基盤ですので、これを蔑ろにするのは得策ではありません。）
仮に、各ユースケースの内容記述が２０ページ前後（10ページから40ページくらいの感覚です。）に統一できれば、 設計書を読んで作業を進める技術者たちにとって、最も効率の良い結果をもたらすでしょう。
（著者の希望的観測ととらえていただければ十分と存じます。）

著者注：
設計書の大きさを２０ページ程度と仮に定義しました。
これは、心理学の研究成果をそのまま借用です。あしからず。

粒度概要-以上

お問い合わせについて

▲ページトップに戻る