ソフトウェアには”遊び”がない

以前に書いた、「静的×動的視点で分析する」を書いてみました の続きの話になります。

この時には、構造化設計技法だって、「静的な側面、動的な側面をそれぞれ考え、両方が上手く一つの構造物で実現できるように考えるのが、設計」ということを言いたくて書きました。
それについて反響をいただいた中で、この記事がとても興味深かったので、さらにそれに続けて、私の考えたことを書きたいと思います。

特に、気になった部分を引用します。

後悔^H^H公開日記：別館　：　設計と実装における「動的」　より
・・・前略・・・
以上のように考えると，機械または建築と状態遷移に着目した場合のソフトウェアは，共に "動く"．しかしこれらの間には違いがある．
機械または建築の可動部には，"遊び"があり，また他のマクロの物理条件の影響を受けやすい．人が普通に暮らせる範囲の温度や湿度で，ドアが開きづらくなったりする．"完璧な歯車は回らない"というのは機構設計をするかたの基礎知識でもあろう．
一方，状態遷移に着目した場合のソフトウェアは，引用元の主張とは異なる特質を持つと私は考える．
「ソフトウェアの挙動には"遊び"が無く，ほぼ100%の再現性で動作する．」

なるほど・・・この表現は、目から鱗って感じでした。

確かに、ソフトウェアは条件が揃えば絶対再現できます。
しかし、ソフトウェアを作られた方なら実感されていると思いますが、その再現をさせるのが大変なのですよね。
なぜならば．．． プログラムを動かす沢山のパラメタをすべて把握して、その条件の組み合わせを見極めないと、再現ができないからです。

そこで、ハタッと思ったのが 「ソフトウェアは”遊び”がないから、これらが重要なんだ！ 」 …と。

一つは、テストです。
機械であれば、遊びを設けて物理的に調整できない誤差は吸収されます。しかし、遊びのないソフトウェアはピッタリ・ピッタリの境界を見極めて、結果の ○ × をハッキリさせておかなければならないのです。そうでなければ、”想定外” なんて動作が起こってしまいます。
実は、最近私自身がソフトウェア・テストを勉強しています。できるだけ ”想定外”をなくすように、しっかりソフトウェアの動作を保障するのは、すごく、すごく、すっご～く難しい ということを、今さらながら実感中です。

そして、もう一つ改めて思ったのが、アーキテクチャ設計の大切さです。
アーキテクチャでしっかり、どこが可動部の接点となるかを見極める。接点を明確にし、各部の関係を疎に保つ。インタフェースを各部の窓口に集約し、やたらといろいろな部分との関係を作らない。
そして、その可動部が解るからこそ、結合テストで、遊びのなさを潰すことができる。
振り返って考えれば、設計の基本そのままですね～。

．．．と、最終的には設計、テストの大切さを改めて実感した。
という、なんかありきたりの〆でした。 m(.￣　￣.)m

「静的×動的視点で分析する」を書いてみました

ちょうど明日(5/25)発売のInterface誌7月号、いつもの連載記事でこんなサブタイトルの内容を書きました。
　　連載：強いプログラムを作るテクニックを学ぶ
　　サブタイトル：静的×動的視点で分析する。

UMLなどで、モデル図書いて設計しているひとには、「また、当たり前のこと。。。」と思われるのではないでしょうか。
そうなんです、ソフトウェアを設計するには当たり前なのですよね。

ソフトウェアの論理設計を考えるとき、よく機械や建築の設計図に喩えて説明されます（私も連載最初の方で使いました）。しかし、機械や建築物と性質的にまったく異なるのは、ソフトウェアは”動く”のです。そして、作った構造物（もしくは部品）はいつも同じ動きをするとは限らず、時間や環境などによって、まったく別の動きをすることもあるのです。
これって、実生活のモノにはとても喩えることができない特徴ではないでしょうか。
ソフトウェアの開発って、そんな小難しいものを作っているのです。
それを、頭の中だけで形作れるわけはない．．．と、凡人の私なぞは思います。

その”動く”という特徴を分析しなければ、ソフトウェアの設計としては片手落ちです。静的な側面、動的な側面をそれぞれ考え、両方が上手く一つの構造物で実現できるように考えるのが、設計なのですよね。

さて、最近ではソフトウェア工学書籍の出版数も増え、設計についての色々な考え方の本があります。UMLで静的モデルと動的モデル、それぞれの特徴に会った図が用意されたこともあり、静的×動的の両面を考えることも、だいぶ浸透してきていると思います。
しかし、本連載で取り上げている構造化分析・設計について、そのような説明をしている本を見かけないと思うのです。

この連載記事執筆の話をいただいたときに、「構造化で、静的×動的って話を絶対に書かなくては。」 と思っていました。順番に書き進み、第7回にしてやっとここに辿りつけた次第です。
この回は、何かの方法論に基づきというのではなく、自分の考えるままに書いたものです。
よければ、皆さんのご意見をお聞かせいただければ、嬉しいです。
私のtwitter ID：Yuko_Ski 宛てにコメントでもOKです。ぜひ、よろしくです。

p.s. その１
構造化設計で、動的分析を一緒に説明している本などあれば、ご紹介ください。

p.s. その２
今月は掛けませんでしたが、状態遷移についても、この後記事かする予定です。（．．．ってさりげに宣伝？）

DFDモデル お勧めできない例（その3）

前回に引き続き、DFDのアンチパターン紹介第三段です。

