uml - 従来のコードベースのエンジニアリングとモデル駆動型のエンジニアリング アプローチの違いは何ですか?

Question

文献でこの段落を見つけましたが、意味がわかりませんでした

設計の実践は、開発ライフ サイクルに沿って作業を強力に分割する従来のコード ベースのエンジニアリングから、設計フロー内のすべての人がモデルについて発言できるモデル駆動型のエンジニアリング アプローチに移行しています。

どんな助けでも大歓迎です

Answer 1

コードベースのエンジニアリングとは、ほとんどの作業がコーディング中およびコード内で行われることを意味します。広く使われている用語ではありません。これはプロジェクト管理方法ではありません。逆に、開発者がタスクを取得した直後にコーディングを開始する場合、PM の悪い慣行を否定的に説明しているように見えます。この方法は以前にも使用されていましたが、残念ながら現在も使用されています。

コードベースのプログラミングが長続きする理由は、最良のバリエーションでは、短いプロジェクト (最大 1,000 行まで) に非常に適していることです。説明/モデルをコメントに直接書き、Structured English(私は name に慣れていますPseudocode) を使用してそれらを 1 ～ 2 回書き直して、同じファイルにコードを挿入できます。小規模なプロジェクトで実際に機能します。人々は小規模なプロジェクトから始め、学生としてこの方法に慣れていることが多く、他の開発者アルゴリズムに移行するのが困難です。ただし、この方法はより大きなプロジェクトでは機能しないため、必ず実行する必要があります。

モデル駆動型エンジニアリングとは、作成された製品がそのモデルと定期的に比較されることを意味します。モデルも変更され、チームが到達する必要がある常に移動するターゲットです。この用語はアジリティプログラミングで登場したため、比較的現代的です。

コードベースのエンジニアリングではなく、テスト駆動型および要件駆動型のエンジニアリングに反対しています。コードベースとモデル駆動型のプロジェクトを作ることができます。しかし、私はそれをお勧めしません。

Answer 2

文の書き方に同意するかどうかはわかりませんが、文脈が欠けている可能性があり、いずれにせよ、それは質問の要点ではありません.

伝統的に、コンピューターの時間は高価だったので、デザインは通常、紙の上で行われました。デザイナーは要件を書き留めます。設計段階で、彼らはプラスチック製の「RapiDesign」テンプレート (私はまだ私のものを持っています...) を使用して紙にいくつかの図を描き、プログラムとデータのフロー図、ラダー (ロジック) 図、信号図などを描きました。プログラムの実行方法を定義するために、さまざまな手法 (「Structured English」など) が使用されました。次に、プログラマーはこの情報を取得して、コンピューターで実行できるコード (アセンブラー、COBOL、FORTAN、C) を実際に作成します。

進化の次のステップは、一部の作業をより適切に処理するためのソフトウェア ツールを構築することでした。情報を表示するさまざまな方法を備えたモデリング ツールが誕生しました。これらの初期のモデリング ツールは、モデルをサポートするためのセマンティクスがほとんど確立されていない、美化された描画プログラムでした。それらは基本的に、プロセスを自動化し、図面の修正を容易にするのに十分でした. Rational Rose (Booch 記法に基づく) と Popkin System Architect の初期リリースは、そのようなツールの例です。

これらのツールがより多くの機能と関連する方法論を追加するにつれて、いくつかのセマンティクスも追加されました (メソッドで暗黙的に示される場合もあります)。これにより、これらのツールでコードの生成を開始できるようになりました。これらのツールは主にオブジェクト指向のアプローチに関心があったため、生成されるコードはほとんどがクラス定義でした。動作セマンティクスの欠如により、実際に実行されるコードを作成できませんでした。

