のた犬のうまい猫めし

どら猫が作る、のた犬のための飯、略称、どら飯について語りつつ、各種技術、経済系セミナーに参加した報告、OSSいじってみた等のネタを入れていきます。更新情報はtwitterの@nota_inuにて。

モデルベースソフトウェア開発コミュニティ#1

技術ネタ UML・モデリング

第ゼロ回（キックオフ）のまとめ：

notainu.hateblo.jp

 

【「実践 UML モデリング」株式会社テクノロジックアート代表取締役長瀬嘉秀氏】

  • 「独習UML」他80冊以上の著書があるらしい。
  • 「コンポーネントベースのモデリング」：あらかじめ部品化を意識し、システム化範囲を分割し、分割の単位でクラス図を描く。クラス爆発の可能性が低いが、分けるのに失敗すると爆発する。
  • CBOP（ビジネスオブジェクト推進協議会）の「コンポーネントモデリング分科会」があり、プロセスの例について議論されている。
  • OMGのMDAに対応させ、CIM、PIM、PSM。
  • CIM（コンピュータ処理非依存、外部仕様）：アクティビティ図を使った業務分析。ユースケ図・非機能要件・画面・シナリオで要求分析。
  • PIM（プラットフォーム非依存、内部仕様）：オブジェクト図、クラス図で構造分析、相互作用図、ステートマシン図、クラス図で振る舞い分析。
  • アーキテクチャ検討、プラットフォーム設計。
  • シーケンス図を書いているとクラス図に操作が挿入されていく。Presentation層、ドメイン層、……。
  • MVCモデル。マッピング。HTML/JSP、Servlet、JavaClass、DB。PIMとPSM。

 

【「そのまま動作するモデル」としての生産管理システムの実例　渡辺　幸三（わたなべ　こうぞう）氏】

  • 業務システム開発における動的制御型MBSDの実践。

  • MBSDには二種類ある。目標が違うため。

  • １）コード生成型。モデルからコードを生成する。コーディングの手間を減らすのが目的。

  • ２）動的制御型。モデルをそのまま動作させる。コードそのものを減らす。モデルがそのまま動けばよいよね、と。個々の開発案件でコードを扱うことが非効率、必要悪、という価値観。コード含有量が高ければ負け。コード行数とファンクションポイント。

 

＜＜動的制御型MBSD基本テーゼ＞＞

  • ドメインの階層化：上位ドメイン：専業開発分野。下位ドメイン：個別案件。専業を上流と決めて、定義の一つとして下位を考える。（？？？）　上位ドメインを規定し、差分が下位。

  • DSLとDSPの準備：DSLは上位ドメイン固有言語。DSPは上位ドメイン固有プラットフォーム（Domain Specific Platform。DSL用のエディタとドライバを擁する開発基盤。）

  • アプリ定義の極小化：処理の類型に基づき、個々のアプリを差分として様式化。処理のパターンを類型。システム定義が信じられないほど小さくなる。生産管理システムを2MB程度に収められたり。従来コードが抱えていた仕様を、ドライバに持たせる。全部パターンとしてドライバにロジックを持たせる。

 

＜＜動的制御型MBSDで＞＞

  • 究極のアジャイル型開発。アジャイル＝コードを愛している人たち、だが、コードを一行も書かないアジャイルもあり、では。業種業態別リファレンスを起点とするスプリングボード型開発。開発案件ライブラリがまとまっていく。レファレンスモデルが教材として使える。

  • 人海戦術が要らなくなる。アジャイル＝チーム開発が好き、だが別に孤独でもいいのでは（おひとりさま開発。フルスタックエンジニア＋クライアント）。

  • 契約単価が上昇する。準委任契約に基づく士業化。フルスタックエンジニアでないとダメ。

  • 動的制御型MBSDのためのモデル表現：UMLはコード生成向け。ERD、DFDはPIM、仕様書はPSMとして有効。PSMはそのまま動くもの。仕様書は人だけに理解可能なプログラミング指示書である限り革新が生まれない。仕様書を、人にも機会にも理解可能な「プログラムの在り方を示すモデル」としたい（＝そのまま動くモデルとしての仕様書。）

  • XEAD　editor（http://homepage2.nifty.com/dbc/）。仕様書の集まり。メニュー仕様書、画面等を階層保存、表示。テーブル仕様書とか機能仕様書とか。パターンが準備されている。実行するとそのまま動く？？（XEAD Driver）。コードを生成するのではなくドライバが仕様書を読み込んで起動しているとか。（なんかすごいなぁどこまでできるのかなぁ。http://d.hatena.ne.jp/kurokouji39/20140522　を見る限りMicrosoftSQLServerとはつながる？）

  • 質疑応答：テーブルのセキュリティは？→メニュー設計で対応できたりする。（発注担当はxxメニューしか見えない、とか。）ログインした人の所属情報（セッション）とテーブルスクリプトでどうの。

 

【EclipseCon 2015 レポート（Eclipseにおけるモデルベース開発技術の現状と動向）ビューファイブ LLC代表社員田中　明（たなか　あきら）氏】

