...またはなぜ彼らは失敗したのですか?
CASE として分類できるものの概念の証明を作成しようとしていますが、以前に行われた間違いのいくつかを回避したいと考えています。
ありがとう!
...またはなぜ彼らは失敗したのですか?
CASE として分類できるものの概念の証明を作成しようとしていますが、以前に行われた間違いのいくつかを回避したいと考えています。
ありがとう!
まず、図が小さくて単純である場合、図は真の価値を提供すると思います。大規模で非常に詳細な図は、ほとんどの場合、多くの紙、時間、ハード ドライブの容量などを浪費します。鉛筆と紙は、有用なほど小さい (そして十分に単純な) 図には非常にうまく機能します。ソフトウェア ツールが役立つのは、非常に大きく複雑なダイアグラムを作成するときだけで、実質的に役に立たないことが保証されています。
第二に、ほとんどの CASE ツールでは、ダイアグラムを描画する最も速い方法は、いくつかの (場合によっては簡略化されたモックアップ) コードを記述することから始めて、コードからダイアグラムを「リバース エンジニアリング」することです。ダイアグラムを直接描画すると、コードを記述するよりも時間がかかることがよくあります。実際の価値を提供するには、ハイレベルなダイアグラムを作成することは、同等のコードを記述するよりもかなり簡単でなければなりません。
とにかく、CASE ツールが実際に「ソフトウェア エンジニアリング」の「補助」として使用されているのを見たことがありません。私が見たほとんどの場合、ソフトウェア エンジニアリングは完全に個別に行われ、CASE ツールを使用して、既に記述されたコードから図をリバース エンジニアリングしていました。ダイアグラムを作成する人々は、一般的にそれらが役に立たないことに気づき、「すごい要素」のために上層部の管理者へのレポートにそれらを含めました。彼らがダイアグラムから望んでいた唯一の「助け」は、資金調達の増加を期待して、彼らが行っていることの複雑さを経営陣に印象づけることでした (純粋に複雑さを増すために、標準ライブラリの一部などのダイアグラムを含めたものもありました)。
ツールがソフトウェア エンジニアリングの部分でどのように失敗したかについては、単純な答えを 1 つも知りません。 、ギラギラした問題。大きな問題を 1 つ挙げる必要があるとすれば、私が調べた問題は実際にはパターンを考慮していないということです。たとえば、私が望むのは、さらに高いレベルの抽象化で作業することです。そのため、いくつかの機能を指定して、「その機能の次の部分をデコレータクラス?」はい、デコレータ クラスとして 1 つのダイアグラムを描画し、1 つのダイアグラムをデコレータ クラスとして描画できません。
典型的な CASE ツールとスプレッドシートを比較してください。スプレッドシートで 1 つのセルを変更すると、それに依存するスプレッドシート内の他のセルにどのように影響するかが自動的に再計算されます。対照的に、CASE ツールは (少なくとも私には) セルに変更を加えることができるグリッド コントロールのレベルにとどまっているように見えますが、そのセルに依存する他のセルと、どの数式を変更するかを手動で追跡する必要があります。影響を受けるすべてのセルを手動で使用、計算、および変更します。はい、正しい値のシートを印刷したい場合、それらをコンピューターで編集できるので、セルに消しゴムの跡がなく、改善されるでしょう-しかし、ほんのわずかですこれは、パソコンを一部の愛好家のおもちゃから、本質的に地球上のすべてのビジネスの必需品に変えたようなものではありません。
ウィキペディアのエントリ ( http://en.wikipedia.org/wiki/Computer-aided_software_engineering ) を見ると、1990 年代の「クラシック」ツールが表示されます。これらのツールの多くを扱ってきた私は、商品化に焦点を当てたことが市場を細分化したことを示唆しています。通常、ツールだけでなく、コンサルティング、トレーニング、およびランタイム環境にも多額の費用がかかりました。非常に多くのツールが提供されているため、特定のツールに特化した有能なチームを構築するのは困難でした。
さらに、ツールが売れすぎたのも助けにはなりませんでした。有望な経営陣は非現実的な生産性の向上を実現します。これほど多くのシェルフウェアを目にした IT の領域は他にありません。あるプロジェクトで使用された製品が、プロジェクトと共に放棄されることもよくあります。
CASE の概念は、Eclipse や他の多くの MDE ツールで生き続けています。急な学習曲線と断片化の問題はまだ解決されていません。ツールのコストは削減されましたが (多くの場合は無料になりました)、トレーニング、コンサルティング、および立ち上げのコストは依然として残っています。
CASE ツールに多大な労力を費やす前に、MDA、MDE、DSL、さらには UML のフィールドを調べてください。OMG の Web サイトも閲覧する価値があります。
結局のところ、ツールではなく、作成するものに集中する必要があります。いくつかのタスクを自動化できれば、それで問題ありません。さらに別の CASE のようなツールを構築することは、優れた知的作業ですが、商業的に成功する可能性は最小限です。結局のところ、IBM、Oracle、および Computer Associates は、自社のツールで散発的な成功を収めただけであり、企業顧客へのマーケティングを今も精力的に行っています。