富士通、設計書からCOBOL/Javaコードを自動生成する「Interdevelop Designer」をリリース

富士通は2014年8月28日、システムの開発・保守作業を効率化する業務プログラム開発支援ツール「FUJITSU Software Interdevelop Designer」を発表、同日より販売を開始した。
日本語の設計書からCOBOLおよびJavaプログラムソースを自動生成する機能により、「開発・保守コストを40％削減できる」（同社）という。

　FUJITSU Software Interdevelop Designerを開発した背景として富士通は、企業における大規模システム開発にまつわる諸課題を挙げている。それは、システム構築ノウハウの属人化
システムの保守や機能改善時に必要となる設計書やテスト仕様書などの部分的な文書欠如、開発要員の高齢化による今後のシステム保守作業への不安などといった課題だ。

　そうした課題を解決すべく、富士通と富士通ミッションクリティカルシステムズによって開発されたのがInterdevelop Designerで、企業のシステム開発・保守作業を効率的かつ迅速に行えるように支援するツールとして提供される。

　最大の特徴は、日本語の設計書からCOBOLおよびJavaプログラムのソースコードを100％自動生成する機能（Javaコードの自動生成機能は現在開発中で、2015年3月末に提供開始予定）。
また、設計を変更する場合は、設計書の当該の記述を変更することで、ソースプログラムが自動的に変更される。ソースプログラム自体に改変を行う必要がなく、設計書とプログラムソースが常に一致するため、
文書管理やプログラム保守作業についても効率化することができる。

http://it.impressbm.co.jp/articles/-/11671

どうせその設計書を作るのにプログラム書くよりよっぽど難しいノウハウが必要なんだろw

>>2でおわってた

尻拭いさせられる下流のSE.PGが可哀想だわ、

日本語でソース書けるよって感じ

これに似た奴ってずいぶん前からなかったか

なるほど、こういうモノで地方自治体を騙すのがF本体のお仕事なんですね。

UMLが書ければ大丈夫だよ

仕様書からCOBOLソース作ってコンパイルって、富士通、昔やってたじゃん

こういうのは総じてクソ

男は黙ってASPENでソース手打ち！

設計書を書く→コンパイル→文法エラー
設計書を修正→コンパイル→文法エラー
。。。

YAC研修で習ったけど１回使っただけだった
ツールアップデートしないから後々めんどくさいことになった

こんなソフト誰が買うの？

マイクに向かって「こんな感じの作って」って言ったらコンパイルまでやってくれるツールだったら欲しい。
ついでにテストもやって、証跡作成までぜーんぶヨロシク。

一ヶ所でも臨時オペで人間がコードに直接手をいれたら当然ノンサポートだよな。

ノンサポートをオンサポートするために多大なテストは誰が負担してくれんの？

システム停まったら普段エンジニアが管理してる部分を機械がやるわけだから、そのコードを人間が解決するのは超絶厳しい。そういう時は対策時間も限られてるし。

どうやってこれを解決してるのか検討もつかん、、

このてのメーカー製ミドルなんて
お抱えの敏腕営業マンを他社と差別化させるためだけの道具であって、
契約さえ済ませば、あとは野となれ山となれ、な訳で。

まあいかにもCOBOLで飯食ってきた無能な連中が知恵出しあった僕達の理想ってかんじだなw
コボラーにはお似合いかな

どうせ生成されたコードを人による修正は必要なんだろうけど設計書に変更が入ったらどうすんのかねｗｗ

BAGLESってツールがだいぶ昔からあったろ

信用できねぇｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

どうせコードからドキュメントを逆生成する機能しか使わなくなるよ

COBOLとJava

ブロックで組み立て方式

コピペ

>>22
ソレすらも機能不全になるのは容易に想像できる訳で。
ちょっと入れ子になったMapでも使われたらアウトな予感。

cobol懐かしい
わしが入社して初めてならった言語じゃ！

ゴミコードいらん

高くてしょぼい製品しか作れないのが富士通

「System COBOL」って名前にすれば良かったのに

顧客が本当に必要だったもの画像通りなら設計書から生成したら
とんでもないモノが出力されるのが容易に想像できるｗ

>>2で終了

