謹賀新年

本ブログをお休みして、かれこれ数ヶ月・・・　あっという間に新年を迎えてしまいました。

その間、Interface誌での連載も終了。記事に連動して、ネタを書いていくつもりが．．．ブログ書きは全く追いつかずでした（ネタ切れではありません、決して）。

連載は終了しましたが、ポツポツとこちらでまた書いて行きたいと思います。
そんなわけで、ブログをご覧下さった皆様、今年もよろしくお願いいたします。

状態遷移のAction設計してます？

一ヶ月ブログ更新せずにほったらかしになってしまいました。
ほとんど”やるやる詐欺”ですな。

今日の記事は、前回の「状態って、どうやって抽出します？」の続きにもなります。

状態遷移図で設計した場合、Actionの設計ってどうしています？

むかしの私は、状態遷移図に処理の概要だけをちょこっと書き込み、そのまま実装で作りこんでいました。
そうすると、各状態Action同士の関係をコード上で考えることになってしまいます。簡単な振る舞いならば、それでも良いのですが、システム構造の上位の方で状態制御をしている場合、気がづけば下位の処理間が複雑に絡み合っていた... という困ったことになったこともありました。

『リファクタリングして、直せばいいじゃない』　とも思いました。
しかし、そもそもActionを設計していないので、リファクタリングするときにも、再考する機能構造を表したものが無かったのです。これじゃぁね．．．なるべくしてなった結果かもしれません

リアルタイム構造化分析を、再勉強したときに、「あ～、CFD（制御フローダイアグラム）の分析って、こういうときに有効なのね」と、後から理解しました。

前回Blog記事の状態遷移図と対となる、CFDがこの図です。

右上にある、黒棒が制御バーと言って、制御の集約場所を表します。この中に、状態遷移図が入っていて、このダイアグラム上の処理を統括していることを表しています。
このように、振る舞いと機能分割をそれぞれ別の図に表し、関係性を表せるのが、CFDの良いところです。
状態遷移のActionにあたる部分が、分割したプロセスとして登場します。
こうして、Actionを設計するモデルを残しておけば、下位の処理を検討するときにも、それぞれの機能分担の中で、重複するところ、統合して再構成すべきところ etc. を考えることができるわけです。
また、制御フローが状態遷移を起こすトリガになるため、どこで遷移を起こす要因を作っているかも、モデル図から見て取れます。

状態遷移図で設計する際、別の角度からActionを設計するモデル図を作る。
結構大事なところじゃないかな... と思っています。

今になっては、CFD というと、松尾谷さんの提唱する 原因流れ図（CFD：cause flow diagram） の方が有名かもしれません。 これとは、まったく別物ですので、ご注意ください。

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

状態って、どうやって抽出します？

だいぶ以前から”書く書く”と言っていた、状態遷移図についての話が、Intreface誌の連載第8回でやっと載せました。

この記事でとりあげた例は、UARTの通信制御の状態遷移図です。
UARTで受信するパケットのフォームに応じた状態を設けて、一連の受信制御を行っています。

状態遷移図って、お馴染みの方は割と多いと思います。
では、その皆さんに質問です。状態ってどうやって抽出します？？
状態遷移図を良く使ってはいても、この本質的な問題って、結構難しいと思います。

この記事の本編では、こんなことを書きました。

同じ入力データであっても，事前に何があったかによってプロセスの対応が異なる場合があるのです．このような振る舞いのことを，「順次処理コントロール」と言います．この順次処理は，DFDだけでは表すことが出来ません．このような場合には，状態遷移図を用いてプロセスの振る舞いを捉えたモデルを作成する方が適しています．

今回の例（UART制御）や、画面遷移のように、状態遷移させるイベントの元が明確であり、それらをどう扱うかを切り替えるための”状態値”は割と考えやすいでしょう。
世の中にはそれ以外のモデルも沢山あると思うのですよね。
よく使われている電子ポットの例で考えると．．．
　● 保温中・沸騰中 といった、ユーザから見たシステムの稼動状況で状態を捉える
　● 蓋OPEN ・ CLOSE といった、モノの物理的状況（＝センサの感知状況）などを状態として捉える
というのがあります。

他には、どんな状態抽出の考え方があるのでしょう。
これって、前々から考えていることなのですが．．． 何か文献などあれば、知りたいなと思うのです。
ぜひ、皆さんコメントにて教えていただけると嬉しいです。

最後にクイズ
Interface誌掲載時と、上記の絵には違いがあります。さてどこでしょう？
（紙面を持っている方だけが分かる ... )
あっ、アクションが記入されていることではありませんよ。

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

コード解析にDFDを使う？

最近すっかり、ブログすっかりご無沙汰しておりました。なんと、6月入って初ネタとは... いかんっすね。

さて、今日のお話はリバースモデリングネタです。
このブログでは、リバースのお話するのは初めてですが、実は前から、コードを読んでアーキテクチャ解析をするところに非常に興味を持っています。（．．．というか、ぶっちゃけお仕事も）

