astahによるUMLモデリング

2018/06/07

7/7土の第2回astah関西の見所 #astahkansai

2018/7/7土にグランフロント大阪で、第2回astah関西勉強会を開催します。
勉強会の見所と、最近僕が考えているモデリングに関する問題意識についてラフなメモ書き。

【告知】
astah関西 第2回勉強会 - connpass

【参加申し込み】
Osaka Mix Leap Study 特別編 - astah関西 第2回勉強会 - connpass

【過去の資料】
第1回astah関西勉強会の感想 #astahkansai: プログラマの思索

【告知】astah関西 第1回勉強会を7/14金に開催します #astahkansai: プログラマの思索

【1】今回のテーマは、「開発現場のモデリング事例紹介」です。

(引用開始)
実際にastahを使っているエンジニアに、開発現場でastahを使ったモデリング利用事例を語って頂きます。
具体的には下記になります。

・astahをより良く使えるためのTips
・リバースエンジニアリングによるモデリング技法に関する事例
・STAMP等の機能安全規格のモデリングに関する事例
・astahを使って、匠メソッドによるビジネスモデリングを行う事例
・astahのRedmineプラグインの利用紹介

また、グループディスカッションでは、モデリングの初心者も気軽に質問できたり、モデリング経験者の経験談を共有できる場を設けます。
(引用終了)

第2回勉強会では、チェンジビジョンの開発者の方2名だけでなく、astahフレンドというastah公認ユーザ、匠メソッド勉強会スタッフをお呼びして、幅広く講演していただけることになった。
たとえば、ビジネスモデリングやリバースエンジニアリング、astahのより良いTips、STAMP等の機能安全規格など、業務システム設計に限定されず、幅広い充実した内容になった。

【2】「モデリング思考とモデリングツールは表裏一体である」という考え方

スタッフ打合せで、@kawakawaさんから「astahとモデリングのどちらをやりたいのですか?」という質問があった。
また、稲田さんから「勉強会の目的、ターゲットは何ですか?」という質問もあった。
以下、自分の考えを書いておく。

僕は以前から、モデリングの技術とその思考にはIT業界に入ってからずっと興味を持っていた。
理由は、いくつもの失敗プロジェクトの原因には、プロジェクト管理やチームビルディングだけでなく、システムを業務やアーキテクチャの観点できちんと設計できていなかった事の方が多いのでは、と痛感していたから。

そのうち、astahを使って、自分が思いつくまま、ラフなスケッチをたくさん書いてきた。
そうするうちに、モデリングという思考技術とモデリングツールは表裏一体ではないか、と感じてきた。

たとえば、UMLでは7つのダイアグラムを用いて、一つのシステムを複数の観点で徹底的に分析する。
UMLの中に、複数の観点でシステムを分析する、という思考方法が既に埋め込まれている。

あるいは、データモデリングでは、T字形ER手法のように、マスタとイベントの間の外部キー・複合キーの制約には、業務上の制約が反映されている、という考え方がある。

「データモデリング入門-astah*を使って、TMの手法を使う-」はとても良いモデリング資料: プログラマの思索

業務ロジックをデータモデリングはどこまで表現できるか?: プログラマの思索

そういうモデリング作業で重要なノウハウというものは、紙でモデルを書いてもいいが、モデリングツールを使うことで自然に身に付く、という場合が多いことに気づいた。
実は、モデリングツールの機能に、そういう数多くのノウハウがいくつか埋め込まれているからだ。
他に、モデリングツールを使うと、気軽にモデルを描けるため、自分の頭で空想していたモデルを書き出すと、たくさんの矛盾や曖昧さが出てきて、色々書いていくうちに、気づきが多くなる、という経験もあった。

そうして、数多くのモデルをモデリングツールで描くことで、自分の中に数多くの暗黙知が溜まってきているのは感じていた。
だから、そういう経験をコミュニティと言う場でみんなと共有して、議論を深めたい、という気持ちがあった。
たぶん、僕なんかよりも、もっと深く考えている人はたくさんいるだろうし、そういう人たちと数多く議論して、気づきを得たい。
あるいは、自分が持っているモデリング上の問題意識を公開することで、誰かに気づきを与えたり、逆に、自分が教えられる場合があるかもしれない。

例えば、モデルと設計書、プロセスの間で発生する「モデルの粒度」「モデルのトレーサビリティ」「モデルの変更管理・構成管理」に関する疑問は、astahに限らず、モデリングツールを使いながら、ずっと問題意識を持ち続けてきた。
その辺りも色々議論してみたいと思っていた。

astahで設計書とモデル、プロセスをつなぐ為の資料のリンク: プログラマの思索

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿: プログラマの思索

モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか: プログラマの思索

そういう僕のわがままな要望に賛同してくれたスタッフが数多く集まってくれたことで、昨年初めてastah関西コミュニティを開催できたし、今年も開催にこぎつけることができた。
ゆえに、astah関西のスタッフには特に感謝したい。
そして、第2回勉強会に既に多数の参加申し込みもあり、とてもワクワクしている。

| | コメント (0)

2018/04/28

第62回IT勉強宴会のメモ~2人の方法論者によるデータモデリング激レア対談

昨夜の関西IT宴会「2人の方法論者によるデータモデリング激レア対談」が開催された。
自分が後で読み直すために、殴り書きのメモ。
自分の感想も入れておく。
DOA屋さんから見れば、理解してないな、と思われるかもしれないが、気にせずに公開しておく。

2人の方法論者によるデータモデリング激レア対談 - connpass

2人の方法論者によるデータモデリング激レア対談<第62回IT勉強宴会in新大阪> | IT勉強宴会blog

【1】By 佐野さん
オブジェクト指向は、ゲームや組込みシステムには向いているだろう。
しかし、業務システムのように、帳簿組織を起源に持つシステムには、オブジェクト指向は向かない。
帳簿組織の業務はデータモデリングすべき。

【2】By 佐藤さん
昔はT字形ERだったが、今はTMと呼んでいる。
中身は別物。
(注:その意味は、後述)
(注:僕はT字形ERの本しか持っていないので、以後は、T字形ERと書く)

TM手法はOOAみたい、と言われる。
理由は、astahで描けるから。

注:たぶん、下記の記事のことかな?
「データモデリング入門-astah*を使って、TMの手法を使う-」はとても良いモデリング資料: プログラマの思索

T字形ERの対照表は、OOAの関連クラスと同じ。

【3】By 渡辺さん
AS400の頃に、RDBを本格的に触り始めた。
私は理系なので、「テーブルA:カラムa, b, c・・・」とモデルを書いていたが、周りのSEが全く理解してもらえない。
しかし、具体的にモデルを書くと、SEも理解してくれる。
仕方なく(?)、今の渡辺式ER図のようなデータモデルを書いている。

その頃に流行した4CLでモデルのテンプレートを作り、システムを自動生成するような仕組みを作っていた。
そして、自分で、Delphiでモデルのテンプレートを作り、システムを自動生成するようなモデリング支援ツールを自作していた。
それが、今の三要素分析手法のきっかけ。

感想:
DOA屋さんがOOA屋さんと同じくモデル駆動開発に行き着くのは、モデリング支援ツールを作りたかったという動機があるんだろうな、とふと思った。

【4】By 佐藤さん

Coddの論文を元に、商用ベンダーは商用RDBMSを実装した。
しかし、実際にRDBをそのまま使うとパフォーマンスが出ない。
DBMSには、性能が悪化しないように工夫している。
だから、DBMSの仕組みを理解しないと、パフォーマンスが出ない。

T字形ERは、Coddの弱点に気づいて理論として構築した。
でも、まだ欠陥が残っていた。
TM手法を構築して、佐藤さんの中では完全に解決した。

【5】By 佐野さん

OOAを毛嫌いする理由は、関数従属性を前提にしないこと。
モデルでは、単なる関連で書いている。

【6】By 渡辺さん

三要素分析法は、ER図、DFD、アクションツリーから成る。
データの形はER図、仕事の連携はDFDやアクションツリーで表現される。

データの形が決まれば、画面UIはほぼ確定してしまう。
また、データの形が決まれば、バッチ処理も決まってしまう。
仕事の連携が決まれば、システムの機能(仕様)も決まる。

そういう発想から、三要素分析法は生まれた。

XEAD Tools and Resources - 設計方法論 三要素分析法(TEA Method)

【7】By 佐藤さん

インデックス設計でアクセスパスが自然に決まる。
T字形ERでは、アクセスパスは自然に実装される。

