タグ

dfdに関するkiyo_hikoのブックマーク (7)

  • 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

    Apps/Dia - GNOME Wiki!
    kiyo_hiko
    kiyo_hiko 2016/02/29
    DFDかける
  • Amazon.co.jp業務システムのための上流工程入門―要件定義から分析・設計まで

    Amazon.co.jp業務システムのための上流工程入門―要件定義から分析・設計まで
    kiyo_hiko
    kiyo_hiko 2016/02/26
    "独自の作図法です。DFDは「タイミングを表せない」という欠点をなくし"
  • Amazon.co.jp: :

  • 実践編・第5回 機能情報関連図(DFD)の使い方と論理化

    文・清水惠子(みすず監査法人 シニアマネージャ) 実践編・第4回で機能分析についての説明をした。次のステップでは、分析した機能と情報の関連を分析し、その機能と情報の流れから業務改善を進めることになる。 ■DFDによる機能の流れの見直し-組織の垣根を越えて 実践編・第3回では、「アクションプラン=行動計画」ついて説明したが、行動の目標を実行に移すにあたっては、まず、具体的に行動の対象とした業務についての現状分析が必要となる。機能情報関連図(DFD)を作成する第一の“ご利益”は、業務を実施する際の機能と情報の流れが組織の垣根を超えて一覧できることにある。 現状のDFDを作成する最後の作業である論理化の作業(業務のくくりなおし)を経てから、理想モデルを策定することになる(DFDについては、併せてコラム第4回を参照)。 論理化の作業によって、業務をくくりなおすことにより、情報の流れが整理される。つ

    実践編・第5回 機能情報関連図(DFD)の使い方と論理化
    kiyo_hiko
    kiyo_hiko 2016/02/26
    これ(キモ注意) http://livedoor.blogimg.jp/worldfusigi/imgs/2/e/2e4ef9c8-s.jpg みたいな複雑なダイアグラムが出てきて脱帽した。やっぱしモデリングとデータ・フローをコードやER図だけで考えるのは限界があるな
  • データフロー図 (DFD) の概要

    by Scott W. Ambler, Copyright 2003 データフロー図は1970年代後半に提案され、構造化分析と設計(Gane and Sarson 1979)において普及しました。DFDでは、外部エンティティからシステムへのデータの流れ、プロセスからプロセスへのデータの流れ方、そしてその論理ストレージを表します。図1は、GaneとSarsonの記法によるDFDの例です。シンボルは4つしか出てきません。 四角形は外部エンティティを表します。これはデータの移動元または移動先になります。 角の丸い四角形はプロセスを表します。プロセスは、入力としてデータを受け取り、何かを行なって、それを出力します。 矢印は データの流れを表します。電子データでも物理的なものでもかまいません。 右端の開いた長方形はデータストアを表します。データベースやXMLファイルといった電子的なものも、ファイルキ

    データフロー図 (DFD) の概要
  • プログラム脳を脱却せよ! ~ 【DFDを理解する その1】 | システムエンジニアの戯言

    新テーマ、”プログラム脳を脱却せよ!” 唐突に・・・、そして勢いで新シリーズをはじめてみました。 テーマの推奨読者は、プログラマの方、または新米SEの方です。 (もちろん、それ以外の人にも是非読んで頂ければと思います。) ”プログラム脳”とは、ある機能をプログラムとして具現化する際に、実際のコーディングがどのようになるかを頭の中でイメージする脳力のことです。 これは、プログラムをつくる人間ならば誰もが当たり前に行う作業ですね。 しかし、この”プログラム脳”に依存しすぎると、より抽象的な物事を分析して解釈する脳力の弊害になることがあるのです。 理由をすごく簡単に説明すると・・・、 より抽象的な物事(設計)を物理的に表現した結果がプログラムである。 この物理的な表現技法(順次、条件分岐、繰り返し等)に囚われすぎると、抽象的な物事に対する柔軟な発想が阻害される。 というものです。 (あんまり、

    プログラム脳を脱却せよ! ~ 【DFDを理解する その1】 | システムエンジニアの戯言
  • UMLの問題演習ならシステムアーキテクト | オブ脳@kcg

    システムアーキテクト「専門知識+午後問題」の重点対策〈2010〉 (情報処理技術者試験対策書) UMLの問題演習用として購入しました。 1 UML UML図のうち,以下の★の図法の問題演習ができます。アプリケーションエンジニア試験の頃は主題されたんですが,システムアーキテクトになってからは出題実績がありません。どうもUMLはレベル2とレベル3で出題されるようですね。 機能要件の図 ×ユースケース図    システムがもつべき機能を図示 ★アクティビティ図   ユースケースを行う処理の流れを図示。シナリオとセット 構造図 ★クラス図       業務で用いられる情報の構造を図示。ER図から変換できる ×オブジェクト図    クラス図をインスタンスのレベルで図示 ×コンポジット構造図  構造を持つクラス等の内部構造の協調関係を図示 ×コンポーネント図   プログラムやリソースファイルの構成を図示

    UMLの問題演習ならシステムアーキテクト | オブ脳@kcg
  • 1