![構造化プログラミング
n構造化定理
• すべてのプログラムは順次・選
択・反復の3つの制御構造だけで記
述できる[Knuth, 1974] [Linger,
Mills & Wit, 1978]
n構造化プログラミング
• 構造化定理に従ったプログラムの
書き方
• 現代的な言語のほとんどが採用
n歴史
• 初期の言語は任意の位置へ処理を
移動できるgoto文を持っていた
• アセンブリ言語，BASIC,
FORTRAN(66, 77, 90), etc
• goto文有害説 [Dijkstra, 1968]
• スパゲッティコードの原因
• 構造化プログラミングの誕生
• 現代的な言語の多くがgoto文を
持たない
• FORTRANも95で削除
• 持つものもある：Go，C++
• ゆるコンピュータ科学ラジオ, プログラミング言語にも歴史の転換点がある
【プログラミングパラダイム・シフト1】#64, 2023/03/19
• ゆるコンピュータ科学ラジオ, 構造化プログラミングが、混沌だったフロー
チャートに秩序を与えた【プログラミングパラダイム・シフト2】#65,
2023/03/26
Graphical representation of the three basic patterns — sequence, selection, and
repetition — using NS diagrams (blue) and flow charts (green)., CC0](https://image.slidesharecdn.com/202303-231007115033-0be4435c/85/2023-03-30-320.jpg)
ソフトウェア工学2023 03 下流工程
- 3. ウォーターフォールモデル nライフサイクルを滝に見立て た開発モデル • 最初の方が上流工程 • 後のほうが下流工程 n一つの工程での成果物を次の 工程へ引き継ぐ • 例：外部設計は，要件定義書を 引き継いでから開始 要件定義 外部設計 内部設計 実装 テスト 運用・保 守 要件定義書 外部設計書 内部設計書 プログラム 上 流 工 程 下 流 工 程 成果物 システム
- 4. 内部設計
- 5. 外部設計と内部設計 n設計：外部設計，内部設計 • 定義された要件からプログラム仕様を作り出す工程 n外部設計 • 基本設計，物理設計とも呼ばれる • 要件定義書をもとに，どのようなシステムとして実現するかを設計 • 外部システムとのインターフェースを定義 • 外部設計書，システム仕様書を成果物として作成 n内部設計 • 詳細設計，論理設計，プログラム設計とも呼ばれる． • 外部設計書をもとに，機能をどのように実現するのかを設計 • システム内部のモジュール間のインタフェースを定義 • 内部設計書，プログラム仕様書を作成
- 7. 開発 nプログラミング（開発）は内部仕様書・プログラム仕様書に基づく n使われる言語やフレームワークはシステムによって異なる • 言語：Java, JavaSript, C, C++, C#, Ruby, Python, Go, Rust, Kotlin, Swift, MATLAB, etc • フレームワーク，ライブラリ • 言語依存：Rails（Ruby，web），Node.js（JavaScript，web），Pytorch （Python，深層学習） • 応用依存：ROS（Robot Operating System，ロボット制御），OPC（OLE for Process Control，プロセス制御），CAN（Controller Area Network，車 載ネットワーク） • 近年はローコードやノーコードも n開発ループ • コーディング，レビュー，テスト
- 8. 開発言語の実際 nJavaが不動の1位 nCOBOLが2位 • 誕生1959年 • Common Business Oriented Language （共通事務処理用言語） • 古いシステム（レガシー）の保守改良に必 須 • IBM, COBOLは「古い」のか？令和の時代にCOBOL の“いま”を語る, 2020/2/4 • 日経クロステック, COBOLがついに国家試験から消 える、若手技術者は「転落」注意, 2019/5/15 ソフトウェア開発分析データ集2022, IPA, 2022. https://www.ipa.go.jp/ikc/reports/20220926.html
- 9. 開発OSの実際 n1位：Linux • Unix + Linuxなら2位 • macOSはBSD（UNIX系） n2位：Windows Server • PC + Serverなら1位 ソフトウェア開発分析データ集2022, IPA, 2022. https://www.ipa.go.jp/ikc/reports/20220926.html
- 10. ローコード・ノーコード nローコード • コードをほとんど書かない開発 • GUI＋マクロ程度のコード nノーコード • コードを書かない開発 • GUIで完結 n例 • 商用：Bubble, Adalo, etc • 個人向け（自動化ツール）： ifttt, zapier, Power Automete nメリット • プログラミングの知識が不要 • 経費削減，時間短縮 nデメリット • 結局，知識が必要 • 学習コストは0にはならない • テンプレートの組み合わせ • 自由度は制限 • プラットフォーム依存 • 開発と運用に必要 • 他に移行できない（ベンダー ロックイン） DX白書2023, IPA, 2023 https://www.ipa.go.jp/publish/wp-dx/dx-2023.html ローコード開発による「悪夢の再来」、ベン ダー・ロックインや技術的負債にどう対応？, ビジネス+IT, 2022/7/7
- 11. 内部設計 n方針 • 外部設計書をもとに，機能をどのように実現するのかを設計 • システム内部のモジュール間のインタフェースを定義 • モジュール＝システムの最小単位 • C言語などなら関数，C++などならクラスやメソッド • どのように「モジュール」を作成すれば良い？ • 作成した「モジュール」の良し悪しをどう評価すれば良い？ n技法 • 設計プロセスに従って，システムをモジュールへ分割 • 問題を階層的に小さな部分問題へ分割 • プログラムとして実装できる詳細までモジュール分割を繰り返す • 構造化プログラミング • モジュールの実装方法
- 12. 分割技法 n構造化分割 • ソフトウェアの機能や，データフローに基づいて構造を決定 • 分析のためのモデル化技法 • DFD • 分割手法 • STS分割 • TR分割 • 共通機能分割 n分割の評価 • 原則：抽象化，分割と階層化，独立性 • 評価尺度：モジュール結合度，モジュール強度
- 13. 構造化分割
- 14. 構造化分析 nデータの流れ（フロー）に着目 • データを処理するために必要な機能と構造を明ら かにする nダイアグラム • DFD（Data Flow Diagram） • 階層的にデータの流れを定義 • DCD（Data Context Diagram） • DFDの最上位階層．システムとデータをやり とりする外部との関係を定義． n構造化設計手法 • DFDからモジュールの構造，呼び出し関係，実行 順序などを定義
- 15. DFDの要素記号 n主な要素記号は4つ • 外的要素 • ソース（発生源） • データをシステムに渡す • シンク（吸収先） • システムからデータを受け取る • プロセス • 入力されたデータを処理（変換）して出力する • 入出力データは複数でもよい • 1vs1, 1vsN, Nvs1, NvsN • データストア • データの保存場所 • データフロー • データのやり取り 外的要素 プロセス データの流れ （フロー） データストア
- 16. n商品の注文と納品 • ソースとシンクは客 • プロセス • 受注 • 手配 • 請求 n処理の大まかな概要 • 一番上位のDFD＝DCD • これを詳細化する DFDの例
- 17. n商品の発注部分の詳細 • 発注前の見積の部分 • データストア • 商品データベース • 見積書データベース • 見積書にIDを割り振る • メーカー，卸業者 • 商品在庫の有無 • 納期の確認 DFDの例
- 18. DFDの段階的階層化 n大まかな記述から詳細な記述へ • トップダウン展開，段階的な詳細化 • 上位レベルのプロセスを下位レベル で詳細に記述する • 十分な詳細になるまで階層化を続け る レベル0（DCF） レベル1 レベル2
- 19. DFDの作成方法 nいくつかの基本ルール • プロセス • 入出力フローの両方を持つ • データを変換する • 処理に順序はない • データストア • データフローを持つ • 外部実体 • データフローを持つ • データフロー • すべてがデータの名前を持つ • 処理を行わない
- 20. DFDの評価 nDFDの評価 • プロセス名は適切か • 適切な下位機能に分割されているか • 必要な出力が生成されているか • データフローは必要不可欠か • すべてのデータフローに名前がつい ているか • 上位と下位でデータフローは一致し ているか nDFDを仕様書にまとめる • DFD • データフロー記述書 • データストア記述書 • 処理機能記述書
- 21. いろいろなDFDの記法 外的要素 プロセス データの流れ （フロー） データストア Yourdon / DeMarco Gane / Sarson SSADM
- 22. モジュール分割
- 23. モジュール分割 n共通機能分割 • 共通して用いられる処理をモジュールとして抽出する nSTS分割 • データの変換点を見つける • 最大抽象入力点 • 入力データ構造が大きく形を変える（抽象化される）点 • 最大抽象出力点 • 出力データへ向かってデータ構造が大きく変わる（抽象化される）点 • 上記2点で，Source（源泉）, Transform（変換）, Sink（吸収）に分割 • S, T, Sのそれぞれをモジュールとする • 入力データが出力データに変換される場合に適用できる nTR分割 • データとその処理をトランザクション（TR）という単位で分割 • データによってフローが分岐する場合に適用できる
- 25. 共通機能分割法 n共通している処理を一つのモジュールにまとめる nよくある例 • main()にベタ書き • コード重複 • 関数にしてスッキリ モジュール1 モジュール2 モジュール1
- 26. STS分割 nデータの変換点を見つける • 最大抽象入力点 • 最大抽象出力点 n分割する • この2点で以下の3つに分割 • Source（源泉） • Transform（変換） • Sink（吸収） • S, T, Sのそれぞれをモジュールと する Source Sink Transform モジュール2 モジュール3 モジュール1 最大抽象入力点 最大抽象出力点 モジュール モジュール1 モジュール2 モジュール3 入力データ構造が大き く形を変える（抽象化 される）点 出力データへ向かって データ構造が大きく変わ る（抽象化される）点
- 28. つまり nmain()べた書きからの卒業 def my_func(data): data = first_process(data) data = second_process(data) data = third_process(data) return data def main(): same_process(arg1) # do someting same_process(arg2) # do someting same_process(arg3) # do something def my_func(): same_process(arg4) def my_func(): if flag: do_process() else: do_another_process() 共通機能分割 TR分割 STS分割
- 29. モジュール分割の必要性 nモジュールにす る利点 • 可読性 • 保守性 • 拡張性 nしないと．．． • すべてmain()に ベタ書き • スパゲッティ コードになる Donald E. Knuth. 1959. RUNCIBLE—algebraic translation on a limited computer. Commun. ACM 2, 11 (Nov. 1959), 18–21. https://doi.org/10.1145/368481.368507
- 30. 構造化プログラミング n構造化定理 • すべてのプログラムは順次・選 択・反復の3つの制御構造だけで記 述できる[Knuth, 1974] [Linger, Mills & Wit, 1978] n構造化プログラミング • 構造化定理に従ったプログラムの 書き方 • 現代的な言語のほとんどが採用 n歴史 • 初期の言語は任意の位置へ処理を 移動できるgoto文を持っていた • アセンブリ言語，BASIC, FORTRAN(66, 77, 90), etc • goto文有害説 [Dijkstra, 1968] • スパゲッティコードの原因 • 構造化プログラミングの誕生 • 現代的な言語の多くがgoto文を 持たない • FORTRANも95で削除 • 持つものもある：Go，C++ • ゆるコンピュータ科学ラジオ, プログラミング言語にも歴史の転換点がある 【プログラミングパラダイム・シフト1】#64, 2023/03/19 • ゆるコンピュータ科学ラジオ, 構造化プログラミングが、混沌だったフロー チャートに秩序を与えた【プログラミングパラダイム・シフト2】#65, 2023/03/26 Graphical representation of the three basic patterns — sequence, selection, and repetition — using NS diagrams (blue) and flow charts (green)., CC0
- 31. モジュール特性
- 32. モジュールが持つ特性 nモジュール強度・凝集度 • 偶発的強度・暗号的強度 • 弱い・悪い • 論理的強度 • 時間的強度 • 手順的強度 • 連絡的強度 • 情報的強度 • 機能的強度 • 強い・良い n凝集度の高いほうが良い • 高凝集，凝集している，同じ機能 がまとまっている https://www.ipa.go.jp/files/000056493.pdf IPA, 開発技法の実践的演習コース教材, 構造化技法, 講義ノート, 2012
- 33. モジュールが持つ特性 nモジュール間結合度 • 内容結合 • 高い・悪い • 共通結合 • 外部結合 • 制御結合 • スタンプ結合 • データ結合 • 低い・良い n結合度が低いほうが良い • 疎結合，結合していない，別々の 機能が分かれている https://www.ipa.go.jp/files/000056493.pdf IPA, 開発技法の実践的演習コース教材, 構造化技法, 講義ノート, 2012
- 34. データベース設計
- 35. データベースの設計 nER図 • 実体関連図（Entity Relationship diagram） • 「実体・データ」間の関連や構造（データモデル）を表す • 3つのレベルがある • 概念データモデル：概念設計により作成されるシステム全体の概要図 • 論理データモデル：論理設計により更に詳細な図 • 物理データモデル：物理設計により実際のデータベースを表す図 • 記号 • エンティティ（実体）：データの集合体 • アトリビュート（属性）：データ項目 • リレーション（関連） • カーディナリティ（多重度）：1対1，1対Nなどを表現
- 36. ER図 n実体と実体を関連で結ぶ https://www.ipa.go.jp/files/000056493.pdf IPA, 開発技法の実践的演習コース教材, 構造化技法, 講義ノート, 2012 https://www.lucidchart.com/pages/ja/ER-diagram-symbols-and-meaning ER図の記号と表記
- 37. ER図の流儀 n複数の流儀がある n例：人と生まれた場所 • 1vsN • ある人が生まれた場所は1箇所 • ある場所から生まれた人は多数 • 場所1に対して人はN人 • 関係 • 人：＊＊で生まれた • 場所：＊＊の出生地 ERD Examples in different Notations Benthompson, Public Domain
- 38. テスト
- 39. テストとデバッグ nデバッグ • コーディングしても • コンパイルが通らない • Syntax error • 実行できない • 実行時エラー • Segmentation fault • Core dump • 期待した動きをしない • コードをデバッグする • 経験と勘を頼りに nソフトウェアテスト • コーディングが終わってコードを 実行する • 実行結果が仕様と一致しているこ とを確認する • 異なる場合にはコードを修正す る • すべてのモジュールをテストする • 網羅的に行う • 系統立てて行う • 上位モジュールから下位モ ジュールまですべて
- 40. テストとは n誤りを発見すること • 誤りが発見されたらテストの意義がある nテストケースを作成する • ある入力に対して期待する出力 • モジュールの出力が，期待する出力に一致する ＝テストは成功（テストをパスする） • 出力が期待するものと違うなら誤り n網羅的，体系的に行う • 勘やなんとなくではダメ n注意 • 誤りは発見され，記録され，その数を予測されるものである • 「誤りがあったらまずい」ではない • 「誤りは0にはならない」ことを前提とする
- 41. テスト専門の資格もあるほど n委員会 • 国際ソフトウェアテスト技術者資 格認定委員会（International Software Testing Qualifications Board, ISTQB） • 日本ソフトウェアテスト技術者資 格認定委員会（Japan Software Testing Qualifications Board, JSTQB） nシラバス • 国際ソフトウェアテスト資格 Advanced Level (AL) シラバス, 2012 • ALテストマネージャ • ALテストアナリスト • ALテクニカルテストアナリスト • 国際ソフトウェアテスト資格 Foundation Level (FL) シラバス, 2012 • FLテスト技術者
- 42. 不具合の種類 n欠陥（defect），バグ（bug） • 作業成果物に存在する、要件または仕様を満たさない不備または欠点。 n誤り，エラー（error） • 間違った結果を生み出す人間の行為。 n故障（failure） • コンポーネントやシステムが定義された範囲内で要求する機能を実行しないこ と。 JSTQB用語集, https://glossary.istqb.org/jp/search/
- 44. 各テスト工程 n単体テスト（ユニットテスト） • 1つのモジュールのテスト • xUnitなどのテストフレームワーク を用いて自動化する n結合テスト • 複数のモジュールを結合して行う テスト nシステムテスト • システム全体として問題なく動作 するかのテスト • ベンダ側でダミーデータを用いて 行う • 性能テスト，ストレステストや負 荷テスト，機能テストなども行う n受け入れテスト • クライアントの要求を満たすかど うかのテスト • クライアントへの納品も兼ねる 場合がある • 実際の現場で実際のデータに対し てテストする • 運用テスト，要件テストなどとも 言う場合がある • クライアントが責任を持って行う べき • 業者任せにせず，発注した仕様 どおりになっているかどうかを 確認してから検収するべき • ベンダーはそれを手伝う立場に なる
- 45. 結合テストの方式 nトップダウンテスト • 上位モジュールを先に作成・テストする • 未作成の下位モジュールにはダミー（スタブ）を用いる nボトムアップテスト • 下位モジュールを先に作成・テストする • 未作成の上位モジュールはダミー（ドライバ）を用いる nサンドイッチテスト • ボトムアップとトップダウンを並行して行うテスト モジュール スタブ スタブ スタブ ドライバ モジュール１ モジュール２ モジュール３
- 46. 結合テストの方式 n増加テスト • テストをパスしたモジュールを順次結合していく • ボトムアップテスト • トップダウンテスト • サンドイッチテスト n非増加テスト • ビッグバンテスト • 単体テストをパスしたモジュールをすべて一度に結合してテスト • 一斉テスト • 単体テストをしていないビッグバンテスト • （学生が個人のプログラミング課題でやりがち）
- 47. テストの終了条件 nいつまでテストをすればよいか • バグが完全になくなったことは確 認できない • テストすればするほど誤りは見つ かる • 定量的品質予測のススメ 〜ITシステム開発にお ける品質予測の実践的アプローチ〜, IPA, 2008 • 続 定量的品質予測のススメ 〜ITシステム開発 における定量的品質管理の導入ノウハウと上流 工程へのアプローチ〜, IPA, 2011 n予測した総誤り数に達するまで • 誤り埋め込みによる予測 • 意図的に誤りを埋め込み，見つ かった誤りの割合で判断 • 累積誤り数による予測 • 発見された累積誤り数の曲線は S字型 • 形状モデル：ゴンペルツ曲 線，ロジスティク曲線 • 名称：バグ曲線，信頼度成 長曲線（Software Reliability Growth Curve） • あらかじめ設定した誤り数に達 したら終了 誤り数 テスト数
- 48. 不具合数と検出バグ数の実際 ソフトウェア開発分析データ集2022, IPA, 2022. https://www.ipa.go.jp/ikc/reports/20220926.html リリース後の発生不具合密度 テスト工程でのバグ検出数 リリース後に不具合を出さないためにも テスト工程でのバグ検出は必須
- 49. 回帰テスト nデグレード • リグレッションともいう • ある不具合を修正したことにより，別の不具合が発生すること n回帰テスト（リグレッションテスト） • 修正後に，他の不具合が発生していないかを確認するテスト • リグレッションを検出するテスト • 修正したモジュール以外も一通りテストする • それまでのテストケースを保存しておいて，回帰テストに用いる n用途 • ある修正が新たな不具合を起こしていないかを確認する • 長期間使用され，要求が変化するシステムを更新する
- 50. テストの種類 nブラックボックステスト • コードを見ない．仕様書に基づく． • 上流工程のテストで利用される • テストケース作成手法 • 同値分割 • 限界値分析 • 原因・結果グラフ • 状態遷移テスト法 • ディジョンテーブルテスト法 nホワイトボックステスト • コードに基づく． • 単体テストなど下流工程のテス トで利用される • カバレッジ • 全体に占めるテストした部分の 割合 • 網羅性の指標 • 命令網羅（C0） • 分岐網羅（C1） • 条件網羅（C2）
- 51. ブラックボックステスト n同値分割 • 同じ出力となる入力をグループ化 • 各グループから代表値をテスト • 例：符号関数sign(x) • 定義 • 入力xが正なら1 • 入力xが負なら-1 • 入力xが0なら0 • テストケースの入力x • 正の範囲から1つ • 負の範囲から1つ • 0 n限界値分析 • 出力が切り替わる入力値をテス • 例：符号関数sign(x) • テストケースの入力 • xが整数の場合：-1, 0, 1 • xが実数（float）の場合： • 工夫が必要
- 52. ホワイトボックステストの網羅性指標 n命令網羅（C0） • すべての命令を1回以上実行 n分岐網羅（C1） • すべての分岐の真と偽をそれぞれ1 回以上実行 n条件網羅（C2） • すべての分岐の組み合わせ（経 路）を1回以上実行 nコードカバレッジ • C0網羅率 • 実行した命令数/全命令数 • C0カバレッジ • C1網羅率 • 実行した分岐数/全分岐数 • C1カバレッジ • C2網羅率 • 実行した経路数/全経路数 • C2カバレッジ
- 53. ホワイトボックステストの網羅性指標 n命令網羅（C0） • すべての命令を1回以上実行 n分岐網羅（C1） • すべての分岐の真と偽をそれぞれ1 回以上実行 n条件網羅（C2） • すべての分岐の組み合わせ（経 路）を1回以上実行
- 54. ホワイトボックステストの網羅性指標 n命令網羅（C0） • すべての命令を1回以上実行 n分岐網羅（C1） • すべての分岐の真と偽をそれぞれ1 回以上実行 n条件網羅（C2） • すべての分岐の組み合わせ（経 路）を1回以上実行
- 55. ホワイトボックステストの網羅性指標 n命令網羅（C0） • すべての命令を1回以上実行 n分岐網羅（C1） • すべての分岐の真と偽をそれぞれ1 回以上実行 n条件網羅（C2） • すべての分岐の組み合わせ（経 路）を1回以上実行
- 59. 国が主導してインストールを推奨
- 65. そして全数把握停止に伴い終了 n河野デジタル大臣「COCOAアプリは機能停止へ」、コロナ全数把握 のルール変更で（2022年9月13日） nCOCOA機能停止、リーダーシップ不在で混乱重ねる 2022年9月14日 nCOCOA“失敗”の原因、当初の開発者が振り返る ユーザーから「役 に立った」の声も 2022年09月15日 n総括すべきCOCOAの課題は何か、政府検討の前に考えてみた 2022.09.22 n「COCOA」が機能停止へ…3.8億円かけて開発した意味はあったの か？2022.09.27 nCOCOAトラブルの要因 内情知る元幹部が明かす「お役所体質」 2022/10/14 • 「更新が必要になれば、新たに仕様書を作り、契約を変更する」という作業を繰り返した結果、契約変更には数週間 単位の時間を要したという。 n「お役ご免」COCOAの教訓から学ぶべきことは 2022/10/19
- 68. 想定試験問題 n以下のモジュール分割技法について説明せよ • 共通機能分割法 • STS分割法 • TR分割法 nDFDとは何か，簡単な例を用いて図解せよ nモジュール強度，モジュール間結合度とは何かを説明せよ nV字モデルとはなにか，テストとどのように関係するのかを説明せよ nソフトウェアテストの種類とそれぞれの違いを説明せよ nホワイトボックステストにおける網羅率とは何かを説明せよ