なぜモデルは普及しないのか?という質問に対し、
モデルはあって当然。
それをユーザの環境に合わせて、どのように導入するか?をモデラーは考えるべき。

【8】By 渡辺さん

経理マンの専門知識をデータモデルで表現すると、システムの知識を知らない経理マンも、そのデータモデルを理解できる、という経験をした。
そして、経理マンは勝手に自分達でモデルを描き始める。
そういう経験を経て、モデルの重要性を感じている。

注:懇親会で佐藤さんに、T字形ERでは、顧客のビジネスをデータモデルで表現した時、イベントとリソースのテーブルの個数を数えて比較する。
その時、イベントの個数がリソースの個数よりも少なければ、顧客の潜在的なビジネスモデルを構築できる可能性がある、という話を読んで、すごく納得した、と僕は話した。
つまり、イベントとリソースの組合せで新たなイベントを作り出せる可能性があること、それは顧客の新たなビジネスモデルを構築することにつながることと同じ。

すると、佐藤さんから、ああ、その話では続きがあって、そのデータモデルを顧客に見せたら、顧客自身が自分達でビジネスモデルを作り始めたんだよ、と言われた。
その話と同じかな。

リソース数がビジネスの可能性に関係する理由: プログラマの思索

候補キーと2次識別子に関する概念: プログラマの思索

【9】By 佐野さん

情報系の大学の学生は、学校でデータモデルを習わない。
UMLは習うのに。
彼らも、Postgresは知っているし、使える。
でも、中身のテーブルは全てサロゲートキーになっている。
関数従属性を気にしていない。
そもそも関数従属性を考える、という行為すらしていない。
テーブルは単にデータを格納するだけ、にすぎない。

【10】By 佐藤さん

元々RADを目指していた。
T字形ERで設計すると、当時100万ステップのプログラムのうち、7割は不要になる。

でも、いつも背中から撃たれた。
同業者から嫌われる。

たとえば、大手SIのSEから、T字形ERみたいなこんなに正規化しすぎるとパフォーマンスが悪くなりますよ。
だから、パフォーマンス向上のために、あえて非正規化を施し、森羅万象テーブルみたいに1個のテーブルに300個以上のカラムを設計する、みたいなデータモデルを作ってくる。

「大規模集積回路モデル」と「板チョコモデル」: 設計者の発言

SIでは、生産性を上げたくない。
人月商売なので、開発者の人数が減ると売上が減ってしまうから。
SIは、高価格で、バグ込みのソフトウェアを納品しているんですよ、と。

【11】By 佐野さん

T字形ERはモノありき、のように感じている。
(注:たぶん、業務システムのリプレース案件では、DOAが最強だからだろう、と思った)

他のDOAの流派でも、AsIsベースが多い。
例えば、請求書をデータモデルにする、とか。

渡辺式DOAの凄い所は、いきなりToBeを描く所。
何もない所から作る。

注:懇親会で佐藤さんから、T字形ERは他のDOAと違う。
他のDOAの流派は具体論ばかり話す。
T字形ERは理論から始める。
だから、数学基礎論から勉強し直した、と言われたのが印象に残った。

Oracleを初めて触り始めた頃、OracleでSQLを書くと、テーブルをJoinした時、小さなテーブルを先に読むとパフォーマンスが遅くなる。
Oracleの中身を知らないと、なぜSQLのパフォーマンスが悪化するのか分からない。

真因は、DB設計できていないから、SQLのパフォーマンスが出ないことにある。
だから、SQLは重視しない。
むしろ、真の問題はデータモデリングにある。

X-TEA Driverの面白い所は、複数のDBも扱える。
例えば、マスタはOracle、トランザクションはPostgres、とかでもOK。
しかも、複数のDBのテーブルもJoinできる。

また、データモデルと業務の整合性も事前にチェックしてくれる。

【12】By 佐藤さん

SQLを何も考えずに書くのは信じられない。

モデルはアトリビュート、インデックス定義が含まれる。
実は、アルゴリズム指示書もある。

その中身は、Input=モデル、Process=アルゴリズム、Output=インデックスのような詳細設計書。
すると、アルゴリズムの部分は、ほとんどプログラム自動生成に近い。
プログラマは不要で、コーダーさんに近い。
SIは不要だね。

【13】By 佐野さん

ORマッパーが普及したので、SQLを書けない人も多い。

一方、SQLマッパーというモノもある。
SQLで書いたモノがオブジェクトになる。
たとえば、下地さんのRMenuではjson形式でSQLを表現でき、そのままパースできるので便利。

注:懇親会で下地さんに聞いたら、RMenuで業務システムを実装したら、最初はあえてインデックスを貼らない。
システムの運用後、データが蓄積されて、遅くなった、と言われたら、該当の画面からjson形式のSQLを抽出し、それをパースしてインデックスを生成して、組み込んでいる。
jsonだからすごく使い勝手がいいよ、と。

【14】By 下地さん

プログラムは使い捨てであるべきだ。
なぜなら、プログラムは資産ではない。
その時限りの費用で計上すべきものだ。

注:その意図は、データモデリングを極めると、テーブル設計さえ確定すれば画面UIはほぼ確定されてしまうので、プログラムはほとんど自動生成できてしまう。
つまり、プログラムで書くべき部分はすごく少なくなる。
すると、プログラムは資産というよりも、データモデルに付随したモノに過ぎない、という考え。

佐藤正美さんも、ソフトウェアを資産と考える考え方は嫌いだ、と言っていた。

但し、会計の理論上では、ソフトウェアは無形固定資産に含まれる。
だから、業務システムは保守フェーズで減価償却費が発生するし、システムの改善は、価値が目減りした資産を増やす行為になるので、会計処理も複雑になるデメリットもある。

注:
アジャイル開発では、ソフトウェア(=プログラム)は、最初は負債であり(なぜなら何もないところに投資するから)、その後、キャッシュを生み出して売上を上げていき、損益分岐点を超えたら初めて黒字になるイメージだ。
そういうアジャイル開発の考え方と整合性は取れるか?

プロエンジニアになるための「アジャイル開発」再入門

「プロエンジニアになるための「アジャイル開発」再入門」が素晴らしい: プログラマの思索

| | コメント (0)

2018/03/09

PlantUMLを使ってExcel設計書をテキスト化するアイデア

以前、Excel設計書をテキスト化できないか、考えたことがあった。
ネットしながら、PlantUMLや他ツールを使ってExcel設計書をテキスト化するアイデアをメモ。
以下は、後で自分が参考にしたい記事をリンクしておく。

仕様書にもExcel脱却が求められている: プログラマの思索

【参考1】
PlantUML 埋め込み AsciiDoc の Gradle を用いた HTML 一括変換 ・ Yutaka ?? Kato

【参考2】
AsciiDoc と PlantUML と mermaid.js で素敵なテキストベース仕様書ライフ

【参考3】
PlantUML を導入するのに適したケースとは - kkeisuke blog

(引用開始)
以下のいずれかに当てはまる場合、PlantUML はプロジェクトの生産性を向上させます。

一人で利用する場合
少数精鋭、もしくは統制(教育)されたチームで共有したい場合
情報共有ツールがすでに浸透している場合

PlantUML が解決している課題
UML を理解していなくてもそれっぽい図が書ける
誰が書いても体裁が揃う
検索が可能
バージョン管理システムと合わせると履歴管理の生産性が向上する

PlantUML は「書く」こと、また適切なツールと併用することで「調べる」ことの生産性を向上させます。
(引用終了)

【参考4】
現場で役立つシステム設計の原則にあるUMLをPlantUMLで書いてみる - Qiita

(引用開始)
システム設計が大好きで大嫌いな皆さん、こんにちは。
突然ですが、皆さんはどのようにシステム設計における ドキュメント腐る問題 に立ち向かっていますか?
ドキュメント腐る問題とは、設計時に作成した各種ドキュメントがGoogle Driveやファイルサーバ上で陳腐化してしまい、現状の正しい状態を指していないことです。せっかく新規参画者がキャッチアップしようとしてもドキュメントが真実を示していないという怖いやつですよね。

解決策としては、各種ドキュメントを、MarkdownやAsciiDoc、UMLはPlantUMLやmermaid、ERDはPlantUMLやerd、画面遷移図はUI Flow、REST-API設計はSwaggerなど、なるべくテキストベースで管理し、GitHubなどのリポジトリで管理することで、(レビューフローなどを適切に設定した上で)コードとの乖離を防ぐ、といったことが一案としてあるかと思います。
(引用終了)

