astahによるUMLモデリング

2019/05/16

GSNの利用事例のリンク

 

astahブログにGSNの利用事例が紹介されていたのでリンクしておく。

GSN広めよう活動奮闘記?三菱電機エンジニアリング株式会社様? | astah in 5 min

GSNは組込みシステムの機能安全の設計で使うツールと思っていたので、タスク管理に使う発想がなかった。
なるほど、変更要求からタスクまでのトレーサビリティを明示できる特徴を生かして、こういう使い方もできるのは面白いと思った。

 

 

 

 

| | コメント (0)

2019/03/31

システムエンジニアリングとしての SysMLの記事のリンク

青木淳さんが書かれたSysMLの記事が分かりやすかったのでリンクしておく。
ラフなメモ。

【参考】
「システムエンジニアリングで SysML を使いこなす」第1章 概要編-システムエンジニアリングとしての SysML | オブジェクトの広場

「システムエンジニアリングで SysML を使いこなす」第2章 実践編-電光掲示板を設計する(1) | オブジェクトの広場

「システムエンジニアリングで SysML を使いこなす」第2章 実践編-電光掲示板を設計する(2) | オブジェクトの広場

上記の記事を読んで面白いと思った点は2つある。
一つは、SysMLという共通言語が複数の専門家集団の意思疎通に重要な役割を果たすこと。

ソフトウェア組込製品でも、システムの大規模化・複雑化によって、開発作業はハードウェア技術者やソフトウェア技術者に細分化され専門化した。
結局、開発プロセスや開発組織そのものも局所最適化されてしまっている。

一方、市場要求や技術革新によって、どんどん製品や技術が陳腐化していくので、製品自体をその次代の技術に合わせて全体最適化する必要が出てくる。

しかし、今までの日本人が得意とする、すり合わせ技術だけでは、システムの複雑化や市場変化の速度に付いていけない。
そこで、モデルベースエンジニアリングのように、システムアーキテクチャを全体最適の観点で構築し直し、ハード・ソフトの専門家も一緒に開発していくスタイルへ変化せざるを得ない。
そういう場面で、ハード・ソフトの専門家同士で会話するための共通言語となるSysMLが必要となり、役立つのだ、というストーリーと理解した。

確かに、例えば、製品ドメインの専門家、熱力学や電気・ロボットなどの自然科学の専門家、そして、機械学習やクラウド等のソフトウェアの専門家のように、多数の専門家から成る集団で開発する場合、共通言語がなければ、価値ある製品を作ることは難しいだろう。
共通言語だけで解決できるわけではないが、必要条件の一つにはなりうる。

もう一つは、あらかじめ全ての顧客要求や製品の部品やアーキテクチャを決める必要はなく、未決定の要素をリスク管理の対象とみなして開発を進めて、必要な時に随時決定すれば良いこと。

製造業の製品開発ではどうしてもWF型開発になりやすいが、各工程の内部は実際はアジャイル開発っぽい雰囲気が出てくる。
原材料や部品の発注があるので納期厳守でWF型開発が王道だが、中身の開発は試行錯誤が普通。

昨今の開発では、要件を全て決めてから開発する、という流れの方が少ないだろう。
その時に、製品のアーキテクチャをSysMLで表現した時、どの部分の要件が未決定であるか、を明確に区別して管理することは重要になってくる。
その未決定の要件はリスク管理の対象として扱い、リスクが顕在化してきた時に、アーキテクチャを明確に固めていく。

そのプロセスでは、SysMLにあるユースケース図、ブロック図、シーケンス図、アクティビティ図などを使えば、複数の観点でアーキテクチャを分析することで整合性が取られることになる。
つまり、SysMLというモデリング言語によって、リスク管理を支援していることになるわけだ。

そんな事を考えると、設計と開発プロセス、モデリングは表裏一体のように思える。
それらを操れることで、開発をコントロールできるわけだ。

| | コメント (0)

2019/02/11

「サピエンス全史」「ホモ・デウス」の図解のリンク

一世を風靡した本「サピエンス全史」「ホモ・デウス」を図解した記事があったのでリンクしておく。
書籍を一度読んだ人であれば、この図解を見れば、そういうストーリーだったことを思い出せるはず。

【参考】
サピエンス全史図解(詳説版)|きょん|note

ホモ・デウス図解|きょん|note

akipiiさんのツイート: "この図解はすごく分かりやすい。plantUMLで書き換えてみたいな。サピエンス全史図解(詳説版)|きょん @kyon_hcj|note(ノート) https://t.co/kpZUiXCvgR"

akipiiさんのツイート: "利害関係者の図をPlantUMLで書く事例。分かりやすい。面白い。2018年の世界情勢をPlantUMLで図解してみた - 木牛流馬が動かない https://t.co/8B15anmKAj"