www.slideshare.net

 

 

Eclipse Con 2015　NA Report。NorthAmericaに行ってきた報告。参加者数775名、日本からの参加は田中氏だけだったとか。
EclipseはIDEという認識が主、という感じだが、今はたくさんのプロジェクトがある（https://projects.eclipse.org/search/projects/?keys=）。検索からModeing選ぶと４０個くらいも出てくる。Eclipse Working Groupというものがあり、Automotive、Location、Science、IoT、Polarsys（組み込み系）とかもあったり。何をしているか、は2014年のAnnualReportがよい（https://eclipse.org/org/foundation/reports/annual_report.php）。ActiveProjectの数とかCommitterの数とか公開されている。
EclipseConferenceは、Eclipseに関する最新情報を提供する場として年３回開催されている。フランス、北アメリカ、ヨーロッパ。それぞれ過去の情報も見える。

  • 　DSL：Xtextは米国でも適用事例が増えている。
  • 　TextUML。テキスト形式でアクションを含むUML記述を行い、Xtendでコード変換を行いクラウド上で実行するプロジェクト。（Xtextとは別系統。）
  • 　EMF Forms：EMF/EcoreモデルからUI生成。
  • 　PolarSys：SimuLinkとEMFのimport/export。
  • 　Xtext：Pythonスタイルモデル記述（インデント）、新FomatterAPIで表形式モデル。IntellijIDEA対応。GitHubへ移行。（スライド：「THE FUTURE OF Xtext」参照。http://www.slideshare.net/sefftinge/future-of-xtext）BEGIN、END区切り。クラウド上のIDEを作るとか。
  • 　Diagrams, Xtext and UX：ダイアグラムはできるが双方向ができないとか。FXDiagram。（Java FXが使われている。）Show in FXDiagramでEclipseから開く。プラグイン依存関係を表示できたりとか。
  • 　Graphical DSL：Sirius＋Xtext、Arduino designer。Siriusのランタイムの上で動き、モデル表示できる（？）。
  • 　UML-RT tool（リアルタイムUML）
  • 　TextUML Toolkit。CloudFire。
  • 　Acceleo：コード生成。
  • 　PolarSys：Massif、Papyrus-RT（UMLツールのRT版。LinkedinのExecutable UML Group参照。）本当にできれば、という印象だとか。
  • 　Capella timelapse。公式サイトに動画とかがあるので雰囲気がつかめる。
  • 　ViewPoint：

 

【BridgePoint を用いたモデルデバッグと自動生成　　ETロボットコンテスト本部審査員　土樋　祐希（つちとい　ゆうき）氏】

www.slideshare.net

ETロボコン実行委員会。BridgePoint自体は昔からある。シュラーメラー法：xtUMLの前身。
ETロボコン：ボディは決まっており、プログラムで対決。32kRAM、256kROMをいかに使うか。コースを走ったり、デモさせたり３つの部門がある。http://www.etrobo.jp/2015/
BridgePoint：xtUMLの方法論を取り入れたツール。モデルを記述し、萌えるのまま動作させ、最終的にはモデルをソースコードに変換する。モデルの変換は変換ルールで実施。昨年からOSS。（以前のブログ記事：http://notainu.hateblo.jp/entry/2015/02/09/213712）
開発プロセスとしては２点。１）と２）はMarkingファイルで変換（？）。

  • １）ドメインモデルの構築。分析モデルの作成、修正、動作確認、コード生成、動作確認。
  • ２）変換ルールの構築。モデルをプラットフォームに変換するためのコンパイラ。Marking使用方針。

モデルはクラス図、ステートマシン図。組み込みでは状態が重要。ステート内のアクションを専用尾アクション言語（抽象度高い）で記述する。アクション言語はいろいろな言語に変換可能で学ぶのはあまり難しくないらしい。
Verifierで、モデルをコンパイルすることなくそのまま実行、モデル検証可能。
モデルとMarkingファイルを入力としてコード生成。モデルは既存の外部コードと接続でき、BridgeとFunctionという仕組みがある。モデルで書いたものがIFとなるFunction、既存のIFを取り込むBridge。
デメリットとしては、モデルの書き方が特殊（継承ポリフォリズムがない）、環境に合わせた変換ルールを用意するのが大変。（メタモデル、プラットフォームなど幅広く知らなければいけない。ただしルールを作る人のみ。ロボコン用にはルールは準備されている。）
メリットはプラットフォームを意識せずコードレビューしなくてよくなる。モデル、変換ルールを再利用しやすい。モデルとコードがかい離しない。


ロボコン用ロボットは二輪で倒立させる。センサを用いて制御するクラス（Balanced robot。）最後にイベントを投げて起動。ボタンが押されるのを待って、ジャイロセンサー誤差補正し、タイマー仕掛ける。……でEclipseで実行の確認して（ステートマシン図が色が数秒ごとに変わったりする）、Cygwinでコンパイルし、USBケーブルでROMで読み込ませ、ロボットが動く、と。
モデルで動作することを学ぶと、どのくらいをモデルで書けばよいのかわかるので、通常の分析、設計にも有効だと感じられる。