【参考5】
PlantUML言語リファレンスガイドのPDFが素晴らしい。
100ページ以上もあり、丁寧。

PlantUML言語リファレンスガイド PDF

akipiiさんのツイート: "@ogomr さんの記事がすごく役立つ。PlantUML Cheat Sheet https://t.co/xoa9xeeVhj"

PlantUML Cheat Sheet - Qiita

(引用開始)
PlantUML は DSL(ドメイン特化言語) で UML の図を描きます。
テキストで記述するので Git で差分を確認したり GitHub Flow で
関係者とコラボレーションをして図が描けるので便利です。

PlantUML は多くの UML に対応していますが、よく使うものを チートシート にまとめました。
(引用終了)

【参考6】
PlantUMLでMySQLやPostgresSQLのER図を生成できるようになったらしい。

Database to PlantUML - データベースの内容からER図を生成 MOONGIFT

Hywan/Database-to-PlantUML: Compile PostgreSQL and MySQL table information into a PlantUML description.

achiku/planter: Generate PlantUML ER diagram textual description from PostgreSQL tables

はてなブックマーク - GitHub - achiku/planter: Generate PlantUML ER diagram textual description from PostgreSQL tables

【参考7】
??...さんのツイート: "PlantUMLで境界づけられたコンテキストとアプリケーション層の設計してみてるんだけどコーディング感覚で書けるしパッケージ設計までできるので実装イメージしながら書けて楽しい"

akipiiさんのツイート: "面白いな。RT @c6h4clch3: シナリオ製作者よ...PlantUMLを使うのです...関係性や時系列などを表すのに便利なテキスト->図の変換ツールです...添付画像はあるシティシナリオにおける探索者と警察、一般人、神話生物との関係性を例にしたものになります...是非ご確認ください... https://t.co/wDfgVTBZNo"

akipiiさんのツイート: "いいね!RT @morimasa1970: @gogotea3 最近、RedmineにPlantUMLのプラグインを導入したんで、フロー図はその辺でがんばろうと勉強中です。"

choroyonさんのツイート: "PlantUMLいいな これなら方眼Excelからおさらば出来る???… "

yojikさんのツイート: "VSCodeのPlantUMLエクステンションがめちゃくちゃ良い。リアリタイムでプレビューしながら書けるだけでこんなに気持ちよく使えるとは。今までつかったモデリングツールの中でもトップクラスの使用感!これこそ顧客(俺)が本当に欲しかったものだ。。"

N.Cさんのツイート: "PlantUMLの導入終わったー! これでコード書いてキャラ相関図作れる! 必要なやつダウンロードしてPC再起動したら使えるよ!?( 'ω' )? やりかたはこちらです https://t.co/Sbl72dGjEd なお、試しに作った画像がこちらです… https://t.co/qPHL28ko8u"

なべや まいこさんのツイート: "数日前にシナリオ書くのに便利!と話題になってた『PlantUML』をWordで動かしてみたので、記事を書いてみた。日本語記事見当たらなかったので、もしかしたら書けば誰かが助かるかな、と。 WordでPlantUMLを動かしてみた(その1)|note(ノート) https://t.co/QGB0FWzgEd"

WordでPlantUMLを動かしてみた(その1)|なべや まいこ|note

【参考6】
PlantUMLは惹かれているのだが、astahで描く方が今は手に馴染んでいる。
下記の意見も同意している。

u6k_yu1さんのツイート: "ちょっと思い返したけど、書き散らすときは紙かホワイトボードでグリグリやって、整理するときにastah使ってる。PlantUMLはテキスト管理のしやすさから何度か試用しているけど、うーんという感じだった。"

岡本卓也さんのツイート: "自分もその感じです。astahはホワイトボードの延長で、思考を直感的に書き出すのに向いてる。『あ、この箱とこの箱は会話しそうだから線で繋ぐか』みたいな。 PlantUMLはここで『線で繋ぐなら文法はこうか?』みたいなワンステップ入るのが辛い。確かにテキストなのでgitとの相性は良いんですがね。… https://t.co/uLQFaWD8uv"

astahとPlantUMLが同期できるといいのだが。

【追記】
akipiiさんのツイート: "これはいいね!確認してみたい。RT @htomine: パフォーマンス見て問題無さそうだったらQiitaにも実装します :+1: / “PlantUML対応、記事のコピー機能を追加しました - 生産性を向上させる情報共有ツール - キータチーム(Qiita:Team)” https://t.co/neyBNqB620"


| | コメント (0)

2018/01/18

AstahのRedmine連携プラグインが公開されました

AstahのRedmine連携プラグインが公開されました。
とても使いやすいので気に入っている。
ラフなメモ書き。

【参考】
Redmine連携プラグイン | Astah

ChangeVision/astah-redmine-plugin: Associating Redmine tickets to a diagram

【1】astahを使いながら、モデリングという作業に、変更管理や構成管理の概念が反映されていない点にずっと違和感があった。
その問題意識は下記に書いた。

モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか: プログラマの思索

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿: プログラマの思索

描いたモデルは、一度書いたらそれで終わりということはない。
頻繁な仕様変更、洗練された設計思想へ反映などの作業で、モデルはどんどん変化する。

また、モデリング作業を行っていくと、数多くのモデル間の整合性を考慮していくうちに、モデルが変化する。
さらに、モデルの粒度を考えながら、モデルをリファクタリングすることもあるだろう。

つまり、モデル間の粒度やトレーサビリティを考慮すると、モデルの変更履歴をどこかで保持したくなる。

しかし、astahにせよ、EnterpriseArchitectやRationalRoseにせよ、モデルのファイルはバイナリのため、Gitで履歴管理してもあまり有り難みがない。
また、モデルの変更箇所をノートや吹き出しで追加していくうちに、モデルが醜くなってしまう。

【2】では、上記の問題点はどうやって解決できるか?

根本的な解決方法ではないが、モデルの変更履歴はRedmineチケットへ外出しすることで、モデルの変更管理や構成管理の問題点はある程度解決できるはず、と僕は考えている。

つまり、モデルの変更履歴のように、モデルのある時点のスナップショットとなる履歴情報は、Redmineチケットで管理すべき、と考える。
そうすれば、モデルは常に最新の仕様を反映した状態で保持すれば良い。
モデルが色んな事情で変更された経緯は、Redmineチケットの内容で確認すればいい。

たとえば、Excel設計書に必ず付属する変更履歴シート、昔のJavaのJavaDocにあった@historyのようなソース変更履歴コメントは、そもそもRedmineで一括管理すべき情報だから。

【3】上記のRedmine連携プラグインでは、下記の機能を持つ。

1)astahのモデル(実際はUMLダイアグラム等)の単位で、Redmineチケットを登録・参照できる
 仕組みとしては、RedmineのREST APIを使う。

2)astahのモデルとRedmineプロジェクトは1対1に対応付けられ、Redmineチケット一覧が表示される。
 astahで表示されたRedmineチケット一覧では、ステータスや優先度などのチケット項目でソートできる。

3)astahの全モデルのRedmineチケット一覧も表示できる。

4)但し、astahにはRedmineチケットの基本的情報を表示するだけであり、詳細な情報はRedmine上で編集する運用になる。
 Redmine上で編集した情報をastahへ同期する場合、「Sync」ボタンを押せばよい。

【3-1】Redmine連携プラグインによって、astahモデルから、モデルの変更履歴の吹き出しの情報は全てRedmineチケットへ外出しされる。
Redmineに蓄積されたモデル変更のチケット情報は、Redmineの優れたチケット集計機能でいくらでも分析できる。

たとえば、モデルのレビュー記録チケットから、レビューの効果やモデルの品質を計測してもいい。
また、モデルのアーキテクチャや要望が未決定のため保留となっている箇所は、課題チケットに外出して、未解決リストとして扱ってもいい。
あるいは、Redmineチケットはタスクと見なせるから、将来のモデル修正のToDoリストとして使ってもいい。

すなわち、astahのモデルに付属するRedmineチケットのビューは、「モデルの変更履歴」だけでなく「モデル修正のToDoリスト」だったり、「モデルの未解決の課題リスト」として扱うこともできる。