2011年6月17日(金)に、派生開発カンファレンス2011というイベントがありました。この講演プログラムの2番目に、
　「完全無知権プロジェクトにおける、変更要求仕様書の作成手法」
といった発表があったのです。
ここで言う”無知見”とは、派生開発元のプログラムについて知見がなく、開発ドキュメントもないような場合（例えば、外注で開発したソフトを扱う場合など）を指しています。つまり、派生開発する際のベースは、コードから読み解くしかないような場合です。
この発表では、コードを読み解く際の調査資料として、階層化DFDとAFD(*)、それとシーケンス図を用いるというものでした。

この方法では、コードから、最初に階層化DFDを作ります。
．．．ん？？　ここで疑問が．．．
コードを読んで、DFDは描けるのか？ コード上のオブジェクト間の関連性は、DFDになるのか??

発表資料をよく見ると、コードからデータフローを読み解き、変更要求仕様の階層化記述に使われています。
どうやら、コード上の構造を表すのではなく、コードを理解した結果の”機能”をDFDで表現したもののようです。
なんとなく、納得です。

DFDを使ったリバース方法については、XDDPの生みの親、システムクリエイツの清水さんが編み出したようです。
とっても気になる方法なので、今後も追跡してみたいと思いました。

(*) AFD：アーキテクチャ・フロー・ダイアグラム(?)
　　下記の本にて登場するモデル図のようです。私も、このモデル図については確認取れていません。
　　リアルタイム・システムの構造化分析　～リアルタイム・システムの仕様書作成手法～
　　Derek J.Haltley (著), Imtiaz A.Pirbhai (著), 立田 種宏 (翻訳)

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

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

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

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

後悔^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月号

WHATで考える練習

プログラムの設計を勉強していると、”WHAT” と ”HOW” という言い方を、よく見かけます。
　WHAT ： 何を　　HOW ： どうやって
プログラムのアルゴリズムを考えるのは、”HOW”。 ですから、プログラムを作ると、必ずHOWは考えます。 しかに、それが ”何を” 実現する目的で作られているか、設計者がそこに注目して思考し、アウトプットしなければ、 WHAT は 見えるモノ として残りません。

連載の2回目の「”いきなりプログラミング”は危険だ」では、　”仕様との関係性が読み取れないコードは危険” といったことを書きました。　HOWでプログラムを作ってしまうと、全体の構造が ”仕様との対応が理解し難い入り組んだ構造（≒スパゲティ状態）” になりやすく、またそうなってしまっていることも気づきにくいのです。

仕様との関係が解るプログラムにすると何が良いのか？
　・ プログラム構造が理解しやすい
　・ 後々、そのプログラムは保守しやすい
　・ 再利用できる場所を考えやすい
2番目以後は、理解しやすいからこそ、使いやすいという二次効果になります。

「イメージ的には解かるけど、本当に？」と思われるかもしれません。
HOW で作ったプログラムと、WHAT で作ったプログラムがどう違うか、システムテスト以後で何か障害が見つかった場合の対策方法を例として考えて見ましょう。

● HOWで考えると．．．

出来上がったプログラムが、HOWで考えられた構造になっている場合、設計図は実装をそのまま絵にしただけなので、「コード見たほうが確実だよ！」といったことになりがちです。そのため、障害が起きたときにも、事象から「コードのどの辺が怪しい」と、開発者は頭の中で辺りをつけて、コードを直接調べているでしょう。

それで、問題箇所が見つかった後も、コード上で修正方法を考えます。そして、他にどんな影響があるのか、工程を遡って、全体を調査するような作業が必要になります。また、修正結果を確認するためにも、修正したコードから必要なテストがどれかを調査し、沢山のテストケースを実行しなければならなくなるでしょう。
といった具合に、調査・修正・確認 のすべての工程がコード基点での考え方になってしまいます。

● WHATで考えると．．．

WHAT で考え出来上がった構造は、仕様からどうプログラム構造に展開したか、さらにどうやって詳細に実装したかが、設計図に残っています。障害が起きたときにも、仕様の中のどれに絡んでその事象が起こっているかを考えれば、自ずと原因調査としてどこにプログラムのどこに焦点を絞るかが考えやすくなっています。

また、それで原因箇所が見つかれば、それに影響を受ける箇所も、またそれらの再確認のためのテストケースがどれかも、仕様を基点として、考えられるでしょう。
それは、WHATで思考した結果、仕様と実装とのつがなりが、設計図として残してあるためです。

ただ、これは開発時にも、保守時にも WHAT で考える癖がないと、途中で破綻してしまいます。
　・ アーキテクチャ設計時に ”WHAT：何を” の塊で作るように、考える。
　・ ”WHAT” で考えた結果を、設計図（＝ 仕様との関連がわかるドキュメント） に残す。
　・ 対策考えるとき、”WHAT：何を” するところに問題があるのか、考える。
　・ 修正するとき、”WHAT：何を” しているところを、どう変更するのか、考える。
　・ 修正確認は、 ”WHAT：何に” ついて確認が必要かを考える。
っと、くどくど書きましたが．．．
伝えたかったこととしては、「常日頃 ”WHAT” 基点で考える癖をつけて、よいプログラム構造が作れるようになりましょう。」　ということでした。

連載記事のほうは、今月発売の2011年6月号から、ちょうど DFD を使って WHAT でプログラムを分析する例をご紹介しています。よかったら、こちらも書店で眺めてみてください。

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