GREEも上場企業なんだから、これやっちゃ、やばいよな・・・

ここの痛いニュース

GREEで配信中の「ラブプラス」風のギャルゲー、イラストのトレース発覚
http://blog.livedoor.jp/dqnplus/archives/1568954.html

重ねると、ばっちり一致しますね・・・
これは、まずいよな・・・

astah*を使って、ICONIX風一気通貫システム開発 その１：概要

　いままで、開発のはじめから終わりまでを、何回か書いてきた。
　でも、１つのツールを出来るだけ使って、その操作法を書きながら、一気通貫させる方法は、書いてない。

　そこで、astah*を使って、開発の要求仕様から、プログラム作成までを、トレーサビリティを保って、どのように開発するかを書いてみたいと思う。

　まずは、概要。

　こんな手順になる

（１）astah*の「ユースケース図」を使って、作るべきもののユースケースを書く
　　　（場合によっては、「アクティビティ図」を先に書くことも）

（２）ユースケースシナリオを書く


（３）（ロバストネス分析）
　　　ユースケース図の１ユースケースを１コントロールとし、
　　　コントロールに付随するバウンダリを１個用意して、
　　　ユースケースシナリオにもとづき、エンティティを作成し、
　　　さらに、ユースケースシナリオの内容に基づきメッセージを
　　　コミュニケーション図に記述する

（４）astah*において、バウンダリ、コントロール、エンティティはクラスになっている。
　　　そこで、コントロールの処理を考えながら、必要な入出力を考え、
　　　バウンダリ（画面）、エンティティ（テーブル等）の属性を埋めていく
　　　→コントロールが肥大化している場合、コントロールクラスを、いくつかに分割してもよい

（５）バウンダリの項目を元に、画面構成を考える。
　　　各画面を１クラスとし、画面入出力項目を決め、
　　　画面遷移を考える。
　　　画面遷移(図）は、１画面１状態として、ステートマシン図で記述する

（６）(必要があれば）エンティティを正規化して、ER図にする

（７）フレームワークを決定する

（８）フレームワークに応じて、（５）で作成した画面クラスを、
　　　ソースコードに書き直す

（９）フレームワークや利用するDBに応じて、（６）のエンティティ
　　　(クラスまたはER図）をDBのテーブルと、DAOに書き直す

（１０）フレームワークによって、こういうコントローラーにしろ！という
　　　指定があるので、（３）ないし（４）で作成したコントローラーを、
　　　フレームワークに合うように書き直す

ユースケース駆動のところ、ロバストネス分析をしているところが、ICONIX風。
ただし、その後、ちょっと違うので、ICONIXでなく、ICONIX風とした。

次回から、上記についての説明を書いていきたいと思う。