並行して、Booch、OMT、および Objectory をはじめとするさまざまな言語を結合するために、UML (Unified Modeling Language) が登場しました。UML が進化するにつれて、そのメタモデルはより複雑になり、より厳密になり、より多くの動作セマンティクスが追加されました。最近では、抽象言語フレームワーク (ALF) も定義されており、プログラムが実行する必要のあるアクションは、グラフィカルな UML 表記を使用して常に表現できるとは限らないことが認識されています。

UML と並行して他のメソッドも登場していることに注意してください。モデル駆動型エンジニアリング アプローチを実装したいくつかの注目すべきアプローチは、ROOM と SDL です。どちらもドメイン固有であり、どちらも UML の進化に機能を提供します (例: ROOM: 構造化クラス、SDL: メッセージ シーケンス チャート)。

これが現在のモデル駆動型エンジニアリングの世界であり、使用されるコードを駆動するために、紙や黒板に描かれた図ではなく、定義されたセマンティクスを持つ形式化されたモデルが設計プロセスで使用されます。

サポート ツールを備えた一部の特定のドメインでは、モデルから完全なアプリケーションが生成されてデプロイされるケースも見られます。つまり、モデルがコードになります。

このモデリングの歴史全体は、実行中のソフトウェアの世代の進化の継続でもあり、そこでは抽象化のレベルがプログラマブル ゲート アレイからバイナリ、アセンブラ、2GL (例: C)、3GL (例: C++)、そして今モデル。

Answer 3

歴史

コードベースのエンジニアリングとは、プログラマーが頭の中で何らかのモデルを作成し、対応するコードを作成することを意味します。要件が変わると、プログラマーは頭の中でモデルを変更し、コードを書き直します。このようなプログラマーは、プログラマー アナリストとしても知られています。(s)彼は漠然とした、しばしば書かれていない要件からコードを作成し、他には何も必要としません。ワンマンショー

未来

それどころか、モデル駆動型エンジニアリングは、コーディング作業が完了する前に、要件を十分に明確にし、書き留めて、ターゲット システムとコードの「モデル」を作成する必要があることを意味します。BPMN、UML などのいくつかのモデリング標準を使用します。このモデリングは通常、プログラマー以外の「アナリスト」によって行われます。次に、プログラマーはモデルを (承認後に) 受け取り、アイデアをコードに具体化します。このアプローチは、特に大規模なシステムでより適切にスケーリングされます。

このアプローチの理想的な目的は、コード (バグを含む) を手動で記述する必要がまったくないことです。モデリング ツールは、モデル駆動型アーキテクチャ (MDA)をサポートし、場合によっては実行可能 UMLをサポートする必要があります。これにより、モデリングの結果が一連の「図」および明確な要件以上のものになります。アプリケーションのバックボーンを形成するソース コードのスケルトンになることもあれば、モデルをクリックして実行する製品になることもあります。

現実

たとえば、 Sparx Systems Enterprise Architectには、このアプローチをある程度実現する多くのモデル駆動型生成 (MDG) テクノロジが含まれています。リバース エンジニアリングによって既存のコード (多くの言語がサポートされています) を UML モデルに変換し、変更後にモデルからコード (多くの言語がサポートされています) を生成できます。多くの UML モデリングの側面 (動作、構造) がサポートされています。実際の画像を取得したい場合や、興味が「学術研究」以上のものである場合は、このソフトウェアで遊ぶことをお勧めします。

(無料ではありませんが、評価ライセンスを取得できます。真剣な作業の場合、製品に多大な労力が費やされるため、何度も費用がかかります。私は彼らの幸せな顧客であるため、偏っています)

Answer 4

コードベースとモデルベースのアプローチの違いは、より高い抽象レベルのプログラミング言語への移行と考えることができます。たとえば、アセンブラー言語や、C/C++、Java などの高水準言語があります。したがって、UML などのモデル言語は、技術的な詳細から抽象化し、解決すべき問題に集中するための次のステップにすぎません。他の言語と同様に、「低」レベル言語 (EMF の場合は Java) へのコンパイル/コード生成が必要です。