のた犬のうまい猫めし

どら猫が作る、のた犬のための飯、略称、どら飯について語りつつ、各種技術、経済系セミナーに参加した報告、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で読み込ませ、ロボットが動く、と。
モデルで動作することを学ぶと、どのくらいをモデルで書けばよいのかわかるので、通常の分析、設計にも有効だと感じられる。

 

モデルベースソフトウェア開発コミュニティ（第ゼロ回）　キックオフ　ブログ内記事のまとめ

UML・モデリング 技術ネタ

第0回モデルベースソフトウェア開発コミュニティ　キックオフ　記事まとめ。

 （2015/2/7開催。http://mbsdcjapan.connpass.com/event/10873/　）

 

notainu.hateblo.jp

 

notainu.hateblo.jp

 

notainu.hateblo.jp

 

notainu.hateblo.jp

 

notainu.hateblo.jp

イベント「Webクリエータに告ぐ！　……ツール紹介」

技術ネタ

2015/03/15 　SHIBUYA★LABU　のイベントに参加。HDE社の会場＠渋谷、にて。正式名称「Webクリエイターに告ぐ！？ ツールに頼って余った時間で◯◯しよう！ ～ 注目！制作現場で触っておきたいツール紹介～」

【ツールの選定眼を鍛える】

頼りになるツールをどう探すか。ツールを選ぶ際に「頼りになる」を選定の基準に。忙しいのを何とかするために頼りになるツールを探す。目的用途にマッチしており、使う気にさせ、信頼ができるものを。他の人に紹介できるものを。
ツールで置き換えられること：記録、整理、解析。（言った言ってない論。タスク。バグ報告数。誰のタスクか。バグ解析。）話し合いの材料に。人間はコレを外に出した分、頭の容量が減って他にリソースを回せる。人間は人間ができる仕事を。
→チャット、ファイル管理、タスク管理を使うことで、記録・整理・解析をツールで行うことができる。

 

【チャットツール】

  • 選定基準：ログが残る。プロジェクトごとの部屋。サムネイル画像（部屋とかがすぐわかるように。可視性のあるアイコンを）。引用（内部外部。あのときの時間につぶやいたコレ、とか）の機能性。
  • 運用ルール：チャット上でファイル受け渡ししない（ファイルの更新の保証がない。ローカルの中に古いものが入ってしまいどれが最新かわからなくなる。ファイル管理ストレージでやりとりするように）、関連タスクのID、URLの明記。話題ごとに決められたチャットルームで発言（未来のあなたのため。いつ死んでもいいように、自分が死んでもプロジェクトが回るように）。サムネ画像登録（すぐ判別できるように）、チャットルームが必要なくなっても消さない（ログを残すため。あるいはエクスポートする。過去のやりとりをさかのぼったり検索したり。）
  • ツールの例１：chatwork（http://www.chatwork.com/ja/）　いつのつぶやきへの返信かがよく分かるのが魅力的。ただ機能が多すぎて嫌われることも。
  • ツールの例２：slack（https://slack.com/）　スラックと読む。チャット情報の編集機能で固定のURLとかメモしておけるのが便利。（テストサーバについてとか。）外部引用が優れておりGitHub、Twitterと連携している。GitHubでのコミット情報を流したり、Twitterの特定IDを全部取っておいたり、とか。かなり快適らしい。


【ファイル管理ツール】

  • 選定基準：容量の監視、増減ができる。バージョン管理システムとの連携。メンバーによるアクセス権限。所属組織全員が同じものを使える。
  • 運用ルール：クライアントとのルールと現場とのルールを定義（クライアントは絶対ルール守らないことを前提として割り切った管理するのも手）、チーム内での命名規約。ディレクトリ構造がツリーになるようにフォルダを作る（社内全員が意識する）。バージョン管理システムが導入できる（Git等）。古いファイルルールを無視しない（できるだけ踏襲して現場感を伝えるように。ただ伝統の継ぎ足しは厳しいので提案してみる）。
  • 皆がいろいろな状況の知識を持ち寄ってツールについて議論し、何を選ぶか皆で検討する。
  • ツールの例１：Bitbucket（びっとばけっと、と読む）。Version管理との親和性が良い。https://bitbucket.org/ コミットメッセージを記録できるのが便利。メッセージをWebで開くことで他の人がソース見なくても進捗を把握できる。
  • ツールの例：SourceTree（https://www.atlassian.com/ja/software/sourcetree/overview）。サーバがフランスにあるのでたまに遅いことがあるとか。（会社がフランス）

 