昔、CASETというのがあってだな

ここでループして処理を行うします。
とかうさんくさい日本語の設計書ができそう

YPSのことか？CAPEかも知れん・・・

QuiQpro、INTARFRMとは別？

いや経験あるけどそういうのじゃないよ。
エクセルみたいな表のフォーマットにこの列に演算項、この列に演算子とか決まってて、変数名とか全部日本語なだけ。

YPS-COBOL資産は捨てるのかな？それともリバースで取り込むのか？

結局これってシステムの新規開発用だよね

こんな素晴らしいソフトできたら
銀行は全部これ使えばよいじゃん！

(余計なことを・・・)

COBOL坊 は無駄の塊

まともな設計書もかけずに下に丸投げしてる業界では必要ない製品だな

日本語プログラム言語で自社でやっていただいたらいいだろ

そんでコンプガチャみたいにモジュールに値段つけたらいいだろ
つーかコンプガチャみたいに分かりやすく機能を説明したほうがいいと思う

他社のどこどこサンみたいな奴っていわれても口を突っ込むとまずいから知りませんだろ営業さん

設計書から自動でUTまでやるツールつくれ、無能。

SDEMなんとか

普通に書いたほうが早かったりして

このスレ、ITドカタが大集合だな

設計書ってCOBOLプログラムと同じレベルで詳細に記述するの？
それとも「こんな感じ」って書いておくと適切なプログラムを考えてくれるのかな？

つかCOBOLがまだ現役だった事に驚き

仕様書からコードを生成するのって、ある意味コンパイラだよね
doxygenの逆のアプローチか

外注切りたいんだろ・・・とか思ったｗ

どうせ設計が矛盾してるから大変なことになるだけ

設計書なんかあるわけないじゃん
設計書が正しいわけないじゃん
設計書どおりに作ってるわけないじゃん

>>4
尻拭いという新しい仕事が出来てSE.PGの定年が延びるからこれでいいんだろう

hell world

製造するのと同じレベルで設計しなければならないので製造したオフショアによるバグではなく、殆どが設計書不備となり、オフショアから仕様変更扱いとされる。
度重なる「仕様変更」にオフショアのストレスMAX。
必然的に詳細設計からオフショアに出すことになる。
オフショアで概要設計レベルを把握などしないから、結合テストでバグだらけになる。
詳細設計からやり直しとなるプログラム続出。
詳細設計からオフショア発注なので国内組は薄い体制しか組んでいないから、もはやスケジュール大幅遅延不可避。

それがジェネレータというものだ。

あ？仕事なくなんのか？
デスマ耐えてこの仕打ちか？

>>54
これ
無脳SEが書いたものなんて自動生成できるはずがない

identification devision

>>59
無能SEが書いた設計書からJavaコードを生成するための設計書を下請けが作るんだよ

需要なさそう

型通りの英語で処理手順を書けば、それを翻訳して実行可能なプログラムにしてくれる
それがコボルだろ
もともと簡単なもんなんだよ
それを日本語でとかいうから難しくなるんだよ
英語を使えよ、英語を

まあ正直言うと驚異だよな
人が不要になるしわ寄せが技術者に押し寄せるとは思わなかったわい

要件定義も設計書も
「〜を適切に行うこと」
って書いてあるだけですからwwwwww

完璧な設計書があるとしたならコーディングなんてすぐ終わるから必要ない

でも、日立のメインフレームじゃ使えなかったりするんだろ？

YPS
CASET
BAGLES

全部富士通が作ったCOBOLプリプロセッサ。
COBOLを知らなくても、仕様書を書くだけでよいという触れ込みだが、
富士通仕様の仕様書を書くために、本当の仕様書を書くことになる。

COBOLで業務システムを作れば、IBM 日立　NEC UNISYSなどに乗り換えられるが、
独自言語で囲んでしまえば、客が逃げる心配がなくなり、どんと値段を釣り上げることができる魔法の商品。

２５年ぐらい前にれからCASEツールの時代とか言われたな

YPSコボル・・・・

テスト自動生成の方がほしいかな

こういうツールって役人相手に仕事をやってるように見せるだけの
見せかけツールだよな

