SL＝StreamLine Object Modeling

　ストリームライン本の表紙が機関車（列車NoはUML！）である理由は、「SL＝StreamLine」だとえがぴ～さんに教えられました。最大の謎の一つが解決できました（笑）

　ストリームライン本は非常に読みにくいです。

　協調パターン→協調ルール→サービス→実装

という目次を読むと理解しやすそうなんですが、

協調パターン定義→クラス図例示→法律みたいな説明→具体例→・・

な感じで延々と続きます。数学の本のスタイル：

公理系→補題→定理→証明→系→具体例→・・・

に似てます。

　とはいえ、ストリームライン本を読むとアナパタで出てくるパターンが実はすごく自然に導かれることが分かります。下記に「特徴」「利点」「欠点」をあげておきます。

【特徴】
　オブジェクト指向の発想に基づくクラス図に出てくるエンティティやトランザクションは、12個の協調パターンのいずれかに当てはまる。（証明できるのか？）
　協調パターンに付随するビジネスルールを詳細化していくと、モデリングから実装まで一気貫通できる（らしい）。

【利点】
　クラスよりも関連に着目することで、エンティティやトランザクションの存在意義をはっきりと説明できる。
　特に、「トランザクションが多くの協調パターン間を調整する」という重要な役割を何度も指摘している。ストリームライン本では、トランザクションを「オブジェクトモデルの糊」と呼んでいる。

●例：「本質」に出てきた「ものーことーもの」パターン
　　→「ストリームライン」で翻訳すると、二つのエンティティ（もの）が関わる時、必ずトランザクション（こと）が協調パターンとして自然に（！）導かれる。
　例えば、人と場所が関わると必ず事象の履歴（例：住民票の履歴）を表すトランザクションが発生する。
　そんな例が延々と続く（疲れます）

●例：「本質」に出てきた「予定ー実績」パターン
　→「ストリームライン」で翻訳すると、「ロールートランザクションー品目」と「ロールー後続トランザクションー特定品目」を組み合わせたものになる。

●例：アナパタの勘定パターン「会計取引ー明細ー勘定科目」
　→「ストリームライン」で翻訳すると、「コンポジットトランザクションー明細ー特定品目」の協調パターンになる。
　コンポジットトランザクションとは、トランザクションの集約です。

【欠点】
●どの章から読み始めても、すごく読みにくい。
●協調パターンに基づくビジネスルールの説明は法律のような文体で読みにくい。
●モデリングは面白いが、実装の方法は大したことはない。付属サンプルソースはしょぼい！！（テストクラスはせめてJUnitを使え！！）

　詳細の続きは、発表会で。