ソフトウェアのモジュール設計について学べる良記事リンク集

はじめに

最近の自分のソフトウェア設計業務にて、機能設計とモジュール設計について考えさせられる機会がありました。今回の問題では、機能設計の後に続くプロセスとしてモジュール設計があるのですが、これらは両者の違いが曖昧であり、機能設計の中で細かい機能の洗い出しや、扱うデータ構造の定義、クラス定義などを行っていると、モジュール設計って何のためにあるのか正直分からなくなります。
そこで、一般的なモジュール設計、いわゆるモジュール化の定義とは一体なんなのかと調べたところ、いくつか参考になる良記事が見つかったので、それらのリンクと、読んで学んだ事をメモしておこうと思います。

組込みソフトウェア開発のための構造化モデリング 要求定義/分析/設計からソースコード作成までソフトウェア開発上流工程の基本を構造化手法に学ぶ

モジュール化について考えてみたときのまとめ

qiita.com

• 問題を部分に分解してから解を貼り合わせることでモジュール化する。
• モジュールとは、システムを構成する要素となるもの。いくつかの部品的機能を集め、まとまりのある機能を持った部品のこと。
• ある操作を、複数の部品の組み合わせで表現する。
• 今まで経験した中で似たような問題がなかったかを確認し、それが今回の問題に使えないか検討する。
• 与えられた問題を、別の形に言い換えてみる。より簡単な問題の組み合わせに変形する。

モジュール化設計について

http://sa.eei.eng.osaka-u.ac.jp/tatsumi/tani_prog/add.html

• モジュール化とは、ファイル単位だけでなく、ある機能や処理を行う関数群や関数単位またはデータ群などを、他のものとは独立して閉じた形で扱えるように構成することなども意味する。
• モジュール化によって、プログラムの処理単位ごとに分割したソースファイルを制作し、プログラム開発やデバッグを個別に行うことができる。
• これにより分割コンパイルが可能となるので、ソースコード全てをコンパイルする手間が省ける。
• さらに大事な事は、処理されるデータや関数を、モジュール内だけで隠ぺいしたものと、外部とのやり取り用に公開するもの、に分けることである。
• 外部へ公開する関数、変数は必要最小限に抑えておく。そうすることで、機能変更による影響がそのモジュール内だけに抑えられるようになる。
• 美しくモジュール化することと、実行速度、メモリー使用量などはトレードオフの関係になることがあり得る。

設計の原則: モジュール化

masuda220.jugem.jp

• 設計原則の会得は、ソフトウェア設計の免許皆伝、達人への道であり、ここぞという時の、銀の弾丸になる。
• どんなデザインパターンでも、モジュール化原則の適用例となっている。
• エンタープライズアプリケーションでは、「変更容易性」はソフトウェア価値の重要ポイント。
• 同じ開発コストをかけたソフトウェアシステムなら、モジュール化され、「変更容易性」「発展性」に優れたソフトウェアの方が価値が高い。
• モジュール化しているはずなのに、変更は難しい、発展性ゼロというシステムの事を、「泥団子システム」という。
• 泥団子になってしまうのは、モジュール化に関連する設計原則に違反しまくっているから。
• カプセルは、がっちりした容器であり、収納したら中身には外からおいそれと手を出せないのがカプセル化原則の意味。
• 容器の中身を空けない(調べない)。容器をおいそれとあちこちに移動しない。
• クラスやパッケージの役割を単純に、明確にした設計をすれば、そのクラスやパッケージは安定し、自然に「カプセル化」された状態に進化していく。
• 中身を見る必要がないように、パッケージ名、クラス名、メソッド名をうまく設計する。
• クラスは本来、フィールドを隠蔽して、何かフィールドに対して加工したり、判断した結果を返すメソッドを持つべきである。
• 設計の腕を磨くには、フィールドが外から見えてしまう設計を、邪悪と感じることがまず第一歩となる。