**********************************************************************
セッションS2-c
テーマ：大事なのでもう一回: 振舞いのコードもモデルを使って作成しよう
コーディネータ: 久保秋 真 (株式会社チェンジビジョン)
日時：2022/9/2(金) 9:30-10:00
参加人数：6人 (開始時 オンライン)
**********************************************************************

■セッションの概要説明
・なぜ設計のモデル図と実装が乖離してしまうのか．
・モデルと対応したコードを安定して得るには．
・Astah*のプラグインを使った実例

■設計でモデル図を作成してもどうして実装で乖離が生じてしまうのか
開発するとき，制約のない設計をした後，実装方式を設計しながらの実装をするという順序では，
どのようにコードを書けば動くかを考えることになる．
これに対し，方法や資源を制約した実装方式を設計しておき，
その実装方式を前提に設計した上実装すれば，設計と実装の乖離は小さくなる．

■上記の例
電子回路の場合，バラバラの部品を使うつもりで設計すると，実装者の介入できる余地が大きい．
一方で，ICを使うことを前提に論理設計するという実装上の制約を設けると，
設計した論理が変わることは少なくなる．

■ソフトウェア設計において
設計やモデルの記載に対する実装の方法については，実装する人が考えるのではなく，
設計の側で決定するべき（設計に仕事であるべき）．
たとえば，クラス図とステートマシン図の組み合わせに対して，
実装に使うコードとの対応関係を規則化しておき，
誰が書いても同じようなコードを得られるようにしておく．

■実装方式以外にも設計側で決定しておくべきこと
・インスタンスが1つか複数か（多重度が1までか1より多いか）
・集約かコンポジットか
・多重度に0を含むかどうか
・など

■具体的なモデルとコードにおける変換と実装の実例
・事例： LEGOで作った運搬ロボットの構造と振る舞いのモデル
・構造の実装方式の設計：クラス，クラス図に対応するコードの書き方
・振る舞いの実装方式の設計：クラスのステートマシン図に対応するコートの書き方
・アプリの設計：上記実装方式を前提にした，構造と振る舞いのモデルの作成
・実装：アプリのモデルと実装方式を使って，決まったコードを得る．

・アプリのふるまい（動作シナリオ）
1. 荷物受け取り待ち
2. 走行開始指示で運搬開始
3. 側壁認識時，停止して荷物降ろし待ち
4. 走行開始指示で回送開始
5. 側壁認識時，停止して業務終了

・システムのクラス図といくつかのクラスのステートマシン図を，
実装方式に従ってコードに変換する
・講演者は，変換が手動か自動かによらず「変換による実装」と呼んでいる．

■変換規則の実用化の
・どんな場合にも対応する一般化は難しい
・一般的なしくみは，やることが決まっているほど無駄が多くなる
・そこで，自分たちの既存コードをベースにテンプレート化する
・テンプレートが十分使えるようにするのは方式設計の責任
・アプリの設計（モデル）は，テンプレートの埋め込みに必要なデータを
決めるところまで詳細化できれば設計が終わりといえる

■Astah m2tプラグイン
・テンプレートにモデルのデータを埋め込んでソースコードを生成する方式
・LED-Campでも使用している

■作成したテンプレートやコード
・コード，モデル，変換用テンプレートなどの詳細は，
GitHubに掲載している(kuboaki/m2t_workspace)

■まとめ
・実装方式を決めない設計（特に振る舞い）が設計と乖離する原因だった
・先に方式設計でモデルとコードを対応付けしておく
・アプリの設計では，方式設計を前提にモデルを作成する
・方式設計ができていれば，実装は機械的，属人化も減らせる


<質疑応答>
・質問
前提として，設計ができる人を増やすということにはならない？
・回答
実装方式を考えながら半分設計している人たちは，そもそも設計の作業もやっています．
それを，モデルとコードの対応関係を考える設計フェーズと，
それを使って機械的に変換していく変換フェーズを分けることになる．
つまり，今まで実装でやっていた設計の仕事が，本来のフェーズである設計に移ることになる．

・質問（コメント）
対象領域というか，応用領域に関する設計と，実装に関する設計の2種類を分離しましょう
という話ですよね．
対象領域のものがステートマシン，実装領域のものがテンプレートだと考えると，自然な変換ですね．
・回答
そうですね．
うまく実装している人は，頭の中でその分離ができている場合が多い（無自覚だったりもするが）．
それを表出化できれば，個人のスキルからチームが利用できる技術に変えられるということでもある．

・質問
状態遷移ってパターンも決まっているし，誰が作っても一緒だと思うので，
誰かOSSにしてくれればいいんですけど，何故出てこないんでしょうね．
・回答
BridgePointのように，完全にOSSで，振る舞いのコードの生成までできるツールもあります．
今日私が話したように，乖離のネックが振る舞いのモデルとコードの対応にあるという
自覚や認識が組織的に欠落しているのが，そういったものが普及しない理由ではないでしょうか．

・質問
できるかはわかりませんが，ステートマシンの所だけを切り取ったクラスを作り，
そのステートマシンクラスのインターフェース関数とかで実装方法を制約するみたいな
やり方もあるのではないでしょうか．
・回答
体系化したりすればそうなる．
手で変換する場合はそうした方がいい．
自動変換なら（そこは生成するしくみの仕事になるので），そこまでこだわる必要はない．
テンプレートのメンテナンス問題はあるが．まずは自分たちの手元から始めたらと思う．

以上．