ソフトウェアコンポーネントとそれらの間の相互作用、渡される情報、各コンポーネントで行われるプロセス（詳細ではありません）、およびコンポーネントの入出力の明確な仕様をモデル化したいと思います。
私がこれまで見てきた UML は抽象的すぎて、あまり詳細には触れていません。
助言がありますか？
1 に答える
1
何人かの人は紙の上にプログラムを図として設計し、
次に、それらをソフトウェア開発者に渡し、Contruct に渡します。
このアプローチが試されます: 「賢い連中」がモデリングを行い、モデルを「普通の」開発者に渡して骨の折れる作業をさせます。そして、これはうまくいきませんでした。
私たちはアナロジーが好きです。私たちは何度も、モデルの設計図を作成する人もいれば建築の設計図を作成する人もいる建設業界に例えます。まず、UML やその他のモデル図は建設業界のモデルの設計図に相当すると考えます。しかし、私たちは間違っているようです。
建設業界に例えると、私たちの青写真はモデル図ではなく、実際に私たちが書いたコードです。
料理レシピのような詳細な紙モデル
詳細なモデルを事前に作成した紙の上でソフトウェア システムを完全に設計することは現実的ではありません。ソフトウェア開発は反復的で漸進的なプロセスです。
都市と同じくらい大きな都市の紙の地図を作成する地図作成者のことを考えてみてください。モデラーは抽象化レベルなしですべての詳細を含めるためです。それは役に立ちますか?
モデリングは役に立たない？
絶対にありません。ただし、問題解決空間の難しい部分に適用する必要があります。それらの些細な部分すべてではありません。
したがって、システムのすべての詳細を開発者に紙の上で説明するのではなく、視覚的な図を使用して、開発者と顔を合わせて問題解決空間の難しい部分を探ってください。
ソフトウェア業界では、好むと好まざるとにかかわらず、ソース コードは依然として王様です。そして、すべてのモデルは、実装されてテストされるまで嘘つきです
于 2013-10-10T12:03:14.937 に答える