お前ら知らんだろうけど
cobolはcobolを動かすマシン毎にランタイムライセンスがあるくらいPCとは別世界の言語だから知ったかでオワコンとか言わない方がいいぞ

痒いところに手が届くような実装には
なりそうもないな

仕様書からCOBOLソース作ってコンパイルって、昔からあるでしょ・・・
今までのとどう違うの？

どうせコードレベルの設計書作成するんでしょ？

cobolシステムのメンテするには技術力より業務知識の方が重要じゃね？

どうやって行間をコード化するんだよ。

これの専門家が必要になるだろ
しかもこれしか出来ないマジで潰しのきかない専門家が

日本語の設計書からだと・・

糞みたいなソースが吐き出され、エラー時の解析が崩壊するようなことがないようになってるのかなぁ？

>>81
前にこんなようなの使ったことあるけど
GOTO文みたいなのばっかりで
とても追えないソースだった・・・

まあでもCOBOLで書かれるシステムの大半は
データベース周りのだからSQL自動生成＆COBOLコードとのマッピングと思えば。。。

おや、それってなんてORM

いまは汎用機にもLinuxが乗っかってJavaが動くんだよな

なんのシステムなのこれ

>>11
まだあるのか？

YPSｗと何が違うの

1ページのレスポンス5秒以内とか、そんな書き方から実装コードが出力されて動くならすごいわ。

>>9
あん時期に入社した
研修でYACチャートやらされた

デバックやバグ取りが大変そう

日本語のプログラムやろ
面倒なだけ

>>88
うわあそれ欲しい棒読み
先日無能SEに「mongoDB使えば速いって聞いたけど学習してます？アンテナ下がってません？」って言われて技術陣の怒りが団結した矢先ですしおすし

>>92
本来SEは安定運用実現のために枯れた技術を推奨するもんなんだけどな。それじゃないと達成できない製品なら別だけど。

この自動化ツールなんて、まさに枯れも枯れた技術で構成されてできてるんだろうけど。高速度処理は期待できないな。

>>2
言うのはやすぎ。

銀行向けにBAGLESを導入されますと、COBOLコードが生成されますってのがあったw

000100 IDENTIFICATION DIVISION.

外注に料金４割減を押し付けるんだろ？

>>15
いまも実現できてるよ。奴隷でな。

仕様書書く奴がプログラマになるだけ
本質的に何も経費削減されてない

どうせ客への売価なんてクソも下がらないんだろ

>>92
自分も無能の人だが、dbには問題があると思う。複数台数のCPUを使って、処理を分散できない。

仕様書の仕様書を書かなあかんやろ

自動生成されたプログラムを保守するのってほぼ不可能だよね。
末端は地獄だろうな。

こういうの入れたらこれ以外じゃ動かなくなるだろ
システムに縛りが入る

>>2
使ってから言えば？

>>16
有償でFのエンジニア派遣するんだろ
現場への教育も兼ねて

その昔YPS-COBOLなんてものがあってだなｗ

これがどんなものなのかしらんけど
いまどきCOBOLで凝ったシステムのコード書くとは思えん

DBやファイル周りのインタフェース定義と編集条件をエクセルかなんかで
INとOUTの対応表みたいな感じで書いて
それでコード生成というのなら
前にそんな簡易ツールを片手間に書いたことあるなあ

仕様書書くときに仕様書言語でプログラミングしてるだけで本質的には何も省力化されてないやつでしょ
知ってる知ってる

いまどきコードレベルの詳細設計書なんて役所相手の
「仕事やってるアピール」な水増し仕事でしか書かないだろ

目的と概要、ＩＯとビジネスルール（計算式）が揃ってればいい
コードレベルの設計みるならコードみたほうが正確だし

COBOLのドカタはコボカタさんって言うのか

コボラーじじい死亡ｗｗ

見かけ上の開発効率はあがるが、最適化がされていないため速度が出なさそう

>>103
つーか、この自動生成ソフト開発した奴呼ぶしかないだろう

昔からあるけどな、ほとんど使い物にならん

富士通ミッションクリティカルシステムズってあるのか、へぇ〜

てっきり幕張のシスラボの連中が作ったのかと．．．

