カテゴリー「構造化分析・設計」の記事

2011年8月 4日 (木)

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

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

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

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

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

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

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

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

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

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

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

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

2011年7月 4日 (月)

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

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

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

Uart

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

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


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

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

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


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

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


2011年5月24日 (火)

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

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

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

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

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

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

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

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

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

2011年5月17日 (火)

DFDモデル お勧めできない例(その3)

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

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

Dfd_

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

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

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

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

2011年5月 9日 (月)

DFDモデル お勧めできない例(その2)

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

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

Dfd0_

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

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

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

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


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

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

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

2011年5月 8日 (日)

DFDモデル お勧めできない例(その1)

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

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

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

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

Photo

Dfd0










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


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

Dfd0_timer

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

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

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


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

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