開発方法論のまとめ　３

概要等

先ほどの続きです。

●外部設計（ＵＩ・ＳＳ）

　要求仕様書で、業務プロセス（アクティビティ）レベルにまで落としました。
　落としてなかったら、落としてください。

　そうすると、アクティビティ１個に対しては、

　　　入力があって、
　　　それを処理して
　　　出力する

　という形になっています（入力がなかったり、出力がなかったりすることはあると思います）

　まず、アクティビティに対する入出力を決めてください。

　たいてい、入出力は、こんなものになります。

　　　・画面
　　　・帳票
　　　・ファイル・データベース
　　　・通信ネットワーク（インターネット）

　これらのフォーマットや遷移を定義していくのが、ユーザーインターフェース定義（ＵＩ）になります。

　具体的には
　　　・画面は、画面定義書に
　　　　　　どのような画面から、どのような画面に遷移するかという画面遷移図
　　　　　　各画面のレイアウト図

　　　・帳票は帳票レイアウト図を書きます

　　　・ファイルやＤＢの定義書としては
　　　　　　全体像として、テーブル一覧ないしはＥＲ図
　　　　　　それと各項目ごとの定義
　　　　をかきます。

　　　・通信フォーマットは
　　　　　　各通信のレイアウト
　　　　　　通信の遷移をシーケンス図や状態遷移(図・表）で、

　を書きます。
　このほか、コード定義やエラーメッセージを定義する場合もあります。

        • -

　つぎに、構造設計（ＳＳ）です。
　現在は、とくに画面を使う場合、そのモデルというのがあります。
　おおくはＭＶＣモデル（モデル、ビュー、コントロール）の３層構造を使います

　そして、ＭＶＣを用いる場合、フレームワークというプログラムを作る枠組みがいろいろありますので、
　どのフレームワークを使うかを決定します。

　現在、有名なフレームワークとしては
　　Javaだと、struts,spring,Seasar2など
　 PHPだとCakePHP,Zend,Symfonyなど
　　PythonだとDjangonado
　　　　：
　　　　：
といろいろあります。これを決めてしまうと、おおよそどんな画面をつくって、どんなコントローラーをつくって、どんなエンティティをつくるかというのが決まってしまいます。

      • -

　どう決まるのかというのを、ＩＣＯＮＩＸという方法論で見てみます。

　ＩＣＯＮＩＸを使う場合、以下の手順で書きます

１．ユースケース（アクティビティでもいいけど）にＵＩ（＝画面・帳票など）があるなら、
　　ユースケースごとに、Ｖｉｅｗクラスを規定します

２．概念モデルをもとに、テーブルを作成し、テーブルをもとに、エンティティクラスを発生させます
　　これをエンティティクラスとします。

３．１のＶｉｅｗクラスに対応するコントロールクラスを発生させ、そのコントロールクラスが、
　　２のエンティティクラスを操作するものとします。

４．ここまでのＶｉｅｗクラス、コントロールクラス、エンティティクラスを書きます

５．ユースケースシナリオに沿って、４の各クラスに対し、処理順番を書いていきます
　　→それをコミュニケーション図にまとめます。

６．先ほどいった、フレームワークを決定します。

７．そして、５の各クラスをフレームワークに対応させます。

　富士通の場合、ＵＩとＳＳの図は規定されています。
　そうでない場合は、ＵＭＬを使って表現したりします。

つかれた。やすむ。
ここまであっぷ。