マエカワの備忘録的な何か

思い立ったが吉日

ソフトウェア工学 其の九 20171221

構造化設計(続き)

良い設計の落としどころ

 実際のところ、考える人によってさまざま。「これが最適だ!」というものは今のところ分からない。そこで、ここではモジュール化(カプセル化*1という考え方を出す。モジュール化を構成する要素には

  • 凝集度
  • 結合度

がある。それぞれを説明していく。

凝集度

 難しい言い方だと、「再利用可能である度合い」。簡単な言い方だと、「用途ごとに分けられている度合い」。言葉で表現するのは難しいので、講義で出てきた例を紹介していく。


 CDラジカセには、「CD」「ラジオ」「カセット」の3種類のメディアを再生できる機能が備わっている。この機械において、CDとラジオどちらにも関係のある部分 Aがあったら、どのような不具合が考えられるだろうか。
 「ラジオ部分に仕様変更」があった場合を考える。修正範囲に部分 Aが含まれていた場合、CD機能との関係を考慮して修正していかなければならない。最悪、部分 Aのプログラムをすべて書き直す必要が出てくる。このような設計は凝集度が低いとされている。
 では、凝集度の高い設計とはどのようなものなのか。それは、CD・ラジオ・カセット機能が独立である設計だ。一部を変えるときに、その部分しか変える必要がないように設計する。これが凝集度の高い設計だ。どのレベルで独立させるのかは、その時の状況や、求められていることに応じて変わってくる。

結合度

 難しい言い方だと、「それぞれのモジュールの責務がはっきりしている度合い」。簡単に言うと「他モジュールの変数を勝手に変えられる度合い」。Javaを例にして説明された。public変数は、誰でも使うことができるので結合度が高く、private変数は、自分しか書き換えることができないので、結合度が低い。大規模システムの開発の際には、どこでバグを起こしているのかをしっかり知るために、結合度を低く保つ必要がある。

 基本的に、「凝集度は高く、結合度は低く」が原則。また、この考え方はソフトウェア工学だけでなく、あらゆる分野で登場してくる。

モノリシック

 全くモジュール化されていないことを表す言葉。出てきたのは「21世紀宇宙の旅」という書籍。巨大な船と、モジュール化されていない巨大なコードを対応付けている。

疎結合化の難点

 疎結合化が進むことで、処理スピードが落ち、パフォーマンスが落ちる危険性がある。

設計とは

 設計はプログラミングではない。プログラムを正しくすることだ。そして、トレードオフトライアンドエラーの賜物である。トライアンドエラーから経験則を得ていく。

期末テストについて

 「凝集度・結合度の考え方を”身近な例”で説明しろ」という問題が出てくるらしい。

クリスマスは何のためのイベント…?

 何かのきっかけにするイベント。なんでもいい。
 ということで、Qiitaで企画されていたソフトウェアテストに関するアドベントカレンダーが紹介された。このようなきっかけで、技術を楽しむことができれば自分の選択が広がっていく。選択肢が多いということは、人生の幅が広がるということ。
 今の時代、ネットを使えば情報は出てくる。いろいろなところへ刺激をもらいに行って、自分の選択肢を増やすことが大切になってくる。
 アドベントカレンダーに参加している人どうしは、顔も知らないし本名も知らないことが多いし、これは技術者界隈では結構当たり前だったりする。
 弊学でも、アドベントカレンダーを書いている方たちがいる。自分が入学した2015年にはもうあった。見てみると、学内無線の設定方法だったり米の話だったりと、かなりバリエーションが豊富。面白い。

*1:最近の言い方だと、「疎結合化」や「マイクロサービス化」と呼ぶ