********************************************************************** セッションS3-d テーマ:構造化分析・設計の勘所 〜強いプログラムを作るテクニックを学ぶ〜 講師:酒井 郁子 氏(組込みソフトウェアギルド) 日時:2011/9/1 10:45〜:12:00 参加人数:28名(終了時) ********************************************************************** 概要 強いプログラミングが何か、どうしたらよいプログラムができるかを構造化分析・設計を題材に解説を行う。 ・自己紹介 Interfaceで、組込みビギナーズ強いプログラムを作るという連載が元となり、 今回発表することになった。 名前はゆうこと読む。 LEDキューブ装置ソフトウェア要求仕様書をもとに、構造化分析・設計した。 グループでのディスカッションもあり。 ・グループ決め 周囲の人と数人のグループ作り ・もくじ 1.強いプログラムを考える 2.思い出してみましょう、構造化分析・設計 3.構造化分析・設計の使い方 4.まず一歩、踏み出そう! ・強いプログラム、何を思い浮かべるか 品質の高いプログラム(数人) 具体的なプログラムの特徴 ・グループで議論 保守性の高いプログラム? ・他グループの意見 ・仕様変更などに耐えられるプログラムの構造 ・一回作ると変更する必要がないくらい、安定したプログラム ・攻撃されても跳ね返す強さ 通信による攻撃、ハードウェアが故障しにくい ・過去に困ったプログラムコードを思い出してみて ・そのプログラムは、どうなっていたらよかったのか? ・使えるプログラムにする →安心して使える 要求仕様書通りに作られている 中身が検証されている 故障耐性の高いプログラム →また使える 趣味としてのプログラムならともかく、製品開発では大切 多くの製品用プログラム開発は派生開発 コンピュータはコード通りに動くが、人間はコードからその通りに読み取ることができない。そのため、要求仕様を作りそこからの一貫性を設計することが大切 ・ソフトウェア設計のポイント 1.わかりやすい境界で処理を分割する 複雑なシステムを管理しやすい形態に分割し、整理 2.システムを階層構造で組み立てる 大きな粒度と、小さな粒度で組み立てる 3.各モジュールの独立性を高める ・構造化分析・設計は古の知識? 構造化分析・設計とは トップダウン式にモジュール構造を階層に分割する設計技法 構造化プログラミングの考え方がベース 構造化プログラミングの効果 前提・仕様が定義されている ・構造化分析・設計の参考図書 1970年代の本など古いものがある ・構造化モデリング(2006) ・構造化設計の三大成果物 プログラムの階層的モジュール構造 各モジュールの機能定義 モジュールインタフェースの概略的な定義 (備考:モジュール構造図に対し、フローチャート、UMLのアクティビティ図などはモジュールの階層構造を示しているわけではない) ・モジュールとは? プログラム構造の基本単位 実行可能なプログラム命令の集合 閉じたサブルーチンである プログラム内のどこからも呼び出し可 モジュールを定義する属性 機能(function) モジュールがなすべきことを定義 論理(logic) その機能をいかに実現すべきか記述 用法(context) モジュール固有の使い方を記述 ・モジュール仕様書 機能、用法、論理の順で書く 普段でもヘッダに似たようなものをを書いている方が多いのでは? ・設計することで・・・ 複雑なプログラムを理解しやすい、扱いやすいものにしたい 複雑さを減少するための手段として「構造化」の特徴を利用する ・ほとんどのプログラムは、構造化されている。しかし、うまく分割されていない! ・独立性を高める 独立性を高めると、何が好いか モジュールの活動が、他のモジュールに影響しない 不具合対策・仕様変更の局所化 モジュールをブラックボックスとして、利用できる 独立性の高い分離の考え方 (凝集度) (結合度) ・凝集度詳細 個々のグループ内部の関連性を最大にする。 7段階くらいある(説明している本による) ・結合度 モジュール間の関連性の強さ(依存度合) ・構造化分析・設計では・・・ 機能視点で分割する 視点が一つであるため、抽象化の概念をとらえるには入りやすい 基本的なモジュール ・DFDモデルで分析 ・丸と丸の関係性(誰に何を渡すかを絵にする。ただし、タイミング等の情報はない。あくまで関係性のみを定義) ・階層化 Whatで分離 機能を分割統治 ・分析する かたまりを分割し、分類・整理し、抽象的概念で再構築 ・DFDによる構造化分析 ・機能視点で分析 ・データの流れで分析する ・Whatで分析する ・分析した結果を構造図のたたき台にする まずはプログラム構造の概要を理解することが大切 [まとめ] ・まとめ 構造化分析・設計を用いることで、 ・複雑なプログラムが、理解しやすくなる ・独立性の高いモジュールが保守・再利用しやすくなる [使い方のコツの紹介] →構造化分析は有用であるが、構造化分析をすぐに使いこなすのは難しい コツをいろいろ紹介 ・使い方のコツ1 開発プロセス(V次モデルのプロセス) 参考:DeMarco説 ・ライフサイクルに対する構造化分析への影響 元々構造化分析ができたときの開発プロセスはウォーターフローモデルぐらいだった。 ・DFD分析モデルの例(LEDキューブを例として解説) ・使い方のコツ2 (部分導入) ・教科書通りの手順では、導入コストが大きい ・もう少し使いやすい方法を紹介 ・お試し施策1 範囲を絞り込む 部分導入のターゲットを絞り込む ・モジュールの特徴 ・役割の違いによる、モジュールの特徴 ・特徴を理解した上で、部分導入 ・解析で使ってみる ・Call Graphを増強する ・関数呼び出し関係図(QACなどのコード解析ツールで調べられる) ・悪い結合度が見えてくることが多い(グローバル変数を使っていたとか) ・レビューで気づく ・入出力、イベント待ちの不適切な関係が見つかるかも ・使い方を考える いつ使う 何に、どこに使う 目的は? 身近なプログラムで、使うことを考えてみましょう ・リファクタリング ・どうなれば、自分の思い浮かべたよいプログラムになるのか? 紹介: blog 9/28, 講演 (SESSAME Seminar) 質疑応答: [質問] 仕様からDFDを作るが、トレーサビリティの必要性は? [回答] 必要である。要求からの一貫性を保つためにトレーサビリティは必要不可欠であると考えている。 [質問] リアルタイムシステム開発で使える手法はありますか? [回答] タイミングチャート、状態遷移図、UMLのシーケンス図などがある。 Interfaceでシーケンス図の例があるのでぜひ見てください。 以上。