Software Designing in Hamburg steak

勉強

1枚目 ハンバーグ

定義的なメタファー
Hardware
料理の皿や鍋。最近は皿も食べられるようになってきた。
Software(広義)
HWではない部分全部。つまりはハンバーグ。材料や調理法も含める。
Software(狭義)
ハンバーグの味付け。
要求仕様
ハンバーグの注文
概要設計
献立決定(ハンバーグは洋風か和風か。おかずはポテトとサラダにしようか)
詳細設計
食材決定・調理法決定
テスト設計
味見をどう行うか。注文どおり作れたかをどう調査するか。
良いハンバーグ
  • 腐らない(保守性 maintainability)
  • おなか壊さない(信頼性 dependability)
  • 栄養価高い(効率性 efficiency)
  • 食べやすい(受容性 acceptability)

2枚目 ハンバーグと調理法

方法論
どういうハンバーグを食べたいか、から調理法を導き出すこと。
SW開発論
調理を始める前にあれこれ悩むこと。
分割統治
たまねぎはたまねぎ、ひき肉はひき肉で分けて考え、最後に混ぜてハンバーグにする。
モジュール方式
それぞれの食材の性質を見つめなおす。
抽象化
目の前にある食材ではなく、その種の食材について考える。

ハンバーグ作ること＝SW開発、ならば、調理器具＝ツール。

3枚目 ハンバーグと食卓

フォン・ノイマン型食器
ハンバーグを上に乗せて使う食器(当たり前か)。
手続き型
一口ずつ食べる。
関数型
ハンバーグを食べる。そのためにナイフで切ったり、フォークで刺したり、持ち上げたりする。
論理型
私はハンバーグを食べる。食べるとは口に運ぶという行為である。口とは人間の摂取機関である……

論理型がマイナーな理由が伺えますね。

パラダイム
ハンバーグという料理の本質の変化を時代で見たもの。
ハンバーグの機能(具象)
味覚を励起する。栄養になる。
ハンバーグの機能(抽象)
献立としてのハンバーグ。
ハンバーグの機能(メタメタ)
ハンバーグという料理の社会的なんか。
トップダウン
何を食べたいかから考える。ハンバーグとポテトとサラダ。
ボトムアップ
何から作るかから考える。ひき肉とジャガイモとキャベツ。

4枚目 ハンバーグの抽象化

食事(計算機)の抽象化

転送
口に運ぶ。飲み込む。→代入
演算
味わう。→式
制御
次に何を食べるか決める。→制御

制御だけ抽象度が低い気がするので抽象化↓

構造化プログラミング
連接
違うものを次々食べる
選択
どっちか食べる
反復
同じものを何回か食べる

↓
客が口にするメニューの制御　→　フランス料理のフルコース的な概念
↓
味のケンカを意識せずに複数の食材を扱うことが出来る。

5枚目 ハンバーグの食材とフルコース

情報隠蔽
物理・化学的な実体ではなく、食材として扱うことでやりやすくなる。
フルコースをさらに抽象化　〜本当かどうかは知らんがね〜
手続きの抽象化
定食とかじゃね。
制御構造の抽象化
実際に口に運ぶ順番(動的構造)とメニュー(静的構造)が一致していればOK
データの抽象化
栄養価や味を定義
サブルーチン
味がまとまってないので、後味を気にしないといけない。
関数
味がまとまってるので、任意のメニューと組み合わせられる。

6枚目 ハンバーグの特性

不可視性
栄養や味は目に見えない
不良率・故障率
腐らない。(ほんとか？)
修正コスト
味付けは濃い薄いなら多少変更できる。でも洋風を和風にするのはメンドイ。
evolutional SW/incrimmental Dev
新しい肉料理→太る→カロリー下げる。
波及効果
調味料かえると他の味付けも変更が必要
十人十色
料理人によってハンバーグは色々ある。

ハンバーグ(SW)工学

  • 要求された味・栄養価のものを作る
  • 時間内に、限られた食材で。
  • てきぱき作れたか。食材に無駄はないか。
属人性の排除
誰がやっても条件に従いハンバーグを作れる

7枚目 ハンバーグの時代変遷

1969 Recognition of Problem(問題提起)
　大規模な献立(フルコース)になると、バグとか品質の問題が。
　いい食器を用意しても、料理が足を引っ張るんじゃないか！

1970年代 Principle Era→Methods Era→Quality Era→Specification&Design Era(SW工学の芽生え)
　構造化プログラミング(フルコースの登場)
　ボトムアップ→トップダウン(食材優先から、嗜好優先へ)

　構造化言語(フルコースを表現できるメニューの出現)
　作るだけではなく、評価もされねば料理ではない。

　味や栄養価を定量的にはかることにする。

1980年代 Application Era→Industrialization Era
　調理器具　直感的で分かりやすい調理器具の出現。(ミキサーとか)
　教育　ハンバーグの作り方を体系的に論じる

　ハンバーグの量産。
　以後、ダウンサイジング。
EUC(End User Computing)
普通の人でもハンバーグぐらい食べられないとね。
CASE(Computer Aided Software Engineering)
献立をつくるのにコンピュータソフトを使う。(さすがにここもハンバーグにしたら謎杉)
プロダクトとプロセス
ハンバーグと調理法

8枚目 ハンバーグ工学の技法の成果

作ってから味付けを整えるより、最初から味付けを決めたほうが楽

テストケース設計
完成品に対する、味見の仕方・栄養価の計り方
モジュール集積度テスト
トップダウンテスト・ボトムアップテストなど。料理の途中で味見(ありえないね)
テストカバレージ
味見を満遍なく行えたか考える。
信頼性予測
ハンバーグに針を仕込んで、食べても大丈夫か調べる(意味不明)

9,10,11枚目　ハンバーグのデータ化

Proccess Programming
  • 味を明確にする。どの食材を、どうやって、誰のために。
  • それぞれの料理がよければ、全て良いわけではない　→局所解から大局解へ。
  • 調理法が明確ならばレシピに出来るはずだ。→形式化プログラミング
  • プロダクトの可視化→プロセスの可視化
プロダクトの可視化
ハンバーグのデータ化
プロセスの可視化
レシピ化

誰が作っても美味しくできるように。レシピは再利用可能。でも下手な人は居るわけで。

コストモデル
Function Point
考慮する栄養などによって見積もり。
ハンバーグの要求モデル
  • システムの構成　ハンバーグと、おかず。
  • データフローモデル　ハンバーグを硬さ・舌触り・後味・ノド越しなどで記述。
  • 状態遷移　ハンバーグが出来立て→半分食べた→全部食ったと遷移する(違うよなぁ)

11,12枚目　食材

モジュール強度
モジュール分割の可否。　その食材はもう少し分けて考えようぜ
モジュール結合度
モジュール分割の妥当性。　キャベツとたまねぎは同じ野菜だけど、使い方が違うがな。
インターフェイス
栄養･味覚的観点からみた食材
実装
食材の実体。育て方、生産地。
12,13枚目　食材の組み立て
STS分割
口に入れる(Source)、味わう(Transform)、飲み込む(Sink)
TR分割
噛んで食べる系(ごはんなど)・飲み込む系(スープ)・切って食べる系(肉)・よく噛む系(野菜)
GOTO有害論
何か食べてる途中で突然別のものが食べたくなる→行儀が悪いので構造化

結局フルコース。