土日ではなくなってしまいましたが（＾＾；）
土日シリーズ「標準ソフトウエア工学教科書」を作ってみたいと思います
今回は、外部設計です。
■３．３ 外部設計
前回、要求分析で要求をだしたので、次に、この要求を満たすシステムを設計していきます。
設計については、ここで、２つに分けて考えます。
１．ユーザーや外部システム等（ユースケースのアクター）で見える部分。
→インターフェース、特にユーザーインターフェース（ＵＩ）
２．ユーザーや外部システム等（ユースケースのアクター）で見えない部分
１は外部に見えるところなので、外部設計、２は、内部部分なので、内部設計となります。
今回は、このうち、外部設計について行います。
------
外部設計に関して、一番大きな部分は、
１．ユーザーとのインターフェースを決める、ユーザーインターフェース
２．他システムがアクセスするＤＢ、ファイル部分
３．Ｗｅｂサービス等の場合、通信部分のインターフェース（引数と返り）
４．２．３の基本となるコード化
画面メッセージを分ける場合もありますけど、それは、１に含まれると、ここでは考えましょう。
２に関して、先ほどの説明だと、他に見えるところだけでもいいのでは？と思うかもしれませんが、このテーブルは見えて、あのテーブルは外部に出さないので、設計しないとなると、検証できなくなってくるので、この場合、外に見えるか否かにかかわらず、全体を設計します。
なお、ユーザーインターフェースとの矛盾をチェックするために、仮に他システムがＤＢ、ファイルにアクセスしないとしても、外部設計でＤＢ、ファイル設計するのが普通だと思います。
なお、４のコード化設計は行うのですが、１、２をしているときに自動的に出来てしまうので、意識して行うのは、１のＵＩ、２のＤＢ，ファイル定義で、最近のＷｅｂサービスにおいて、３を考えるという形です。
なお、以降面倒なので、ＤＢ，ファイル設計と書かずに、ＤＢ設計としてしまいます。
--------------
では、ＵＩ，ＤＢをどのように設計していくかですが、まず、前提について、確認してみます。
前提として、要求仕様では、こんなことをしているのでした。
（１）プロジェクトの目的と、プロジェクトマネージャーは決まっている状態で、
（２）えらい人からえらくない人へ、仕事を分割していく
→その仕事の範囲をざっくりと図や文にまとめる
（３）最終的に、仕事を受け持つ担当者に行き着く
担当者のやるべきことを、入力と出力に着目して、記述する
→機能要求
（４）機能要求以外（非機能要求）を何らかの方法で、えいやときめる（＾＾；）
（５）機能要求、非機能要求を要求仕様書という形でまとめる
つまり、（３）の段階で、入力と出力は、決まっているはずです。
なので、この入出力を検討します。
（あ）（３）の入出力を、画面、帳票、ＤＢなど、メディアごとに分ける。
（い）画面について
（い－１）画面全体のルックアンドフィールを決める
→全体的な画面イメージ
（背景、大きなレイアウト、ナビゲーション等）
（いー２）（あ）で抽出した画面を、１画面にするか、複数のものを
まとめるかなど考慮して、画面割りをきめる。
（い－３）画面をどのように遷移させていくか、画面遷移をきめる
→追加する画面が出てくるかも
（い－４）各画面の画面レイアウトを決める
（い－５）い－３、い－４をまとめて、画面定義書とする
つまり、画面定義書は、画面遷移図と画面レイアウトからなる
（い－６）お客さんにチェックしてもらって、承認を得る
（う）ＤＢについて
（う－１）どのようなテーブルがいるか決める
→正規化したりして
（う－２）テーブルの項目などを決める
（うー３）テーブルの妥当性を確認する
・入力したデータで、必要なものは保存されているか
・容量などの見積もりで、無茶はないか？
帳票に関しては（い）の画面を帳票にかえて読み替えてください。ただし帳票遷移はありえないので、そこは無視します（い－３はない）
Ｗｅｂサービスに関しては、（う）のテーブルをサービスに読み替えてください。
（え：成果物）結果として、画面定義書、ＤＢ定義書、帳票定義書、サービス定義書ができます。
------------
Webアプリケーションの場合、画面をＨＴＭＬで記述しておくと、レイアウトは画面イメージを貼るだけだし、お客さんと確認するとき、ブラウザを使ってプレゼンできます（＝プロトタイプになる）。
このＨＴＭＬで画面をつくるということが、後工程でとても楽になることなのですが、
それは、後工程の話としておいておきます。
上記のやり方だと、画面・帳票のレイアウト、遷移に関しては、この外部設計の段階で確定し、ＤＢはおおよそ決まります（内部設計や実装で変更もありえる）。
ただし、画面設計はそこまでやらないという考えもあります。
項目をこの段階では確定させない（確定できない）という考え方で、その場合、画面定義書は、内部設計でつくられます。
が、この方法の場合、お客さんに見せるのがもっと後になり、画面が内部設計中に動くので、内部設計にダイナミックな修正が入ります。これを嫌う場合、ここ（＝外部設計）で大まかに確定してしまいます。
土日シリーズ「標準ソフトウエア工学教科書」を作ってみたいと思います
今回は、外部設計です。
■３．３ 外部設計
前回、要求分析で要求をだしたので、次に、この要求を満たすシステムを設計していきます。
設計については、ここで、２つに分けて考えます。
１．ユーザーや外部システム等（ユースケースのアクター）で見える部分。
→インターフェース、特にユーザーインターフェース（ＵＩ）
２．ユーザーや外部システム等（ユースケースのアクター）で見えない部分
１は外部に見えるところなので、外部設計、２は、内部部分なので、内部設計となります。
今回は、このうち、外部設計について行います。
------
外部設計に関して、一番大きな部分は、
１．ユーザーとのインターフェースを決める、ユーザーインターフェース
２．他システムがアクセスするＤＢ、ファイル部分
３．Ｗｅｂサービス等の場合、通信部分のインターフェース（引数と返り）
４．２．３の基本となるコード化
画面メッセージを分ける場合もありますけど、それは、１に含まれると、ここでは考えましょう。
２に関して、先ほどの説明だと、他に見えるところだけでもいいのでは？と思うかもしれませんが、このテーブルは見えて、あのテーブルは外部に出さないので、設計しないとなると、検証できなくなってくるので、この場合、外に見えるか否かにかかわらず、全体を設計します。
なお、ユーザーインターフェースとの矛盾をチェックするために、仮に他システムがＤＢ、ファイルにアクセスしないとしても、外部設計でＤＢ、ファイル設計するのが普通だと思います。
なお、４のコード化設計は行うのですが、１、２をしているときに自動的に出来てしまうので、意識して行うのは、１のＵＩ、２のＤＢ，ファイル定義で、最近のＷｅｂサービスにおいて、３を考えるという形です。
なお、以降面倒なので、ＤＢ，ファイル設計と書かずに、ＤＢ設計としてしまいます。
--------------
では、ＵＩ，ＤＢをどのように設計していくかですが、まず、前提について、確認してみます。
前提として、要求仕様では、こんなことをしているのでした。
（１）プロジェクトの目的と、プロジェクトマネージャーは決まっている状態で、
（２）えらい人からえらくない人へ、仕事を分割していく
→その仕事の範囲をざっくりと図や文にまとめる
（３）最終的に、仕事を受け持つ担当者に行き着く
担当者のやるべきことを、入力と出力に着目して、記述する
→機能要求
（４）機能要求以外（非機能要求）を何らかの方法で、えいやときめる（＾＾；）
（５）機能要求、非機能要求を要求仕様書という形でまとめる
つまり、（３）の段階で、入力と出力は、決まっているはずです。
なので、この入出力を検討します。
（あ）（３）の入出力を、画面、帳票、ＤＢなど、メディアごとに分ける。
（い）画面について
（い－１）画面全体のルックアンドフィールを決める
→全体的な画面イメージ
（背景、大きなレイアウト、ナビゲーション等）
（いー２）（あ）で抽出した画面を、１画面にするか、複数のものを
まとめるかなど考慮して、画面割りをきめる。
（い－３）画面をどのように遷移させていくか、画面遷移をきめる
→追加する画面が出てくるかも
（い－４）各画面の画面レイアウトを決める
（い－５）い－３、い－４をまとめて、画面定義書とする
つまり、画面定義書は、画面遷移図と画面レイアウトからなる
（い－６）お客さんにチェックしてもらって、承認を得る
（う）ＤＢについて
（う－１）どのようなテーブルがいるか決める
→正規化したりして
（う－２）テーブルの項目などを決める
（うー３）テーブルの妥当性を確認する
・入力したデータで、必要なものは保存されているか
・容量などの見積もりで、無茶はないか？
帳票に関しては（い）の画面を帳票にかえて読み替えてください。ただし帳票遷移はありえないので、そこは無視します（い－３はない）
Ｗｅｂサービスに関しては、（う）のテーブルをサービスに読み替えてください。
（え：成果物）結果として、画面定義書、ＤＢ定義書、帳票定義書、サービス定義書ができます。
------------
Webアプリケーションの場合、画面をＨＴＭＬで記述しておくと、レイアウトは画面イメージを貼るだけだし、お客さんと確認するとき、ブラウザを使ってプレゼンできます（＝プロトタイプになる）。
このＨＴＭＬで画面をつくるということが、後工程でとても楽になることなのですが、
それは、後工程の話としておいておきます。
上記のやり方だと、画面・帳票のレイアウト、遷移に関しては、この外部設計の段階で確定し、ＤＢはおおよそ決まります（内部設計や実装で変更もありえる）。
ただし、画面設計はそこまでやらないという考えもあります。
項目をこの段階では確定させない（確定できない）という考え方で、その場合、画面定義書は、内部設計でつくられます。
が、この方法の場合、お客さんに見せるのがもっと後になり、画面が内部設計中に動くので、内部設計にダイナミックな修正が入ります。これを嫌う場合、ここ（＝外部設計）で大まかに確定してしまいます。
アクセス
トータル
ランキング
