実践的オブジェクト指向設計入門26

　この記事は、実践的オブジェクト指向設計入門25の続きです。前回は、物理的なパッケージ化について解説しました。今回は、設計における決定事項の文書化を解説します。
　いよいよ、オブジェクト指向設計の最後の作業です。今まで設計で様々な決定を下してきました。それらの決定を文書化する必要があります。システムは終わりがありません。後でシステムをバージョンアップする場合や、開発の途中で仕様が変更される場合すらあります。そうした状況が起こることを前提に、担当者が変わっても今までの流れがわかる状態にせねばならないのです。そのために文章を清書します。
　ただし注意するべき事があります。それは、下書きは他の作業と並行するのが前提である事です。いきなり全てを文章化しようとしても上手くいきません。全ての決定事項を、詳細かつ正確に覚えていられないでしょう。しかしながら、文書化という手段を目的にしてしまう人が居ます。こうした過ちは人間ならば誰しもする可能性があります。文書化はあくまでも手段であって目的ではありません。十分に注意しましょう。
　以上でオブジェクト思考法論OMTにおける、オブジェクト指向設計は終わりです。世の中にはほかにも方法論がありますし、物事は教科書通りに進みません。オブジェクト指向方法論OMTを学び、その知識を応用しましょう。そうすれば、システムの品質は飛躍的に上がるでしょう。この連載を読んでくれた方のご活躍を心から願っています。終わり。

実践的オブジェクト指向設計入門25

　この記事は、実践的オブジェクト指向設計入門24の続きです。前回は、オブジェクトの表現について解説しました。今回は、物理的なパッケージ化について解説します。
　今回解説するのは、いよいよ最後の1個手前の作業です。この段階まで設計が進むと、後考えるべきことは、どのようにオブジェクトをパッケージ化するかです。パッケージ化するにあたって、考えるべきことは、情報隠蔽、実態の一貫性、物理的なモジュールの構築の3点です。これから個々の要素を解説します。
　情報の隠蔽とは、オブジェクト指向のカプセル化の事です。つまり、余計な細部に悩まされることなく、オブジェクトを使用できるように、余計な情報を隠すことを指しています。しかし、何でも隠せばよいというものではありません。極論を言うと、1個の何でもできるオブジェクトがあれば隠蔽度は最大です。ですが、1個の何でもできるオブジェクトを定義してしまうと、分担作業ができなくなりますし、仕様変更や機能拡張に耐えられない設計になってしまいます。設計者は、何の情報を公開するのかをよく考えなくてはなりません。オブジェクト指向の基本は隠蔽であり、何の情報を公開するのかを考える事が肝要です。
　実態の一貫性は、クラス、操作、インタフェースなどといった要素を、設計思想にそって一貫させることです。個々の要素に一貫性があると、将来拡張するのも容易ですし、途中参加したプロジェクトのメンバーの仕事がやりやすくなります。具体的には、命名規則が挙げられます。命名規則がおろそかにされることが多いのですが、人間は名前で意味を理解しようとするので非常に重要です。名前とまったく違う動きをするオブジェクトを理解することは容易ではありません。
　最後のモジュールの構成は、簡単に言うとオブジェクトの分割の仕方です。オブジェクトの粒度をどれくらいにするのか、アセンブリやDLLといった物理的なファイルをどのようにするのか、インタフェースをどのようにするのかなどといったことを考えます。一見簡単そうに見えますが、非常に複雑なものです。参考文献をあげます。




ほかにも参考になる書籍と、必要となる書籍がありますが、ひとまずこの3冊を押さえておきましょう。設計の世界も奥深いものです。続く...

実践的オブジェクト指向設計入門24