【3-2】そういう複数の観点でRedmineチケットを管理できれば、astahのモデルの作業管理が大変やりやすくなるだろう、と思う。
なぜなら、モデルは一夜で完成するものではなく、数多くの顧客要望を五月雨式に反映したり、他要件を考慮しながら洗練させていく作業のために、たくさんのToDoや課題が発生するからだ。
それらのTODOや課題を漏れなく管理していくことは、とても重要だから。

【3-3】そこで、astahのモデルのRedmineチケット一覧画面で、各項目をソートできる機能が有効に役立つ。
たとえば、ステータスでソートして、未着手・作業中のチケットを一覧の上部に表示するようにすれば、TODOリストのように扱える。
あるいは、優先度でソートして、優先度の高いチケットを画面上部に表示すれば、直近で最優先のタスクを判別できるようになる。
さらに、トラッカーでソートして、障害や課題チケットのみに注目してもいい。

実際にRedmine連携プラグインを使っていくと分かるが、モデルの変更作業の情報をチケットに起票していくと、じきに10件、50件とチケットが増えていく。
そして、完了チケットと作業中チケットがたくさん混じってしまい、管理しにくくなる。

だから、変更履歴として見たい時は、ステータスの降順でソートする一方、TODOリストとして見たい時はステータスの昇順でソートするし、課題リストとして見たい時は、トラッカーでソートしたくなるだろう。

【3-4】さらに、Redmineチケットの情報をもっと詳しく書きたいなら、astahではなく、Redmineチケットに書き込めばよいだろう。
そうすれば、Redmineの優れたチケット集計機能や全文検索機能で、欲しい情報をいくらでも集計したり検索できるようになる。
また、Wikiとリンクさせて情報を集約させることもできるだろうし、モデルのTODOリストとなるチケットを元に、Redmine上で進捗管理してもいい。

すなわち、astahではモデルそのものの要件や仕様を描くことに注力し、課題やTODOはRedmineで管理するように、区別して管理すればいい。
つまり、モデルの作業そのものの進捗管理、課題管理はRedmineで代用できるし、その方がRedmineの優れた機能を利用できるメリットがある。

但し、モデルそのものの履歴管理、つまりモデルの構成管理はRedmine単体だけでは実現できない。
モデルがどのように変化したのか、実際に見たい、という要望は、上記のプラグインでも実現されないので注意。

【3-5】astahユーザがRedmineを使っているならば、Redmine連携プラグインはたぶん使いやすいと思う。

似たようなastahのプラグインとして、TODOプラグインなどがあったけれど、TODO一覧がastahモデル単位に表示されないので、TODOが溢れると探しにくくなる弱点があった。
また、TODOをソートできない弱点もあり、TODOが多くなるとイマイチな面があった。
でも、Redmine連携プラグインで、それらの弱点は全て解決される。

【4】僕は、astahのようなモデリングツールとRedmineやTestLinkなどの開発支援ツールと外部連携することは、とても発展の余地があると考えている。
なぜなら、astahのモデルと外部の開発支援ツールが連携することで、数多くの情報を相互に参照しやすくなり、色んな使い道が出てくるからだ。

実際、Redmine連携プラグインによって、astahのモデルの変更履歴がRedmineチケットに蓄積されるだけでなく、モデリング作業の進捗管理やモデルの課題管理を行えるようになる。
また、TestLinkとastahがもし連携できれば、テストケースと要求図を相互リンクできて、要件カバレッジを出力できたり、トレーサビリティマトリクスを出力する、という機能も実現できるかもしれない。

よって、モデリング作業を開発プロセスの一部に取り込んでしまい、昨今の優れたプロセス支援ツールの機能を流用して相乗効果を得る、ということもできるのではないか。

あるいは、astahで設計したモデルに関する情報を超高速開発ツールに取り込んで、即座に開発していく、というモデル駆動開発も実現できるかもしれない。

この辺りの構想も今後まとめる。

【追記】下記の要望があがっていた。
上記のRedmine連携プラグインは、astahモデルから、変更履歴や課題一覧、ToDoリストをRedmineへ外出ししているに過ぎない。
最終的には、モデル自身の構成管理、つまりモデルの変更履歴を保持する仕組みが必要になるだろう。
つまり、モデルのライフサイクルを管理する枠組みが必要になるのではないか。

岡本卓也さんのツイート: "Redmineチケットからastahダイアグラム方向への参照(クリックで図に飛ぶ)が出来ると素晴らしいのですが、そうなるとastahファイル自体がシングルトンで共有できてて欲しい。 と言うようなことを開発者の人とも話してました。… "

岡本卓也さんのツイート: "確かに現状では難しいですよね。ただ、モデリングの目的(の1つ)がコミュニケーションだとすると、モデルを共有して検討を積み上げる機能が欲しいなと。 astah Shareが健在なら、、ってよく思います。… "

| | コメント (0)

2017/12/30

モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか

下記の記事で、モデルの粒度とトレーサビリティの問題はモデリングツールではなくUMLそのものに真因がある、という事実に気づいたのでメモ。
以下、ロジカルでないラフなメモ書き。

【参考】
プロジェクトを成功させるモデリングの極意(3):UMLやSysMLなどのモデリングは“いつ”“何を”“どうするのか” (1/8) - MONOist(モノイスト)

akipiiさんのツイート: "「UMLの使いにくいところと開発現場での実際的対応」の内容が本当に同感。UMLそのものが大規模案件で使うことが想定されてない問題があると思う。プロジェクトを成功させるモデリングの極意(3):UMLやSysMLなどのモデリングは“いつ”“何を”“どうするのか” (1/8) - MO… https://t.co/qHIjmtpMKt"

【1】(引用開始)
UML/SysMLの使いにくいところと、それを使いこなすコツ
 UMLとSysMLは組み込み系開発で比較的多く使われていますので、ここではUMLとSysMLの使いにくいところと、開発現場でそれを克服して使いこなすコツを紹介していきます。

UMLの使いにくいところと開発現場での実際的対応

(1)階層記述ができない
 UMLで大規模なシステムをモデリングするときに、使いにくい欠点としては「階層記述」ができないという点を挙げることができます。大規模なシステムでは、ユースケースやクラス、オブジェクト、シーケンスなどの個数が膨大な量になり、ユースケース図やクラス図、シーケンス図などを描くときに階層記述ができないと非常に大きな紙が必要になります。A3用紙であっても描ききれなくなります。

 そこで開発現場では何らかの工夫をして、これらの図を階層記述をしているのが実情です。しかし、階層記述の方法が統一されていないため、各組織や各プロジェクト、さらに個人で違う記述をしていることがあります。結果として、階層記述の方法を確かめるところから、レビューを始めるということになります。

(2)要求図が弱い
 UMLで要求をまとめる図はユースケース図とそれを補間するシナリオ記述、さらに詳細に記述するためにアクティビティ図などを用いますが、要求図としての分かりやすさとしては不十分です。

 ユースケース図で要求とそれらの概略の関係は分かりますが、要求の一覧や要求間の関係、特に内包関係、要求の差分、要求の優先度などの記述は弱いものになっています。それを補間するシナリオ記述は基本的に自然言語で記述するため、モデラーの表現能力に大きく依存します。逆にアクティビティ図は機能がありすぎて、要求を記述すると別の図のようになってしまいます。

 開発現場ではユースケース図で要求の概略を表現し、詳細や一覧は昔ながらのExcelを使って自然言語で記述し、それに要求番号を振って、トレーサビリティを高めているような記述方法をよく見かけます。

(3)仕様が膨大で不統一
 UMLはその歴史から分かるように、モデル図と仕様が膨大になっていて、その思想も記述も不統一です。平たく言えば、図がばらばらで多すぎます。図が多いので、真面目なメンバー(融通がきかないメンバー)はどうしても多くの図を描いてしまいます。類似の情報を複数の図やその説明で見かけることになります。さらに悪いことにその用語や使い方がモデル図間で統一されておらず、同じ用語でもモデル図で違う情報になっていることもあり、どれを信用するか分からなくなります。まさしく魑魅魍魎な図になりがちです。

 開発現場では新規の開発よりも既存開発(改良開発)が多く、既存の多数のUML図をほぼコピペして再利用していることが多くなっています。コピペで低コストなのはいいことかもしれません(本当はそんなことはありません!)が、図が多いため、差分管理ができずに、全ての図の全ての部分を延々と保守続けることになります。いざ差分を探そうとすると、非常に面倒なことになります。

