やあ皆さん、それは実際にはプログラミング関連の質問ではありませんが、間違いなくプログラマー関連です。新しい Case ツールが開発されていた場合。仕様から設計までのシステムの動作を説明するために、どのような機能が必要ですか。
1 に答える
3
CASE の基本的な問題は、分析/設計/コーディング/展開 (または選択した手順) の反復を進めると、ソフトウェア システムのさまざまなビュー間で維持および合理化する必要がある詳細とマッピングが指数関数的に爆発することです。 . 私がこれまでに遭遇したすべてのケース ツールを打ち負かすのは、この爆発です。それらはすべてうまく機能しているように見えますが、いくつかの中間レベルのアーティファクトを作り直すことに直面した場合、変更の影響は他の何かを壊さずに伝播するのが非常に難しく、それが他の何かを壊し、最終的に管理不能になるカスケードにつながります. 影響カスケードは、より高いレベルの抽象化からより低いレベルの詳細へと移行する際に関係が爆発することの論理的な結果にすぎません。
最終的には、Case ツール内での変更管理/影響の管理に費やされた時間/リソースがそのメリットを上回り、単純な非 Case ダイアグラム/ライティング ツールに戻ってしまいます。
したがって、私のアドバイスは、緊密に統合された CASE システムを構築しようとすることを忘れることです。UML の基本的な図と表記のサポートを提供します。さらに、マクロ機能を提供するため、ユーザーは動作をカスタマイズしたり、ソフトウェア開発の管理に使用される他のツールと統合したりできます。
最後に、Case ツールによって管理されるすべての「アーティファクト」を XML に保持します。これにより、ユーザーが独自のカスタム プロセッサと xsl を製品に追加できるようになります。
最終的に真の価値は、CASE ツールが実際にどれだけ機能するかではなく、ユーザーが独自のソリューションを構築するために提供するフレームワークです。
于 2011-01-12T15:59:58.040 に答える