　この記事は、実践的オブジェクト指向設計入門23の続きです。前回は、関連の設計について書きました。今回は、オブジェクトの表現について書きます。
　オブジェクト指向方法論OMTは、基本データ型を使う状況と、関係するオブジェクトを組み合わせで使うのはどんな状況なのかを、明確に定義しなくてはならないと説いています。ちょっとわかりにくいので噛み砕いて説明します。
　オブジェクトの属性を表現するとき、大まかにいうと、基本データ型（整数型、実数型、文字列型など）で表現するのか、特別なオブジェクトを定義して表現するのかの2通りの方法が考えられます。例えば、社員オブジェクトの属性・住所に使用する郵便番号は、文字列で表現できますし、オブジェクトでも表現できます。どちらが良いのでしょうか？こうした実装者の疑問に対し設計者は、明確に答えねばなりません。しかし、どちらの方法が良いのかは決まっていません。絶対の答えがないからこそ設計者の腕の見せ所なのです。絶対の答えがないというのが分かりにくいと思いますので、両方法についてちょっとだけ詳しく書きます。
　先程の例でいうと、郵便番号を文字列で表現すると簡単に扱えるように思うでしょう。しかし、実現するシステムにより、簡単か否かは変わってしまいます。社員の住所を表示するぐらいの処理しかなければ、文字列でも問題はないでしょう。ですが、郵便番号を解析して複雑な処理をするようなシステムならば、オブジェクトにしたほうが簡単に実装できます。すなわち、実現しようとしているシステムで可否が決まります。よくいわれる、設計のトレードオフの一つといえます。
　絶対に正しい答えというものがないので、設計者はトレードオフに対して、毅然とした態度で決定を下しましょう。もちろん、そこには設計思想がなければなりません。設計思想がないその場限りの決定は、現場を混乱に陥れるだけです。十分に注意しましょう。
　以上がオブジェクト指向方法論OMTの説明です。私個人の考えを付け加えます。日本の状況を考えると、この作業は余計な干渉のもとになるから注意する必要があると思います。日本では、プログラミングを知らない設計者がいます。そんな設計者がデータ型にまで口を出すと、プログラマーの仕事がやりにくくなるだけです。むろん、プログラミングを知らずとして正しい設計などできないと思いますが、日本の体制ではそうなっているので柔軟に対応するしかありません。
　それともう一つ注意するべき点があります。それは、プログラミングと設計の境が薄くなるという点です。もともと設計と実装は切り離された工程ではなく、数直線のように無限に途切れなく続くものですが、設計と実装の目的の違いを常に意識しなければなりません。やはり、設計と実装は違います。この作業（オブジェクトの表現を考える）をする際には特に注意しましょう。

実践的オブジェクト指向設計入門23

　この記事は、実践的オブジェクト指向設計入門22の続きです。前回は、継承の調節について解説しました。今回は、関連の設計について書きます。
　オブジェクト指向設計は、オブジェクトそのものについて着目するだけではなく、オブジェクトの関連についても熟考が必要です。情報システムにおいて設計するオブジェクト群が、単独で存在する事は稀で、互いになんらかの関連を持ちます。従って、オブジェクトの関連についても分析と設計が必要なのです。
　オブジェクト指向方法論OMTでは、関連のたどられ方の分析が提唱されています。設計段階では、オブジェクトモデル中の関連を実装する戦略を明確化する必要があります。オブジェクト間の関連を明確にしておかないと、実装の詳細に意識を奪われ設計が失敗します。関連は双方個のものが大半ですが、本当にそうなのかよく分析すると、システムの流れと本質がよく分かります。具体的には、関連の方向と多重度が重要です。
　関連には、互いに参照する双方向と、どちらかが参照しかしない片方向があり得ます。普通に考えて、双方向の場合が多いと思うでしょうが、同じ双方向でもオブジェクト群としてみたとき、設計によりパス数が異なります。上手く設計すれば、同じ操作をするにも効率よく操作できます。ですが、あえて余分なオブジェクトを加えることにより、より柔軟で再利用性が高い設計が可能となる場合もあります。GoFデザインパターンがよい例です。ただし、余分なオブジェクトを無目的に追加しても、混乱をもたらすだけです。よく注意しましょう。
　関連は多重度も大切です。主となるオブジェクトが１、使われるオブジェクトが多数というのがよくあるパターンです。他にも、多対多の関係のオブジェクトもよくありますが、関連オブジェクトを追加して、多対１の関係にすることを検討しましょう。そういった関連の重要さはデータベース設計となんら変わりません。
纏めます。個々のオブジェクトを設計するだけではなく、オブジェクト間の設計も必要だと言う事です。設計と実装の違いはこういった所で現れます。続く...