【バージョン管理システム】

  • SVN、Git（ぎっと、と読む）など。複数あるバージョンの差分を記録。ファイルの変更履歴の記録やバックアップ、修正内容や機能追加を復元、修正することができる。
  • 分散型と集中型が存在。SVNとGitを使い分けすると良い。（目的に合わせた管理手段。）
  • SVN（Subversion）（http://subversion.apache.org/）：ファイルを同時に編集することがないリソースで使うのに向いている
  • Git（http://git-scm.com/）：同時に同じファイルを編集するリソースに向いている。


【タスク管理ツール】

  • 選定基準：最低限の登録項目（名称、概要、期限、担当者、ベロシティ）が網羅されているか。作業量の見積もり、記録ができる。現状のステータス（タスクが終わったのか進捗中なのか）。全員が閲覧できる。
  • 運用ルール：タスクには必ず担当者を作る。期限切れを放置しない（やりたいこととやることを一緒にしないようなタスクのきりかたをする）。見込み・実動向数の記録（見込みとどう違うかをあとで確認できる）。タスク粒度を細かく。詳細は後ほど、をしない（詳細欄を書くところにすぐ書かないと絶対やらない）。
  • TiDD（TicketDrivenDevelopment）：チケット駆動開発。TicketFirst。NoTicket,NoCommit。タスクが発行されることでリソースが動く。チケットが出てから仕事をする。チケットがなければコミットしなくて良い。無駄なリソースが発生しない。（チケットがないのになんか忙しそう……はダメ。）
  • ツール例１：Trello（https://trello.com/）　小規模なものに向く。運営の確認とかToDoにすべて発行して、メンバーどうしが何をやっているか等にも使える。アカウントがあればだれでも。背景変えたい場合は課金。個人的に「今日のタスクはコレ」が日報管理に良い。常にChromeにつけっぱなし、で使っている。
  • ツール例２：JIRA（有料）（https://www.atlassian.com/ja/software/jira）。インタフェースのラベルを変えられる。Backlog、ToDo、Doing、Done等。レポートの出力がすごい良い。いまどれだけ時間が費やされているか等。検索システムも優れている。公式の英語動画を見るべし。
  • ツール例３：producteev（https://www.producteev.com/）（ぷろだくてぃーぶ、と読む。）スピード感が優れている。インタフェースは英語。

 

【まとめ】

 

タスクの記録、整理、解析は道具に任せて、コミュニケーション、やるべき仕事に集中できるように。

 

【質疑応答】

  • SubversionとGitの使い分けは？　→　Gitは同じファイルを複数で、は向いているが、全員がソースコードを修正することは意外にない。Version管理を触ったことがない人にGitが説明しにくい　　→　講演者様からご指摘があり修正しました。「Gitは同じファイルを複数で編集するようなことに向いているので、ソースコードファイルの管理がベスト。しかし、稀なことが無い限りは同時に編集をしないデザインカンプやドキュメント等はSVNでいいのでは。」　　（……たしかにプログラムソースでも小規模だとよほどのことがないと同じファイルをほかの人と一緒に修正かけることはないですよね）
  • チケット管理をエンジニアが守らないんだけどｗ　できないものは見ないふりをするとか　→　次の次のリリースにはFixしたいからチケット発行する、等。誰かが管理するとか。（増えすぎたり消えない・期限切れの場合。）
  • 会社で揃えられるの？　→　うちはばらばらだよ。でも揃えようとしている。チャットはchatwork一つ。

 

【その他】

HDE（会場提供会社）からの紹介。クラウドセキュリティ「HDE one」。一つのアカウントパスワードでの統一的管理。