(4)トレーサビリティが弱い
 各モデル図で使用した要求やクラス、オブジェクト、シーケンスなどが他の図でどのようになっているかを追跡するときに、UMLでは弱すぎます。UMLツールによって、ある程度のトレーサビリティは保証されますが、図として見た場合は、トレーサビリティがなく、見にくくなっています。

 開発現場では、ここでもUML図とは別にExcelなどを使って、トレーサビリティを保証するようにしている場合が多くなっています。

(5)目的が総花的
 仕様が膨大という欠点と同様ですが、UMLを描く目的が曖昧になるとUMLで作ったモデルも総花的になりがちです。このため、モデル図は大きくなり、大きな紙(A3用紙)を必要とします。

(6)コード生成が弱い
 UML2.0になってコード生成は強化はされていますが、UMLでコード生成をするのは弱く、はっきり言って、使いものになりません。特に例外処理のコードも含めると面倒なことになります。最初の1回はコード生成をしても、その後、プログラムを変更する必要が生じたときに、モデル図から変更するのは骨が折れます。心が折れます。

(7)差分表記(相違性と共通性の表記)が弱い
 これはUML特有の欠点ではなく、多くの図的表現に当てはまりますが、以前のシステムとの差分、以前のモデル図との差分の記述が明示的にできません。ソフトウェアプロダクトラインエンジニアリング(SPLE)で使われるフィーチャー図のように差分を明示的に記述できません。開発現場では前のモデル図とどこが変わったのか、逆にどこが同じなのかを何らかの方法で記述し、共通部と差分(派生部)を明確に示す必要があります。

(5)その他のコツ
 UMLの各図では目的を絞って描く、コード生成には使わない、一覧表示などの管理は別にするなどがあります。
 ここではUMLの悪口とその対応の面倒くささを紹介した形になりましたが、これは逆に開発現場でUMLが定着し、使っている人が多いからこそです。この記事を読んで別のものを使おうとせずに(苦労はするかもしれませんが)UMLを使ってみてください。
(引用終了)

【2】astahをずっと使い続けてきて、モデルの粒度とトレーサビリティ、変更管理に関して不満があったので、その問題点について下記で考えていた。

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿: プログラマの思索

しかし、上記の記事を読むと、モデリングツールの問題ではなく、UMLの仕様そのものに真因があるようだ。
UMLでは、アーキテクチャを描いたモデルの階層化やトレーサビリティに関する仕様またはプラクティスがほとんど見られない現状がある。

一方、実際の開発現場では、要件定義から基本設計、詳細設計へ工程が進むにつれて、モデルの粒度はどんどん詳細化していく。
もっとモデルを詳細化すべきだ、という認識になったら、普通は次フェーズの工程で作業するように予定する。
つまり、各工程の設計モデルに関する粒度については、基本は設計者の間で認識は統一されているのが一般的だ。

また、要件から画面帳票の詳細設計書に至るまで、普通は設計書の間でトレーサビリティを確保するように、開発プロセスを計画する。
なぜなら、各工程のアウトプットが次工程のインプットになるので、トレーサビリティを意識しなければ、詳細設計書の正当性を保証できないからだ。
一般に、Excelの管理台帳で、要件定義書、基本設計書、詳細設計書の一覧を管理し、それらの間の関係を何らかの形で保守し続ける。

そういう現実を考えると、UMLでは各工程の成果物の粒度やトレーサビリティに関する基本方針がない点に問題があるような気がする。

【3】では、なぜ、UMLでは粒度やトレーサビリティに関する問題点にあえて触れていないのか?

理由はおそらく、粒度やトレーサビリティに関する仕様は、各案件で多種多様な運用ルールがありうるので、標準化する作業そのものが難しいからだろう、と推測する。
もし、粒度やトレーサビリティに関する標準ルールを決めたとしても、抽象的すぎて、実際の現場では、その仕様に耐えうるテーラリングにすごく時間や労力を費やすしかないのではないか。

似たような事例として、過去に、IPAがソフトウェアタグという仕様を定めて普及しようと頑張っていた事例があったけれど、実際の現場にはほとんど影響しなかった。

IPA 独立行政法人 情報処理推進機構:ソフトウェアジャパン2009 IPAフォーラム

コンピュータソフトの開発過程が一目でわかる仕組みを世界で初めて規格化 複雑化、大規模化する製作状況に対応した「ソフトウェアタグ」|奈良先端科学技術大学院大学

理想論としては、ソフトウェアタグのような符丁をソフトウェア成果物に組み込めば、農産物や製品のトレーサビリティのような運用が可能なはず。
しかし、ソフトウェアはそれらモノとは違って、実体が曖昧で管理しにくいために、現実に運用しにくい。
結局、粒度やトレーサビリティに関するExcel管理台帳が余計に増えていくだけで、その保守コストが増えていくだろう。

【4】また、UMLで変更管理や構成管理の問題を解決するアイデアはないのか?
UMLの仕様に関する最新情報は知らないので、この辺りは分からない。

しかし、UMLでモデルをお絵描きしても、その後の保守で問題となるのが、構成管理や変更管理の話題だ。
実際、本番リリース後の保守フェーズで、細かな仕様追加や仕様変更が発生すれば、その都度モデルを修正していくコストが発生する。
その作業コストは意外とバカにならない。

また、仕様変更前のモデルと仕様変更で変わった後のモデルの差分を表示する機能がモデリングツールでは弱い。
だから、その後の保守作業で、作業者が頻繁に入れ替わったら、変更理由や本来の意図も分からなくなりがちだ。

さらに、Gitならフィーチャーブランチを切って、マージする時にプルリクエストを送ってコードレビューを依頼する、という一連のプラクティスをモデリング作業に適用しにくい。
つまり、モデリングのレビューは、昔ながらのレビュースタイルで実施せざるを得ない。

モデルの構成管理、変更管理に関する問題は、10年以上前からほとんど進歩がないように思える。

【5】さらに、UMLそのものにその弱点が内包されているとすれば、どんな影響が出てくるのか?

僕は、大規模システムでは特に、モデルの粒度とトレーサビリティに関する枠組みがなければ、現実的に運用しにくいだろう、と考えている。

たとえば、大企業向けのERPは、販売管理、発注管理、生産管理、会計管理、人事管理など数多くのサブシステムで組み立てられている。
それらサブシステム単位に要件から仕様まで数多くのモデルがあり、それらが階層化されて、トレースされていなければ、描いたモデルは設計書の代わりにはならない。

また、描いたモデルの粒度について認識が合わなければ、設計者と開発チームのコミュニケーションを促進されないだろう。
さらに、大規模システムでは、数多くのテーブル、画面帳票、バッチがあり、機能が複雑に絡み合っているので、元々混乱しがち。

10年以上前に、オブジェクト指向開発プロセスが流行していた頃、全ての設計書をEnterprise Architectのモデルで描いて、Javaで実装するWebシステム開発案件に加わっていたが、内実は混乱していたのを思い出す。

【6】このように、UMLの仕様そのものに、モデルの粒度とトレーサビリティ、変更管理の問題が内包されているので、その仕様そのものを実現したモデリングツールもその問題点をそのまま現状に反映しているだけ、と理解できる。
つまり、モデリングツールに罪はない、と僕は考えた。

一方、モデリングツールがUMLの弱点を解決していく、という方向性もあるのではないか、と考えている。
つまり、モデルの粒度とトレーサビリティ、変更管理に関する問題は、むしろ、モデリングツールが積極的に解決できる分野ではないか、と考えている。

実際、業務フローやアーキテクチャをモデリングしていたら、モデラーは自然に、自分が描いているモデルの粒度を揃えたり、詳細化していく時にトレースしながら仕様を詰めているはずだ。
よって、モデリングツールが、モデラーの思考行為そのものを支援するように操作性を向上させることは可能なはずだ。
つまり、モデリングツールは、モデラーのモデリング作業を補完する統合設計環境であるべきだろう。

その辺りも今後考えてみる。

【追記】
モデル駆動開発の考え方について、良い記事があるのでリンクしておく。

モデル駆動開発におけるモデル変換の役割 (1/2):CodeZine(コードジン)

akipiiさんのツイート: "モデル駆動開発用ツールBridgePointを使って、クラス図とステートマシン図を作成して実際にシステムを動かすお話。面白い。モデル駆動開発におけるモデル変換の役割 (1/2):CodeZine(コードジン) https://t.co/StxjQjZ8pg"

| | コメント (0)

2017/12/16

Friends of astah*になりました

このたび、Friends of astah*になりました。
とても嬉しいです。

【参考】
Friends of astah*

振り返ると、自分は10年以上前からastahを使っていたんですね。