実践的オブジェクト指向設計入門22

　この記事は、実践的オブジェクト指向設計入門21の続きです。前回は、並列タスクによる制御について解説しました。今回は、制御の実装の次の作業である、継承の調節について解説します。
　オブジェクト指向設計が進んでくると、操作やオブジェクトが複雑化してきます。そこで、継承関係が無いのかチェックします。ある程度の規模のシステムとなると、オブジェクトの数は膨大となります。膨大なオブジェクトは、設計の理解を困難にし、あらゆる作業に悪影響を与えます。従って、継承による設計の簡素化が重要となるのです。
　オブジェクト指向方法論OMTでは、設計を簡素化するために、継承の検討が提唱されていますが、それと同時に 注意もされています。継承はカプセル化の原則を崩します。無理な継承関係は、余計にシステムを複雑化してしまいます。ですから、継承だけではなく、委譲も視野に入れて設計のリファクタリングを行いましょう。
　ただし、継承と言っても実装の継承とインタフェースの継承がある点に注意して下さい。プログラムの量を減らす事だけを考えて設計しても、オブジェクトの構造が複雑化し、余計に実装を困難にします。インタフェースの継承を賢く活用しましょう。

実践的オブジェクト指向設計入門21

　この記事は、実践的オブジェクト指向設計入門20の続きです。前回は、状態機械エンジンについて解説しました。今回は、最後の制御の実装である、並列タスクによる制御について解説します。
　オブジェクト指向方法論OMTが書かれた時代には、並列タスクはあまり一般的ではありませんでした。それ故、オブジェクトをタスクと見做し、それを並列に扱う事しか書かれていません。しかしながら、今現在は並列タスク制御が一般的ですので少し書き足します。
　オブジェクトは一つのタスクと看做せます。また、一つの処理を複数のタスクに分けることも簡単です。問題となるのは実装ではなく、どの様に事象を表現して設計するかです。搭載されるCPUのコア数は年々に増加していますが、それでも無限でありません。有限のリソースを、どの様に使用するのかを考えるのが設計です。
　具体的には、時間と処理プロセスの関係について分析します。直列的な処理でよい時代は、あまり時間に注意を払いませんでした。しかしながら、並列処理では、タスクが資源を占有している処理区間が非常に重要です。従って、時間に注目せねばならならないのです。
　並列処理システムの設計は一大トピックですので、全然書き足りませんが、ひとまず時間と処理の関係について分析する所が要点です。他の事柄については、並列処理全般を学ぶしかありません。実際に並列処理システムを設計すると自ずと分かります。続く...

実践的オブジェクト指向設計入門20

　この記事は、実践的オブジェクト指向設計入門19の続きです。前回は、プログラム中の位置による状態の表現について解説しました。今回は、今回は制御の実装の内の1つ、状態機械エンジンについて解説します。
　オブジェクト指向方法論OMTでは、状態機械エンジンを明示的に表現し、かつ実行するなんらかの手段を用意する事が提唱されています。これは難しい概念だと思います。情報科学を学習していない人にはピンとこないでしょう。
　簡潔に説明すると、動的モデルを状態機械で表現すると、オブジェクト指向分析を効直接的に表現でき、強いては（※）検証がやりやすいと言う事です。確かに状態の変移として捉える見方は有用です。
※長すぎて省略しているからちょっと強引になっています。
　しかしながら、情報科学について学習していない人は出来ないでしょう。そんな人は、インスタンスの状態遷移をよく分析して、その流れがスムーズになる設計を行うと考えて下さい。続く。

実践的オブジェクト指向設計入門19

　この記事は、実践的オブジェクト指向設計入門18の続きです。前回は制御の実装を解説しました。今回は制御の実装の内の1つ、プログラム中の位置による状態の表現について解説します。
　プログラム中の位置による状態の表現とは、簡単に言うと手続き型のプログラミングで処理を設計する事です。伝統的なプログラミングは、直列的（逐次的）なプログラムの流れを前提として処理を考えます。従って、処理の流れを設計しなくてはならないのです。
　具体的には、メインとなる流れ、分岐した流れ、例外処理の流れの3点の状態遷移を設計します。基本的にはアクティビティ図を使用するのがよいでしょう。ただし、処理の流れと言っても実装ではなく、設計段階だと言う点に注意して下さい。設計段階で考えるのは、大まかな流れであり、フローダイアグラムで記述するような細かいプログラムの処理ではありません。十分に注意して下さい。
　この作業については、多くを語る必要が無いと思いますので、今回はこれで終わりです。

