ここで説明したのはリアル建築で例えれば「どんな生活をしたいのか」「家主の要望は何か」「予算はどれくらいか」などによって，家の構造設計は変わるということだ。
ソフトウェアのアーキテクチャも何をしたいのか，どんな困りごとを解決したいのかによって，ソフトウェアシステムのアーキテクチャは変わる。ソフトウェアのアーキテクチャの重要なポイントは「設計思想」だと思う。設計思想こそが「アーキテクトの腕の見せどころ」のポイントなのだ。
『ソフトウェアアーキテクチャとは何かを考える』にも書いたが，ソフトウェアの場合は，「大改造！！劇的ビフォーアフター」のようにリフォーム後に アーキテクトの仕事の成果を顧客とともに見て回り，リフォームのできに感動してもらうといったシーンがない。ソフトウェアは見えないから，アーキテクチャの善し悪しは分かる人にしか分からない。そこがなんとも悲しいところなのだが，だからこそ，アーキテクトはそのシステムのアーキテクチャの設計思想を他人にキチンと説明できるようにしておかないとダメなのだろう。
そう思い，今回の記事では 『Raspberry Pi3を使ったリアル波形描画』の取り組みの中で採用しようとしているアーキテクチャの設計思想を説明しておきたいと思う。
考え方はInterface誌 2003年1月号に投稿した記事『オブジェクト思考を使ったリアルタイム信号計測システムの開発』と同じなので，まずは，この記事で想定した 1ch のデジタルオシロスコープを例に説明しようと思う。
この製品のソフトウェアシステムを設計したい。設計の前に解決したい問題を確認しておこうと思う。
解決したい問題
この商品の基本機能はノイズを除去するためのデジタルフィルターであり，ハイエンド製品では，さまざまな，フィルターを搭載できるようにしたり，切り替えたりできるようにしたい。よいデジタルフィルターを設計し，搭載することができれば，それがこの商品群のコア資産となり，その資産が他社の商品と競合したときのアドバンテージとなる。
したがって，アーキテクチャの第一の目的は「コア資産となるデジタルフィルタのソフトウェアモジュール」の再利用しやすく設計し，さまざまな商品群にソフトウェアにまったく手を加えることなく※1，利用できるようにすることである。
※1 コア資産の主要部分（パラメータ設定以外）についてはソースコードを1行も変更しないで複数の製品に使用できることを「再利用」と言っている。ソフトウェアは簡単に変更することができ，1行変更しただけで動かなくなったり，デグレードしたりするので「再利用」は基本，ソースコードの変更はなしでできることが前提。
それがうまくいけば「競争力の高いソフトウェア資産」使って，さまざまな商品展開ができ，顧客満足が高まり，商売も儲かる。
また，「競争力の高いソフトウェア資産」に問題があり，それが市場で発覚すると，組織に大きなダメージを与えるため，コア資産となるソフトウェアの信頼性は十分に確認しておきたい。これらの要求をまとめると次のようになる。
- コア資産となるデジタルフィルタのモジュールを再利用可能な資産（ソフトウェア本体にまったく手を入れることなく再利用可能）にする。
- コア資産となるデジタルフィルタはさまざまなバリエーションを持たせる。
- 新しいフィルタを開発することと，採用するフィルタの妥当性確認（バリデーション）をしやすくするために，実機ではなくPC上でフィルタ効果を確認できるようにしたい。
- フィルタの入力は信号ピックアッププローブから入力するだけでなく，検証用に持っている信号データや，擬似的に作成したデータを入力できるようにしたい。
- データの保存はUSB経由を想定しているが，将来は Wi-Fi や ブルートゥース経由でPCへ保存できるようにしたい。
ちなみにソフトウェアの「再利用」ではなく「流用」ということばを使っている技術者をよく見かけるが，自分は「流用」ということばは絶対に使わない。「流用」ということばの響きに「再利用のための設計思想はありません」というニュアンスを感じるからだ。
設計思想のないアーキテクチャには将来ろくな事がないと思う。設計思想なく「流用」されたソフトウェアは，最初に設計したときの思想が伝わることなく，別のシステムにはめ込まれ，予想もしなかったような不具合が起きることがある。
さて，これらの要求を実現するための概念的な構造を図で表してみると左図のようになる。（設計の思想）
入力は製品では信号ピックアッププローブから入力（A/D変換）するが，実験，検証のために信号データファイルからも入力できるようにしたい。
この入力の切り替えは簡単にスイッチできるようにしたいし，その後のソフトウェア（デジタルフィルタやディスプレイ表示やデータ保存）には影響を与えたくない。（1行もソフトウェアを変えないで済むようにしたい）
信号処理部のデジタルフィルターは，さまざまなものをラインナップし，こちらも簡単に切り替えられるようにしたい。新しいフィルタも簡単に試せるようにしたい。
波形の出力は 小さなLCDディスプレイに表示するが，このLCDディスプレイは商品によってサイズや解像度が変わる。また，後継機種を出す際にはLCD部品が変わる可能性が高いので，これらの変化に柔軟に対応できるようにしたい。
さらに，データの出力機能としては，当初は USB I/FでデータをPCに送るが，将来はWi-Fi や ブルートゥース経由でデータを格納できるようにしたい。
このシステムにおけるコア資産は何か？変わりない部分と変わりやすい部分
なお，出力部のLCDディスプレイは変更となる可能性が高い。また，出力の I/F は時代とともに新たなものが増えていく。ようするに，将来の商品開発を見据えて長い目でみれば，変わりやすい部分と言える。
変わりやすい部分の影響を受けて，コア資産にも変更が加わるようにはしたくない。ソフトウェアアーキテクチャ上，信号処理部と出力部はキッチリ分けて，信号処理部から出力部へのデータ渡しの I/F はできるだけ変わらないようにしたい。
また，入力部の信号ピックアッププローブと信号データファイルについても，その後ろの工程からみたらその差について気にしないですむようにしたい。
信号ピックアッププローブと信号データファイルの切り替えのイメージはこのような感じとなる。
製品では A/D変換器から取り込んだ信号でデータにデジタルフィルタをかけ，結果を表示する。
これをリアルシステムとすれば，バーチャルシステム（仮想システム）では，信号データはファイルたか取り込んで，デジタルフィルタをかけ，その結果を開発マシンのPCのディスプレイ上に表示したい。
「バーチャルシステムでコア資産の性能を検証し，商品として使えそうであること（有効性）が確認でき次第，コア資産のソフトウェアに手を加えることなく，リアルシステムで動かす」これが，今回のシステムの設計思想となる。
ちなみに，コア資産は変わりにくいとはいえ，一度作ったら終わりということにはならない。競合他社と競争しているわけだから，日々改善，性能向上をしていく必要もある。そのき，改善したコア資産の中身だけを入れ替えて，コア資産の入力と出力のI/Fを代えなくて済めば，安全に性能向上のバージョンアップができる。
コア資産の改善と，入出力の仕様の変化の対応を同じレベルで考えてはいけない，コア資産の改善は，その商品や商品群の屋台骨を強くするための取り組みであり，入出力の仕様の変化に対応するのは，ユーザインタフェースの改善が目的である。後者は商品の本質的な価値に関係し，後者は商品の（表面的な）魅力に関係する。どちらも，商品が売れるためには必要だが，コア資産は他社にまマネできない競争力の源泉であり，後者は他社が真似しようと思えば真似できる。だから，コア資産は機能や性能を確認し，信頼性が十分に高い状態を維持し，ユーザインタフェースの部分は時代に合わせて素早く変化できるよにしておくことが重要となる。
コア資産の性能向上を検討したときに，デグレード（今までできていたことができなくなったり，性能が落ちたりすること）してはまずいので，これまでできていたことの検証もできるようにしておきたい。
そのとき，実機でさまざまな入力信号を再生して，結果を確認するのは多大な工数を必要とする。だから，この検証部分は バーチャルシステムで網羅性の高い確認を行い，最後にリアルシステムでサンプル検証する方法を採りたい。
これらができると飛躍的に開発効率が高まる。
- 新しい性能（今回はフィルタの特性）の確認が実機なしで確認できる。
- さまざまな入力データを新しいコア資産に通した結果をシミュレーション環境で確認できる。
- ソフトウェアをいじることなく，かつ，安全に新しいコア資産をリアルシステムに実装できる。
- フィールドで問題が起きたとき（例えば，結果が期待通りにならないケース）入力データを記録できれば，そのデータを繰り返しシミュレーション環境で再現できる。
仮想システムでコア資産となるデジタルフィルタにサンプルデータを流し込み，開発環境のPCのディスプレイに表示する。
このとき，デバッグ用に内部データをPCに表示することも可能。
そして，さまざまな入力データで網羅性の高い検証を行ったのち，リアルシステムにスイッチして実機環境にて，シミュレーション環境と結果が同じになることを確認して実装を完了する。
今回のシステムでやりたいことは，こういったことだ。
ここまでの説明でお分かりかと思うが，ソフトウェアのシステムアーキテクチャの設計にあたって，対象の商品や商品群，提供するサービス，顧客の要望，開発効率を妨げていることなどの情報が必要となる。
そして，商品や商品群のコア資産が何か，そのコア資産を再利用して効率よくまた，安全に派生開発できるようにするには，どんなアーキテクチャが最適かを考える。
ソフトウェア開発を単発で考えているとこの発想にはならない。製品のソフトウェアを外部の協力会社に丸投げしているようなプロジェクトでは，およそこういった発想にはならないだろう。商品開発とソフトウェアの再利用，開発の効率化，安全性信頼性の向上を頭にいれたアーキテクチャ設計が必要になる。
5年とか10年，また，複数の商品，商品群で共通に利用するコア資産をベースにした再利用開発を想定したアーキテクチャ設計を行う，これがソフトウェアアーキテクトの腕の見せどころとなる。
このようなシステムを実現するためのソフトウェアアーキテクチャは具体的にどう設計するのかを次回以降解説する。
今回の記事には書かなかったが『Raspberry Pi3を使ったリアル波形描画(6) Qtでマルチスレッド処理をやってみる』に書いたように，マルチスレッドによる正確なタイムインターバルの実現と，タイマーイベントとデジタルフィルタのモジュールはパッシブに（『ソフトウェアアーキテクチャとは何かを考える』で解説したデータ結合のような疎結合状態）つながるようにしないといけない。
また，デバッグ用の画面も含めたユーザインタフェースはゼロから作るのは効率が悪い。今の時代，さまざまなお助けツールがある。
今回の特集記事で Qt を使った事例を書いているのは，ここまで説明してきたアーキテクチャの基本設計の方針を Qt を使うと上手に実現できそうだということが分かったからだ。（特にユーザインタフェースの部分は相当お助けになる）
波形描画やボタンなどのユーザインタフェースは自分で作ると結構時間がかかる。しかも，UIは時代とともにどんどん変わっていくし，ユーザもリッチなUIに慣れてきているので，プアーなUIだと中身の性能が良くても，商品として評価が低くなるかもしれない。
だから，Qt を使うことでユーザインタフェースは最大限作業を省くことができたし，デバッグ用の内部のデータ表示なども，サクッと作ることができた。
そして，PC上で表示した画面をソースコードを変えることなく，そのまま，Raspberry Pi3 上で使えるのも魅力的だった。
さらに，4ms の正確なタイムインターバルを発生させて，Qt のSIGNAL/SLOTのしくみをつかって，他のコア資産にイベントを伝達できることも分かった。
ソフトウェアアーキテクチャの設計思想がよくても，実現の方法や条件が満たされていないと上手くいかない。さまざまな制約条件をクリアしつつ，目的のアーキテクチャを設計思想通りに実現する，これがソフトウェアアーキテクトの腕の見せどころなのだ。
制約があればあるほど，燃えるのがプロの職人であり，そのためには，数多くの経験とソフトウェア設計に関する多くの引き出しがないといけない。いろいろな制約条件がある中で，設計思想にぴったりくるアーキテクチャが見つかったときに「いける！」と感じる瞬間がある。
それは，開発の相当初期の段階で，実現可能性の検討段階（フィージビリティ・スタディ）のときでないとまずい。作り始めてしまったあとに，最初の設計思想が実現できないことがわかり，妥協していくと，グダグダになってプロの仕事でなくなってしまう。
制約条件をクリアしながら，価値の高い商品を効率良く生み出していくアーキテクチャ，これを実現するのがプロのソフトウェアアーキテクトだと思う。
今回，ソフトウェア自体（ソースコードやクラス図など）に一切触れなかったのは，アーキテクチャを決定するのに，いかに設計思想が重要かということを理解してもらいたかったからだ。
プログラマーとしてプロならば，デザインパターンなどの定石や手筋が習得できているだけでいいのかもしれないが，ソフトウェアアーキテクトしてプロの仕事をするのならば，効率良く儲かる，ユーザにも高い満足を与えることができる設計が必要だ。
リアル建築に例えれば，一級建築士の資格をもって，個人事務所を持ち，限られた予算でさまざまな要求を持つ顧客を満足させる家を実現するために最適な図面を書き，設計思想どおりに家ができるようにコントロールする役割が求められる。
同じ要求のユーザはほとんどいない。業務ドメインによって，求められる構造も，制約条件も変わる。今回紹介しているリアル波形描画のシステムにしても，ドメインに依存しており，処理の時間制約が厳しいという条件に特化していると言える。
だから，このアーキテクチャはどの業務ドメインにも使えるというわけではない。しかし，だからこそ，アーキテクトは幅広い見識と経験，多くの引き出しが必要だ。銀の弾丸はなく，どのドメインにも最適な解はない。
なお，『リアルタイムOSから出発して 組込みソフトエンジニアを極める[改装版]』は，全編 仮想の電子レジスター 商品群をテーマに，今回書いているようなことを解説している。
今回の特集記事は，この本で書いたことを，実機で実現できると証明するために書いた。机上の空論と言われたくなかったからだ。
次回からは，実際にどのような構造にすると実現できるのかを説明していく。
大規模・複雑化している組込みソフトウェアにC言語だけで取り組んでいるエンジニアに，オブジェクト指向設計やC++などのオブジェクト指向言語を使うと，開発がこんなに楽になるよと伝えたいというのも，この特集記事を書いている理由だ。
0 件のコメント:
コメントを投稿