派生開発における変更指示をモデルで表現する（問題編） - Qiita
セイコーエプソンの萩原さんと、モデルを使って派生開発の変更指示をうまく表現できない、という課題を議論しました。考えのメモです。 派生開発における「変更指示」 日本の組込み開発でよく使われる手法である清水さんの「派生開発」(XDDP)ですが、派生前の状態に対して「変更指示」を文書化します。 ソースコードレベルであれば問題は少ないのですが、構造に対しての修正は大域的になり、うまく表現しにくくなります。これをモデルで扱いたい、というのが問題です。 Before/After の問題点 まず考えられるのは、Before と After を示す方法です。 ここから実際の変更を行うのはとても観察力が必要！例えて言えば、間違い探しになってしまいます。 例えば astah などでは diff をとる機能もありますが、もっといい方法はないでしょうか？普通は「赤ペン」を入れたいところ。 さらに言うと、せっかくな
派生開発における変更指示をモデルで表現する（試案編） - Qiita
さて、派生開発の「変更」をどうモデル化するか。。。前回までのあらすじはこちら。 派生開発における変更指示をモデルで表現する（問題編） デルタの導入 欲しいものは、「修正」そのものをストレートに表現することです。なので、クラスの「修正」を表すステレオタイプ、《delta》を導入します。これは、クラスに対する変更指示そのものを示すクラスです。赤ペンで書くことを、少々フォーマルにして、このクラスの中に情報として書いて行きます。さらに、サブとなるステレオタイプ、《add》, 《delete》, 《modify》も導入。 デルタ: 《delta》 追加: 《add》 削除: 《delete》 変更: 《modify》 この 3 つに分け、変更を表現します。変更を「クラス」として閉じ込める分けです。さらに、この変更指示は、上位の変更要求に対応するはずです。この変更要求を「要求」（UMLでは《requi
折り紙の「コツ」をGSNで記述する。重要な暗黙知を引き出し共有するには - Qiita
この記事は、英語ブログエントリ"How to make it better ? - Extracting implicit knowledge via GSN"の日本語訳です。 -あまりうまくない「かぶと」- 折り紙をうまく折る 折り紙には上手い人とそうでない人がいます。また、外人に折り紙を教えると、手順はうまく伝えることができても、あまり奇麗にできることはありません。折り紙をうまく織るには、「ここは角がしっかり合うように気をつけて」などというコツをうまく伝える必要があります。 ソフトウェア開発においてドキュメント、コード、報告書などをレビューしていても、同じ悩みがあります。作成する手順、プロセスだけではだめ。この小記事では、折り紙を例題に、このあたりのことを考えてみたいと思います。 折り紙の「かぶと」１つ１つのステップは難しくありません。でもステップにはコツやポイントがあります（暗黙知と
オブジェクト指向の法則集 - Qiita
この記事は、故石井勝さんが1999年に書いた記事を Qiita に転載するものです。オブラブ(objectclub.jp)にて記事をホスティングしていましたが、現代でも十分に読める内容なので、たくさんの方に読んでもらいたいと思い、若干の編集（リンクとコンテキスト追加）を平鍋が行い、転載します。今でも、読みやすく、カジュアルな語り口のよい記事です。 オブジェクト指向の法則集（転載元：http://objectclub.jp/community/memorial/homepage3.nifty.com/masarl/article/oo-principles.html ） なお、この記事の他にも石井さんのオブジェクト指向やRubyに関する多くの記事をオブラブの「まさーるのページ」で読むことができます。では、以下に石井勝さん（旧メールアドレス masarl@nifty.com）の記事を転載します
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
