はじめに

大規模複雑化する組込みソフトウエアに対応するために、モデルを開発に導入している企業が増えてきています。実際、コンサルティングの現場でも以前よりも多くの業界からモデリングに関する問い合わせがきています。

そうしたモデリングですが、モデルを書きさえすればソフトウエアの生産性や品質が向上するというものでもなく、UMLを導入したけど、現場が混乱しただけで効果が出なかったなんて話も多いのではないでしょうか。

この連載では、そうした組込みソフトウエアの開発の現場でモデルの効果をうまく出すためのポイントを伝えていければと考えています。この連載を通して、皆さんのモデルの効果が高まっていったとしたら幸いです。

モデリングから見た組込みの特徴

まずは、モデリングという観点から見た時の組込みソフトウエア開発の特徴を挙げていきたいと思います。モデリングには「観点」が必要となりますがこの観点に組込特有のものがあります。

一般的なモデリングに登場する観点は次のようなものです。

  • 静的、動的、機能的
    • 静的:対象の時間によって変化しない構造を捉える観点
    • 動的:対象のライフサイクル(生成から消滅まで)中の状態変化を捉える観点
    • 機能的:対象の実現する機能を捉える観点
  • 論理的、物理的

こうした観点から見た時に、必要な情報を残し、不要なものをそぎ落としていくことでモデルはできあがります。

組込系のモデリングではこれらの観点に加えて組込固有のものとして、システム、ハードウエア、ソフトウエアという観点が加わります。これは、組込ソフトウエアがシステムを構成する一要素でしかないことから来ています。

業務系のシステムでは、ほぼ、システム=ソフトウエアという考えが成り立ちますが、組込系の世界ではシステムはハードウエア(もっと細分化すると機械的なものと電気的なものとに分けられますがここではいっしょにしています)とソフトウエアから構成されています。そのため、一口に「システムをモデル化する」といっても、それがシステム全体のことを指すのか、ハードウエアのことを指すのか、ソフトウエアのことを指すのかがはっきりしていないと何をモデル化しているのか分からなくなってしまうのです。

組込系でモデリングをする際、この部分で混乱しているモデルをよく見かけます。システム(ハードウエア+ソフトウエア)の論理的な構成をモデル化をしようとしているのに、ハードウエア構成を表したモデルになってしまっていたり、ハードウエアの構成をモデル化しようとしているのに、機能の階層構造を表すモデルになってしまっていたり。

こうした間違いを防ぐためには次の2点に気をつける必要があります。

  1. モデル化しようとしている範囲を認識すること
  2. 作成したモデルが何を表しているのか判断できること

1.については、モデルを作る前に、自分がシステム、ハードウエア、ソフトウエアのどの範囲をモデル化しようとしているのかを認識することです。それにより、モデル上に登場してくるものが異なってきます。例えば、システム全体をモデル化するのであれば、ソフトウエアで取り扱うデータに関する部分がモデル内に登場してこないといけませんが、ハードウエア構造をモデル化する際にはそういった情報はモデル上に必要ありません。

2 .については、できあがったモデルが結果的に何を表現しているものになっているのかを判断できることです。この判断ができないと、目的と異なるモデルをずっと作り続けることになってしまいます。例えば、ソフトウエアのモデルを作っているつもりでも、ハードウエアのモデルになっているような場合です。そうした目的と実際のモデルとのズレを自分で読み取るか、その判断のできる他者を連れてくる必要があるということです。

おわりに

今回は、組込み開発におけるモデリングで重要となる、モデリング対象の明確化について話をしてきましたが、いかがだったでしょうか。

組込系でのモデリングには組込ならではの課題がいろいろとあります。そうした課題を解決しようと思っても、世の中のモデリングに関する本のほとんどは業務系のモデリングを対象としているため、組込系にそのまま適用できないことがほとんどです。そうした、なかなか情報のない組込系ならではの課題を今後も取り上げていきたいと思います。