ここ
SDN解体新書 新しいIPネットワークの幕開け
伊勢 幸一 (著)
http://airbook.jp/AirSIN/31895
この著者で、この表題で、読みたい１冊です。
Ｐ．Ｓ 本当にある本では有りません。
SDN解体新書 新しいIPネットワークの幕開け
伊勢 幸一 (著)
http://airbook.jp/AirSIN/31895
この著者で、この表題で、読みたい１冊です。
Ｐ．Ｓ 本当にある本では有りません。
シリーズ無料の論文管理＆bib書き出しソフトMemdeley － 移動先でも
のつづき
前回は、Memdeleyをインストールしました。
今回は、論文を登録してbibファイルを作るまで。
■論文を登録する
まず、Mendeleyを立ち上げると、こんなかんじになる。
真ん中のところに、論文のＰＤＦをドラッグ＆ドロップすれば、追加される
■論文を削除する
削除したいときは、削除したいものを選択して、
右ボタンクリックまたは
左上の
Delete Documentをクリック
■登録内容を変更する
登録内容を変更したい場合は、選択すると、右にいろいろでてくるので、
そこをクリック。編集できるので、編集する
（他のところをクリックすると、内容が確定）
■論文を見る
選択したところをダブルクリックすると、論文が立ち上がる
■bibにかきだす。
File→exportを選択すると
ダイアログが出て、bibが書き出される
きょうは、ここまで
のつづき
前回は、Memdeleyをインストールしました。
今回は、論文を登録してbibファイルを作るまで。
■論文を登録する
まず、Mendeleyを立ち上げると、こんなかんじになる。
真ん中のところに、論文のＰＤＦをドラッグ＆ドロップすれば、追加される
■論文を削除する
削除したいときは、削除したいものを選択して、
右ボタンクリックまたは
左上の
Delete Documentをクリック
■登録内容を変更する
登録内容を変更したい場合は、選択すると、右にいろいろでてくるので、
そこをクリック。編集できるので、編集する
（他のところをクリックすると、内容が確定）
■論文を見る
選択したところをダブルクリックすると、論文が立ち上がる
■bibにかきだす。
File→exportを選択すると
ダイアログが出て、bibが書き出される
きょうは、ここまで
シリーズ「ZendにおけるMVC（Javaフレームワークとの違い）」の続き
前回Ｊａｖａとの比較をした。
今回は、このシリーズの最後として、要件定義が決まってから、実装までの流れを
・一般的な設計の流れ
構造化手法
オブジェクト設計
・ウェブ戦略としての「ユーザーエクスペリエンス」―5つの段階で考えるユーザー中心デザインに基づいた流れの２とおりで紹介する。
■一般的な開発の流れ：構造化手法
-----------Ｚｅｎｄに関係ないところ
１．システムが大きすぎる場合、どんな機能が必要か考えて詳細化する
→ＤＭＭが使える。もちろんマインドマップでもいい
→この時点でＭＥＣＥにしようとすると、躓くので、まあ、ざっと挙げる程度でよい
２．ＤＦＤを使って詳細化する
一番初め、このシステムの入出力を考え、真ん中に開発するシステムを書き、
入出力をつないでいく→コンテキストダイアグラム
そうしたら、コンテキストダイアグラムの中を埋めていく。ＤＭＭを参考にしたり、
う～んと唸りながら？考える。
このとき、
・どんなプロセスがあるか
・入出力は何か（ＤＢないしファイル）
というのを注意して書く。
もちろん、ＤＦＤの記法や決まりに則って書く
コンテキストダイアグラムから、いくつかのプロセスをＤＦＤで書いたら
今度はそのプロセスの内部を、（新たなＤＦＤとして）書いていく
そして、
ある画面から入力し、ＤＢやファイル、帳票に書き出すプロセス
（いわゆるアクティビティ）レベルにまで、ＤＦＤを落とし込む
３．業務流れ図を書く
上記のＤＦＤのプロセスは、どの順番で動かすかは、書かれていないので、
ある業務において、どんな画面から入力し、どうＤＢに書き出され、どうなるか
という業務流れ図を書く。
→つまりここで、画面と帳票名はでてくる。ただし、１画面という区切りではなく、
画面群になる。たとえば、受注画面というのは出てくるが、実際は受注画面群であり、
受注画面は
受注検索
受注一覧
受注編集
確認画面
などから構成されるということが多い。
４．画面定義、帳票定義を行う
業務流れ図の中に、画面と帳票が書かれているはずである。
そこで、その画面を元に、ユーザーとどんな画面レイアウトで、どのように画面遷移
するか決める
また、帳票を出す場合、どのような帳票レイアウトにするか決める。
ここで、入出力項目は決定する。
５．入出力項目をもとにテーブル設計を行う
入出力項目がわかったので、それをどのようにテーブルに格納するかきめる。
ＲＤＢであれば、正規化手法を使うことによって、テーブルは決められる。
-----------ここからＺｅｎｄに関係
６．画面定義をもとに、viewのスクリプトファイルを作成し、
それをもとにコントローラーを作成、
画面が遷移するかどうかたしかめる。
くわしくは、
ZendにおけるMVC（Javaフレームワークとの違い）その３
http://blog.goo.ne.jp/xmldtp/e/d0d71cc1e7ebe06ece0d2d4c81566aca
７．このコントローラーから呼ばれるアクションに対応するモデル部分の
ビジネスロジックを作成し、ビジネスロジックにダミーデータを入れて、
動くかどうか確認する。
８．テーブル定義をもとにＤＡＯを作成する。
ここまでのモデル作成の流れ、くわしくは
ZendにおけるMVC（Javaフレームワークとの違い）その５
http://blog.goo.ne.jp/xmldtp/e/97742540f6d398d6e15171baf6669496
９．ビジネスロジックから、ＤＡＯを呼び、業務ロジックを組み立てていき、実装を
完了させる。
■ウェブ戦略としての「ユーザーエクスペリエンス」の流れ
ここ
Web構築のワークフロー
http://www.doburoku.com/wiki/index.php?Web%B9%BD%C3%DB%A4%CE%A5%EF%A1%BC%A5%AF%A5%D5%A5%ED%A1%BC
を参考に・・・
・戦略
上記の「一般的な開発の流れ：構造化手法」では省略した。
超上流部分。この開発はなぜするかということについてなど。
・要件
上記１．２．３までの作業。
ただし、上記は機能要件だけで、非機能要件や制約（blogにするとかは、本来設計で
決めていいことに対して、縛りを入れることになるので、制約になってくる）も決める
・構造
４．の画面定義における画面遷移・・だと思う。
・骨格
４．の画面設計における画面レイアウトの大まかな部分だと思う
・表層
４．の画面設計がレイアウトまで含めて完成する？
そのあと、５以降を行うことになる。
■一般的な開発の流れ：オブジェクト指向分析
・構造化手法の１．２．に相当する部分を行う
ユースケースを作成する。
アクターは出てくるが、データ関係は出てこない。
ＤＦＤのプロセスが、ユースケースとなってくるが、
ユースケースは、アクティビティにいく「前で」止める
・構造化手法の３に相当する部分を行う
アクティビティ図を書く。
アクティビティ図は、原則、あるユースケースに対するアクティビティ図を書く
ことになる（＝対応するユースケース図がある）。
ただし、アクティビティ図には、画面やＤＢを書くところはない。
（オブジェクト指向分析では、この段階では、物理的な層は抽象化されているから）
そこで、オブジェクトノードで画面やＤＢを書くか、
対応するユースケース図のユースケース記述の中で、画面、ＤＢ、帳票など、
入出力を自然言語で書く。
・オブジェクト指向の場合・・・
クラス図を書くのが好きなので（＾＾；）
ここで、概念クラス図を書いてしまうことが多いと思う。
・構造化手法の４．５を行うのであるが・・・
画面定義書などを作らず、画面をhtmlで記述し、画面遷移をそのhtmlから行う
ことも多い。
こうすると、このhtmlが、実装で再利用できることもある。
・以降の手順は同じ。
→注意：概念クラス図を書いてしまい、画面をhtmlで適当に作ってしまうと、
画面の入出力が、概念クラス図のデータだけで、本当にできるかどうかの
確証がとれていない（っていうか、たいてい足りないはず）
これをウォークスルーで補完するわけだが、アジャイルなどで、五月雨式に
決まっていく場合、どこで確認を取るか、あらかじめ考えていないと、
矛盾だらけになる。
このしりーず、おしまい。
前回Ｊａｖａとの比較をした。
今回は、このシリーズの最後として、要件定義が決まってから、実装までの流れを
・一般的な設計の流れ
構造化手法
オブジェクト設計
・ウェブ戦略としての「ユーザーエクスペリエンス」―5つの段階で考えるユーザー中心デザインに基づいた流れの２とおりで紹介する。
■一般的な開発の流れ：構造化手法
-----------Ｚｅｎｄに関係ないところ
１．システムが大きすぎる場合、どんな機能が必要か考えて詳細化する
→ＤＭＭが使える。もちろんマインドマップでもいい
→この時点でＭＥＣＥにしようとすると、躓くので、まあ、ざっと挙げる程度でよい
２．ＤＦＤを使って詳細化する
一番初め、このシステムの入出力を考え、真ん中に開発するシステムを書き、
入出力をつないでいく→コンテキストダイアグラム
そうしたら、コンテキストダイアグラムの中を埋めていく。ＤＭＭを参考にしたり、
う～んと唸りながら？考える。
このとき、
・どんなプロセスがあるか
・入出力は何か（ＤＢないしファイル）
というのを注意して書く。
もちろん、ＤＦＤの記法や決まりに則って書く
コンテキストダイアグラムから、いくつかのプロセスをＤＦＤで書いたら
今度はそのプロセスの内部を、（新たなＤＦＤとして）書いていく
そして、
ある画面から入力し、ＤＢやファイル、帳票に書き出すプロセス
（いわゆるアクティビティ）レベルにまで、ＤＦＤを落とし込む
３．業務流れ図を書く
上記のＤＦＤのプロセスは、どの順番で動かすかは、書かれていないので、
ある業務において、どんな画面から入力し、どうＤＢに書き出され、どうなるか
という業務流れ図を書く。
→つまりここで、画面と帳票名はでてくる。ただし、１画面という区切りではなく、
画面群になる。たとえば、受注画面というのは出てくるが、実際は受注画面群であり、
受注画面は
受注検索
受注一覧
受注編集
確認画面
などから構成されるということが多い。
４．画面定義、帳票定義を行う
業務流れ図の中に、画面と帳票が書かれているはずである。
そこで、その画面を元に、ユーザーとどんな画面レイアウトで、どのように画面遷移
するか決める
また、帳票を出す場合、どのような帳票レイアウトにするか決める。
ここで、入出力項目は決定する。
５．入出力項目をもとにテーブル設計を行う
入出力項目がわかったので、それをどのようにテーブルに格納するかきめる。
ＲＤＢであれば、正規化手法を使うことによって、テーブルは決められる。
-----------ここからＺｅｎｄに関係
６．画面定義をもとに、viewのスクリプトファイルを作成し、
それをもとにコントローラーを作成、
画面が遷移するかどうかたしかめる。
くわしくは、
ZendにおけるMVC（Javaフレームワークとの違い）その３
http://blog.goo.ne.jp/xmldtp/e/d0d71cc1e7ebe06ece0d2d4c81566aca
７．このコントローラーから呼ばれるアクションに対応するモデル部分の
ビジネスロジックを作成し、ビジネスロジックにダミーデータを入れて、
動くかどうか確認する。
８．テーブル定義をもとにＤＡＯを作成する。
ここまでのモデル作成の流れ、くわしくは
ZendにおけるMVC（Javaフレームワークとの違い）その５
http://blog.goo.ne.jp/xmldtp/e/97742540f6d398d6e15171baf6669496
９．ビジネスロジックから、ＤＡＯを呼び、業務ロジックを組み立てていき、実装を
完了させる。
■ウェブ戦略としての「ユーザーエクスペリエンス」の流れ
ここ
Web構築のワークフロー
http://www.doburoku.com/wiki/index.php?Web%B9%BD%C3%DB%A4%CE%A5%EF%A1%BC%A5%AF%A5%D5%A5%ED%A1%BC
を参考に・・・
・戦略
上記の「一般的な開発の流れ：構造化手法」では省略した。
超上流部分。この開発はなぜするかということについてなど。
・要件
上記１．２．３までの作業。
ただし、上記は機能要件だけで、非機能要件や制約（blogにするとかは、本来設計で
決めていいことに対して、縛りを入れることになるので、制約になってくる）も決める
・構造
４．の画面定義における画面遷移・・だと思う。
・骨格
４．の画面設計における画面レイアウトの大まかな部分だと思う
・表層
４．の画面設計がレイアウトまで含めて完成する？
そのあと、５以降を行うことになる。
■一般的な開発の流れ：オブジェクト指向分析
・構造化手法の１．２．に相当する部分を行う
ユースケースを作成する。
アクターは出てくるが、データ関係は出てこない。
ＤＦＤのプロセスが、ユースケースとなってくるが、
ユースケースは、アクティビティにいく「前で」止める
・構造化手法の３に相当する部分を行う
アクティビティ図を書く。
アクティビティ図は、原則、あるユースケースに対するアクティビティ図を書く
ことになる（＝対応するユースケース図がある）。
ただし、アクティビティ図には、画面やＤＢを書くところはない。
（オブジェクト指向分析では、この段階では、物理的な層は抽象化されているから）
そこで、オブジェクトノードで画面やＤＢを書くか、
対応するユースケース図のユースケース記述の中で、画面、ＤＢ、帳票など、
入出力を自然言語で書く。
・オブジェクト指向の場合・・・
クラス図を書くのが好きなので（＾＾；）
ここで、概念クラス図を書いてしまうことが多いと思う。
・構造化手法の４．５を行うのであるが・・・
画面定義書などを作らず、画面をhtmlで記述し、画面遷移をそのhtmlから行う
ことも多い。
こうすると、このhtmlが、実装で再利用できることもある。
・以降の手順は同じ。
→注意：概念クラス図を書いてしまい、画面をhtmlで適当に作ってしまうと、
画面の入出力が、概念クラス図のデータだけで、本当にできるかどうかの
確証がとれていない（っていうか、たいてい足りないはず）
これをウォークスルーで補完するわけだが、アジャイルなどで、五月雨式に
決まっていく場合、どこで確認を取るか、あらかじめ考えていないと、
矛盾だらけになる。
このしりーず、おしまい。
ウィリアムのいたずら @xmldtp
アクセス
トータル
ランキング