今回お見せするモデルは、Interface誌連載第7回のコラム用に当初書いたものでした。が．．．、共著者とレビューの結果、没ネタにしました。そのモデルがこれです。

さて、これはどこが問題か．．．
まず、目につくのは真ん中にデータフローの集中しているプロセスがあるところです。
入出力を制御する足回りのプロセスを置いて、変換処理部分は一つのプロセスにまとめてしまっている。これは、分析不足に多くみられる例です。

プログラムが複雑化して、絡み合ってしまうのは、複数の変換部（ここでは ＝機能）が同じデータを使用していたり、出力するために振る舞いによって必要なデータが変わったりするからです。つまりは、この真ん中の変換部が複雑化していきます。なので、このハリネズミ型の症状が現れたら要注意！
その中は、肝心な変換部が分析されておらず、その中にはたくさんの役割が隠されているでしょう。

もうひとつ、この図で軽く注意をしてほしいのが、”メイン”部という名称です。
プログラムを作っていると、『メイン関数があり．．．』 から考え始めてしまいます。でも、システムの担う役割で考えたときに、”メイン”って何ですか？？よ～っく考えてみましょう。
それぞれの役割分担が解るように、分析により分割・階層化を考えているのに、ＴＯＰレベルに何しているかわからないプロセスがドーンと構えているって、とっても変です。このところ続けて言っている ”ＷＨＡＴ” でちゃんと考え直してみましょう。

※　関連記事：　Interface 2011年6月号

DFDモデル お勧めできない例（その２）

# ゴールデンウィークで、先週更新をサボったので、今週は記事二つUPにしました。

またまた、DFDモデルで見たお勧めできない例です。
今回のモデルは、こちら！

何がお勧めできないポイントかといえば、プロセス間で受け渡しているデータ（青点線で囲んだ所）を見てください。
”ｘｘｘ完了” って具合のデータが行き来しています。

WHATでプロセスの分割だけを考えると、こういったデータは出てきません。
プロセスの役割分担を表すのではなく、実行順序を示そうとすると、プロセス間に無理やり何か渡そうとして、このようなデータが出てきます。

DFDでは、プロセスの実行順序は表しません。
あくまでも、各プロセスの役割と、プロセス間のデータの流れだけを表しています。
各プロセスは、その○に流れ込むデータを使って、○から流れ出るデータを出力する処理（役割）が成り立てば、他のプロセスとの実行順序がどうでも、 ”知ったこっちゃない” というのが、原則なのです。(*1)

この例のように、ｘｘｘ完了 とか ｘｘｘ指示 といったフラグっぽいデータ名が出てきたら、要注意です。
また、そのデータを入力されたプロセスの中を考えてみると、役割を果たすためにはそれは必要ない。たんなる起動のきっかけになっていることで多いでしょう。

繰り返しますが．．．
DFDは、フローチャートや、アクティビティ図ではないので、処理の順序は表しません。
この例のようなデータが現れてきたら、やはり HOW で考えてしまっている兆候なので、お気をつけくださいませ！

(*1)
どうしても、プロセス間の実行順序を表現したい場合があります。
そのために CFD（Control Flow Diagram）という表記法がありますが、これは難しいので今回は触れていません。

※　関連記事：　Interface 2011年6月号

DFDモデル お勧めできない例（その１）

今回のお話は、ちょっと前回のつづきになります。
前回のblog記事：WAHTで考える練習

未だ構造化設計の認知拡充を図る私としては、WHATのモデルとしてDFDによる分析モデルをちょいちょいご紹介しています。UMLが浸透した今となっては、すっかり忘れ去られた表記法かもしれません。でも、丸と矢印だけで、プロセス（処理のかたまり）の関係を表すこの表記法、とってもシンプルで好きなんです。
忘れ去られるのも悲しいので、コレ使いつづけてます。

さて、Interface6月号では、LEDキューブシステム(*1)のDFDによる分析モデルの例を載せました。
(*1) 開発対象物［LEDキューブシステム］の仕様については、こちらあたりをご覧下さい。
　過去blog：組込みソフトウェア開発者にとっての要求仕様書

このLEDキューブシステムを分析したコンテキストと、第一階層のDFD０はこんな感じになります。（雑誌掲載済み）

これらは、何度か描きなおして、出来上がった結果のDFDです。
この形におさまるまで、4, 5回は、機能の分割、グループ分け、再統合．．．を繰り返しています。

6月号には、もう一つアンチパターンとして、こんなモデルを載せました。

この例は、HOWで考えてしまった典型例なのですね。
どこがって．．． 左上にある 「100msタイマ割り込み処理」 があるところです。
これって、
　どうやってプロセスを順番に動かそう．．．、
　どうやってアレと、コレ同期させよう．．．
どうやって．．．（＝HOW) を考えないと、この タイマ割り込みドリブン な分割にはならないのです。

手続き型の言語によるプログラミングになれた人ほど、これはやってしまいがちです。

タイマ割り込みプロセスをDFDモデルに登場させないというのは、タイマ割り込みを使ってはいけないということではないですよ。
プロセス分割した結果、それらを動かす仕組みとして、タイマ割り込みを使うのはOKなんです。でも、タイマ割り込みはあくまでもプロセスを動かす仕組みであり、それ自身が要求仕様に紐付いた役割を担ったものではないということに、注意しましょう。

Whatによる思考に慣れない場合、まずこのタイマ割り込みドリブンを頭に思い浮かべずに、機能分割してモデルを書いてみる。　そんなところから、初めてみるのも、一つ手だと思いますよ。

※　関連記事：　Interface 2011年6月号