# 2021.05.12(水)①② [![hackmd-github-sync-badge](https://hackmd.io/OIPBsDRtS6e2X5GCtg-AVg/badge)](https://hackmd.io/OIPBsDRtS6e2X5GCtg-AVg) ###### tags: `SD25` `授業ノート` # 2. 内部設計 外部設計に基づき、どの様にシステムに処理させるかを設計 ## 2.1 内部設計とは ### 2.1.1 目的と留意点 1. 目的 * システムが備えるべき機能と開発者視点で定義 * 各フェーズ(開発段階)の独立性を確保する 2. 留意点 * Why, What, Howの視点で検討を行うこと ### 2.1.2 手順 外部設計書の理解→機能分割・構造化→物理データ設計→入出力設計→内部設計書の作成→デザインレビュー 1. 外部設計書の理解 * 内容をシステムに反映させる 2. 機能分割・構造化 * サブシステム展開で定義された機能をより詳細に分割、各処理の詳細設計を行う→why, what, howで分析 * 構造化 * 詳細機能の洗い出し * プログラム間のインターンフェース * プロセスフローの決定 3. 物理データ設計 * 論理データ設計を基に、 * データベース・ファイルへのアクセス方法 * データベース設計・ファイル編成・レイアウト設計 * <手順> 1. 特性分析 2. 論理編成方法の決定 3. 物理編成形式の決定 4. 記憶媒体の決定 5. データ項目のレイアウト設計 4. 入出力詳細設計 * 外部設計で作成されたイメージを基に、入出力の詳細設計を行う。現在ではGUI環境が当たり前になっているので、自由度は高い * 入力に関しては、キーボードからの入力だけではなく、バーコード、OCR、OMRなどの光学的入力も普及している * 出力に関しては、専用帳票を用いる場合と、汎用用紙を用いる場合とで設計はことなる 5. 内部設計書の作成 * 設計方針 * システム構成 * 画面レイアウト * 入出力レイアウト * ファイル構成 * システム性能 * 結合テストに関するテスト計画 6. レビュー * ユーザーの要求仕様を満たしているか? * 外部設計との一貫性はあるか? * プログラム設計に移行できるか? ## 2.2 機能分割と構造化 ### 2.2.1 分割・構造化の単位 外部設計ではサブシステム単位まで分割したものを、内部設計では、機能を基準としたプログラム単位まで分割する ### 2.2.2 分割・構造化の手順 1. 機能の洗い出し 2. データフローの明確化・・・DFDやバブルチャート 3. 機能のグループ化 各機能の部品化や、再利用に繋がる作業でもある 4. 階層構造化 * 各階層をあまり深くしすぎないこと * 並列する同一階層のプログラムが多くなりすぎないこと 5. プログラム機能の決定 * 階層化の最下段の層について、データフローに着目し、プログラムの処理内容を決定 * なんなら、この時点でソフトウェアの部品を組み込む 6. 分割結果の評価 * 分割することが目的ではなく、必要に応じた分割を行うことが目的 * 何でもかんでもではない * 分割しすぎることで処理効率が悪くなるのはあまり良い分割ではない ※ 機能強度は高める ※ 結合強度は弱める 7. 機能仕様の文書化 各種の図式化手法がありますが、社内標準があるのであればそれに従う。 ### 2.2.3 構造化設計の手法 * 流れ図、DFD,HIPO,構造化チャート、状態遷移図、バブルチャートなどがある 1. 流れ図 * 処理手順・範囲を定義・分析し表現する * [概括/詳細]フローチャートで図式化する 2. DFD * データの流れを中心として図式化する * 利用者には流れ図よりはわかりやすい傾向 3. HIPO(Hierarchy plus Input Process Output) * 設計補助手段 * どちらかと言えば、開発者以外にもわかりやすくするための図式化 * 入力と出力およびその間の処理を記載する 4. 構造化チャート * 分割された各機能を分かりやすく表現するためのもの * 各プログラム間の従属関係を階層構造で表す 5. 状態遷移図 * 処理における状態の移り変わりを図式化する * 画面遷移図とは似てるけど違う 6. バブルチャート * システムやプログラムの分割時などに作成される ## 2.3 物理データ設計 ### 2.3.1 設計手順 1. 特性の分析 * 特徴・用途 * 追加・削除・変更 * 更新 * 仕様形態 * 保守性 ※こういった点を踏まえて考えると、データベースを利用することが最も理にかなっていることが多い 2. 論理編成方式の決定 * 先に物理編成を決定すると面倒になることが多い * 活用範囲 * 一時的なものか? * 随時処理・増加するデータか? 3. 格納媒体の決定 * 現実的に現在では、ハードディスク(SSD含む)が標準的な記憶媒体です * 大規模システムのバックアップ用途などでは、磁気テープシステムも用いられることがあります * アクセス方式によっては、媒体は限られる ##### <容量とアクセス時間の計算> * 論理レコード * プログラムの処理単位 * フィールド設計の対象 * 物理レコード * 記憶媒体の入出力単位 <留意事項> ブロック化係数が「3」であれば、記憶媒体の1ブロック(物理レコード)に3つの「論理レコード」が入っている。 記憶媒体からの入出力は、原則物理レコード単位で行われる。 ### 2.3.2 ファイル設計(データベース設計) 1. レコードレイアウトの設計 ①フィールド設計 * 項目の順番 * フィールドの大きさとデータタイプ * 余白フィールド * コーディングのしやすさを考える ②レコードタイプ * 固定長 * 可変長 * 不定長 ③レコードレイアウト * レイアウト用紙などを用いて設計sする <span style="color: #ff3333">aaa</span> <span style="text-decoration: underline">aaa</span> ## 雑談 (0→やまぴ 1→みや 2→やすい 3→りょうくん) 1.頑張って(笑)