【1】「サピエンス全史」「ホモ・デウス」は歴史好きの人にはたまらない本ではないか、と思う。
欧米人の学者は、歴史上の数多くの事実を一つの理論や体系、思想を元に整理して、一つの壮大な絵巻物で表現するのが上手だと思う。
でも、その膨大な量に圧倒されて、結局何が言いたいのか、を掴むのに結構時間がかかる。

そこで、上記の図解を読めば、まずは一つのストーリーを即座に理解できるので、その理解をもとに書籍を読み直すと理解しやすくなると思う。

【2】最近、歴史や法律など文系の知識をモデル化する事例に興味がある。
たくさんの文章に、言いたいことが埋もれてしまっていてすぐに理解できない時に、図解やモデリングの技術を使って、概念を鳥瞰して理解したいのだ。

例えば、利害関係者の図はパッケージ図やクラス図、歴史の流れはシーケンス図、といったモデルで表現すると、実は意外に分かりやすくなる。

2018年の世界情勢をPlantUMLで図解してみた - 木牛流馬が動かない

歴史の流れをPlantUMLのシーケンス図で書き起こす事例のリンク: プログラマの思索

akipiiさんのツイート: "この発想はいいな。歴史や政治、法務はモデル化したい。RT @naruyo_t: UMLで図を描くというのはおもしろい。ただ見栄え気にしたい派の私としてはpptがなじんでて下書きでの整理に良さそうと思った。 “2018年の世界情勢をPlantUMLで図解してみた - 木牛流馬が動かない” https://t.co/8B15anmKAj"

色々試してみたいと思う。

| | コメント (0)

astahのモデルをGitで差分比較する方法のリンク

astahのモデルをGitで差分比較する方法の記事があったのでリンクしておく
この方法は使えそう。

【参考】
astah*とGit | astah in 5 min

【1】UMLでモデルを書いていると、差分比較を取りたくなる時がある。
顧客の要求事項を一つずつモデルに反映して、課題を一つずつ潰していく作業は地道で労力がかかる。
だから、顧客のヒヤリングのたびに、想定したモデルをどんどん洗練させていく時、前回の状態とどれだけの変更箇所があったのか、後で振り返りたくなる。

また、マイルストーンごとに、モデルの差分比較もやりたい時がある。
仕様変更のスコープだけ、顧客に見積もりを請求したいからだ。

その為には、たとえモデルがバイナリファイルであっても、ソースと同じような差分比較機能が欲しくなる。

【2】(引用開始)
astah*には、プロジェクトの比較機能というものがあります。これをコマンドラインから利用できるようになっていることはあまり知られていないかもしれません。
このastah-commandコマンドは、インストールフォルダに配置されています。下記のように、-diffオプションに、比較対象の2つのファイルを指定して実行すると、モデルの差分や図の差分を確認する画面が開くというものです。

astah-commandw.exe -diff file0.asta file1.asta

このコマンドを利用することでGitリポジトリで管理するastah*のプロジェクトファイルのリビジョン間の比較をすることが可能です。
(引用終了)

なるほど、astahのコマンドにDiffオプションがあるので、それを使うという方法。
差分履歴を持つ2個のastahファイルがあれば、コマンドを使ってプロジェクト間の差分比較ができる。
このコマンドをスクリプト化しておけば、気軽に差分比較できるわけだ。

さらに、記事によれば、SourceTree上でもastahモデルを差分比較できるらしい。
これは便利だ。
Gitの履歴のリビジョンを取得して差分比較するスクリプトも用意しておけばいい。

色々試してみたいと思う。

| | コメント (0)

2019/01/04

PlantUML Example for モデルベース要件定義テクニックの記事のリンク

@ogomrさんのPlantUML Example for モデルベース要件定義テクニックの記事がとても参考になるので、リンクしておく。
以下は、論理的でないラフなメモ書き。

【参考】
PlantUML Example for モデルベース要件定義テクニック - Qiita

akipiiさんのツイート: "この発想は面白いな。RT @ogomr: PlantUML はテキストだけど意外と表現力があって モデルベース要件定義テクニック のUMLを拡張した図も描ける。GitLab なら RDRA をブラウザで表示できて便利 https://t.co/IpCRFQ4XDu"

akipiiさんのツイート: "後で試す。RT @zenzengood: PlantUML Example for モデルベース要件定義テクニック https://t.co/IpCRFQ4XDu #Qiita テキストベースでRDRAモデルを書きたい方はとても参考になります。"

歴史の流れをPlantUMLのシーケンス図で書き起こす事例のリンク: プログラマの思索


【1】最近、PlantUMLに着目していて、色々試しているのだが、@ogomrさんのPlantUML Example for モデルベース要件定義テクニックの記事がとても参考になった。