>>113
未だにcobolで動いてるようなシステム速度いらんだろ
遅くなった分はハードウェアの入れ替えで帳消しだ

>>117
COBOLが使われてるのは銀行や証券を初めとする金勘定処理なので、ひたすら大量のデータを処理する必要があるな。

設計書次第だろうね。

設計書細かく書くほど、コード書いたほうが速いわってなりがちだけど。

COBOL ＞　設計書が読めません。日本語でおｋ？

設計書とか存在しないから、プログラムとデータからどんな役割なのか
類推して、どこをどう直すか考えるのがコボル保守の仕事だろｗ。

システムを理解していない奴が上司になると、仕事は見て覚えるとか
間抜けなこと言ってくるのなｗ。

役割とかプログラム読んだだけではわからないし、売上とかの集約が

店舗→県→地方→東日本、西日本→全国

となっていると最初からわかっているのと、集約の仕組みを読み取るのでは
掛かる時間が全く違うのに、読み取る能力が無いとかふざけているのか？

>>116
糞なまず人？

プログラム書いちゃったほうが早くて楽だって意見が多いみたいだな
プログラムから設計書を起こすソフトを開発して、それを変換すればいいんじゃない？

>>123
それは昔あった
2000年対策の頃には

COBOLってのが富士通らしいな

汎用性のない糞みたいな言語ルール覚えるだけで、結局コーディングと変わらないんだろ。
知ってるよ。今のプログラミング言語なんて、これ以上絞れないぐらい簡単なんだから。

>>114
ソースは触らないんじゃないか？
メンテナンスも仕様書から行うんだろ。
ソースファイルは中間生成物で、仕様書からCOBOLのロードモジュールやjarまでを作るんじゃないか。

コボルとかそんなのどうでもいいから、
エクセルのマクロで記録していったヤツを
最適化するやつ作ってくれ
他の人にマクロ入りやるときに、
「何コイツ、マクロの記憶で作ったのｗﾌﾟｹﾞﾗｯﾁｮ」
って思われそうで怖い

工場実習の時、蒲田の富士通FIPシスラボでコーディングした。
南武線分倍河原の寮で色々お世話になった。

開発・保守コストが40％削減てことは、発注費がそれだけ減るってことで、その上ツールの使用料金は別途請求されるとかｗ
どう考えても下請けイジメ。

変換フリーソフトをつくったら、嫌がられるだろうなw

シグマ計画…

>>132
それは日本のIT業界の触れてはいけない黒歴史…
口にしただけで呪われるぞ

COBOLのコード出力してどーすんだよクソワロタ

cobolってマイコン時代からのアレだからROMに組込んだ専用機だった

>>128
VBエディタで消せよ

自動生成されたソースを読み解くのに
技術力のある奴を雇わないといけない罠

その辺が解ってない上のひとが雑魚雇ってカオスになる

コメントがないソースから設計書つくってくれよ

エンドユーザのレビューに堪える機能設計書からＣＯＢＯＬプログラムを生成できるならちょっとは褒めるわ
プログラムロジックそのまま書いたものを設計書っていうならいまさらって感じ

>ソースプログラム自体に改変を行う必要がなく
ソースを生成するんじゃなくて、実行モジュールつくれよ。ｗ

>>135
COBOLは古くから銀行で使われた言語だから、紙テープや磁気テープによるロードがスタートじゃろね。
IBMのイメージ。

>>140
既存コンパイラ使うんだから意味ねぇ

富士通の人間が開発するわけないじゃん。
富士通から請負契約してる会社が契約する派遣PGにやらせる事になる。
派遣PGにコレ使うスキルがあるわけ無いし、仕様の説明に加えてこのツールの説明が必要になって、
中流ベンダが苦労する事に。

COBOLの仕事してた時こういうの誰か作ってくんないかなーと思ってた。
COBOLのプログラムは仕様書を言語にそのまま置き換えるだけでうっとうしい。

この板が盛り上がってないので、みなさんよろしくお願いします・・・

昔のPC
http://hello.2ch.net/i4004/



こんなスレも・・・

【WIZARD】WEST SIDE【OTADON】
http://hello.2ch.net/test/read.cgi/i4004/1096405458/