【再考】GanttProjectとFreeMindとJude: プログラマの思索

astah*Professionalファーストインプレッション: プログラマの思索

本格的にastahを使い始めたのは、Redmineによるチケット駆動開発の開発プロセスをUMLで分析してみよう、と思い立って色々描いていた時。
その頃は、アクティビティ図とステートマシン図、配置図がメインだった。

我流のプロセス分析をしながら、色んな気づきがあった。
たとえば、プロセスの例外処理はJavaやVBスクリプトの例外処理に似ているなあ、と思った。
また、プロセスが複雑な理由は組織の構造や権限をそのまま反映しているからだ、と気づいた。
つまり、コンウェイの法則そのままじゃないか、とか。

また、要件定義でシステム構成図、機能構成図、業務フロー、データモデルを書きながら、それぞれのダイアグラムにトレーサビリティという関連があること、粒度を保ちながらレイヤ化という思想で詳細化していく、という発想も身を持って体験できた。

こういう体験は、モデリングツールがあったからこそ、できたのだろうと思う。
なぜなら、Excelやパワポで絵を描くと、ちょっとしたレイアウト変更だけで労力を費やして、本来明示したい設計思想を忘れてしまいがちだから。
また、ダイアグラムを試行錯誤して描くことで、複数の観点でモデルを分析することが自然に身に付くし、各ダイヤグラムのトレーサビリティや粒度を気にするようになるから。

一般に、日本企業では、設計書は日本語という自然語で記述するのが普通。
しかし、日本語では主語が明示されていない、構造が明確化されていない、などの弱点があるので、いくら詳しく書いても必ず漏れる。
巻物みたいなExcel設計書をたくさん書いても、その後のマイグレーション案件では役立たない。

むしろ、A3の1枚用紙に描いたシステム全体概要の方が役立つ時もあったりする。
そんな経験もあって、自分の理解も深めるために、astahを重宝している。

しかし、astahも10年以上使っていると、こういう機能も欲しい、という思いも強くなってくる。
そんな思いも書いてみた。

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿: プログラマの思索

また、XPJUG関西メンバーの後押しもあり、astah関西というコミュニティも立ち上げてみた。
来年度も、Redmineコミュニティと合わせて、色々活動してみたいと思う。

astah関西 第1回勉強会 - connpass

個人的には、ソフトウェア工学の実験ツールであるRedmineと同様に、astahも、ツールがモデリング技術の可能性を高める部分が沢山あると思っている。

ツールがプロセスを改善していく。
ツールが開発プロセスに新たな利用シーン、想定していなかった副次効果をもたらす。
ツールがモデリング技術の新たな可能性を開拓していく。

そんなアイデアを色々考えてみたいと思っている。

| | コメント (0)

2017/12/04

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿

astahを使いながら、モデルの粒度とトレーサビリティのあるべき姿について考えたことをメモ。
以下は、最終的には、astahへの改善要望になるだろう。
ラフなメモ書き。

【参考】
astahによるモデリングのメモ: プログラマの思索

派生開発における変更指示をモデルで表現する(問題編) - Qiita

【1】個人的には、astahは好きだ。

astah* オンラインマニュアル

理由は2つある。
一つ目は、他のモデリングツールに比べて、操作が直感的でサクサク描けるから。
astahでUMLのダイアグラムを書く時に、迷うことがないし、サクサク描けるので、アイデアが無くなることも少ない。
一方、他のモデリングツールでは、UMLの各種ダイアグラムを描く時に、どうやって書けばいいんだっけ、と迷う時間が多いと、その間にアイデアは消えてしまう。
また、線を引っ張る時、保存する時にプログレスバーが出て待たされるようでは、イライラしてしまう。

二つ目は、一つのモデルを複数の観点で分析する考え方が自然に身につくことだ。
UMLでは約7種類、他にER図やDFD、マインドマップもあるので、一つのシステム像を表現したい時、静的なモデルだけでなく、動的なモデル、物理的な配置図、論理的なモデル、DOA的な視点、などでも自然に考えるようになる。
複数の観点でシステムの要件や機能を考えることによって、モデルの整合性やトレーサビリティにも気づきやすくなる。

そんな経験をしながら、モデリング技法のあるべき姿について考える時がある。
astahで色々書いていると、まだ何か足りない気がしてくるのだ。

【2】では、astahでモデルを書いていて、何が足りないと感じるのか?
不足していると感じる観点は、モデル間のトレーサビリティと粒度、変更管理に関する内容だ。

【2-1】モデル間のトレーサビリティ

たとえば、要件定義フェーズで、業務フローをアクティビティ図で描いて分析したら、その後、どこをIT化すべきか、という方向に分析が進む。
すると、業務フロー図に出てくるアクターがシステムである箇所で、アクティビティがあれば、そのアクティビティがユースケースに対応付けられる。
それらユースケースを集めると、ユースケース図になり、システムの全体像が定まる。

つまり、業務フローの各アクティビティ→ユースケースへの詳細化が後方追跡性に相当する。

また、各ユースケースは、論理モデルや実装モデルの観点で、クラス図やシーケンス図に分解されていく。
つまり、ユースケース図の各ユースケース→クラス図、シーケンス図への詳細化という後方追跡性が発生する。

しかし、アクティビティ図→ユースケース図→クラス図、シーケンス図へトレーサビリティが発生するのに、それらモデルのトレーサビリティを表現する方法がastahでは直感的に表現されていない。

モデラーの観点では、アクティビティ図のアクティビティをクリックしたら、対応するユースケースに遷移して、さらにユースケースをクリックしたら、対応するクラス図やシーケンス図を選択して表示される、という利用シーンを実現して欲しい。
そうすれば、要件定義→設計へモデルが詳細化されていく作業をトレーサビリティの機能によって補完することができる。

では、なぜそんなにトレーサビリティが必要なのか?
なぜなら、モデル間のトレーサビリティを考えることで、モデル要素の漏れや矛盾に気づきやすくなり、モデルの精度を上げられるからだ。
おそらくどのモデラーも、概要レベルのモデルを描いた後で、詳細化したモデルは別に描き、それらの整合性をどこかで考えているはず。
そういうモデル間の整合性を考える作業を支援する機能が欲しいのだ。

一方、現状のastahでトレーサビリティに相当する機能は、ハイパーリンク機能に相当するだろう。
つまり、モデル要素のリンク機能で十分だ。
モデル要素をクリックしたら、別のモデルへ遷移するように、ハイパーリンク情報を設定すればいい。

しかし、ハイパーリンク情報を設定するには、詳細画面を開き、遷移先のモデルを選択して更新する、という操作が発生し、とても面倒。
この操作を1クリックで操作できるようにしたい。
つまり、遷移元のモデル要素(ダイアグラム)を遷移先のモデル要素にドラッグ・アンド・ドロップすると、自動で相互リンクするようにハイパーリンク情報が設定される、といったイメージだ。
たとえば、アクティビティ図にあるアクティビティをドラッグして、ユースケース図へドロップすると、相互リンクが設定される、というイメージ。

すなわち、ハイパーリンク機能を流用したトレーサビリティの実現は、そんなに難しくないだろうと思うし、その効果はすごく大きいだろう、と考えている。

なお、モデラーの観点では、トレーサビリティの制御は手動の設定で十分だ。
ラフなスケッチでモデルをたくさん描いていくので、そんなに難しい機能は必要ないから。

【2-2】モデル間のレイヤ化、モデル間の粒度

業務システムの設計を開始すると、サブシステムの観点で、作ったモデルをグルーピングして整理したくなってくる。
たとえば、ECサイトなら、注文システム、商品検索システム、バックエンドのマスタ管理システムなど。
すると、普通は、パッケージをフォルダ代わりに使ってモデルをグルーピングして、モデルをどんどん深掘りしていく。
つまり、パッケージによるグルーピングは、モデルの粒度を揃えて整理する作業に相当する。

しかし、astahではパッケージ図でモデルをまとめた時に、モデルの内容が表示されないし、モデルへリンクする機能がない。
モデラーの観点では、パッケージ図に、パッケージでまとめたモデル名(ダイアグラム)が表示され、表示されたモデル名をクリックすると遷移する、という機能が欲しい。
そうすれば、モデルの粒度を揃えながら、モデルのトレーサビリティ機能を使って、モデルの漏れや整合性を考えやすくなる。

