(訳注：2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) 開発者は嫌うでしょう。 ここでは、標準的なコツや策略について書きますが、本当に興味があるのは、別のことです。究極の奇策を見つけたいと思います。策略をひとつずつ試して、プログラミングの聖域に少しでも近づければ良いのですが。 はじめに 私が初めて書いたビデオゲームは、 Ninja Wars （忍者戦争）でした。 そう、これは、画像で埋めたHTMLのtableです。 src 属性を変えることで、動きを実現しています。JavaScriptファイルの冒頭は下記のようになっています。 var x = 314; var y = 8; var prevy= 1; var prevx= 1; var prevsw= 0; var row= 304; var endrow= 142; var sword= 296; v
鈴村さんが指南する業務フロー図の上手な書き方
まずは，業務フローの例を見てみよう。UMLのアクティビティ図で書いたのが（図1）である。スイムレーンに役割を書き，上から下（または左から右）に向かって業務の進行を書いていく。かどの丸い四角形で示したアクティビティが業務プロセスに対応し，矢印で示したフローが業務の流れになる。「誰が何をするか」が明確になる。 よほど定型化されたものでない限り，業務とは複雑なものである。厳密に書こうとすると，業務フローも複雑になりがちである。しかし，分かりやすさを重視するなら，一つの業務フローに登場するアクティビティはせいぜい10～15程度にとどめるべきだ。 複雑なフローを表現したければ，一部の業務フローを別に切り出して，サブ業務フローとして記述すればよい。親の業務フローのある業務プロセスの内部が，サブ業務フローとなっているというように階層化する。 スイムレーンには顧客や営業担当など役割を設定する。「松山さん」
MH Free Software iEdit
iEditは、いわゆるアイデアプロセッサの一種です。ラベルとテキストからなるノードをアイデアを構成する１つの単位とします。iEditではツリー構造とネットワーク構造を用いてノードを組み合わせ、アイデアを練り上げていきます。アウトラインエディタとダイアグラムエディタが融合したものです。 ツリー構造ではノードの追加・削除、レベルの上げ下げなどが自在にできます。ネットワーク構造においては、ツリー上で同一レベルにあるノードが表示されます。ネットワーク構造ではノードの位置と大きさ、フォント、色が自由に設定できます。 ノードとノードの関連はリンクという概念で表現されます。リンクはネットワーク構造においては線と矢印で表現されます。また、リンク先はノードに限らず、ディスク上のファイルやWebのURLなども指定できます。 ネットワーク図はクリップボードで他のアプリケーションに貼り付け可能な他、テキスト、HT
日本IBMのシステム開発プロジェクトで多くの実績を持つDOA（データ中心型アプローチ）型の要件定義手法を解説する。「いまさらDOAか」と思う読者もいるかもしれない。しかし，DOAはあらゆるプロジェクトに応用できる極めて基本的なアプローチである。基本をしっかりと押さえて欲しい。 「いつまでたってもユーザーインタフェースが決まらない」，「設計の段階で機能が追加され，開発範囲が膨れ上がった」，「テスト段階に入ってからも仕様変更が多発する」，「システム・テストの中盤でデータベースが変更され，すべてのテストをやり直さなければならない」…。システム開発ではこうした声があちこちのプロジェクトで聞かれる。なぜこのような状況がいつまでも改善できないのか。結論から言えば，これは要件定義のやり方にそもそもの問題がある。 本来システム開発プロジェクトでは，予算，期間，開発の優先順位に見合った最適なスコープ（開発範
モデリング：XEAD
現在進行中のプロジェクトで、設計の品質や生産性を高めたい．．． 業務知識や上流工程のスキルを身につけてキャリアアップしたい．．． ――そのためのお役立ち情報を揃えています。実務家から高い評価を得ている設計手法、専用の支援ツール、洗練されたモデルライブラリー。これらを駆使して、効率的にシステム設計のレベルアップをはかりましょう。 ニュース 「ＣＯＮＣＥＰＷＡＲＥ／自治体」の開発が始まりました(080420) 「ＣＯＮＣＥＰＷＡＲＥ／販売管理」をバージョンアップしました(080404) 「ＣＯＮＣＥＰＷＡＲＥ／生産管理」をバージョンアップしました(080404) ＸＥＡＤで入出力パネルの画像ファイルを扱えるようになりました(071004) 管理人のブログ「設計者の発言」
木村さんが指南するDFDの上手な書き方
要求定義でDFDを利用する人は多いだろう。しかし，見よう見まねで書かれたDFDに出会うことも多く，業務の真の姿をとらえて構造化できていないケースも少なくない。 使えるDFDを書くにはどうしたらよいか。DFDの特徴に着目すると，上手な書き方が見えてくる。 「誰が」を記載しないこと DFDは，UMLのユースケース図と同様，対象となる業務の範囲を把握するのを主な目的として使われる図である。要求定義の初期段階で，システム化して解決したい問題領域を可視化することができる。要求定義でDFDをうまく書くには，DFDでは何が記述でき，何は記述されないのかをよく知っておくことが大切である。 ユースケース図と比較すると，DFDの特徴が浮かび上がってくる。（図1）の×印（図に記述しない対象）に注目してみよう。共通で×印が付いているのは「処理の順序やタイミング」だ。DFDとユースケース図は，これらが分からなくても
Apps/Dia - GNOME Wiki!
Welcome to Dia's homepage. Dia is a GTK+ based diagram creation program for GNU/Linux, MacOS X, Unix, and Windows, and is released under the GPL license. News! 2011-Dec-18: Version 0.97.2 has been released. Visit the Download page to get your copy! (Download shortcuts: Windows,Mac OS X) Dia is roughly inspired by the commercial Windows program 'Visio,' though more geared towards informal diagrams
データフロー図 - Wikipedia
データフロー図（データフローず、Data Flow Diagram、DFD）は、情報システムのデータの「流れ; flow」をグラフィカルに表現する図である。システム設計段階の初期に描かれることが多い[1]。データフロー図はデータ処理の可視化にも使われる（構造化設計）。 DFDはシステムの入力と出力がどんな情報なのかを示し、データがどこから来てどこに行くのか、どこに格納されるのかを示す。処理のタイミングや逐次的な処理を示すものではない（その用途にはフローチャートなどがある）。一方で、データフローの図というのは依存関係を示すものであるから、互いに影響するような関係にない処理は並列に行えるというような、並行性は表現される。 概要[編集] 一般に設計者は最初にシステムとシステム外部とのやり取りをコンテキストレベルのDFDで描く。その後コンテキストレベルのDFDを「詳細化」してシステムの細部をモデル
「第1回 モデリングなしで開発はできない」は、モデリングという概念の説明と、いかにシステム構築においてモデリングが重要な役割を果たすかというポイントを解説しました。今回は、範囲をシステム構築に狭め、システム構築において利用されるモデリング手法を解説し、その中で、データモデルの果たすべき役割を明確にしていきます システム構築におけるさまざまなモデリング手法 システムを構築する際に必要になるモデルには数多くのものが挙げられますが、大きく分けるとすれば、「システム化をする対象領域」を抽象化したモデルと、「システムそのもの」を抽象化したモデルの2つに分けることができます。 企業で利用する業務システムの場合には、「システム化をする対象領域」とは業務領域ということになり、業務モデルが必要になります。例えば、受注システムの場合には、システムが支援する対象となる受注業務とはどのような業務なのか、その中でシ
データフローダイアグラムの書き方
はじめに これまで作成したデータモデルをもとに，「アプリケーションルール」の作成を行います．「アプリケーションルール」を以下のように定義します． アプリケーションルール エンティティのデータや他のプロセスの出力結果を使い，業務上必要な情報を導き出す方法． データモデルからアプリケーションルールを作るのですから，アプリケーションルールはデータモデルに「依存」します．これに対し，アプリケーションルールはユーザインターフェースからは「独立」します．すなわち，ユーザインタフェースが未定義のままでもアプリケーションルールの設計は可能です．今回も，ユーザインタフェースは未定義です．これは，画面や帳票のレイアウトや操作方法の変更がアプリケーションルールに影響を与えないことを表しています． アプリケーションルールを表す手段としてデータフローダイヤグラム（以下DFDと略記）を使用します．その理由は，データ構
Part2 設計手順の基本を身に付ける
Part2では，多くのシステム開発で実績を持つ日本IBMの「IBM-DOA」に基づく外部設計フェーズの手順を説明する。ここで紹介するDOAに基づく複合／構造化設計手法は，どんなプロジェクトにも応用できる基本的なアプローチだ。基本をしっかりと身に付けてほしい。 DOA（Data Oriented Approach：データ中心型アプローチ）は対象システムの「データの流れ」の把握に重点を置きながら，要件定義や設計を進めていくアプローチである。 DOAには様々なタイプがあるが，日本IBM独自の「IBM-DOA」では，主に業務全体をデータの流れに着目して図で表現するDFD（Data Flow Diagram）を使って業務を分析・設計していく。Part2では，この「IBM-DOA」に基づく外部設計フェーズの進め方を説明しよう。「今さらDOAか」と思わないでほしい。最も基本的で一般的なアプローチなので，
第4回 データの「見える化」ならDFDを使おう
「ずいぶん前に使っていたと，先輩から聞いたことがある」「今はUMLがあるからそんな手法はいらないのでは」――。開発現場で最近，DOA（Data Oriented Approach）についてこんな声を耳にする。確かに，システムの部品化が進んでSOA（Service Oriented Architecture）に注目が集まり，UMLやBPMN（Business Process Modeling Notation）を用いたモデリング手法が広がりを見せている。 しかし，従来から変わっていないことがある。それはすべてのシステムは必ず「データ」を扱うことだ。システムが大きくなればなるほど，扱うデータも多くなる。ここで機能を中心に考えていると，データの漏れや不整合の発生を招き，システム全体を見渡すのが難しくなる。だから筆者は，データの流れの把握と分析に着目したDOAにこだわる。以下では，筆者が実践するD
漂流記
概要 概要（変化に強いシステムの構築方法）2000-12-10 データモデル エンティティとリレーションシップ2000-12-28 エンティティのライフサイクル2001-01-12 アプリケーションルール データフローダイアグラムの書き方2001-01-28 アプリケーションルールの定義2001-02-04 プログラム設計 プログラム設計2001-02-18 その他 ことの経緯 その１2001-03-04 ことの経緯 その２2003-09-21 その他更新：2002-11-24，2002-06-16 作成例：販売・生産・搬送計画立案支援システム 業務概要2001-09-09 データモデル2001-09-16 エンティティのライフサイクル2001-09-30 アプリケーションルール2001-09-23 プログラム設計2001-10-07 各論 データウェアハウス2001-03-25 ファンク
サービス終了のお知らせ
サービス終了のお知らせ いつもYahoo! JAPANのサービスをご利用いただき誠にありがとうございます。 お客様がアクセスされたサービスは本日までにサービスを終了いたしました。 今後ともYahoo! JAPANのサービスをご愛顧くださいますよう、よろしくお願いいたします。
文・清水惠子（みすず監査法人 シニアマネージャ） 実践編・第4回で機能分析についての説明をした。次のステップでは、分析した機能と情報の関連を分析し、その機能と情報の流れから業務改善を進めることになる。 ■DFDによる機能の流れの見直し-組織の垣根を越えて 実践編・第3回では、「アクションプラン＝行動計画」ついて説明したが、行動の目標を実行に移すにあたっては、まず、具体的に行動の対象とした業務についての現状分析が必要となる。機能情報関連図（DFD）を作成する第一の“ご利益”は、業務を実施する際の機能と情報の流れが組織の垣根を超えて一覧できることにある。 現状のDFDを作成する最後の作業である論理化の作業（業務のくくりなおし）を経てから、理想モデルを策定することになる（DFDについては、併せてコラム第4回を参照）。 論理化の作業によって、業務をくくりなおすことにより、情報の流れが整理される。つ
簡単なソフトウェアを作るときには設計書はメモ程度に済ませ、いきなりコーティングやテストを行うこともあります。仕様が簡単なため認識のズレやバグの作り込みの可能性が低いのでメモ程度の設計書でこと足りるからです。 ですが、大規模なソフトウェアを作るときにメモ程度の設計書でソフトウェアの作成を進めることは難しいでしょう。それは、ソフトウェアの作成を依頼する側と、ソフトウェアを作る側に認識のズレが起こる可能性が高いからです。 DFD（データフロー図）はソフトウェア制作を依頼する側と作る側の認識を合わせるツールとして使うことができます。ソフトウェア開発を行うメンバーと、システムのイメージを共有するのにも使え、機能の漏れや重複を防ぐこともできます。 ここではDFDとは何か、そしてDFDの書き方についても紹介します。 DFD（データフロー図）とは 「DFD（データフロー図）」とは、システムにおけるデータの
データフローダイアグラムの書き方
はじめに これまで作成したデータモデルをもとに，「アプリケーションルール」の作成を行います．「アプリケーションルール」を以下のように定義します． アプリケーションルール エンティティのデータや他のプロセスの出力結果を使い，業務上必要な情報を導き出す方法． データモデルからアプリケーションルールを作るのですから，アプリケーションルールはデータモデルに「依存」します．これに対し，アプリケーションルールはユーザインターフェースからは「独立」します．すなわち，ユーザインタフェースが未定義のままでもアプリケーションルールの設計は可能です．今回も，ユーザインタフェースは未定義です．これは，画面や帳票のレイアウトや操作方法の変更がアプリケーションルールに影響を与えないことを表しています． アプリケーションルールを表す手段としてデータフローダイヤグラム（以下DFDと略記）を使用します．その理由は，データ構
http://twitter.com/ckuwata/status/4939817655 : 檜山さんとのミーティングは半分〜 1/4ぐらいは計算機科学の講義なのだが、今日は圏論とデータフローダイアグラムと「真のフローチャート」と「真の goto」についてだった。関連する論文を見つけたので読んでるが、 160p 近い英語論文で早くも泣きが入りつつある。 Kuwataさんが謎のような言葉をつぶやいているのだけど …… フローチャートとgotoについては、「イヂメられて石投げられるから人に話しちゃダメだよ」と言っておいたんだけどなぁ。まーいいや、この機会に述べておこう。おおっと、石投げるのはちょっと待ってよね。 内容： 口にしただけで忌み嫌われる フローチャート研究の歴史（断片） フローノミアルとネットワーク gotoと圏論的なオペレータ 僕の動機と根拠 マゾ・テスト 構文の問題とかナニヤラ
データフロー図 (DFD) の概要
by Scott W. Ambler, Copyright 2003 データフロー図は1970年代後半に提案され、構造化分析と設計(Gane and Sarson 1979)において普及しました。DFDでは、外部エンティティからシステムへのデータの流れ、プロセスからプロセスへのデータの流れ方、そしてその論理ストレージを表します。図1は、GaneとSarsonの記法によるDFDの例です。シンボルは4つしか出てきません。 四角形は外部エンティティを表します。これはデータの移動元または移動先になります。 角の丸い四角形はプロセスを表します。プロセスは、入力としてデータを受け取り、何かを行なって、それを出力します。 矢印は データの流れを表します。電子データでも物理的なものでもかまいません。 右端の開いた長方形はデータストアを表します。データベースやXMLファイルといった電子的なものも、ファイルキ
設計段階でよく利用されるDFD、CRUD、ER図。それぞれ「何のために作成するのか？」「どのように作成するのか？」について紹介します。 そもそも設計書は必要か？ 小規模なソフトウェアの作成であれば簡単なメモ程度の内容で設計を済まし、すぐにテストコード、実処理のコードを書いても良いと思います。設計書よりもきちんと動くソフトウェアのほうが価値があるからです。要求を聞いて、すぐできそうだな(1日でコーディング、テストができそう)と思ったらソフトウェアを作成しユーザに早く評価をもらうことが大事だと思います。設計書を作成すると仕様が変わるたびに書き直す手間もかかるので、要求が頻繁に変わりそうな場合も詳細に作成しないです。 それに対し、規模が大きくてコーディングやテストに何日もかかりそうな場合、時間を確保して設計書を作成します。設計書がないと、一度に複数のことを考えながらコーディングすることになり、バ
データフローDSL考
ニコニコ超会議 2012の超エンジニアミーティングのScalaユーザーグループのコマで「Scalaでプログラムを作りました」のセッションを行いました。昨日の「Scalaへのアプローチ」はそのまとめです。このセッションの主張の一つがScalaの最も重要な用途がDSLであるということです。 3月に要求開発アライアンスでオブジェクト指向モデリングと関数型の関係を検討したセッション『Object-Functional Analysis and Design: 次世代モデリングパラダイムへの道標』を行いました。その内容のまとめは「Object-Functional Analysis and Designまとめのまとめ」となります。ここでは、OOADと関数型の接点としてデータフローが重要というのが結論でした。データフローの実装技術についても「データフローの実装技術」として考察しました。 この2つのセッ
ＥＡの詳細（図表類の説明）＜法規・基準＜Ｗｅｂ教材＜木暮
図をクリックすると拡大図が別ウインドウに表示されます。 政策･業務体系（ＢＡ） 経営戦略の明確化とかビジネスモデルの策定のプロセスです。対象となる業務・システムの範囲と最適化の方向性を優先順位をつけて明確に示す体系です。この体系で作成されるドキュメントには，業務説明書，機能構成図，機能情報関連図，業務流れ図があります。 業務説明書 業務・システムの管理・運用体制や最適化に向けた責任体制を明確化したものです。一般に簡潔な文章で記述されます。以下の文書は，それを具体的に詳細化したものであると位置づけられます。 機能構成図（ＤＭＭ：Diamond Mandala Matrix） 業務機能を階層的に３×３のマトリックスで表現します。中央のマスに業務名を書き，その周囲のマスに中央の業務を構成するサブ業務を，左上から時計周りに業務の順序に合わせて記述します。中央のマスを目的だとすれば，周囲のマスはそれ
新テーマ、”プログラム脳を脱却せよ！” 唐突に・・・、そして勢いで新シリーズをはじめてみました。 本テーマの推奨読者は、プログラマの方、または新米ＳＥの方です。 （もちろん、それ以外の人にも是非読んで頂ければと思います。） ”プログラム脳”とは、ある機能をプログラムとして具現化する際に、実際のコーディングがどのようになるかを頭の中でイメージする脳力のことです。 これは、プログラムをつくる人間ならば誰もが当たり前に行う作業ですね。 しかし、この”プログラム脳”に依存しすぎると、より抽象的な物事を分析して解釈する脳力の弊害になることがあるのです。 理由をすごく簡単に説明すると・・・、 より抽象的な物事（設計）を物理的に表現した結果がプログラムである。 この物理的な表現技法（順次、条件分岐、繰り返し等）に囚われすぎると、抽象的な物事に対する柔軟な発想が阻害される。 というものです。 （あんまり、
Part2 要求定義の方法論を知る
日本IBMのシステム開発プロジェクトで多くの実績を持つDOA（Data Oriented Approach）型の要求定義手法を解説する。DOAはあらゆるプロジェクトに応用できる基本的なアプローチである。 「いつまでたってもユーザーインタフェースが決まらない」，「設計の段階で機能が追加され，開発範囲が膨れ上がった」，「テスト段階に入ってからも仕様変更が多発する」，「システム・テストの中盤でデータベースが変更され，すべてのテストをやり直さなければならない」…。システム開発ではこうした声があちこちのプロジェクトで聞かれる。なぜこのような状況がいつまでも改善できないのか。結論から言えば，これは要件定義のやり方にそもそもの問題がある。 本来システム開発プロジェクトでは，予算，期間，開発の優先順位に見合った最適なスコープ（開発範囲）を早い段階で明確にし，新システムに対する要求仕様を確かなものにしたうえ
DFD
ＤＦＤの内容と書き方 ＤＦＤは、次のような記号で構成します。 データの源泉・行き先は、システムの利用者や外部システムです データストアは、台帳やデータベースです データフローは、伝票やデータ伝送の内容です 処理は、手続きや計算およびデータの変換内容です 記号の記入要領をまとめると次のようになります。 ＤＯＡの開発は、 ４つのモデルを順次作成する 現行物理ＤＦＤ（現状をそのままＤＦＤにすること）の作成要領は、次の通りです。 ①問題記述書を作成して「現状」を記述します。事務フローでもＯＫです。 ②問題記述書から「データのＩＮＰＵＴ元（発生源）」と「データのＯＵＴＰＵＴ先（行き先）を抜き出す。 ③問題記述書から「動詞」を抜き出す。 ④問題記述書から「名詞」を抜き出す。 ⑤問題記述書から「帳票名」を抜き出す。 ⑥「ＩＮＰＵＴ」を発生源、｛ＯＵＴＰＵＴ」を行き先、「動詞」を処理（プロセス）、「名詞」
DFD（でぃーえふでぃー）
データの入出力・流れ・処理の視点から対象世界（システム）の機能や振る舞いを分析・記述するための図のこと。データを処理するプロセスを丸（バブル）で表すため、バブルチャートともいう。 DFDは構造化分析で中心的に使われる分析技法で1970年代後半に提案され、C・ゲイン（Christopher P. Gane）とT・サーソン（Trish Sarson）の共著『Structured Systems Analysis: Tools and Techniques』（1977年）やトム・デマルコ（Tom DeMarco）の『Structured Analysis and System Specification』（1979年）などによって普及した。 機能（データの処理）同士の関係をグラフィカルに表現することにより、システムの構造を明確にする。この機能とはコンピュータによる処理だけではなく、きちんと定めら
プリント基板の検証やデバッグが非常に困難な作業となってきている。部品の高密度実装や、やりとりする信号の高速化が進んでいるからだ。こうした状況に対応するために、プリント基板を開発する際には、検証やデバッグの作業を容易に行えるよう、アクセシビリティを高める工夫を盛り込むことが求められている。 by Ron Wilson “DFD”の必要性 プリント基板（以下、基板）の設計を検証したり、問題点の解析を行ったりする技術者が、ドリルやテスト治具、集束イオンビーム（FIB）などの手段を用いなくても、容易に信号にアクセスできること——この要件を満たすのは、基板設計者の責任の1つである。パッド間が十分に離れており、ICがそれほど複雑なものでなく、信号がより頑強なものであったころは、この要件を実現するのは難しいことではなかった。しかし現在では、基板設計者にとって、このDFD（Design for Debug
VividCar
HOMEトピックス新車速報お買い得限定車イベント情報オーナーズ・レポート企画プレミアムサマー特集今こそチャンス！ 南原流『クルマ逆指名方式』Vivid勝手にランキング!!挑戦！ JAIA2009ムービー発表会＆試乗会ムービーJAIA2日目 小沢＆OG編!!優雅にボートライフ!!これからはセイフティ！ 開校『スバル安全大学』九島辰也のBOAT & レガシィB４飯田裕子のFUN DIVE! FUN DRIVE!オート上海2011 美女写真館2012ちょい乗りインプレ懐かしのリバイバル記事JAPANESE CARBRITISH CARGERMAN CARFRENCH CARITALY CARSWEDISH CARAMERICAN CARKOREAN CAR＋二輪ライフ今すぐお電話!!『Vivid選び抜き中古車ガイド』小沢コージ『貴方もどう？ 好きから始めるクルマ屋さん』森口将之のネオヴィンテージ
●図による分析法はいろいろあるが... UMLを図と考えると，同様なものとして関係データベースを設計するER（Entity Relation）図，構造化分析・設計のDFD（Data Flow Diagram）などがあります．実際，あるアンケートによると，UMLを使い始めたけれどもなじみの深いDFDを手放せずに併用している人の割合は，組み込み関係では20％程度だそうです． DFDは処理手順と処理モジュール（あるいは関数）を同時に考えるときに便利な図です．UMLでこれに対応するものはアクティビティ図になります．あるいは処理手順だけならシーケンス図，処理モジュールはクラス図とオブジェクト図などが対応します． UMLでは目的に特化した図（ダイヤグラム）を何種類も使用してソフトウェアの構造を表現します．UMLは何種類もの図によって定義されている言語なので，DFDのような1種類の図とは異なります．この
SHAPE RECOVERY FROM BLURRED IMAGE USING WAVELET ANALYSIS 1. Introduction Passive technique of ranging or determining distance of object from a camera is an important problem in computer vision. Recently, alternative passive techniques, which are based on focus analysis, have attracted the attention of researchers. First, Depth from Focus (DFF) uses a sequence of images taken by changing t
眠る猫の頁
新着 2024-02-25 歳時記に2024-02-18から2024-02-24までを追加． 備忘録の「Excel」に「[PowerQuery]ヘルパークエリを作らない」を追加． 歳時記 日々の出来事など． 旅行記 旅先での写真や駄文． 漂流記 システム開発への私見． 備忘録 教えてもらったことやできたことを忘れないうちに． 雑録 その他雑多なものが色々． リンク 友人・知合い，便利なソフトウェア，参考になるサイト等． このサイトの詳細については「眠る猫の頁」についてへ．
コンテキストダイアグラム まずはコンテキストダイアグラムである．今回対象となるシステム「オンライン書店」と他システムとのデータのやり取りを整理する．なお，DFDの作成にはMicrosoft Visio Professional 2002を使用した． プロセス「オンライン書店」の内部記述 コンテキストダイアグラムの中のプロセス「オンライン書店」の中身を記述する．プロセス「検索・閲覧」はさらにサブプロセスを持っている．本来であれば，プロセス「データの維持・管理」もサブプロセスに分割すべきであるが，今回はそこまでは行わない． プロセス「検索・閲覧」の内部記述 プロセス「検索・閲覧」の中身を記述する．今回は，このダイアグラムが最下位レベルである．
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
より良いプログラムを書くための究極の奇策 – 「Data first, not code first」 | POSTD
要求定義の方法論を知る【前編】：DOA型要件定義の実際
Amazon.co.jp業務システムのための上流工程入門―要件定義から分析・設計まで
オブジェクトモデリングの基礎としてのデータモデリング
LUMIX GH4の「空間認識AF」は何が凄い? 2枚の画像から合焦方向を計算する“古くて新しい技術”
実践編・第５回 機能情報関連図（DFD）の使い方と論理化
DFD（データフロー図）ってなに？DFDの概要と書き方をあわせて紹介 | Cacooブログ
フローチャートからマゾ・テストまで - 檜山正幸のキマイラ飼育記 (はてなBlog)
http://www.ogis-swe.jp/process/am-res/am/artifacts/dataFlowDiagram.html
設計スキル : DFD、CRUD、ER図の目的と書き方 | DN-Web64
プログラム脳を脱却せよ！ ～ 【DFDを理解する その１】 | システムエンジニアの戯言
プリント基板のアクセシビリティを高める | EDN Japan
UMLを基礎から理解する ――UMLでできること，できないこと
Depth from Defocus using Wavelet Analysis
アプリケーションルールの定義（トランザクショナルファンクションの元ネタ）