NTTデータ、既存システムのソースコードから設計書を自動生成するサービスを開始 92
ストーリー by hylom
設計書があればいいというわけではないが 部門より
設計書があればいいというわけではないが 部門より
あるAnonymous Coward 曰く、
NTTデータが、既存システムのソースコードから設計書を自動生成する「設計書リカバリーサービス」を発表している（クラウドWatch、プレスリリース）。
ソースコードの解析は自動で行い、設計書の出力についてはカスタマイズが可能で独自仕様のフォーマットにも対応できるという。対応言語はCOBOLやJCL、PL/Iなど。
以前、東証曰く、システム開発においてコーディング後にはドキュメントは不要という話もあったが、これさえあれば大丈夫ですね（違う）
規格準拠の建前のため？ (スコア:2, 興味深い)
中身の品質評価は尺度を調整すればいくらでも操作できますが、「無い」ってのはね・・・・・・・・
実は中の人が… (スコア:2)
実は中の人がツールをちょっとだけ使って出力していると邪推してみる。コンサルはツールじゃできないし、柔軟なエンジンは人手部分か、ツールを人手で書き換えているのではないかと。
設計書リカバリーサービスは、システム運用者へのヒアリング・コンサルティングを行いながら、現行のソースコードを元に現行設計書の姿に合わせて設計書を再生し、提供するサービスです。
設計書リカバリーサービスでは、解析エンジンのカスタマイズが容易な仕組みのため、柔軟に対応することができます。
設計書リカバリーサービスでは、設計書を再生するエンジンのカスタマイズを実施することができるため、既存システム独自仕様の設計書フォーマットに合わせた出力にも対応できます。
20～30年前から継続して長期運用されているシステムに適用できるよう、COBOL、JCL注7、PL/Iといった言語に対応をしており、その他の言語についても今後順次拡充していく予定です。
日本語でコーディングしてるような仕様書とかあるけど (スコア:1)
http://d.hatena.ne.jp/irof/20120808/p1 [hatena.ne.jp]
こういう感じの日本語でコーディングしてるような仕様書って、なんの役にもたたないと思うけど膨大な工数をかけて作製してる現場あるよね。
こういうのが何の役にもたたないってのが理解出来ない人がけっこう、っていうかかなりいるからせめてこういうツールで自動化する流れになってほしいわ。
Re:日本語でコーディングしてるような仕様書とかあるけど (スコア:2)
ただ、こういう形で完全統一出来ていなくて、部分的に言語依存な書き方しているのが殆どだから役に立たないって所だね。
Re:日本語でコーディングしてるような仕様書とかあるけど (スコア:1)
ありがとう。
自分の職場に不満があったんだけど、贅沢な悩みだったということを確認できた。
リンク先の話って「ifとかswitchとか英語わからんのだったら日本語でおｋ」「お、かしこい♡」
というレベルの話ですよね。。。
つらい、つらいよ。。なんだか泣けてくる。。。
Re:日本語でコーディングしてるような仕様書とかあるけど (スコア:1)
>「ifとかswitchとか英語わからんのだったら日本語でおｋ」
昔、NHKで日本語C言語というのが紹介されていた。
予約語が日本語というもので例えば
if () {} else {}
を
条件 () 成立 {} 不成立 {}
と書きましょうというもの。
開発マネジャー曰く「日本語なのでパッと見判りやすい」
PG曰く「開発効率上がりました(ﾁｯ」
#Fだった気がするんだがググッても出てこない
アレを使えば仕様書要らないね(棒
Re:日本語でコーディングしてるような仕様書とかあるけど (スコア:1)
富士通だったら YPS かなぁ。
今は YPS/COBOL だけなのかな？ YPS/C はさすがに死んだか。
Re:日本語でコーディングしてるような仕様書とかあるけど (スコア:1)
同意するけどおそらく見果てぬ夢に近いものがあるんじゃないかなー。
でも追加記述なしに自動的に仕様書なり設計書なりとバイナリが生成されるプログラミング言語ならまだ...。
# プログラミング言語の型とかによる縛りはキツ目の方がドキュメントの自動生成はやりやすそうだ。その方がコード自体も安全だし。
Re:日本語でコーディングしてるような仕様書とかあるけど (スコア:1)
確かにほぼ役に立たない。
「ソースコードから自動生成できる設計書」ということは、
その設計書はソースコードの持つ情報量を実質超えないわけで、
余計なドキュメントが増えるだけだわな。
言語が読めない人のために自動翻訳した日本語訳をつけておく、
程度の存在価値しかないドキュメントだけど、
逆に言えばその程度の僅かな存在価値はあるので、
こういったツールがゆくゆくはソースコードのビューワーみたいな形になると良いのだろう。
Re: (スコア:0)
志村～、設計書設計書。
この形式の詳細設計書を作る現場に入った事がありますが、そこではステップテスト仕様書を兼ねていました。
Excel方眼なのでチェックも簡単です（棒。
その意味で「（３）処理を続行する」はいりませんよね。該当するステップがありませんから。
逆に自動出力すると必ずテストに成功しますｗ
まぁ受託出向で得体の知れない２０代が集まっていたということもあって、事前レビュー繰り返して技術的なところを揃える意味もあったのでしょう。
実際ここまでやっても、できない人はできませんでした。
ちなみにこの手のツールとかサービスですが、もともとの仕様や設計との差異をあぶりだしてしまうと言う意味で有用だと思います……
Re: (スコア:0)
コードから仕様書を起こすのが困難というのは誰でも知ってるのに、こういう、コーディングに限りなく近い仕様書は仕様書として役にたたないということが理解できない人がいるのがよく分からない。
「仕様がここまでできてるなら、もう直接コーディングしたほうがいいですよ」とか言っても「手抜きするな。いきなりコーディングなんか素人のすることだ」みたいな反応になるんだよな。
Re: (スコア:0)
はっはっは。
IFとかDOとかをインデントできない言語を使ったことがないみたいですね。
そういう言語で、深くネストしたIF文の意味を理解する時には、このレベルの仕様書がないと手がつけられませんよ。
Re:日本語でコーディングしてるような仕様書とかあるけど (スコア:1)
そして仕様書とコードが一致してないというw
# プリプロセッサを作って編集用ソースからビルド用ソースを生成したらどうだろう。
Re:日本語でコーディングしてるような仕様書とかあるけど (スコア:1)
逆にソースをフォーマッタにかけてから読むという手もあるね。
Re:日本語でコーディングしてるような仕様書とかあるけど (スコア:1)
どのみち書かなければならないのだから両方を相手にしたくなきゃ読むフォーマットと各フォーマットは一致してなきゃならない。
となるとプリプロセッサ一択になるのよ。
処理系が出力するメッセージによってはデプロセッサみたいなのも必要になるだろうけど。
# 昔マルチバイト文字をそのまま突っ込めるようにプリ／デ・プロセッサ書いたのはいい思い出w
Re: (スコア:0)
理由というのはロジックを書けないプログラマがたくさんいる職場だから?
Re:日本語でコーディングしてるような仕様書とかあるけど (スコア:1)
それも一つだろうね。元コメが役に立たないとは限らないが確実に宝の持ち腐れ。
例えばExcel方眼紙は(情報を認識できないアレでも)それっぽい書類を作れる(と皆が思っちゃうくらい皆もアレ)だから絶滅しない。
# OJTって「今、目の前にあるソレに対するHowTo」しか教えないから間違いを拡大再生産するのよな。
# それだけでなく間違っていることほど取り扱いに注意を要するから拡大再生産されやすいというか。
完璧でなくても (スコア:1)
全体を再整備するに足しになるものなら、それはそれかな...
# 最初からdoxygen前提でコメント入れたいけどね
M-FalconSky (暑いか寒い)
Re:完璧でなくても (スコア:2)
なんだかんだ言って、第３者が見る場合に手助けとなる文書は必要だと思っています。
数日前の自分は別人ですし、自分が追うのにも役に立ちます。
先日、自分が書いたソースを元にその手の文章をExcel方眼紙に簡単なフローチャートと説明を起こしたのですが、思い違いとか整理できて意外と有意義でした。
# doxygenのコメントを自動生成するツールが欲しい…。DoxygenToolkit.vimを使ってメソッドの先頭で":Dox"と打つの('A`)ﾏﾝﾄﾞｸｾ
Re:完璧でなくても (スコア:4, 興味深い)
・「数日前の自分は別人」全く同意。先日、excelでちょっと複雑な計算をした。翌日、検算が必要になり、見直したら、かなり丁寧に式を分割して書いたのに、分からなくなっていた orz
・20ン年前に、「FORTRANのソースしか無い」というシミュレーションシステムから、仕様書を起こすバイトの経験あり。おそらく、当時まだ(今も？)、海外ベンダとの立場の違いで、詳細な仕様書が入手できなかったのではないかと。割と最近話題になり、当時のバイト仲間と話してたら、そんな物件がまだチラホラと動いているんでは無かろうかと、再認識した次第。同時に、当時の自分の"いい加減さ"も再認識。
そんなこんなで、本題の自動生成。中の人の構成は、途上国のIT系学部の学生にバイトに出して、上がってきた中身も英語もヨレヨレの成果物を、国内の下請けに修正させて、表紙を付ける。そうすると、機械生成したように、イイカンジにワケワカな設計書が完成すると。
Re: (スコア:0)
C#だとGhostDocっつーVisual Studioのプラグインでそれっぽいことできるよ。メソッド名とか引数名からそれっぽい英語のコメントを自動生成してくれんの。
Re:完璧でなくても (スコア:1)
そういう処理は自分で手を動かしてやるから考えの整理になるんであって、自動化したら今度はそのドキュメントを解析するために同じ事をしなきゃいけないだけだと思う。
どっちにしろ (スコア:1)
ベンダさんに仕事してもらわなきゃってのもあるしな‥
それはそれは遠い昔 (スコア:1)
３０年ほど前の話ですが、RPGII ソースコードからプログラム仕様書を生成するなんてのを作った記憶あり
これはかなり便利に使えましたよ
仕様書→コーディングするより、いきなりコーディングした方が開発効率の上がるし、総務／経理部門が自分勝手に帳票プログラムを作ってしまった故ですが
ジョースター卿 (スコア:0)
なにジョジョ? 設計書からソースコードを自動生成する技術の実用化のめどがまったくたたない? ジョジョ、それは無理矢理自然言語AIを開発しようとするからだよ。逆に考えるんだ、「ソースコードから設計書を自動生成すればいい」と考えるんだ
昔あったねぇ。今でもあるか (スコア:0)
A HotDocument [hotdocument.net]とか。
ちょっと使ってやめた。
Re:昔あったねぇ。今でもあるか (スコア:2)
Re:昔あったねぇ。今でもあるか (スコア:2)
あったねぇ。
15・6年前かな
VB4.0あたりでお世話になった気がする。
なんらかの制限付きで無料だったような…
Re:昔あったねぇ。今でもあるか (スコア:1)
たしかその頃のは、構造解析なんか一切せず、
オブジェクトとプロパティとファンクションの一覧と定形コメント並べただけでドキュメントでござい、って言ってた。
ソースに定形コメントガッツリ書かなきゃ役に立つ物は出来なかった。
その頃よりは進化したと思いたいな。
Re: (スコア:0)
受注仕様書以外のドキュメントは要らない、って最初言ってた客が急に詳細仕様書が欲しいとか言い出したときはお世話になった気がする。
仕様書ドクター (スコア:0)
既視感が。
仕様書ドクターは黒歴史。ググっても出てこん。
気になる名前、"perl.exe"がしょっちゅう暴走してた。
わわわ (スコア:0)
仕様書が無いシステムの解析で大変なのは、ソースコードでなく周りにある物だと思う。
手作業とか、古株とか。
Re:わわわ (スコア:4, すばらしい洞察)
ドキュメントで一番欲しいのは、「プログラムがやっていることの説明」ではなく
「プログラムにやらせようと意図していたことは何か」なのだが、それは文法をいくら
解析しても出てくるとは思えない。
求められているのは殺人現場の写真から写っているものを列挙するカメラじゃ無くて、
欠けているものを引っ張ってきて推論するコナンなんだよ…。
Re:わわわ (スコア:3, おもしろおかしい)
いい感じによろしくやってくれること
Re: (スコア:0)
なんか納得できる
ドキュメントが無くて何が一番困るかというと「何をどうするのが正しいのか？」が分からない事だったりする
バグが仕様になっていたり、無駄や無意味があったり。
Re: (スコア:0)
求めてもそんなもの出てきませんから。
ベストが望めないなら、ベストへの道を少しでも近くしてくれるベターを望むだけ。
この手のツールは、そういうのに役立つ。
Re:わわわ (スコア:1)
で、大抵はベターにもなってなくて、金と時間を無駄に食いつぶすだけだから嫌われる。
「ほらン十万かけたんだから有効活用しろ。これで人月を半分にできるだろ？」
「できませんってば。むしろ邪魔。」
そんな感じ。
Re:わわわ (スコア:2)
「もう人月(人数)を半分にしたよ」でしょう。
Re: (スコア:0)
「プログラムにやらせようと意図していたことは何か」は出てくるんじゃ無いかと思います。
ただ、実用的なプログラムだと一本当たり意図千個とかになって読む気が失せるだけ。
書いている最中は一本道でも読むとなったら何をどうしても大変なのに変わりはない。
あるいは技術的負債を撒き散らして単純化に走るか。
ビッグデータの要約技術に期待！
Re:わわわ (スコア:1)
ソースコードから要件定義を生成してくれたら最高なのにwww
建築家も使ってみよう (スコア:0)
家を建ててから設計図を作る
Re:建築家も使ってみよう (スコア:2)
古い寺社や城の「○○の大修理」とかはそうなんでしょうね
Re:建築家も使ってみよう (スコア:3, 興味深い)
道後温泉、進まぬ修復計画…観光客離れを懸念
http://www.yomiuri.co.jp/homeguide/news/20130408-OYT8T00306.htm [yomiuri.co.jp]
「２００１年の市の調査で、床下のシロアリ被害や浴槽下のコンクリート劣化が次々と見つかった。
しかも昭和初期まで増改築を繰り返したことで構造が複雑化し、簡単には修復できないことが判明。
全面修復だと８年間は閉館、営業しながらの部分改修でも１１年かかるという。」
ドキュメントがあろうとなかろうと、技術的負債がある限り修正は容易ではない。
#重要なのはドキュメントの有無ではなく、シンプルな構造（≒優れた実装）だ。
Re: (スコア:0)
粘土細工を3Dスキャナーで形状スキャン。3Dプリンタで違う材質で再現。
悪くないかも。
Re: (スコア:0)
設計図通り家を建てたけど（ただし設計通りでない場所多数）、
更にその上に増改築くりかえし、元の容積の10倍の家になっちゃってるんだ。
構造図がほしいと思うだろ。
Re:建築家も使ってみよう (スコア:1)
改築を依頼された業者が物件を調査しようと立ち入って遭難。
では一休よ、ここに設計書がある (スコア:0)
では一休よ、ここに設計書がある
この設計書からソースコードを取り出してみせよ
Re:本当に欲しいものは (スコア:1)
まともな仕様書が一番欲しいです。そしたらソースコードぐらい自分で書きます。
Re:本当に欲しいものは (スコア:1)
実装コードと同等な精度で厳密に書かれた、ミスのない完璧な仕様書。
それはソフトウエア業界で、「ソースコード」と呼ぶものだと思う。
そんな厳密で正確でバグのない「仕様書」を書くのは、プログラミングと一緒だってば。
Re:仕様書と設計書 (スコア:1)
検死報告書と呼ぶほうがふさわしい気がしないでもないな。
まだ、動いてるんだっけ？