ストーリーは、モデルベース要件定義テクニック(RDRA)で使われるUML技法を、PlantUMLを使って書いてみよう、という流れ。
モデルベース要件定義テクニックは、UMLの技法をプロファイルで拡張していて、Enterprise Architectにはそのテンプレートがあるが、astahでは使えないので、いつも残念に思っていた。
だから、PlantUMLでモデルベース要件定義テクニックの技法を使えるのは非常に嬉しい。

記事では、コンテキスト図、概念モデル、ユースケース、データモデルなどがPlantUMLで紹介されている。

【2】RDRA(モデルベース要件定義テクニック)については過去に色々試していた。
僕は、UMLを要件定義に使う場合にRDRAの技法や考え方が非常に役立つ、と思っている。

さくさく要件定義(リレーションシップ駆動要件分析RDRA)セミナーの感想 #RDRAセミナー: プログラマの思索

リレーションシップ駆動要件分析による実践的な要件定義手法の記事のリンク: プログラマの思索

理由は、UMLを要件定義に使おうとすると、要件を複数の観点で分析したい時に、粒度やトレーサビリティがバラバラになりやすい弱点があるが、モデルベース要件定義テクニックを使えば、その弱点を克服できるから。

実際、UMLやオブジェクト指向分析の技法を使うと、中間成果物が多い割には、結局、どんな要件が決まったのか、という事が分かりにくい時がある。
一方、モデルベース要件定義テクニックでは、システム地図の一部にUMLの各種ダイアグラムが埋め込まれ、それらがどんな粒度でどのように関連しているか、システム地図を鳥瞰する観点で要件を整理できる。

僕は、下記の記事にあるシステム地図の中で、「システム外部環境」「システム境界」の部分が一番重要と思っている。

要件定義支援ツール「要件のツボ」によるRDRAの実践 (1/3):CodeZine(コードジン)

なぜなら、人とシステムが相互作用するI/Fは、それら2つの観点で整理でき、相互に関連させることで、トレーサビリティを確保できるからだ。

結局、モデリングで一番重要で、かつ、難しい部分は、各モデルの粒度を揃えてレイヤ化することと、各モデルのトレーサビリティを保証することだと思う。
だから、モデルベース要件定義テクニックのような考え方を、具体的な技法で表現できると非常に心強い。

【3】PlantUMLには非常に可能性があると思う。
システム開発がプログラミング主体であるのと同じく、設計書もテキスト化して、構成管理の配下に置きたい野望があるから。
そのイメージは1年前に書いていた。

PlantUMLを使ってExcel設計書をテキスト化するアイデア: プログラマの思索

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

一般ユーザやプログラマへ業務イメージや技術イメージを説明する時に、何らかの図や絵を描いた資料を作るが、それらはExcelやパワポでは作りたくない。
そこで、PlantUMLを使えば、プログラミングと同じ感覚で書けるし、Webで情報共有もしやすい。

さらに、PlantUMLで描いたモデルも、モデルベース要件定義テクニックのように、各モデルの粒度やトレーサビリティを意識した規則に当てはめれば、その精度も上がるだろう。

PlantUMLが普及すれば、UMLは中間成果物が多すぎて使いものにならない、という声よりも、プログラミングの概念設計の一部として普通に使う、という考え方に変わるだろうと期待できる。
@u6k_yu1さんと同意見だ。

akipiiさんのツイート: "すごくいいね!RT @u6k_yu1: なんかこう、PlantUMLとか、モデルベース要件定義テクニックとか、ICONIXプロセスとかが広まることで、UMLが背負ってしまったトラウマとか業とかが払拭されて、みんな気軽にUMLを使えるようになるといいと思う。"

そして、最終的には、モデリングの根本問題の一つである「モデルの粒度を揃えてレイヤ化すること」「モデルのトレーサビリティを保証すること」も、PlantUMLとモデルベース要件定義テクニックを併用することで、具体的な解決方法を持って解決できそうな気もしている。
そのアイデアも試してみる。

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

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

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

【追記】
u6k_yu1さんのツイート: "PlantUMLのパーサーが欲しい。モデリングツールとして機能させたい。"

u6k_yu1さんのツイート: "はい、そうですね。と最初は思っていたのですけど、どうも私のイメージはPlantUMLのIDEっぽいです。VSCodeにPlantUMLのプロジェクト管理機能とモデル間のトレーサビリティ検証やバリデーションやチェック機能が欲しい、みたいな。… "

| | コメント (0)

2018/12/30

歴史の流れをPlantUMLのシーケンス図で書き起こす事例のリンク

歴史の流れをplantUMLのシーケンス図で書き起こした事例がツイートされていいたのでリンクしておく。
これは分かりやすい。

【参考】
読書猿『問題解決大全』4刷、『アイデア大全』9刷さんのツイート: "右手を痛めてから手書きを減らすべくAtom+PlantUMLで図を描くようにしてる。 画像は、大化の改新の前後をシーケンス図でまとめたもの。… "

