派生開発における変更指示をモデルで表現する（試案編） - Qiita
さて、派生開発の「変更」をどうモデル化するか。。。前回までのあらすじはこちら。 派生開発における変更指示をモデルで表現する（問題編） デルタの導入 欲しいものは、「修正」そのものをストレートに表現することです。なので、クラスの「修正」を表すステレオタイプ、《delta》を導入します。これは、クラスに対する変更指示そのものを示すクラスです。赤ペンで書くことを、少々フォーマルにして、このクラスの中に情報として書いて行きます。さらに、サブとなるステレオタイプ、《add》, 《delete》, 《modify》も導入。 デルタ: 《delta》 追加: 《add》 削除: 《delete》 変更: 《modify》 この 3 つに分け、変更を表現します。変更を「クラス」として閉じ込める分けです。さらに、この変更指示は、上位の変更要求に対応するはずです。この変更要求を「要求」（UMLでは《requi
「追加開発時にデグレードが気になる」という相談：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
去年1年くらい（2007年）で昔の仕事仲間や大学のときの知人からプライベートな場で何件か相談を受けた。デグレードしないように改変したいという点で、内容はどれも似通っている（デグレードについてはここに書いた）。対象ソフトウェアも以下のようなもので似通っている。改版時に何か役立つものを知らない？という相談だ。 数年前くらいでいったん開発を終えた。 当時の担当者が異動になったりして情報が少ない。 組織として「中規模」以下に位置付けられ、ドキュメンテーションや管理等、若干緩め。ソースコードへの改変のうち、ドキュメントに記録されていないものがある。 ちょっとした機能追加をしたい、あるいは、今後の保守に備えて既知の潜在的な不具合を直しておきたい。 この状況で、抜本的、安全で低コストの手法があればいいのだが、そうそう簡単な方法はない。間接的に以下のような解決策に頼ることになるだろう。 より一層コストを積
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