実践的オブジェクト指向設計入門18

　この記事は、実践的オブジェクト指向設計入門17の続きです。前回は、設計の最適化について解説しました。今回は制御の実装を解説します。
オブジェクト指向方法論OMTでは、次の作業として制御の実装が提唱されています。この名称は紛らわしいのですが、実装／プログラミングの事ではありません。実装の制御とは、動的モデルに表されている状態ー事象モデルを実装するための戦略を具体化する作業の事です。すなわち、動的モデルの具体化を示しています。
　オブジェクト指向方法論OMTでは、動的モデルの具体化するアプローチを、手続き駆動システム・事象駆動システム・並列タスクの3点挙げています。
　長くなるので次回から、動的モデルを具体化するためのアプローチ法を1つずつ解説していきます。続く。

実践的オブジェクト指向設計入門17

　この記事は、実践的オブジェクト指向設計入門16の続きです。前回は、設計の最適化について解説しました。引き続き設計の最適化について解説します。
　オブジェクト指向方法論OMTの「効率的なアクセスのために冗長な関連を追加する」とは、複雑な操作の再計算を避けるために、派生属性を保存することだとされています。分析中に冗長な関連は望ましくありません。しかしながら、実装するという観点から見れば、システムの効率が上がる場合もありうるので、冗長な情報を付加するのが望ましい事もあります。
　例えば、データベースに於いてテーブルは基本的に第3まで正規化します。しかし常に第3正規形にしておくと、頻繁に検索されるパターンによっては、逆に効率が悪い場合があります。その様な状況では、第3正規形をあえて崩して、頻繁に検索される列を追加して冗長にする事により、結合コストを低くするとよい場合もあります。ただし、冗長化すると更新コストが上がるので、慎重にせねばなりません。なお、この作業項目は、インデックスの検討も含まれています。
　次に「効率化のための実行順序の再調整」があります。アルゴリズムは、計算手順を変える事により処理効率が上がる場合があります。オブジェクト指向分析では論理的な順序が導き出されますが、実装の観点から言って最適な順序だと限りません。時には実行を変える柔軟な思考が求められています。
　最後に「派生属性の保存による再計算の回避」です。これは、他のデータから派生させることができる冗長なデータを再計算するオーバーヘッドを避けるために、一旦計算した値のままキャッシュしたり保存したりする事です。「効率的なアクセスのために冗長な関連を追加する」と似ていますが、この項目はインデックス等についてであり、派生属性の保存による再計算の回避はキャッシュの事を指しています。ネットワークの設計でよくみられる現象ですが、オブジェクトを使われる場所の近くにコピーしておくと、遠隔地に一々データを取りに行く手間が省けます。これはあらゆるオブジェクトに言える事です。そのよい例がADO.NETのオブジェクトモデルです。
　ADO.NETを使用すると、メモリ内にデータをコピーしておく事が出来ます。これは処理効率を大きく上げます。何故ならば、遠隔地にアクセスしてデータを受信するスピードよりも、メモリからデータを取得する方が圧倒的に速いからです。適切なデータを取得しておけば、パフォーマンスは大幅にアップします。
　こうした事例はシステム開発では頻繁にあります。あらゆる場所にキャッシュがある事からその事実がそれを裏付けています。ハードディスク・CPU・主記憶・・・・それら全てにキャッシュが存在します。しかしながら、キャッシュは更新に関するデメリットがある事を忘れてはなりません。DNSのキャッシュにより、名前解決に関するトラブルを経験した人も多いでしょう。
　前回も言いましたが、最適化にはデメリットがあり、早すぎる最適化は毒となります。十分に注意して下さい。最後に注意するべき点について述べます。オブジェクト指向方法論OMTがいう計算とは、コンピューターの処理全般を指しています。数値処理だけの話題ではないので注意して下さい。