ソフトウェア工学

第9回 設計（4）

2019.11.21

前回までのお話

⚫ ソフトウェアを多人数で協働して開発する必要

⚫ 協働するために段階に分割して問題を理解する

◆開発の過程は段階を繰り返しながら進む

⚫ 開発プロジェクトを管理する

⚫ 要求分析

⚫ 設計

分割と統合・階層的詳細化・MVC・抽象化・機能中心設計／データ中心設計・モジュール・モジュール構造図／外部設計

◆システムの外部・サブシステム

2019.11.21

フェーズ

今日のお題

内部設計

2019.11.21

設計 実装 テスト 運用分析 保守

外部設計と内部設計

外部設計依頼者との合意を得る

依頼者は、プログラムの細かい構造に興味はない

…プログラムの構造を依頼者に説明する必要は無い

内部設計プログラムの具体的な実現方法を検討・決定する

外部設計との食い違いがないことを確認する

2019.11.21

内部設計とは

⚫外部設計をもとに、プログラムの具体的な実現方法について検討する

⚫内部のデータやクラスを定義する

⚫サブシステムをモジュールに分解する

◆機能仕様を満たすようにモジュールを設計する

⚫プログラムのミスを未然に防ぐ

⚫共通化できるモジュールは共通化する

2019.11.21

内部設計の重要性

⚫実装した後で訂正すると、多大なやり直しが発生する。

◆内部設計をきちんとやっておくと、後のプログラミングの工数とテストの工数、全体のコスト削減につながる

⚫個人がそれぞれ作ったモジュールを組み合せようとすると、うまくいかないことが多い。

◆方針を最初に定義し、開発者間で意識合せをしておく 2019.11.21

開発者間の意識合せ

⚫用語の統一

一つの語が一つの意味を表して曖昧さが無いように、定めておく

⚫命名規則（クラス名やメソッド名の付け方）

2019.11.21

内部設計書の構成

⚫内部設計書作成方針◆内部設計書をどのように書くかを決めておく

⚫モジュール設計書◆モジュール構造図

◆各モジュールの処理手順

⚫内部データ・クラス設計書◆データの構造・形式

◆モジュール間のデータの受け渡し方法

⚫通信プロトコル設計書（NWを使う場合）

⚫データテーブル設計書（DBを使う場合）2019.11.21

データ構造の決定

必要な情報を、どのようなデータで保持するか

C言語の場合：

変数・配列、それらの型、構造体

Java の場合：

クラスおよびそのフィールド、それらの型

これらの名前も決めておく

2019.11.21

クラス図

オブジェクト指向におけるクラスの設計図

⚫ クラス名・フィールド・メソッドを列記する

⚫ データ構造とモジュール(メソッド)を併記している

⚫ 複数のクラスのクラス図を描いて、関連するものを線で結ぶ

2019.11.21

クラス名

フィールドフィールド…

メソッドメソッド…

フローチャート

処理の流れを図示したもの

⚫ 一つ一つの処理を図形で描きそれらを矢印で結ぶ

◆上から下へ流れる矢印は、省略して線で描いてよい

⚫ 基本的には上から下へ向かって流れていく

2019.11.21

フローチャートの構成

⚫ 処理：長方形の中に処理内容を書く

⚫ 条件分岐：ひし形の中に判定内容を書き、出ていく線のそばに Yes/No などの条件を書く

⚫ 端子：プログラムやモジュールの 最初および最後を表す。全体の最初は「開始」最後は「終了」、モジュールの最初はモジュール名、最後は「復帰」と書く。

⚫ 呼び出し：呼び出すモジュール名を書く

2019.11.21

※）処理の内容（入力する処理・出力する処理など）によって図形を変える書き方もある。

フローチャートの例

2019.11.21

開始

iに0を代入

iは10より小さいか？

iを表示

iを1増やす

終了

小さい

小さくない

例）0から9までの整数を、繰り返しを使って表示する

注意点：

⚫ 図形には必ず上から入る

⚫ 合流するときは、上から下に向かう線に横から合流する

余談：フローチャートと再帰

int fact(int n) {

if (n == 0) return 1

return n*fact(n-1);

}

再帰的なプログラムの流れは図示しづらい

無理矢理フローチャートを描いてみても、(プログラムの構造を表すかもしれないが)流れは表現できない

2019.11.21

fact

n==0

fact

復帰

n倍する

復帰

Yes

No ？

2019.11.21

余談：「設計」と「現場」

NHKスペシャル「東京リボーン第1集」の中のセリフ

設計通りに作れることはない。なんとかするのが職人のウデ。

⚫ ソフトウェアでも同じことが言えそう

◆身も蓋もないが、真理だなぁ

◆「…ない。」は言い過ぎかな…

⚫ とは言え設計は大事

◆職人だって設計通りに作れるほうが楽なはず

◆設計通りに作れないのは、設計者の怠慢・勉強不足

◆コードまで見通してソフトウェアを設計すべき

東京五輪に向けた巨大建造物の建築現場の実録

（NHK総合 2018年12月23日21:00放映）

職人の立場から出た言葉

将来情報系の開発に携わる人が目指すべきは：• なんとかできる優秀な職人（プログラマ）• 優秀なプログラマに無視されない設計者・企画者

技術的な内容を話したとき、分からないことがない程度に話についていける理解力が必要

次回予告

実装（次回の演習ではコーディングをしてもらいます）

2019.11.21