なぜ、モデルのグルーピング後のリンク機能が必要なのか?
なぜなら、モデルの粒度を揃えながら、モデルをレイヤ化する作業を行い、各レイヤ間のモデルのトレーサビリティを考えることで、モデルの精度を上げようとしているからだ。
こういうレイヤ化の作業は、設計作業だけでなく、プログラミングにおいても普通に行われている。
レイヤを一つ増やすことで、絡み合った仕様を整理し、ソフトウェアの複雑さを軽減していく手法は非常に重要だし、モデリングツールがそういう作業を支援するようにして欲しい。

しかし、astahではパッケージ図があるものの、EnterpriseArchitectのように、パッケージにモデル要素を表示してリンクする機能がないので、レイヤ化や粒度による整理がやりにくい。
逐一、構造ツリーでポチポチ開いて確認するしかない。
こんなイメージ。

ビュー

なお、現状のastahでは、パッケージやパッケージ図そのものにもハイパーリンク機能があるので、相互リンクさせることは可能だ。
但し、トレーサビリティの相互リンクと同じく、操作回数が多いので、イライラしてしまう時がある。

Enterprise Architectにはこの機能はあるので、astahにあともう少し機能があれば、という所だろう。

追跡(トレーサビリティ) - Enterprise Architect 13.5 日本語版 ヘルプ

ダイアグラムのトレーサビリティについて スパークスシステムズジャパン フォーラム - ユーザー掲示板

【2-3】モデルの変更管理と構成管理

要件定義では、顧客打合せをしながら、要件や仕様をモデルに反映していく。
その反映作業は、ソースにパッチを当てていく感覚と同じだ。
そして、モデルへのパッチ当ての作業は、行ったり来たりする場合も多い。
顧客の要望、実現すべき機能、実装可能な技術の選択、スコープと納期・コストとのトレードオフを考慮しながら、要件を固めていくので、手戻りはよく発生する。

この作業中に、当初作られたモデルはたくさんのパッチが当てられて、どんどん変化していく。
これがソースコードならば、Gitで構成管理されるので、変更理由のRedmineチケットと相互リンクされてどんどんコミットされていく。
そのコミット履歴から、ソースコードの変更箇所が特定できるし、どういう変更の経緯から発生したのか、という変更理由もチケットから辿ることができる。

しかし、モデルは普通は構成管理されていないので、変更履歴が残っていない。
モデルをGitで管理したとしても、差分箇所を表示できないので、日次バックアップにしか過ぎない。

また、各モデルが変更された時に、どんな変更理由で変わったのか、というRedmineチケットとモデルが相互リンクされていない。
よって、なぜモデルのこの部分が変わったのか、という理由を、後から辿ることが難しい。

本来は、モデルであろうとも、Git等の構成管理ツールの配下におき、変更履歴を管理し、チケット経由でトレーサビリティを実現したい。
しかし、その手法が現実的でないならば、せめて、モデルのメタ情報に、変更が発生したチケットNoを埋め込んでリンクする機能が欲しい。

そういう機能がないと、モデルに数多くのノートが作られて、いつどんな理由で変更された、というコメントがたくさん混じりこんでしまう。
この症状は、ソースコードにガラクタのコメントがたくさん残っている状況と同じだ。
残骸となったコメントは後からリファクタリングするのが難しくなるから、そういうコメントは不要。

さらに、メリットとして、Redmine上でモデルの変更履歴を全文検索できるので、保守フェーズで別の開発者が過去の要件や仕様を探しやすくなる。
また、Redmineにモデルの変更履歴が一元管理されるので、そこから、たとえば、レビュー指摘事項の修正件数や手戻りの設計工数などのメトリクスを集計して分析することもできる。

なお、現実的な機能としては、モデルを描いた後で、astah画面右下(拡張ビュー)でチケット登録できて、登録したチケット一覧が表示される機能があればよい。
そして、拡張ビューのチケット一覧で、チケットNoを押下すると、Redmineチケットへ遷移する機能があれば十分。
実際は、RedmineのREST APIキーとURLをastahで保持しておき、astahのモデル上でチケット情報を入力したら、Redmineでチケットが新規作成されて、拡張ビューに新規チケットが表示される、という流れになるだろう。

この機能が実現できれば、モデルの変更理由の一覧がRedmineチケット一覧と同一視できるので、開発工程以後でモデルの変更理由を探す時に役立つだろう。

Enterprise ArchitectにもRedmine連携プラグインがあるので、astahでも同様に実現できるはず。

Enterprise Architect-Redmine連携アドイン

あるいは、Backlogのastahプラグインがあるので、同様にRedmineプラグインをastahで作れるはず。

Backlog Connector for astah

【3】以上をまとめると、幅・深さのトレーサビリティと変更管理という要望にまとめられる。

1)幅のトレーサビリティ→同じ粒度のモデル間のトレーサビリティ

たとえば、1つのユースケースに含まれるクラス図、シーケンス図、ステートマシン図は相互リンクで行き来できる。

2)深さのトレーサビリティ→別レイヤのモデル間のトレーサビリティ

たとえば、パッケージ図において、グループ化されたパッケージに含まれるモデルへ深掘りしながら、リンクして行き来できる。

3)モデルの変更履歴

たとえば、モデルの変更履歴は、外部サーバーにあるRedmineチケットへリンクして確認する。
つまり、モデルの変更履歴の内容は、astahのモデルそのものに書くのではなく、メタ情報として外部サーバーのRedmineへ蓄積され、参照されるようにして、モデルから分離できる。
変更履歴がモデルから分離されることで、モデルは常に最新版の状態だけ保持すればよく、シンプルなモデルになる。

【4】レイヤ化されたモデル間のトレーサビリティが強化されれば、一つの全体的なモデルとして網の目状に紐付けられた成果物になる。
そして、astahのトレーサビリティマップの機能を使えば、相互リンクで紐付けられた状況を一目で見ることも可能なはずだ。

トレーサビリティマップ 【p】

[pro] トレーサビリティマップ

最終的には、さらに、トレーサビリティマトリクスが生成できるといい。
つまり、全てのモデル間で相互リンクがあるか否かを一目で確認できるクロス集計表が出力できればいい。
この機能は、XDDPのトレーサビリティマトリクスに相当するものだろう。

ソフトウエア改造力 - 第6回 改造の影響を調べる:ドキュメントをまとめ作業計画をレビューする:ITpro

XDDP成果物:USDM、トレーサビリティマトリクス、変更設計書

『XDDP』では「トレーサビリティマトリクス(TM)」で変更箇所を特定

このトレーサビリティマトリクスを生成できれば、特に派生開発やソフトウェア保守で、影響箇所の調査にすごく役立つだろう。
設計フェーズの事前調査で、あらかじめ仕様変更によるモデルの影響箇所を即座に把握できるようになるからだ。

また、モデルの変更履歴がRedmineに蓄積されることで、モデルから不要なコメントがなくなり、モデルは常に最新版だけ保持されるようになる。
残骸となった変更履歴のコメントはモデルには不要。
変更履歴の内容は本来、構成管理ツールで管理すべきだからだ。

なお、トレーサビリティの設定はモデラー自身が手動で設定すればいい。
実際、RedmineとGitなどの構成管理ツール連携によるトレーサビリティも、手動でチケットNoを入力することで対応しているので、違和感はないから。

【5】以上のような事を考えると、モデリングツールはまだまだ改善の余地があるし、換言すれば、数多くの可能性を秘めているのだろうと思う。
Redmineのように、ツールを使いながらプロセスを改善していくアイデアが思いつくように、モデリングツールを使いながら設計技法を改善するアイデアは、もっとたくさん出てくると思う。

| | コメント (0)

2017/10/12

astahを起動せずにJavaScriptで情報を取得する方法

tokudiroさんが、astahを起動せずにJavaScriptで情報を取得する方法を公開されていたのでメモ。

astah APIをjjsを使って楽に呼び出す - Qiita

やり方は、java8 のjavascript 実行エンジンjjsを使って、下記のようなコマンドを実行すればよい。
詳細は上記参照。

jjs.exe -cp astah-api.jar;astah-community.jar openProject.js hoge.js closeProject.js -- fuga.asta

使いたい状況としては、astahファイルからクラス情報などを一括出力したい時、hoge.jsにJSスクリプトで取得プログラムを書いておき、JJSエンジンで実行すればよい。
これは便利だ。

astahにはスクリプトエディタがあり、そこにJavascript、Ruby、Groovyなどを書けば即実行できるが、バッチ出力したい状況も多い。
プログラムは使い慣れたテキストエディタや開発環境の方が書きやすいから。
また、astahのスクリプトエディタではなく、プログラムを別ファイルで保存できるので、バージョン管理もやりやすい。