設計書で表現できるレベルの簡単なコードしか出てこないんだろ。
複雑な処理をするんだったら、直接コードを書いたほうが絶対に楽だし早いわ。

Javaプログラマーも! 要らんってこと
ちゃんと生成できたら購入した社長さんでもできるってことw

資料を見てみた
http://jp.fujitsu.com/group/fmcs/downloads/services/purpose/interdevelop-designer-catalog.pdf

予想していたとおり、結局のところ、インタフェースの定義書（入力→チェック→編集→出力）と
コード定義を辞書化してDB管理するような感じっぽいな

まあ、COBOLで書かれたシステムなんて、大半は巨大ファイルを読み込んで編集して中間ファイル出力
の繰り返しだから、こんなもんでもありなのかね

ただ、それ以外の細かい処理をやろうと思ったら積むと思うけど。あとパフォーマンス出んのか。
前にJavaでハイバネORM採用して処理遅くて結局生SQLで書きなおしたことあったが
それと同じことになりそうな気がしなくもない

プログラマーとSE死亡か？！

こうして、また仕事がなくなっていくのね

設計書：現状の手作業と同じ答えが出せること

>>148
パフォーマンスはこのソフトの改良が進めばいいだけで
設計書はそのままでいいだろ

COBOLのソースがいじれない（いじる必要がない）なら、「設計書」という新しいプログラミング言語なんじゃね。

この手のソフトはパフォーマンスを保証するするものではないから、現場のＳＥ・ＰＧが苦労するんだろうなー

言語すら自作したいんだね
自分とこの製品で固めたがる富士通らしいな

宇宙人はわれわれは宇宙人だって自動生成するけど恒星間移動できるテクノロジーがあれば当然のこと

>>156
富士通のオレオレフレームワーク触ったことある？
そびえ立つクソだ。

InterStageだっけ
大昔触ったわ

中身はただの旧バージョンのeclipseとTomcatだった

>>150
設計書の保守とか、表現できない機能の実装とか、特有のバグの調査だの標準化だの、再発防止だのでよけーな仕事が山盛り増えるんで無問題。

漢字とかも変換してくれるのかな？

一番そこまでやるかと思ったのは、こういうオナニー開発ツールを
「社内標準」に担ぎ上げ、専用の認定試験を作り、外注のソフトハウスの
発注条件に「その資格保持者が何名以上」とかいれた某社。

20年以上前、日立が　第4世代言語　EAGLE/4GLで　似たような事やってただろ

SIer系じゃないと知らんと思うが
設計書に絶対のルールが無いんだよね
人それぞれだし、建築物みたいにいかない
変換精度はどうでもいいが、これで設計書が標準化されれば嬉しいかな
ドキュメントがバラバラなのはこの業界が属人主義を表してる。が、クビが怖いのでわざとやってる

スペサフィケイターなる職種がw

ついに俺氏引退の時が来たか

OS/2 の悪口禁止

>>163
これは現在の詳細設計以上の情報量だから実際の保守の役には立たんと思われ。
(詳細設計なんて見るやついない)

クライアントも見ないだろうし、これを作らせるための設計書もいる。

結果として、基本設計とデータ設計はいまのままだと思われw

自動コード生成って
オーバーヘッドがでかそうだけど実際どうなん

>>167
たぶん既存設計書にほぼ追加してこの専用設計書を作成するんだろうな。
で、この設計書の作成・レビューのコストも追加される
そこまでやってもトータルコスト４０％減だから工期短縮できますｗｗｗ

富士通って自社に都合の悪いコストは見えなくなるメガネとか支給してるのか？

COBOLは金融向けなんだろうな
それよりJavaの生成か
動くの？ｗ

>>158
＞InterStageだっけ
＞大昔触ったわ
＞
＞中身はただの旧バージョンのeclipseとTomcatだった

おっと、菅田、小菅、立岩の悪口はそこまでだ

>>170
ほとんどのプログラマは冗長なオレオレコードばかり書いてるから
これで最適化されて標準化されれば目が覚めるだろう

元はBAGLESだよな
昔銀行でなんかやとった
COBOLを知らんやつが、プログラムの勉強するのがいややから
なんかこれにしがみついているアパレル男がおった