組込みソフトウェア開発のための構造化プログラミング(SESSAME WG2)

書籍情報

• 著者:SESSAME WG2(著)
• 発行日:2016-09-05
• ISBN:9784798147611
• URL:https://www.shoeisha.co.jp/book/detail/9784798147611

書籍目次

• はじめに
• 本書の使い方
• Chapter1. 良いソースコードとは
  • 1.1 シンプル
    • 1.1.1 簡潔
    • 1.1.2 明快な命名
    • 1.1.3 規則的
  • 1.2 本質指向
    • 1.2.1 分割・凝集・集約
    • 1.2.2 抽象化
  • 1.3 洗練された階層
    • 1.3.1 自然な呼び出し
    • 1.3.2 包括的
    • 1.3.3 対称的
  • 1.4 丁寧で慎重
    • 1.4.1 補助説明
    • 1.4.2 文書と一致
    • 1.4.3 予防的
• Chapter2. 良いコードを見る
  • 2.1 要求仕様
    • 2.1.1 ライン走行ロボット本体
    • 2.1.2 動作仕様
    • 2.1.3 ソフトウェアの全体構成
  • 2.2 ファイル構成
  • 2.3 mian関数
  • 2.4 main関数から呼び出されている関数
  • 2.5 入力モジュール
  • 2.6 センサ値を読んでいるモジュール
  • 2.7 演算モジュール
  • 2.8 出力モジュール
  • 2.9 どこが良いのか？
    • 2.9.1 ファイル名と変数名からファイルの責務が見えてくる
    • 2.9.2 ファイルヘッダで関数インターフェースを公開している
    • 2.9.3 変数がカプセル化されている
    • 2.9.4 状態や状況が「漏れなく」分類・定義されている
    • 2.9.5 関数の行数が短く簡潔である
    • 2.9.6 関数の名前から機能がわかる
    • 2.9.7 利用される変数だけ渡している
    • 2.9.8 利用するヘッダファイルだけインクルードしている
    • 2.9.9 深くまで追わなくても動きを予測できる
• Chapter3. 良い設計図を見る
  • 3.1 ソースコードを構造的に見る
  • 3.2 良いソースコードは構造も良い
    • 3.2.1 BOSSモジュールと処理モジュールが階層化されている
    • 3.2.2 入力部と出力部が分割されている
    • 3.2.3 引数と戻り値が明確になっている
    • 3.2.4 単方向の依存性になっている
    • 3.2.5 同じ階層での横のつながりがない
    • 3.2.6 モジュール名で何をしているのかがわかる
    • 3.2.7 第2階層のモジュール名で主要機能がわかる
• Chapter4. ソフトウェア設計の基本
  • 4.1 ソフトウェアの設計とは？
    • 4.1.1 さまざまなソフトウェア設計
    • 4.1.2 構造化は設計の基本
    • 4.1.3 箱と線と配置
    • 4.1.4 静的構造ファースト
    • 4.1.5 仕様追加・変更時も「箱、線、配置」から
  • 4.2 設計図とは？
    • 4.2.1 検索から図面化へ
    • 4.2.2 設計図で設計意図を伝達する
    • 4.2.3 設計図はモジュール構造とデータ構造
  • 4.3 モジュール構造図
    • 4.3.1 上下左右のシステム形状を形成する
    • 4.3.2 コーリングシーケンスは、なぜ設計図ではないのか？
    • 4.3.3 構造図の表記法
  • 4.4 データ構造
    • 4.4.1 データ辞書
  • 4.5 ファイル構造図/クラス図
    • 4.5.1 最小のソフトウェア部品
    • 4.5.2 クラス図
    • 4.5.3 コミュニケーション図
    • 4.5.4 コミュニケーション図とシーケンス図の使い分け
  • 4.6 コンポーネント構造図
    • 4.6.1 コンポーネントでモジュールを実現
    • 4.6.2 コンポーネントのインターフェイスの定義
  • 4.7 静的構造は粒度を変えられる
  • 4.8 タスク構造図
    • 4.8.1静的構造と動的構造の関係
• Chapter5. コードと設計図を同期させる
  • 5.1 仕様変更:お買い物ロボット
  • 5.2 近視眼的な派生開発
  • 5.3 大局的な派生開発
    • 5.3.1 仕様変更に対応したソースコード
• Chapter6. 7つの設計指針
  • 6.1 単一責務
    • 6.1.1 WHATの名称
    • 6.1.2 カプセル化
    • 6.1.3 入り口1つ出口1つ
  • 6.2 データ設計ファースト
    • 6.2.1 本質データ
    • 6.2.2 分類と階層化
    • 6.2.3 データ抽象
  • 6.3 知的階層化
    • 6.3.1 レベル化
    • 6.3.2 単方向依存
  • 6.4 インターフェース定義
    • 6.4.1 インターフェースと実装の分離
    • 6.4.2 置換可能
  • 6.5 水平レイヤリング
    • 6.5.1 3層構造
    • 6.5.2 指示と報告の伝播ルート
  • 6.6 垂直パーティショニング
    • 6.6.1 IO分離、STS分離
    • 6.6.2 UI分離
  • 6.7 横断的関心
    • 6.7.1 伝播ルート
    • 6.7.2 対称性（シンメトリ）
• Chapter7. 設計品質の指標
  • 7.1 モジュラリティ
    • 7.1.1 モジュールとは？
    • 7.1.2 モジュールの長さ
    • 7.1.3 凝集度
    • 7.1.4 結合度
    • 7.1.5 識別性
  • 7.2 システム形状
  • 7.3 2つのビューポイントと品質特性
• Chapter8. 設計中心開発
  • 8.1 アセンブラ的Cからモジュール的Cからへ
    • 8.1.1 中心ファイル
    • 8.1.2 設計の主題
    • 8.1.3 ヘッダファイルの位置づけ
    • 8.1.4 変数スコープ
    • 8.1.5 main関数の役割
  • 8.2 派生開発で設計図とソースコードを同期させる
  • 8.3 新規開発で設計図とソースコードを動機させる:段階的詳細化
    • 8.3.1 骨格（スケルトン）の作成
    • 8.3.2 実現可能性調査
    • 8.3.3 段階的詳細化（肉付け）
  • 8.4 ソフトウェアを活用しやすい資産にする
    • 8.4.1 ソースコード流用
    • 8.4.2 部品化再利用
    • 8.4.3 プロダクトライン開発
    • 8.4.4 体質変換:在庫化サイクルから資産化サイクルへ
• AppendixA. ソフトウェア疲労（良くない例）
  • A.1 そもそも設計していない
    • A.1.1 一筆書き
    • A.1.2 クローン
  • A.2 設計技法を使いこなせていない
    • A.2.1 神様データ
    • A.2.2 中央集権
    • A.2.3 スパゲティ
  • A.3 全体設計ができていない
    • A.3.1 老舗温泉旅館
    • A.3.2 一枚岩
• AppendixB. ソフトウェア設計の定石
• AppendixC. 構造化モデリングの実施例
• AppendixD. 配列とポインタの文法
• Index
• 用語辞書
• 参考文献