たぶん、JavaScriptだけでなく、Ruby、Groovyでも、上記と同じようなやり方で実行できるだろうと推測する。

利用シーンは、たとえば、本番稼働中の既存ソース群をastahへリバースして、クラス図などで設計図を書き起こした後、astahAPIでソフトウェアメトリクスを計算するJavaScriptをプログラム化しておき、上記のJJSエンジンでメトリクスを一括出力する、とか。

astahのモデルからソフトウェアメトリクスを出力して、既存のソフトウェア工学の理論を実証実験したい時に有効活用できるような気がする。

| | コメント (0)

astahのシーケンス図をPlantUMLへ変換する方法

astahのシーケンス図をPlantUMLへ変換する方法が公開されていたのでメモ。
これは興味をくすぐる。

【参考】
astah*で描いた図をPlantUMLやmermaid用に変換 | astah in 5 min

Avens666/Astah_Jude_UML_export_to_Markdown-mermaid-Plantuml-: Use Astah JS plugin, export astah diagrams data (such as flowchart, class chart ) to mermaid text fomat and Plantuml format

PlantUML インストール方法 - unhurried

UML図を描画するための単純なテキスト記述を使用したオープンソースのツール。

テキストでUMLを書く - Qiita

【1】手順はこんな感じ。

astahのシーケンス図を開く

astahのスクリプトエディタ起動

Jude_sequence_to_plantuml.jsを貼り付ける

スクリプトエディタからRunで実行

実行結果に、PlantUMLのソース(シーケンス図)が出力される

たとえば、PlantUML Web Serverに、PlantUMLのソースを貼り付けると、シーケンス図が表示される。
これは便利だ。

Jude_sequence_to_plantuml.jsを読むと、astahのシーケンス図の要素をAPIで取得して、PlantUMLの記法にセットしているだけでシンプル。
このやり方を真似れば、PlantUMLのクラス図、ユースケース図、アクティビティ図、コンポーネント図などにも適用できるだろう。

【2】PlantUMLを使いたい場面は、UMLの各種ダイアグラムで基本設計や詳細設計の成果物を作りたい時。

以前は、RationalRose、EnterpriseArchitect、Astahなどの設計ツールか、ExcelやVisioなどのOfficeソフトでお絵描きするのが普通だったが、こういうお絵かきツールはちょっとした仕様変更にすごく弱い。

メソッドが1個増えただけで、レイアウトが大きく変わり、お絵かきの修正にかなりの時間が取られたりする。
お絵かきがしたいのではなく、クラス設計に注力したいのに、実際は、線1本のレイアウトに時間を取られる時の方が多くないだろうか?

また、お絵かきソフトは、バージョン管理が弱いので、修正履歴がない場合が多い。
すると、ちょっとした変更で間違えたので元に戻したい、という作業ができなくなる。

そんな場面では、PlantUMLのように、UMLの各種ダイアグラムもテキストで書いた方が楽。
テキストであれば、Gitでバージョン管理できるので、Undo・Redoがいつでもできるので、試行錯誤しながら、設計することもできる。
バージョン管理の環境がない作業は、UndoやRedoができないので、今何をやっているのか、常にログを残して覚えておく、というプレッシャーが残り、本来の創造的な作業がやりにくいように思う。

但し、ラフなスケッチでお絵描きしたい時もある。
だから、astahで書いてPlantUMLに出力し、その後はPlantUMLのソースを修正していく方が楽かもしれない。

【3】上記のやり方を発展させると、以下のような機能へ発展できないか、と思う。

・astahから、PlantUMLの各種ダイアグラム(クラス図、ユースケース図、シーケンス図等)のソースを出力する
・PlantUMLのソースから、astahへリバースしてダイアグラムを復元する

つまり、astahとPlantUMLで相互にエクスポート・インポートできるようになれば、色んな可能性が出てくると思う。
たとえば、astahでラフなスケッチをしてからPlantUMLに出力して、ソース管理する。
本番稼働中の既存ソースをastahへリバースしてクラス図を作り、PlantUMLへ出力してバージョン管理しておく、とか。

あるいは、PlantUMLからastahへインポートして、さらにastahからJavaやC#のスケルトンクラスを出力する、とか。

プラグイン化できたら面白そう。

【追記】
RedmineにPlantUMLを表示するプラグインは、既に公開されている。
海外の開発者のコメントを見ると、好評らしい。

plantuml - Plugins - Redmine

dkd/plantuml: PlantUML Plugin for Redmine

RedmineでPlantUMLを使う事例: プログラマの思索

Redmine で技術仕様書を書こう | Aiming 開発者ブログ

| | コメント (0)

2017/07/16

第1回astah関西勉強会の感想 #astahkansai

第1回astah関西勉強会が無事に終わりました。

参加者は少なめでしたが、参加者層は、普段のアジャイル系の人達とは違った顔ぶりの人達が多かった。
astahを使っているか挙手を尋ねてみたら、大半の人は使用経験があるみたい。

一部の人達から感想を聞いてみると、マニアック過ぎた、という感想から、スクリプトやOffice連携のようなマニアックな使い方は面白いですね、という感想まで様々。
以下、ラフなメモ書き。

astah関西 第1回勉強会 - connpass

【告知】astah関西 第1回勉強会を7/14金に開催します #astahkansai: プログラマの思索

akipiiさんのツイート: "#Astahkansai 第1回目勉強会に参加者23人で狭い部屋が超満員です笑。関西でこんなにastahに興味を持つ人がいたんですね"

Masatoshi 0w0さんのツイート: "コードからモデル、モデルからコードはもちろん、モデルからXML出力やモデルデータ出力からのoffice連携。スクリプトやAPIすごいな。 #astahkansai"

Masatoshi 0w0さんのツイート: "限定的な使い方しかできてなかったことを再認識できました。もっとastah活用しよう。 #astahkansai"

Yoichi Nakayamaさんのツイート: "スクリプトプラグインで色々できそう。今度遊んでみよう #astahkansai"

Yoichi Nakayamaさんのツイート: "細合さんの濃い話面白かった。 #astahkansai"

勉強会の内容は、私から、ユーザの立場からのastahを使った感想やastahを使ったモデル(プロセス、システム設計、ビジネスモデル)の事例紹介。
細合さんから、astahの製品シリーズの紹介、astahプラグインの作り方、スクリプトプラグインを入れてEcmaScriptやGroovyやJRubyでスクリプトを書いてastahにメニューを追加したり、astahのモデルを操作する例、また、Office連携プラグインを入れてastahモデルとWordのクラス図を同期させる例などの紹介。

今回の勉強会では、チェンジビジョン社長の熊谷さんも参加されていて、astah製品の利用事例やastahの使い方のコメントを時々発言されて、とても興味深かった。

たとえば、astahGSNを使って、組込みシステムの開発プロセスだけでなく、業務システムの業務プロセスを設計してモデル化する時、リスク内容をモデルの中に埋め込みたい場合がある。
その場合、モデルに、リスク用のタグやステレオタイプを埋め込んでおき、スクリプトプラグインやastahプラグインを使って、モデルからリスク一覧を抽出して、リスク対策へつなげることもできる、という話もあった。

つまり、単にモデルをツールで描くだけでなく、astahのAPIによってモデルから必要な情報を抽出して別の用途に役立てる利用事例もある。
この手法のメリットは、モデルを再利用できること、さらに、モデルを色んな観点のビューで提供できることだ。
すなわち、個別のユースケースに応じて、モデルを再利用できるわけだ。

この観点は、熊谷さんの言葉「astahでモデルをしゃぶり尽くす」につながると思う。

僕としては、この勉強会を上流工程からのモデリング技法の探求、という観点だけでなく、プログラマの観点で、作ったモデルから、ビューを提供したり、ソフトウェアメトリクスを抽出したり、プログラムでモデルを再利用する議論もしたい、と思っていた。
単なるお絵かきの話だけで終わらせたくなかった。
だから、こういう濃い話ができて面白いな、と思っている。

astahのメリットは、直感的な操作がやりやすく、モデルを描きやすい、というのが最大のメリットだが、もっとプログラマの観点を入れてみたいのだ。

「プログラマの立場からのモデル再利用、モデリング技法の探求の勉強会」みたいな場にできたらいいな、と思っている。

| | コメント (0)

より以前の記事一覧