Upgrade to Pro — share decks privately, control downloads, hide ads and more …

せっかくモデル図描くのなら、 嬉しいことが多い方がいいよね!

せっかくモデル図描くのなら、 嬉しいことが多い方がいいよね!

この資料はObject-Oriented Conference 2024 Track B 15:00からの同名のセッションの資料です。
このセッションでは、当初はあまりモデル図が活用できていない方に向けて、モデル図の利用シーンや、モデル図を活用する方法を紹介する予定でしたが、実際には、どうしてみなさんがモデルを作らなくなって、今後はどうなりそうか、という話が中心になっています。

Shin Kuboaki

March 25, 2024
Tweet

Other Decks in Programming

Transcript

  1. Object-Oriented Conference 2024 3 今⽇の話題 • みんな、モデルを作らなくなった…? • モデルを作らなくなったのはなぜか •

    これまでの時代とこれからの時代 • 再びモデルの必要性が⾼まる • 次の時代に備える • いまのうちに培っておくべきちから • いまの仕事の中で培う⽅法 • それに使えるツールと⽅法 2024/03/24 ©Change Vision Inc.
  2. Object-Oriented Conference 2024 5 Googleでトレンドを調べてみた※1 • どうやらUMLやオブジェクト指向のモテ期は過ぎた? • 特別ではなく⼀般的なものになった模様 •

    ということは、みんなUMLでモデル図を描いているってこと? 2024/03/24 ©Change Vision Inc. 2004/1 2014/1 2024/1 ※1 https://bit.ly/3PzLaQq
  3. Object-Oriented Conference 2024 7 どうして作らなくなったの? • 以前は…頼れるモデルがなかったからかも? • システムの構造や振舞いは⾃前で作っていた •

    実装する前に考えることが多かった • 実装技術の発展にフレームワーク等が追いつけていなかった • RailsやSpringBootが登場する前のことって覚えていますか? 2024/03/24 ©Change Vision Inc. ※1 SmalltlakのSystem Browserの例 https://cuis-smalltalk.github.io/TheCuisBook/A-brief-introduction-to-the-system-Browser.html もっともっと昔: クラス図もなかった時代 (Smalltalkのブラウザ) でも、この時代に戻って いるような印象…
  4. Object-Oriented Conference 2024 8 どうして作らなくなったの? • いまは、頼れる環境がある • ⾯倒⾒のよい、リッチなフレームワークとサポートライブラリがある •

    普遍的な構造や要素の構築は、ライブラリやフレームワークに移動した • ベースを継承すれば、アプリの構造はできている • デザインパターンに沿って実装できる ©Change Vision Inc. 2024/03/24
  5. Object-Oriented Conference 2024 9 どうして作らなくなったの? • モデルの関⼼はドメインモデルへ移った • 業務フロー、ビジネスロジック •

    会社の利益構造やDXのために重要な、業務領域固有のもの • そして、ドメイン駆動設計(DDD)がやってきた • 業務領域の開発において、モデルはとても⼤切 2024/03/24 ©Change Vision Inc. 翔泳社 https://www.shoeisha.co.jp/book/detail/9784798121963f 増⽥さんほかDDDなすごい⽅々の有益な セッションがあるので、私はここには踏 み込まないでおきますね…(笑)
  6. Object-Oriented Conference 2024 10 どうして作らなくなったの? • さらに使えるドメインモデルも既にある分野では… • 安定して使えるモデルがあるから、それを使えばよい •

    似たサイトの資産があれば、同じような作りを提案できる • 遵法な商売はどこでも似ていてるのがわかった • 販売、財務、給与、在庫管理、CMS、eコマース、... etc. • 楽天にお店を出すなら、店舗と品物のデータを作れば済む • だからSAPやSalesforceが席巻した(UIのことは…) • 実装になってから考えることが減った • すぐ実装できるなら、作って動くものをユーザーに⾒てもらえる • 設計書を作って、「これでちゃんと作るから」って約束しなくても済む ©Change Vision Inc. 2024/03/24
  7. Object-Oriented Conference 2024 11 どうして作らなくなったの? • フレームワークとドメインモデルが揃ったから • 他⼈から提供済みのものを使えば済む領域が増えた •

    アプリ(フロントエンド)が差分開発のホットポイント 2024/03/24 ©Change Vision Inc. フレームワーク インフラ アプリ ドメインモデル フロントエンド ✓ ✓ ✓ ✓: 使うモデル
  8. Object-Oriented Conference 2024 12 どうして作らなくなったの? • モデルを作るにしてもツールが⼀⻑⼀短 2024/03/24 ©Change Vision

    Inc. ドローイングツール PlantUML モデリングツール ◯ 記法に縛られない 共同編集できるもの が多い Webから使える テキスト形式 コードリポジトリと の相性がよい ⾃動レイアウト 記法や制約をガイドす る モデル要素として扱う △ 記法や制約をガイド する 図としてしか扱えな い 複雑な図を描く 頭に図が浮かばない とコードが書けない レイアウトの指定 専⽤アプリが必要 共同編集 コードリポジトリとの 相性が悪い
  9. Object-Oriented Conference 2024 13 どうして作らなくなったの? • ウェブページやUIにUMLは向かない? • かつてはモデルでUIをなんとかしようとしていた •

    「UML User Interface」で検索すると⾒つかるのは論⽂ばかり • 本だとだいたい1990年代 • Building Web Applications with UML • User Interaction and Interface Design with UML • Constructing the User Interface with Statecharts • その後はあまり取り上げられていない • 最近は、どんなふうに捉えているか • 本質的にはデータストリーム系の処理になっている • 関数型を使っていなくても、関数型になじむような処理が向いている 2024/03/24 ©Change Vision Inc.
  10. Object-Oriented Conference 2024 14 どうして作らなくなったの? • 「モデルは使う時代」になった • 業務ドメインの既存モデル+リッチなフレームワークとライブラリ •

    実装して試す⽅がはやくなった • ⼤部分の設計が済んでいるのなら、すぐ実装できる • 新しく作る場所のコードを作れば済むから • UIは、モデルで書くよりコードを試したほうが可否がわかる • 視覚的な確認、動作のフィーリング、Seleniumなどによる⾃動テスト • 設計書とかモデル図が、みんな同じに⾒える • 現状のモデルで表せている部分は差が少ないから • でも、モデルは必要 • ドメインモデルもフレームワークも使っているんだから 2024/03/24 ©Change Vision Inc.
  11. Object-Oriented Conference 2024 15 組込み現場はちょっと違う • ドローン制御の例 2024/03/24 ©Change Vision

    Inc. 事例は、平鍋、ドローンの数学・物理・制御基礎より https://speakerdeck.com/hiranabe/math-physics-and-dynamics-of-drone-in-hakoniwa 航⾏等の機能を ドローンにやらせる ドローンをちゃんと⾶ばす (操作量を求めてドローンへ渡す) ドローンから位置や 姿勢の情報を得る ドローンへの 航⾏の指⽰ 全体がドローンを使ったアプリのモデル ドローンを制御するためのモデル ドローンを制御する際の座標系 (操作や観測の対象)
  12. Object-Oriented Conference 2024 16 組込み現場はちょっと違う • ドローン制御の例(続) 2024/03/24 ©Change Vision

    Inc. 事例は、平鍋、ドローンの数学・物理・制御基礎より https://speakerdeck.com/hiranabe/math-physics-and-dynamics-of-drone-in-hakoniwa 得られた操作量の計算 式をコードに変換 ローターの推⼒・トルクから 機体の位置と姿勢を求める 計算⽅法を定める ローターの推⼒・トルク から機体の位置と姿勢を 求める⽅法のモデル
  13. Object-Oriented Conference 2024 17 組込み現場はちょっと違う • かつては⼿書きを信じていた • ⼝頭で頼む →

    特定の領域の制御と実装の経験値の⾼い職⼈が請負う → アセンブラやCで書く → 実機で動かす • モデリングとかいう代物は相⼿にされなかった • 「なんとか⽣成とかそれ⼤丈夫なん?」 • プログラムで作ったコードなんぞ信⽤できんら • 「モデル?なに?それって動くの?」 • 動かんなら作らんのと同じやな • 「うちのアセンブラコードのほうが、⼩さくて早くて正確よ」 2024/03/24 ©Change Vision Inc.
  14. Object-Oriented Conference 2024 18 組込み現場はちょっと違う • いまは「怖くてコードは⼿で書かせられない」 • リーンバーン、ハイブリッド、複合動作…で、やること増えすぎ •

    ⼿書きコードでは制御不可能に • ⼈はモデルは作るけどコードは作らない • 考えながらコードを書くのは危険(安全や品質のためにも) • 数式をモデルとしたシミュレーション → 動作に必要なコードを全て⽣成 → HILSや実機で実⾏ • MATLAB/Simulinkとオートコーダー(コード⽣成器)が普及 • シミュレーションして動くとわかってからコード⽣成 • 設計の情報をもっとコードからモデルへ移す • ちゃんとしたシミュレーションのためにも • 欲しいコードに到達するためにも 2024/03/24 ©Change Vision Inc.
  15. Object-Oriented Conference 2024 19 オブジェクト指向の変遷 • オブジェクト指向の発展の歴史※1 2024/03/24 ©Change Vision

    Inc. ※1 「オブジェクト指向の発展の歴史」⽇経クロステック https://xtech.nikkei.com/it/article/lecture/20070710/277100/
  16. Object-Oriented Conference 2024 20 オブジェクト指向の変遷 • まずプログラミングから始まった • Smalltalkは1970年代、Javaは1995年、Rubyは1998年※1 •

    構造化とかERとかステートマシンは割と古い • オブジェクト指向分析・設計の元 • 構造化やERは1970年代、HarelのStatechartsが1987年 • オブジェクト指向分析・設計は上記の20年後 • S-MやBoochやOMTで1990年代後半 • モデリング記法が統⼀されるのはさらに10年後 • UMLのドラフト(0.98)が1998年、UML 2.0は2004年 ©Change Vision Inc. 2024/03/24 ※1 初の公開の年、誕⽣は1993年2⽉24⽇(毎年のメジャーリリース⽇) https://logmi.jp/tech/articles/279858
  17. Object-Oriented Conference 2024 21 UML以前はこんな時代だった • オブジェクト分析と設計 : オブジェクト指向21⼿法の解説と徹底⽐較 •

    アンドリュー T.F.ハット (編), 1995. • 世界中の先⽣⽅が、オブジェクト指向分析・設計の必要性を説いていた • でも、こんなにたくさんあったら、同じ⼿法使える⼈を調達できない… 2024/03/24 ©Change Vision Inc.
  18. Object-Oriented Conference 2024 22 再び歴史は繰り返す(かもしれない) • 実は、いまは「プログラミングの時代-その2」 • みなさんがモデルを作らなくなって5年?10年? •

    もうすぐ実装やってられない時代に(組込みをみよ) • Smalltalkを思い出す(彼らはOOをわかっている連中だった) • そして、「分析・設計の時代-その2」がやってくる • 実装段階では対処が難しい、煩わしいことが増えてくる • セキュリティ、セーフティ、⼤規模なIoT・System of Systems • そして、その煩わさに対処する分析・設計⼿法が出てくる • ⽣成系AIの台頭が予感させている? ©Change Vision Inc. 2024/03/24
  19. Object-Oriented Conference 2024 23 再び歴史は繰り返す(かもしれない) • 新しい仕事のやり⽅に変わり始めている(すでに) • 既に世の中の何処かにあるもの使う⼈ •

    ⽣成系AIに頼んでやってもらうことが増える • 新しい道を作る⼈ • 「⽣成系AIへ焚べる」ような成果を⽣み出す ©Change Vision Inc. 2024/03/24
  20. Object-Oriented Conference 2024 24 再び歴史は繰り返す(かもしれない) • 新しい⽅法に合う⼿法や記法がほしくなる • 表現⼒の拡⼤ •

    ⼿法や記法を⽀援するツールも必要になる • 作るものはコードではなくなるだろう • モデル、AIへの⼊出⼒の⾼度化 • より設計で決め、記載することが多くなる • 実装しながら決めていたことがらが、設計(モデル)に移る ©Change Vision Inc. 2024/03/24
  21. Object-Oriented Conference 2024 26 どんなちからを備えるべきか • 分析や設計についてモデルで考える頭が必要 • コードを書きながら考えていたことが、設計(モデル)へ移る •

    考えていたことをモデルの情報として表現できる • 具体的なコードのない(動かせない)場⾯でも • システムの要件や機能、構造や振舞いを検討できる • 分析や設計はモデルで表現・議論するちからが必要 • その表記はUMLではなくなっているかもしれないが… • AIに対しても、コードではなくモデルでやり取りすることになる • ⾃然⾔語であっても、AIと交換できるなら話すことばはモデルになる 2024/03/24 ©Change Vision Inc.
  22. Object-Oriented Conference 2024 27 コードで考えるからモデルで考えるへ • いまはコードで済むことを別の表現でも表せるように • コードでは済ませられない話に合わせられるように •

    コードじゃないと表せないと思い込まない • 「わかりにくいから図にしてこい」 • どうして図の⽅が、コードや⽂章よりわかりやすいんでしょう? • 2つあります • 「図のほうがわかりやすい」を活かすには • モデルの持つ効⽤を知る • それに⾒合う整理と表現に慣れておく 2024/03/24 ©Change Vision Inc.
  23. Object-Oriented Conference 2024 28 モデルを⽬に⾒える形で表現する • 実際に図を描いてみる • 頭に浮かべるだけでなく、⼿やツールを使って •

    ぼんやりとしたものは、他⼈やAIと共有できない • ⾒える形、送受できる形で表して、初めて他へ伝えられる • 図を描くにはなんらかの表記が必要 • 数式、回路図、Simulink • UML、SysML、将来登場する表記法? • 図を描くにはツールが必要 • ホワイトボード • ドローイングツール • モデリングツール? 2024/03/24 ©Change Vision Inc.
  24. Object-Oriented Conference 2024 29 モデルで詳細を表現できるようになる • コードで伝えていたことと同様な情報を伝える • モデルの情報とプロセスが適⽤する変換規則からコードが作れる •

    システムの構成要素や振舞いのデータ化(テーブル化) • モデルには機能・仕様のことばが使われる • ドメイン駆動の主張が⽣き残る • コードにはドメインのことばが残っているべき • プラットフォームとドメインのつながりもモデルで表す 2024/03/24 ©Change Vision Inc.
  25. Object-Oriented Conference 2024 30 モデルで詳細を表現できるようになる • コードに直すのに必要になる情報をモデルに収める • プロセスが適⽤する変換規則もモデルで表してみる •

    レガシーなコードもクラスなりライブラリにみなして • 詳細を記載するならモデリングツールが必要 • 詳細を記載する記法に対応している • 詳細を編集できる機能をツールのエディタが持っている • 特性(属性や操作と)識別できるように保存できる • モデル要素の間の整合をとる • システムは複数のモデル図の組合せで表す • 複数のモデル中の要素や情報の整合を⼈が担保するのはムリ 2024/03/24 ©Change Vision Inc.
  26. Object-Oriented Conference 2024 31 PlantUMLのコードをツールで編集してみよう • AI等でPlantUMLでモデルを作ってもらう • もしくは、他の⽅法で作成したPlantUMLのコード 2024/03/24

    ©Change Vision Inc. @startuml class main_task class OS class touch_sensor{ +is_pressed() : void } class motor main_task --> OS driver --> motor porter --> touch_sensor class porter{ +transport() : void } main_task --> porter porter --> OS class driver{ -dr_power : int +init() : void +turn_left() : void +turn_right() : void +stop() : void } class color_sensor porter --> touch_sensor class ultrasonic_sensor{ +get_distance() : void } class speaker class timer{ +start() : void +stop() : void +is_timedout() : bool +is_started() : boolean } porter --> timer timer --> OS porter --> speaker porter --> ultrasonic_sensor porter --> driver porter --> color_sensor @enduml
  27. Object-Oriented Conference 2024 33 PlantUMLのコードをツールで編集してみよう • モデル図を確認する • できたモデル図と頭の中で考えていたモデルとの違いを確認する •

    モデルを編集して情報を増やす • ⼊出⼒が思った通りでないなら • プラグインの不備 2024/03/24 ©Change Vision Inc.
  28. Object-Oriented Conference 2024 37 まとめ • モデルは使う時代になった • 歴史が繰り返すなら、ふたたびコードからモデルへと移る •

    実はAIの台頭がその端緒 • 再びモデルの必要性が⾼まる • 次の時代に備える • モデルで考える頭 • モデルを⽬に⾒える形に表現する • 精密なモデルで表現する • いまの仕事の成果でやってみてる • いまあるツールを使ってやってみる ©Change Vision Inc. 2024/03/24
  29. Object-Oriented Conference 2024 38 モデリングツールへの要求も変わった • 困っている場所は移動した • これまでツールが⽀援していたところから、違うところへ移動した •

    いま困っているところを解消する⼿段になる • いまかかっている⼿間を、コードを書いて試すより素早く楽にできるか • そこではオブジェクト指向やUMLとは別の表現がいるのかも • いまの開発環境にフィットする機能・使⽤感がいる • Webブラウザで利⽤できる(インストールレス) • 共同編集、分散編集とマージ • モデルや図の版管理、成果群のタグづけ • 開発環境との⼊出⼒(API、オートメーション) • ⽂書の中の図なら埋め込みが、できないなら⽂書が作れる ©Change Vision Inc. 2024/03/24 うちもまだまだ がんばります!