akipiiさんのツイート: "歴史はシーケンス図で書くと面白いな。RT @kurubushi_rm: 右手を痛めてから手書きを減らすべくAtom+PlantUMLで図を描くようにしてる。 画像は、大化の改新の前後をシーケンス図でまとめたもの。 https://t.co/4FBraKNyco"

読書猿『問題解決大全』4刷、『アイデア大全』9刷さんのツイート: "実は「UMLで描く日本史」という企画もあってですね。… "

apple][ (28)さんのツイート: "あーこれはわかりやすいかも。 歴史の教科書って、時系列に文字で説明されているだけだから、相互関係や因果関係がすごく分かりにくいんだよね。図があってもすごく分かりにくかった。結局単なる暗記ものの域を脱しなくて、学問として全く興味が湧かなかったのもそれが大きな要因と思う。… https://t.co/kEoyxxbWNg"

akipiiさんのツイート: "「UMLで描く日本史」だけでなく「UMLで描く世界史」も期待しております! PlantUMLでソースをGitHubで公開してくれると、日本の高校生や受験生にも役立つと思いました。… "

てるりん🍙お結び隊 No.6🎸TEAM Mさんのツイート: "納品ドキュメントにWordやExcelが求められたりした場合は仕方ないけど、納品対象にならない内部設計のドキュメントやチームメンバー間での情報共有目的なんかは、SublimeTextやVSCodeとPlantUMLで書いてMarkdownで埋め込んでPDF化とか、最近よくやる。… https://t.co/ZxsDIBnsmJ"

【1】日本史や世界史のような歴史は大嫌い、という人も多いと思う。
理由は、暗記が大嫌いだからだ。
訳の分からない人名、関連して覚えにくい年号、など、丸暗記しなければ解答できないものばかりだから。

でも、僕自身は数学と歴史は好きだった。
理由は、数学はロジカルに組み立てられているので、基本的な公式さえ理解すれば、後は、そこから演繹的に導くだけで暗記が不要だから。

また、歴史も、その時代の政治的な背景や経済的な構造という仕組みを理解すれば、歴史上の大事件をマグマの噴火の現象として捉えることで、一連の流れで捉えることができるから。

たとえば、一昔前の歴史物であれば、マルクス主義史観や民主主義史観みたいに、歴史は経済中心で発展していくべきものであり、最終的には独裁政治から資本主義を経て民主主義へ落ち着く、という流れの中で、その国の歴史をプロットする、という考え方もある。
実際、民主主義に発展した国と歴史を考えれば、英国→フランス・米国→ドイツ・日本→ロシアの順で民主主義化されてきた。
あるいは、一人あたりGDPがある一定水準を超えると、中産階級の政治的発言力が高まり、独裁政治から民主主義に政治体制が変わる、とか。
とは言え、そういう進歩主義的歴史観が中国に当てはまるのかどうか、分からないが。

【2】では、そういう考え方で、歴史を捉えたい時、どんなモデリング手法を扱えばいいだろうか?

その答えの一つは、歴史をシーケンス図で書き起こしてみる事ではないだろうか。

たとえば、上記では、大化の改新前後の歴史的事件を、シーケンス図で書き起こしている。
さらに、吹き出しに、年号と事件名を書いている。
ゆえに、シーケンス図を見ると、誰が誰に何しているか、というのが一目で読み取れるので、理解しやすい。

シーケンス図のメリットは、アクターやオブジェクトの相互作用を表現できることだ。
そこから、UMLモデリング手法の考え方も適用できるだろう。

たとえば、Fatなオブジェクトがあって、メッセージの発信源が集中しているならば、他のオブジェクトが実は他に存在しているのではないか、と疑ってみると面白いかもしれない。
実は、XX事件の黒幕とか、他の重要人物が隠れているのかもしれない。

あるいは、「責任の委譲」を使って、メッセージが階段状になるように書き起こしてみて、歴史的事件のステーク・ホルダーが誰なのか、ステーク・ホルダー同士でどんなやり取りがあったのか、を書いてみると、より詳細に理解しやすくなるのではないか。
特に、XX戦争における敵と味方の区別、とか。
たとえば、新聞の国際欄では、シリア紛争の複雑な利害関係者の敵と味方の区別をクラス図に近いモデル図で表現している。

【3】そこで、歴史をシーケンス図で書き起こす時、VSCode+PlantUML+Gitを使うと非常に書きやすくなるだろう。

なぜならば、シーケンス図をプログラミングのように書けて、即座にプレビューできるので、試行錯誤しながら考えをまとめられるから。
また、Gitで構成管理の配下に置けば、理解した内容を継ぎ足していくことで、歴史のシーケンス図を一つの絵巻物として書き上げられるから。

上記の日本史のシーケンス図を見ていると、PlantUMLと歴史は相性が良い、という気がした。
日本史や世界史の年表を全てシーケンス図で書き起こしてみたら、世の中の高校生に貢献できるのではないだろうか??

たとえUMLを知らない高校生であっても、シーケンス図のように箱と矢印だけの絵を見れば、だいたいのイメージは分かるはずだろうから。

【4】PlantUMLの可能性については、以前から考えていた。

僕は、日本のSIで広く使われているExcel設計書は、全てテキスト化してGitで構成管理させたい。
そのためには、PlantUMLのような何らかのモデルの絵が必要だろうと思う。

一昔前の詳細設計書のような自然言語のドキュメントは現代では不要だが、システムの構想やアーキテクチャのイメージは、何らかのモデルという絵で表現したいからだ。
そうすれば、アーキテクトは、顧客やプログラマに説明しやすくなるから。

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

PlantUMLを使ってExcel設計書をテキスト化するアイデア: プログラマの思索

ツイートを読み流していると、世界中の人達がPlantUMLを使って色んなアイデアを試そうとされているのがよく分かる。
業務フローやシステムのアーキテクチャだけでなく、ER図、ジョブフロー図、ガントチャートもPlantUMLで実現できる。
さらに、リスク関連図(?)みたいな、因果ループ図までPlantUMLで実現しようと試されている人もいるみたい。

akipiiさんのツイート: "後で読む。RT @pdl_runa: 現場で役立つシステム設計の原則にあるUMLをPlantUMLで書いてみる https://t.co/LIRmSOsBWW"

akipiiさんのツイート: "後で読む。RT @tech_advent: OPENLOGI Advent Calendar: plantUMLで業務フローを整理する https://t.co/2LWksWSyuI"

akipiiさんのツイート: "なかなか良いな。RT @abe4tawa8: PlantUMLでER図を描く! – VELTRA Engineering – Medium https://t.co/7eVRHuFjFC"

akipiiさんのツイート: "ジョブフロー図も書きたくなるな。RT @jiro_saburomaru: 定期実行のバッチとかのタイムチャートをテキストから生成できないのかな。plantuml みたいに"

akipiiさんのツイート: "I think it interesting. RT @DinisCruz: Here is the first draft and @PlantUML version of our revised @Jira schema for risk management What do you think? Does it make sense? Created by @madplatt #IN https://t.co/76Fy4FM1me"

立花優斗さんのツイート: "PlantUMLめっちゃいいな… "

【5】PlantUMLを用いて、Excel設計書をテキスト化するだけでなく、日本史や世界史もモデルで書き起こす事例のように、他の分野にも適用して試してみたくなってきた。

来年のastah関西でも、そういう話をしてみたいな。

【追記】
@kurubushi_rmさんが、「大化の改新前後.pu」「環大西洋革命.pu」をGitHubでソースを公開されている。
とても参考になる。

kurubushi--rm/history-in-UML: We will use UML to summarize Japanese history and world history

読書猿『問題解決大全』4刷、『アイデア大全』9刷さんのツイート: "@akipiiさんのご提案を受けて、このPlantUMLでソースをGitHubを公開しました。https://t.co/I8kF93dALf これだけだと日本史なので、世界史のサンプルとして「環大西洋革命」を追加しました。 何れにせようろ覚えなので、修正パッチなど遊んでいただけると幸いです。 https://t.co/aaYZyrlmSJ"

akipiiさんのツイート: "年末年始の忙しい時にありがとうございます! 歴史だけでなく、新聞の国際欄にある利害関係者の図、例えばシリア紛争、をクラス図やコラボレーション図で描く、とか、色々アイデアが膨らみます。… "

akipiiさんのツイート: "@kurubushi_rmさんが日本史と世界史のシーケンス図がPlantUMLでソースをGitHubを公開されてます。https://t.co/RzJsYwXpUj 中国の王朝変遷の歴史、歴史上の戦争とか、色々描けそう。 他に、民法や会社法、知財法などの理解の為に、UMLが使えないかな?と思ってる。"

akipiiさんのツイート: "すごくいいね!RT @u6k_yu1: なんかこう、PlantUMLとか、モデルベース要件定義テクニックとか、ICONIXプロセスとかが広まることで、UMLが背負ってしまったトラウマとか業とかが払拭されて、みんな気軽にUMLを使えるようになるといいと思う。"

【追記2】
y503Unavailable@非公式Redmine調理法unofficialcookingさんのツイート: "Redmine界隈をネタに作成してみました。(記載判断は自分の主観) 振り返り易くすることは必要ですね。… "

【追記3】
ステークホルダーの関係をPlantUMLで図式化した事例が面白い。
歴史の内容は、全てPlantUMLで置き換えた方が分かりやすいのではないだろうか。

2018年の世界情勢をPlantUMLで図解してみた - 木牛流馬が動かない

| | コメント (0)

2018/09/09

第2回astah関西の感想 #astahkansai

昨日の第2回astah関西の感想をラフなメモ書き。

【参考】
第2回astah関西勉強会「開発現場のモデリング事例紹介」 - connpass

Mix Leap Study 特別編 -「開発現場のモデリング事例紹介」(astah勉強会) - connpass

7/7土の第2回astah関西の見所 #astahkansai: プログラマの思索

第2回astah関西勉強会(2018/9/8)のスライドが公開されました | astah in 5 min

【1】7月の西日本豪雨で1度流れ、4日前の台風の影響で参加者は減りましたが、参加者の熱気もあって盛り上がり、雰囲気はとても良かったように思います。
講演の内容もビジネスモデリングから組込み系、astahのより良い使い方など盛りだくさんで、飽きない感じでした。

講演中のアンケートでは、astahの利用または経験者が多数いた事、組込みエンジニアまたは組み込み系コンサルタントの方が半数以上いた点が興味深かったです。
僕自身は、業務系Webシステム開発をベースとしたビジネスモデリング系だったので、グループディスカッションでは、全く違う層の人たちと、最近の電気自動車や組み込み機器のセンサー化、機械学習の動向などの話が聞けて面白かったですね。

以下、講演内容について感じたことをメモしておく。

【2】兒玉さんの講演では、astahに描いたアクティビティ図から、astahAPIで情報抽出するデモを見せてくれた。

考え方としては、レガシーなCプログラムから手作業でastahのアクティビティ図へリバースしてモデリングする。
その時、アクティビティ図の吹き出しに、該当ソースの行番号も書いておく。
その後、astahAPIを用いて、JavaScriptでアクティビティ図の吹き出しにあるソース行番号の情報を抽出し、Excel設計書に貼られたCプログラムと照合して、合致した行番号に色塗りする、という仕組み。

つまり、astahのモデルとCプログラムの照合作業をastahAPIを使って自動化する、という作業を実現されている。
もちろん、astahのモデルは手作業で描くし、ソース行数も手作業でモデルに埋め込む必要はあるが、モデルを作っておけば、後はastahAPIでいくらでも情報を抽出できるので、照合やカバレッジなどの作業を自動化できる点は面白い。

astahを起動せずにJavaScriptで情報を取得する方法: プログラマの思索

また、astahAPIは、公開されているJavaDocだけでなく、astahからXML出力されたXMLファイルのXPATHを参考にすると良い、という話もあった。
つまり、XPATHからJavaDocにあるメソッドを連想しやすくなる、ということで、これは面白いなと思った。

astah* API

astah* API概要

astahAPIを使いたいと思っていても、大量のJavaDocから見当を付けるのが面倒でいつも何とかならないかな、と思っていたので、この発想は使ってみたいと思った。

【2】高井さんの講演では、組込みシステムのソースのリバースエンジニアリング作業は、プログラマだけでなく、熱力学など自然科学の専門家、自動車や家電機器などの業務の専門家も関係していて、彼らドメインの専門家のリバースエンジニアリングの観点は異なるので、SySMLという共通言語によって有益な情報を組合せることができる、という主張が面白かった。

確かに、プログラマはCやC++は強いだろうが、熱や振動などの自然力学の法則に詳しいわけではないから、アルゴリズムの本来の意味まで分からない。
自然科学の知識を持つ専門家であれば、このアルゴリズムが表す制約条件は、鉄板の強度や耐熱や振動の範囲を示す、などの知見を言い当てることができる。
そうすれば、自動車や家電製品の設計エンジニアは、材料の強度や耐熱、振動などの制約条件を元に、製品の形状や大きさはこういう範囲で設計しなければならない、等の知見が得られる。

すなわち、リバースエンジニアリングした内容は、プログラム層、自然科学のドメイン層、業務ドメイン層等で解釈が異なるわけだ。
そんな事を理解すると、ソフトウェアを組み込んだハードの設計や開発を真に理解するには、プログラミングだけでなく、自然科学の知識や製品の知識まで知る必要があり、膨大な範囲になる。
だから、組み込み機器の設計開発は、どんどん難しくなっているのだろう、と推測した。

もう一つ面白いと思った話は、SysMLはソフトウェア技術者の地位を高めた、という話。
つまり、今まではハードの部品ができた後で、ソフトウェア開発を行うので、ソフトウェア開発者は限定された仕様の中でプログラミングせざるを得ず、主導権を取ることができなかった。
しかし、ハードの部品が開発される前に、SysMLを用いて、製品の論理構造をモデル化できるようになり、ハード技術者へソフトウェア開発に必要な仕様や制約条件を事前に伝えられるようになった、と。

確かに、ハードの部品や製品は、材料の購買・発注・組み立てなど数多くのコストがかかるので、そう簡単に作り直しはできない。
一方、ソフトウェアはいくらでも変更できるので、無理な要望を受けてしまいがち。
しかし、ハードを発注する前の設計段階で、ソフトウェア開発では、これだけのメモリや性能は必要です、という情報を事前にハード設計者に伝達できれば、ソフトウェア開発もやりやすくなる。
SysMLはそういう波及効果があった、という話が面白かった。

【3】細合さんのSTAMPの講演後、僕は、そういう機能安全設計のモデリング技法は、一般事象のリスク識別に適用できるのではないか、と質問してみた。

僕の理解では、自動車の機能安全設計のモデリング技法STAMPでは、対象のハード製品の利用シーンをユースケースとみなして、そこからハザード分析し、人命に関わるリスクを識別し、そのリスクを潰す為の安全設計の仕様を導き出す。
そうならば、PMBOKのリスク管理に出てくるリスク識別において、ある事象のリスクを、何らかの対象の相互作業(I/F)をユースケース(利用シーン)とみなすことで、STAMPの技法を適用できるのではないか、と連想したからだ。

しかし、後で、宿口さんから、STAMPとリスク管理は観点が違いますよ、と教わった。
宿口さんの話を理解した限り、PMBOKに出てくるリスク管理は発散系の技法に近いが、STAMPは収束系の技法である。
仕様が固まっている製品に対し、製品の利用シーンを想定して、それを元にハザード分析していく手法なので、根本から手法が異なる、と。
話を聞いた限り、STAMPの技法は、ロジカルに説明できるような資料作りに役立てる技法の一つ、という印象を受けた。
僕はPMBOKもSTAMPも詳しくないので、この辺りはまた考えてみる。

【4】稲田さんの匠メソッドによるビジネスモデリングでは、経験に基づいた試行錯誤の話が興味深かった。

彼の講演の中で、ビジョンから業務要求・IT要求・仕様へ至るまでモデリングしていく中で、モデルを書いていると、ダブリやつじつまが合わなくなる時がある。
特に、数多くのステークホルダーにヒヤリングしてその内容を収集すると、そういう傾向が出やすい。
だから、その内容を早めにフィードバックして、何を最優先すべきなのか、何を妥協すべきなのか、を決めていく、と。

【5】僕の講演では、astahのRedmineプラグインの紹介。

AstahのRedmine連携プラグインが公開されました: プログラマの思索

言いたかったことは、単にプラグインの紹介だけでなく、その背景にあるモデリングツールが今後発展するために必要な機能追加の要件だ。
それは、モデルのグルーピング機能とモデル間の相互リンク機能を追加することだ。
それらは、モデルの粒度やモデルのトレーサビリティという、モデリング作業の問題解決に直結すると考えている。

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

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

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

高井さんと話していて、モデルを沢山書いていくと、astahでもモデルのタブを切り替えるのが面倒になってくる、という話があった。
モデルが3個ぐらいなら問題ないが、10個、50個と書いていくと、モデルを探す作業に相当の時間が取られるから、とのこと。
つまり、モデルの関連や情報を検索するのに時間がかかっているのだ。

その問題の真因には、モデルの粒度とモデルのトレーサビリティがあると思う。
大規模なシステムになるほど、概念モデル、論理モデル、物理モデルなどモデルにも数多くのレイヤが発生し、区別せざるを得ない。
すると、それらモデルの粒度を合わせるために、グルーピングしたくなる。
しかし、そういう機能がUMLの仕様そのものにないし、astahにもない。

また、一つのシステムを静的な観点、動的な観点、状態遷移図、利用シーンなど数多くの観点で分析したモデルを作ったとする。
それらモデルは、一つのシステムの射影にすぎないので、相互にリンクさせることで、追跡できるようにしたい。
そうすること、重複や考慮漏れに気づくことができ、モデルの精度を上げることができるはず。
しかし、そういう機能がUMLの仕様そのものにないし、astahにもない。

つまり、astahを含めた既存のモデリングツールは、大規模なシステムの分析にはたぶん力不足。
もっと大規模で複雑なシステムを、数多くの観点で数多くのモデルで分析した時に、それらモデル間の整合性をとるために、モデルの粒度とモデルのトレーサビリティという考え方が必要になってくると思う。

一方、アプリ開発者の観点では、モデルのグルーピング機能は所詮、フォルダ分けという機能にすぎない。
また、モデルの相互リンク機能は、モデル間の相互のハイパーリンクという機能にすぎない。
つまり、モデルの粒度とモデルのトレーサビリティという問題解決に必要なモデリングツールの機能改善は、さほど難しいわけではない。

しかし、そういうちょっとしたUIの機能改善が、モデリングツールを洗練させるし、モデリング作業そのものを効率化させていくものと思っている。

モデリング技術の習得とモデリングツールの習得は表裏一体: プログラマの思索

【6】本勉強会のスコープは、「製品astah」「astahで描けるモデリング技法全般」というかなりマニアックな内容だったので、今後の勉強会の継続を懸念していた。
いくら僕が勉強会をやりたい、と思っても、そもそも人が集まるのだろうか、という不安があった。

しかし、参加者から好意的な感想も多く、また、本勉強会を以前からウォッチしていた、という方もいて、勉強会のニーズはある、と感じ取った。

いつまで続けられるか分からないけど、緩く長く続けられればいいな、と思う。


| | コメント (0)

2018/08/19

モデリング技術の習得とモデリングツールの習得は表裏一体

1ヶ月前に、関西IT勉強会で「ITアーキテクチュアのセオリー」出版記念講演に出て、データモデリングの話を聞いてきた。
その講演者から、赤俊哉さんをお手本にしている、という話があり、赤俊哉さんの書籍をいくつか読んでみて、感じたことをメモ。

【ITアーキテクチュアのセオリー】出版記念講演<第64回IT勉強宴会in新大阪> | IT勉強宴会blog

赤俊哉さんの本「SE職場の真実 どんづまりから見上げた空」という本を読んだ。
著者が派遣プログラマ、ユーザ企業の社内SE、そしてユーザ企業のCIOへ築き上げたキャリア遍歴の話がメインで、自分の経験を振り返りながら、そうだなあ、と頷いていた。
その本の中で興味を惹いたのは、業務システムのリプレースの時に、有償の設計モデリングツールXupperに出会い、データモデリングを興味を持ち、データモデリングの技術習得に努め、業務システムの設計情報をXupperのリポジトリに集約させた事で、プロジェクトが成功した、という話があった。

Xupperとは? | 製品情報 | XupperII

Xupperの製品は僕も詳しくは知らない。
しかし、SoRのようなレガシー業務システムの設計情報をDOAモデリングツールのリポジトリに集約することの意義について、色々考える所があった。

SoRのような業務システムでは、どうしても上流工程の設計技術が起点になると僕は思う。
すると、DFD・ER図・CRUD表というDOAの3種の神器のような設計資料がどうしても必要になってくる。
なぜなら、業務の流れをつかむためにDFDが必要だし、データの構造をつかむためにER図が必要だし、仕様変更の影響範囲の調査やテスト設計のためにCRUD表が必要になるからだ。
しかし、それら設計資料をExcelドキュメントで手作業で作り出すのは正直面倒だ。

そこで、例えばXupperのようなモデリングツールが威力を発揮する。
設計情報がモデリングのリポジトリに一元化されていれば、そのリポジトリから、DFD・ER図・CRUD表は最新状態で出力でき、その内容を元に設計作業を効率化できる。
特に、仕様変更の影響調査では、設計情報が三位一体となったモデリングツールがなければ、システム保守でどんどんコストが増加していき、業務システムが経営環境の変化についていけなくなってしまう。

そういう観点では、DOAをマスターする事とモデリングツールを使いこなす事は表裏一体ではないか、と思う。
つまり、データモデリングを理解して自由自在に使いこなすには、モデリングツールがあればその成長速度を速められるし、他方では、モデリングツールを使いこなしていくうちにデータモデリングの技術を習得し、その作法に慣れていく、という側面があるだろう、と思う。

そういう背景やニーズが20年以上前からあるからこそ、最近、超高速開発という分野も脚光を浴びるようになったのだろうと思う。
僕は、超高速開発とは、データモデリングツールとそこから自動生成されたソースとそのシステムをシームレスにつないだもの、と思っている。
その本質は、モデリングツールで業務システムの設計情報をリポジトリ化できたからこそ、設計資料の出力だけでなく、システムの自動生成という所まで行えるのだ、という点にあるのだろう、と思う。

そんな事を考えると、モデリング技術の習得とモデリングツールを使いこなすことは表裏一体ではないか、と改めて感じる。
僕がUMLモデリングツールastahが好きな理由の一つに、そういう考え方を持っている事がある。

丁度それは、プログラミングの習得には、そのプログラミング環境の構築と習得が含まれていることと同じような気がしている。

【追記】
9/8土にastah関西の勉強会をやります。

第2回astah関西勉強会「開発現場のモデリング事例紹介」 - connpass

Mix Leap Study 特別編 -「開発現場のモデリング事例紹介」(astah勉強会) - connpass

| | コメント (0)

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回勉強会に既に多数の参加申し込みもあり、とてもワクワクしている。

【追記】
大雨のため、9/8土曜に順延となりました。

Mix Leap Study 特別編 -「開発現場のモデリング事例紹介」(astah勉強会) - connpass

第2回astah関西勉強会「開発現場のモデリング事例紹介」 - connpass

| | コメント (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)

より以前の記事一覧