DFDモデル お勧めできない例（その3） - SHIKOU-SAKUGO
前回に引き続き、DFDのアンチパターン紹介第三段です。 今回お見せするモデルは、Interface誌連載第7回のコラム用に当初書いたものでした。が．．．、共著者とレビューの結果、没ネタにしました。そのモデルがこれです。 さて、これはどこが問題か．．． まず、目につくのは真ん中にデータフローの集中しているプロセスがあるところです。 入出力を制御する足回りのプロセスを置いて、変換処理部分は一つのプロセスにまとめてしまっている。これは、分析不足に多くみられる例です。 プログラムが複雑化して、絡み合ってしまうのは、複数の変換部（ここでは ＝機能）が同じデータを使用していたり、出力するために振る舞いによって必要なデータが変わったりするからです。つまりは、この真ん中の変換部が複雑化していきます。なので、このハリネズミ型の症状が現れたら要注意！ その中は、肝心な変換部が分析されておらず、その中にはたくさ
DFDモデル お勧めできない例（その２） - SHIKOU-SAKUGO
# ゴールデンウィークで、先週更新をサボったので、今週は記事二つUPにしました。 またまた、DFDモデルで見たお勧めできない例です。 今回のモデルは、こちら！ 何がお勧めできないポイントかといえば、プロセス間で受け渡しているデータ（青点線で囲んだ所）を見てください。 ”ｘｘｘ完了” って具合のデータが行き来しています。 WHATでプロセスの分割だけを考えると、こういったデータは出てきません。 プロセスの役割分担を表すのではなく、実行順序を示そうとすると、プロセス間に無理やり何か渡そうとして、このようなデータが出てきます。 DFDでは、プロセスの実行順序は表しません。 あくまでも、各プロセスの役割と、プロセス間のデータの流れだけを表しています。 各プロセスは、その○に流れ込むデータを使って、○から流れ出るデータを出力する処理（役割）が成り立てば、他のプロセスとの実行順序がどうでも、 ”知った
DFDモデル お勧めできない例（その１） - SHIKOU-SAKUGO
今回のお話は、ちょっと前回のつづきになります。 前回のblog記事：WAHTで考える練習 未だ構造化設計の認知拡充を図る私としては、WHATのモデルとしてDFDによる分析モデルをちょいちょいご紹介しています。UMLが浸透した今となっては、すっかり忘れ去られた表記法かもしれません。でも、丸と矢印だけで、プロセス（処理のかたまり）の関係を表すこの表記法、とってもシンプルで好きなんです。 忘れ去られるのも悲しいので、コレ使いつづけてます。 さて、Interface6月号では、LEDキューブシステム(*1)のDFDによる分析モデルの例を載せました。 (*1) 開発対象物［LEDキューブシステム］の仕様については、こちらあたりをご覧下さい。 過去blog：組込みソフトウェア開発者にとっての要求仕様書 このLEDキューブシステムを分析したコンテキストと、第一階層のDFD０はこんな感じになります。（雑誌
GREEにおけるJenkins, その4 | GREE Engineering
こんにちは、エンジニアの岡崎(@watermint)です。 今回は、先日行われたJenkinsユーザカンファレンスで発表した内容をもう少し掘り下げて紹介していこうと思います。今回のカンファレンスでは、「開発者とディレクターの視点を変えていく方法」と題してJenkins初期導入時のこつ、その後の運用の改善について説明していきました。今回は特に初期導入の部分についてもう少しご紹介します。 Jenkins導入のコツ Jenkinsを導入したいがなかなか進まないという経験をお持ちの方は多くいらっしゃると思います。CI(継続的インテグレーション)のようなツール群は一度回り始めれば必要不可欠とも思えるような仕組みを持っていますが、利用経験の無い方からすると得られるメリットのイメージが既存の仕事のやり方やワークフローを変えるコストをなかなか超えることが出来ないために積極的になれないということが多いようで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Togetter - まとめ「まとめ「派生開発カンファレンス2010」」