システム・モデルの作成とレビュー

再利用方針の策定とモジュール化

既存システムのモデル化をしておくと、再利用方針を効率よく立てることができます。次期システムの要件を満足させるためには、再利用できる部分や機能拡張のために必要な拡張ポイントの洗い出しの作業に、既存システムのシステム・モデルを使います。

再利用のためにはモジュール化が必須です。ところが、ソフトウエアはモジュール化が難しいため、再利用が進まないのが現実です。ソフトウエアは、そのままでは全体の構造が見えにくいため、全体構造の可視化には、別の手法が有効です。

全体構造の可視化で有効な手法が、DSM（ディペンデンシ・ストラクチャ・マトリックス）と呼ばれる手法です。システムのモジュールの依存関係をマトリックスで分析するこの手法は、トップ・ダウンで解析が可能なため、大規模なシステムで威力を発揮します。

ソフトウエアのモジュール化で重要なことは、「独立性の高い分節点」を見つけることです。

「再利用しようとしたら、よく分からない別モジュールを使っていた。別モジュールを使おうとしたら、また別のモジュールが必要になった」という経験を持つ方は多いでしょう。モジュール間の依存関係は詳細レベルで起こるので、トップ・ダウンで最初からきれいなモジュール化をしようとすると、さまざまな問題が起こります。初期の設計では、大きな分割の方針を決めるだけにしましょう。

最初から完璧な分割を望むのではなく、詳細化の後で無理のない分割法を考えたほうが、現実的です。このためにも、DSM分析は有効です。マトリックスを使えば、「独立性の高い分節点」を簡単に見つけられます。

モジュール化には望ましくない依存関係が、一部に見られる場合があります。また、拡張性を持たせるために、一部の構造を変更しておいたほうがよい場合もあります。このような、ソフトウエアの構造を改善する方法として注目されているのが、リファクタリングです。

図4は、リファクタリングによって発芽点（スプラウト・ポイント）を作成する例です。発芽点（インターフェース）により、既存システムを「変更しない部分」と「交換して拡張する部分」に分離します。このようにソフトウエアの構造を変更することで、拡張による影響個所をなくすことができます。

システム設計レビューのポイント

システム設計の大きな部分をソフトが占めるようになると、メカとエレキの設計者にもソフトウエアの設計レビューに参加してもらわないと、設計品質の向上は望めません。しかし、ソース・コードを直接読むためには、プログラミング言語の文法を知っている必要があります。このため、言語を勉強したことのない人には、敷居が高くなります。

メカ、エレキの設計担当にソフトウエアのレビューに参加してもらう際には、ソフトウエアをモジュール化して、それぞれのモジュールをブラック・ボックス化して「関数」としてレビューしましょう。「関数に、入力と出力がある」という風に考えてもらいます。メカやエレキの視点で、その関数がシステム全体の機能として十分かを、レビューしてもらうことができます。

状態とイベントの整理が重要です。メカ、エレキ、ソフトの設計者全体で、「システム全体としてどのような状態があり、それぞれの状態で発生するイベントに対してシステムはどのように機能するか」について共通認識が必要です。システムが取りうる状態と、発生するイベントについては、設計者全員で共有できる状態遷移モデルを作成しておくとよいでしょう。