なぜUML

Vsevolod Leonov-エンバカデロのプロダクトマネージャー。

アレクサンダーリュリン -リードデベロッパー、 ガーラント

マキシムクリロフ-Garantプロジェクトマネージャー



次の段落の情報は、 本質的に広告ではありません 。 著者は誰も、その名前の繰り返し発音から頭に現れる特性、機能、競争上の優位性、感情的な認識の文脈でソフトウェア製品を議論したり言及したりしません。 以下は、招待された専門家の資格を決定するための製品および会社への参照です。 簡単に言えば、「best-xxx-dauloader-iksployt」プログラムを開発した特定の「Vasya Pupkin」のUMLに関する意見を読むことに興味があるのは誰ですか？



Garant社は 、主要製品であるIPO GARANTシステムにより、多くのロシアのIT専門家に知られています。 同社の従業員のほとんどはソフトウェアの生産に従事しており、システム自体には23年にわたる開発の歴史があり、さまざまなプログラミング言語で記述された数千万行のコードがあります。 このような規模、言語的および技術的な異質性、高い生産率、安定性に対する非常に厳しい要件により、進化するシステムの品質を保証できるのは最先端の技術のみです。 モデリングツールとしてのUMLは、間違いなくそのような「高度な」アプローチの1つであり、「Garant」企業でのアプリケーションは、システムの役割を強化する重要な部分を持つ高レベルの自動化によって区別されます。 今日、GARANTシステムの主要な開発者であるAlexander LyulinとプロジェクトマネージャーのMaxim Krylovが経験を共有しています。



広告がないことの証拠-上記の内容を見てみましょう。 決定したのは：

• 専門家が従業員である会社の名前。
• 会社のウェブサイト。
• 会社概要;
• 会社が生産する製品。
• 製品の技術的パラメーター（定量的および定性的）。開発の規模を評価できます。
• UMLがソフトウェア生産プロセスに浸透する度合い。

同社のウェブサイトは、広告目的ではありません。 「広告なし」の標準であるウィキペディアもそうです。 上記の段落は、出版物にa）完全性を与えるのに役立つ。 b）読者への責任。



（広義の意味で-人、企業、専門家、専門家）が著者に同意しない場合は、このテーマに関する出版物へのリンクが表示されます。 これに関するヘルプが必要な場合は、vsevolod.leonov @ embarcadero.comにお問い合わせください。



Vsevolod ：教えてください、UMLの使用は開発プロセスのコンポーネントの1つとして当初受け入れられましたか？



マキシム ：いいえ、もちろん、ガーランドに着いたとき、彼はただそこにいませんでした。 しかし、すでに97年に、若くて才能のある同僚（当時は私たち全員が若かったのですが）が、最初のUMLモデリングツールの1つを備えたフロッピーディスクを持ってきたようです。 この時点で、「保証人」の壁にUMLが導入され始めたと想定できます。 しかし、いわば産業規模で言えば、私たちの主要なプロジェクトで使用されるまでには何年もかかりました。



Alexander ：さらに、UMLの使用は長い間、いくつかの段階で実装されてきました。 開発が成長し、このツールがないと、ますます複雑化するコード構造とプロジェクトの内部アーキテクチャに対応できないリスクがあることを理解しています。



Vsevolod ：「イデオロギーの不一致」はありませんでしたか？ さまざまなコーディングスタイルがありますが、「誰もが独自のUMLを持っている」とはうまくいきませんでしたか？ それとも、UMLは「全員を1つの櫛の下でunderく」のですか？



アレクサンダー ：もちろん、意見の相違がありました。 そして、導入のイデオロギーに基づいて、すべてを「くし」にし、既存のアプローチを統一したいという願望がありました。



マキシム ：1人または2人の愛好家の実験からUMLの使用がプロジェクトの実装段階に移行する頃には、それが何であり、なぜ、どのように「異なるUML」が存在しないようにするかについてかなり明確な理解がありました。



Vsevolod ：どの時点でUMLを検討する決定が下されましたか？



アレクサンダー ：プロジェクトが複雑だと気づいたのはいつですか。 多くの人々が彼らに関与していること。 何とか「交渉」するために必要なもの。 そして、プロジェクトの全体的なアーキテクチャを何らかの形で「見る」必要があります。



マキシム ：長い間、その使用は、「開始者」の狭いグループによる消費のための個人的なスケッチに限定されていました。 ある時点で、彼らはそこからCORBA IDLの生成を開始しようとしました。 その結果、彼らはそれがほとんど不可能であるという結論に達し、独自のシンプルなジェネレーターを作成しました。 実際には、これはリターンのないポイントでした。 その後、ほとんどのプロジェクトでUMLが使用されるようになりました。最も重要なことは、UMLが単なる写真のセット以上のものに変質したことです。これについては後で詳しく説明します。 しかし、初めは、はい-より速く、より効率的に交渉する機会として。







Vsevolod ：UMLでさえ同意できない場合がありましたか？



マキシム ：どのチームでも、誰かが交渉の欲求を失った場合があります。 ここではUMLも他のものも役に立ちません。 しかし、人々が建設的な立場をとるとき、普遍的な言語の存在は人生をとても楽にします。



アレクサンダー ：UMLは教義でも「普遍的な薬」でもありません。手段です。 しかし、仕事は本当に良くなりました。 システム全体を単純に「一”」することが可能になり、レビューの範囲をすばやく変更できるようになったためです。 次に、UseCaseを見て、5分後には既にバイト数になっています。 スケーリングは非常に高速です。 Google Earthのように言ってください。



Vsevolod ：そのような手法を使用し、単に「交渉」する必要があるのは、コード内の「責任範囲」の分布に問題があることを示す指標ではないのですか？ 誰がどのクラス/メソッドを開発し、誰がそれらを使用するかを明確に区別できる場合、交渉して同意するのはなぜですか？ 私はボルトを作り、Vasyaはナットを作り、Zhoraは2つのパーツを作ります。 詳細は何ですか？ 関係なく、責任範囲を明確に分けました。 ソフトウェア開発でこれが機能しないのはなぜですか？



アレクサンダー ：ある時点まで、そのような計画は私たちのために働いた。 しかし、私は役割を変えなければなりませんでした。 他のものを交換してください。 そして、プロジェクトの複雑さが増しています。



Vsevolod ：そして、プロジェクトがすでに「複雑」になっていることをどのように理解しますか？



マキシム ：それはすべて、ボルトナット部品チェーンの数、各ナットの汎用性、ボルトの多様性、およびそれらの取り扱い方法に依存します。 「こんにちは、世界」を書くために、誰かと交渉して責任を共有する必要はありません。 UMLとOOP、SOAP、XML、および柔軟な方法論は不要です。 すべては、プロジェクトの成長から始まります。 ある時点で、Vasyaがナットのネジ山の直径を変更し、Zhoraがそれらをボルトにねじ込むことができなくなり、さらに悪いことに、すでにどこかでさらに飛び出していることが判明しました。 または突然、チェーンの最後に真新しいマーシャがいることが判明しました。マーシャは非常に困難で、ナットとボルトを緩めて戻し、隣接するワークショップから来るリベットと交換します。 これらはすべて原始的な例ですが、蓄積、混合、奇妙な組み合わせの形成、複雑さの原因となるのは、プロセスと結果の両方の品質を失うからです。



プロセスのすべての参加者が理解できる表記法を使用すると、そのような驚きの数が減ります。 ボルトとナットを使用した仮想的な製造は、図面と文書なしでは不可能でした。 しかし、これでも十分ではありません。 効率的なコンベアを構築するには、CNCマシンとロボットが必要です。 それらは明確にかつ自由に入力ドキュメントを解釈し、保証された結果を提供します。 したがって、UMLだけではUMLほどのメリットは得られず、「マシン」にフィードして100％有効なデバッグ済みコードを取得し、手動モードで最終製品に変換できます。



Vsevolod ：モデリングプロセスはどのように進んでいますか？ これは、「関心のある同志」のグループが集まり、同時に「チャートに指を向けて」それを作成する方法ですか？ または明確な区別があります-マスターフォロワー。 つまり 引き分け-他の人は注意しますか？



アレクサンダー ：それは起こります。 そして彼らは集まり、突く。 マスターとスレーブの分離も起こります。 しかし、これは投稿というよりはむしろ「役割」です。 「専門家の輪」は最初のものです-何らかの種類があります。 まず、口頭で話します。 次に、要件を読みます。 次に、それらについて質問します。 それらに対する答えが得られます。 プロトタイプを作成します。 そこのどこかで「専門家の輪」を定義します。 狭い。 またはより広い。 ソリューションで実行します。 「TKの落とし穴」または「既存のアーキテクチャ」との矛盾を見つけます。 さらに、プロセスは一般に周期的です。



マキシム ：私たちは、原則として、すべて、まあ、またはほとんどすべてを描きます。 もちろん、プロジェクトと詳細に依存します。 しかし、理論的には、「リーディング」モデル（つまり「ie」）-「led」は、より正確で実行可能だと思われます。 一部の長所を最適に使用し、他の短所を相殺することができます。 設計を上手く「地上」にいる人は、モデルを描きます。 アルゴリズムの実装に自信を持っている人は、アルゴリズムからコードを生成し、ビジネスロジックで埋めます。



Vsevolod ：UMLを使用して最初に解決したい問題は何ですか？



マキシム ：最初は、実験レベルで、思考を構築する方法として。 最初の実験には描画クラスと接続のみが含まれ、明確に定式化された実用的な利点はありませんでした。私たちはそれを美学的に好み、「古典」の本のイラストを描いているかのようにクールで興味深いものでした。 しかし、実際の実装時までに、私が解決したかった主な問題は、「ルーチン」コードの手動コーディングの速度と品質が不十分だったことでした。 つまり 最前線にはコード生成がありました。



アレクサンダー ：関係の複雑さ。 「裸の」コードでの「知覚不能」。 設計およびコーディング規則。 テンプレートソリューションの使用。 繰り返しますが、UMLはより正式に「同意する」機会と見なされていました。



Vsevolod ：そして、なぜまさにUMLですか？



マキシム ：当時は単に代替手段はありませんでした。UMLは、ある種のコード生成であっても、対象分野を包括的に説明し、手段をサポートする唯一の汎用グラフィカル表記法でした。 したがって、これは歴史的に起こったと言えます。 その後、「どのように」描くのがそれほど重要ではないことに気付いたとき、どれだけの「何を、なぜ」、そしてUMLを他の何か（例えば、DOT）に変更するのは意味がありませんでした。 概して、UMLはほとんどの人にとって馴染みのある特定の表記である「矢印と正方形の形状」であり、重要ではありませんが、動作の原則、つまり、 私たちが何をし、どのように。



Vsevolod ：古典は欺かれませんか？ または、UMLの場所と役割について独自のビジョンを持っていますか？



マキシム ：古典が基礎を設定し、それを使用しました。 そして、私たちには思われるが、完全に定式化されていないように、暗示される古典として使用されます。 まず、モデルの浸透度が決定されていません。 はい、誰もがMDAについて聞いたことがありますが、何人がそれを見ましたか？ 私たちはこれを「修正」しました。たとえば、メタモデルのバージョンの1つは、解決すべきUMLの「問題」、それらから「機会」、それらからの「先例」などの説明でシステム設計を開始することを意味しました。 「サイドボード」、「バイト」に。 これはすべて、ユーザーの問題が解決する各「バイト」について言うことができる全体的なモデルでした。 そして、「問題」ごとに-それに関連するすべてのソースコードを取得します。



アレクサンダー ：これは一種の「入れ子人形」と「組立図」です。 さらに、さまざまなレベルで、「クラシック」のようにクラスビュー、展開ビューだけでなく、任意の数にすることができます。 「エンタープライズレベル」の図面と「STLスタイルのコンテナレベル」の設計。 UMLを使用すると、タスクの複雑さを「対数化」できます。 個人的には、十分に大きいUseCaseの設計/コーディング/デバッグ/テストは、「整数のリスト」のデバッグよりもそれほど難しくありません。 もう1つは、「整数のリスト」のデバッグに数か月かかる場合があることです。

など-「組立図面」、入れ子人形、「超小型回路の命名法」。 これらが基本です。 一方では、それらは「対数」の複雑さであり、他方では、システム検討の「スケールをすばやく変更する」ことを可能にします。

それでも、「クラシック」は「ステレオタイプ」に十分な注意を払っていませんでした。 そして、私たちにとってこれが礎石です。 <<ステレオタイプ>>は、アーキテクチャの要素であり、メタモデルです。 ステレオタイプは、コード生成の方法と最終コードに影響します。



Vsevolod ：「ステレオタイプ」の概念について話しましょうか？



マキシム ：「クラシック」ツールでUMLを使用する場合の主な問題は、コード生成が事前定義された静的メタモデルと密接に結合していることです。 どちらも変更できません。 ルールを変更したり、拡張したり、ルールを変更したり、新しい特定のルールを設定したりしないでください。 主なことは、古典が一般に公開されておらず、「古典的なツール」が実現されていなかったことです。これはメタ構築の観点から正確にUMLの可能性です。 独自のコード生成を使用して独自のメタモデルを作成します。 そして、ここでアレクサンダーが話す「ステレオタイプ」の概念が重要な役割を果たし始めます。 ステレオタイプにより、特定のメタクラスのグループを定義し、それらに任意のコード生成をバインドできます。 実際、ステレオタイプの助けを借りて、任意のメタモデルを形成します。これは自動的に独自のDSLになり、実装するルールによって正方形をコードに変換します。 UMLが私たちにとって絵を描くためのツールだけでなく、開発プロセスを本当に単純化し、時には本当に不可能なことを不可能にするものになることを可能にしたのは、この側面でした。 そして、商用ツールにこれまたは同様のメカニズムが存在しないことで、UMLが使用されなくなり、「5番目のレグ」と見なされるようになったようです。



Alexander ：UMLには、UML自体に描かれた独自の「メタモデル」があると付け加えます。 「要素クラス」という概念があります。 これらは、クラス、カテゴリ、操作、属性、依存関係、ポート、ユースケース、アクターなどです。 これらのクラスから「有限図」が構築されます。 また、コード生成は通常、クラスだけに結び付けられています。 しかし、これは「クラシック」の間違いです。柔軟性も拡張性もありません。 私たちは、いわばレベルを上げました。 UML自体は、メタメタモデル、つまり ルールの形成のためのルール。 次に、必要な概念を導入してメタモデルを定義します。 たとえば、Delphiの場合、多重継承の可能性を判断できます。 次に、このメタモデルに、その要素をコード（またはドキュメント、補助ファイルなどの他のアーティファクト）に変換するためのルールを添付します。 多重継承の例では、これは単一の継承と集約への変換になりますが、同時にプログラマーの観点からは完全に100％の継承のように見えます。 最後に、サブジェクト領域の実際のモデルを作成していますが、「クラシック」が最初に提供したものではなく、メタレベルで私たち自身が発明したすべての武器ですでに動作し、それらから複雑な既製のコードを取得します。



Vsevolod ：それがどのようにあなたのために発展したのか詳細に教えてください-段階的ですか？



マキシム ：新しいバージョンのGarant（Platform F1）の作業の開始時に、問題に直面しました。サーバーはC ++ / CORBAで開発され、クライアントはDelphiのシェルでした。 特定の理由により、DelphiのネイティブシェルでVisiBrokerを使用できませんでしたが、サーバー側の適切な代替手段が見つかりませんでした。 その後、CORBAを使用してサーバーで動作するクライアント（C ++のdll）上で「アダプター」を作成し、さらにいくつかの内部変換、キャッシング、さらには必要なすべてを提供しながらクライアントロジックの一部を含むソリューションを提案しましたDelphiシェルをわかりやすく便利な方法で。 アダプタとシェルが相互作用するインターフェイスの命名法である「保証人」のようなシステムが、脅威となる割合をすぐに獲得したと言う価値はないと思います。 C ++のdllとdelphiの間のオブジェクトインターフェイスを想像してください。 要するに、これは「本当の地獄」です：異なるタイプ転送ルール、異なるメモリ管理、エクスポートされたヘッダーとDelphiの記述制御の欠如、まったく矛盾が完全に予測不可能な結果と非常に重要なデバッグなどにつながる場合



予定されていたインターフェースの数と、そのばらつきの程度を考えると、タスクが本質的に実行不可能であることがすぐにわかりました。 実際、現時点では、初めて「意図した目的のために」UMLを使用しました。 CORBA IDL用の独自のジェネレーターは既にあり、メタモデルとそれに基づいたコード生成を記述するテンプレートの原則に基づいて既に構築されています。 実際に必要なのは、アダプターインターフェイスの新しいメタモデルを定義し、それに基づいてコード生成を記述することでした。その出力は、すべての機能と微妙さを考慮して、C ++とDelphiの両方について100％一貫した記述を生成します。



その結果、すべてが十分に迅速に行われ、結果をもたらし始めました。 アダプターを作成したC ++プログラマーは、どこかにエクスポートする必要があるとはまったく思いもしませんでした。Delphiのプログラマーは、通常の原則に従って、まるでDelphiで作成されたかのようにアダプターを操作しました。メソッドとプロパティに名前を付ける前。 すべてがモデルに必要なインターフェイスを描画し、コードを生成し、両方の言語に対して「ネイティブ」な方法で機能しました。 概して、これは最初の成功物語であり、その後、テンプレート生成とメタモデリングのアイデアを積極的に開発し始めました。 また、多くの分野で（すべてではありませんが）印象的な結果を達成しています。



Vsevolod ：新しい人は開発チームにどのように関与していますか？ 彼は図の「ヒープ」を与えられますか？ それとも、「システム全体を見る」必要のない基本的な操作から始めますか？



Alexander ：非キーまたはマイナー機能のリストがあります。 手始めに-それらを与えます。 しかし、それほどではありません。 ルーチンを「非難」しないために。 それがどのように描かれるのか見てみましょう。 途中で、「インフラストラクチャ」とそのコンポーネントについて説明します。 口頭および書面で助言します。 読むことをお勧めする一連のドキュメントもあります。 その後、徐々に、「実際の」タスク、モデル、その他すべての作業を行います。 そのようなもの。 アジェンダに「別個の大きなタスク」がある場合、それらから始めます。



Vsevolod ：誰もが、新しいアプローチと方法が常にすべてのチームメンバーによって肯定的に認識されているわけではないことを知っています。 アクティブまたはパッシブ抵抗のケースがありましたか？



マキシム ：多くの人が「私たちのUML」を自分の生活への侵略、行動の自由の制限として認識しています。 結局のところ、その前に、誰もが望むようにプログラムしました。 インターフェイスだけでなく、設計実装のレベルでもいくつかのルールと制限がありました。 おそらく、私たちは少し行き過ぎて、あまりにも多くの制限を導入しました。 しかし、これは非常に強力なツールです。メタモデルとコード生成を定義するだけでなく、それに関連する任意の「定数」を記述することもできます。 たとえば、「結果としてコレクションを参照で渡すことはできません」または「メソッドは5つ以上のパラメーターを使用できません」から、アーキテクチャ層を制御し、要件に対する「トレーサビリティ」まで。 もちろん、すべての制限に同意するどころか、それらの多くはおびえ、押しのけられました。



Vsevolod ：実装プロセスはどのように進みましたか？リバースエンジニアリングは実行されましたか？



アレクサンダー ：やったな。 その瞬間、良いツールはありませんでした。 そして今、私はこれが必要ではないことを深く確信しています。 なぜなら「既存のコードを描く」プロセスでは、考え直され、アイデアとそれをリファクタリングする方法が現れます（描画プロセスで単に見直すだけでなく、別の段階として行ってください）、デザイン/コーディングテンプレートが適用されます。これを行う「マシン」はありません。 「自動機械」によって何かをあらゆる種類のモデルに転送しようとする試みはすべて、憂鬱に見えました。



マキシム：既にテンプレートジェネレータを作成する段階で、自動リバースエンジニアリングは「悪」であることが明らかになりました。そして、言語のネイティブな抽象化のみを含む基本的な基本メタモデルを持っているとしても、十分に高い品質レベルでそれを実行することが実際に不可能だからではなく、理論的にも自動リバースを行うことは不可能だと思うより複雑な特定のメタモデルは言うまでもありません。重要な点は異なっていました-逆方向の存在は、コード生成にUMLを使用するというアイデアを壊します。私たちの仕事は、自分自身で学び、コードではなく、可能であればコードに関連しない抽象化で考えることを他の人に教えることでした。これは別の複雑なトピックであり、私たちにとって非常に重要でした。したがって、私たちのジェネレーターは、そのアーキテクチャーとコードの生成方法において、除外され、同時に逆にする必要がなくなりました。など。



Vsevolod：OOPに「戻り」ましょう。 UMLはリファクタリングを促進していると言えますか？



アレクサンダー：はい。貢献します。しかし、リファクタリングと「要件の実装」を混在させないでください。それらは「時間内に広がる」必要があります。そして、テストについて考えてください。



マキシム：繰り返しますが、「何」のUMLを見てください。単純に「デッド」ダイアグラムを描画する場合、これはあまり役に立ちませんが、小さなプラスの効果が得られる場合があります。私たちの場合のように、メタモデルと定型コード生成がある場合、リファクタリング機能はまったく新しいレベルにあります。



ヴセヴォロド：なぜオブジェクトコードをリファクタリングする必要があるのですか？これは経験不足ですか？または、システム全体の進化による客観的な理由ですか？または、システムの自然な「幅と深さの成長」だけですか？



アレクサンダー：上記の理由はすべてここに当てはまると思います。リファクタリングは別の大きなトピックです。しかし、リファクタリングはカップル-モデル+テストに役立ちます。



このモデルにより、開発者は「上から」制限され、「アーキテクチャ内」（これらのメタモデル）にとどまるか、有能に変更できます。また、テストにより開発者は下から制限され、TORのフレームワーク内にとどまり、すでに見つかったエラーを退行させることができます。つまりたとえば、モデルは「家庭教師」であり、テストは「検証者」です。私はこのフレーズを正確に言った同僚がいますが、彼らはそれを懐疑的に受け止めました。 「曲がりくねったプログラマーがViewでビジネスロジックを作成したり、Viewエレメントを作成するビジネスロジックを作成したりすることを誰も禁止することはありません」などと言います。そして彼らは正しい。そして、通常、「直接利きの」プログラマーは通常懐疑的です。



リファクタリングが必要なのはなぜですか？世界中のIT業界全体が、開発スケジュールを計画するために「正気」を身につけていないことは周知の事実です。もしそうなら、タイミングが不足し始めます。初期段階で有能な分析が行われたとしても、人生はより困難です。そして、「XPのスタイルで」決定が下され始めます。私の意見では、これは一般的に正しいです。 「明日考えます」と、あるヒロインが言った。そして、当分の間、これらの決定は「生命に対する権利を持っています」。



既存のシステムの要件が「爆発的に」または「雪崩のように」変わることがよくあります。そして、「柔軟」ではあるが「ゴム」ではないアーキテクチャのフレームワーク内で「混雑」します。ここでも-リファクタリングを行う必要があります。アーキテクチャがバラバラにならないように。



ヴセヴォロド : «», UML, DSL, ?



：これが実際の例です。メタモデルにインターフェイスファクトリを定義しました。これは、テンプレートを使用して、いくつかの異なるパターンを実装するコード内の他のインターフェイスとクラスのセットになる特殊なステレオタイプを持つインターフェイス上のメソッドです。これにより、インターフェイスとキャッシュへの実装の実行時バインディングを非常に柔軟に管理できますそれら、強制退去など繰り返しますが、これはすべてモデルに描かれた1つの方法です。ある時点で、それが数年間使用されていて、そのような工場が1つか2つもなかったとき、私たちはコードがパフォーマンスに影響する非最適性を持っていることに突然気付きました。しかし、それを排除するには、これらの生成されたクラスの構造を変更する必要があります。プロジェクト全体を検索して「a」を「b」に置き換えるだけではなく、構造を変更してください。私たちのケースでは、数時間かかりました生成テンプレートを書き換え、すべてのプロジェクトを再レンダリングします。そして、これらすべてが手書きで書かれていた場合、これらのいくつかのパターンの実装は100か所で「押し込まれ」、どこでもわずかに異なり、2時間または2か月でこれをすべて変更してデバッグすることは不可能です。 。



Alexander：さらに、コードではなくダイアグラムを「リファクタリング」する方が簡単です。フォルダー間でコードやファイルを分割するよりも、場所から場所へモデルに正方形を転送する方が簡単です。同時に、「手」で「建築レイヤーを保存」する必要があります。そして、モデルは「私にとって考えている」。彼女は家庭教師です。彼女は私に「故意に間違った決定」をさせません。または、この決定は少なくとも通知されます。



Vsevolod：リファクタリングの品質を測定することは可能ですか？リファクタリングする必要はありませんか？



アレキサンダー：これは基準ではないのではないかと思います。もちろん、そのような必要性の欠如を達成することが可能であった場合、おそらくリファクタリングが理想的です。別のことは、完璧なコード/アーキテクチャを見たことがないということです。何かが「上から」理想的である場合、「下から」理想的ではありません。またはその逆に、「下」は理想的なコードであり、「上」は不完全なアーキテクチャソリューションです。



Vsevolod：リファクタリングについてよく話しますが、多くの人はこれを否定的に受け止めています。たとえば、「すべては機能しましたが、その後リファクタリングを行いました。」 UMLモデリングを使用しているときに、コードが最初に光線になり、リファクタリングの頻度が少なくなったと言うことはできますか？



マキシム：すべてが機能し、外部の変更が発生しない場合、リファクタリングを行う必要はありません。リファクタリングはそれ自体が目的ではなく、コードを「オリビエサラダ」に変えるのではなく、より迅速かつ正確に目標を達成する方法です。コード生成でUMLを使用すると、最も単純なバージョンであっても、すぐにコードが自動的に構造化されます。それで、もちろん、はい。



Vsevolod：痛い質問は、UMLダイアグラムとプログラムコードの同期です。 100％のコンプライアンスが達成されていますか？



アレクサンダー：達成。モデルからコードへの100％のコード生成があるという事実のため。彼女がいなくなった間、私自身はモデリングの大敵でした。私は、チャートを描くことを「猿の労働」と考えました。



マキシム：はい、逆方向がないため、同期は常に一方向です。そして、あなたもそれを通り過ぎません。



Vsevolod：つまりコード生成は、開発プロセスでUMLを効果的に実装するための必須条件ですか？



アレクサンダー：もちろん。さらに、コードが生成されない場合、さらには一定である場合、ある時点でダイアグラムは「単なる写真」になります。彼女は「腐っている」。彼女は「何もない」。



そしてもちろん、私たちが言ったように、コード生成はコードを「エンコード」することを可能にします、私はトートロジーをおizeびします-もっと速く。私を信じて、上記の例はすでに引用されており、私はさらに100万を持っています。



マキシム：より明確に言うと、コード生成はUMLを使用する重要なポイントです。少なくとも私たちにとっては。なるほど、これから議論のトピックに反する奇妙なことを言うことにしましょう。古典的な意味でUMLを使用することはまったくありません。



Vsevolod：まあ、「到着」、あなたが何を意味するのか説明してください？



マキシム：心配しないでください、私は確かに少し誇張しています。すでに上で示唆したように、私たちにとってのUMLは単なる「正方形」の形式であり、特定のグラフィック表記法であり、それ以上のものではありません。グラフィカルエディターのプリミティブのセットとして、それらからさらに大きなものを構築しました。上記で説明したパターンにより、これらのUMLプリミティブの観点からメタモデルを説明できます。アレクサンダーは既にそれらを「クラス」、「カテゴリー」、「コミュニケーション」などにリストしています。そして、その結果、新しい用語、新しいプリミティブ、すでにより高いレベルで、さらに必要に応じて再帰的に、特定のデザイナーまたはプログラマーが特定のモデルを作成し、そこからコードを取得するために使用します。つまり 実際、テンプレートは特定のDSLを形成し、その上に描画されたモデルをコードにコンパイルするものであり、UMLはそのモデルを描画する方法にすぎません。 つまり古典的なUMLに精通している人でも、私たちが描いた絵をすぐに「入力」することはできません。



Vsevolod：「時間の無駄」は、グラフィック表記でのコードの作成を正当化するのに、その品質の向上によって正当化されますか？



アレクサンダー：私の観点からは、彼らは言い訳をします。より高いレベルのステレオタイプの可能性のため。設計上の決定が繰り返されるのがわかるとすぐに。さらに、モデルは開発フレームワークに影響し、フレームワークはモデルに影響します。さて、前述のように、モデルの存在下でのリファクタリング（およびテスト）は、まったく異なる品質レベルになります。



マキシム：アレクサンダーは、高レベルのステレオタイプについて述べました。これは別の非常に重要なトピックであり、これは私たちが現在知っている最も強力なメカニズムです。これにより、原子を分子に、分子を合金に、部品に、アセンブリに、そして最終的に完成品に変えることができます。



Vsevolod：リファクタリングのコンテキストでテストについて言及しました。これは、一般に、テストなしではリファクタリングについて考える必要がないことを意味し、リファクタリングなしではモデリングは特に必要ないということですか？



アレキサンダー：私の意見では、もちろん、最初にテストし、次にUML、モデリング、コード生成の方が良いと思います。しかし、私たちにとって、これは歴史的に反対でした。しかし、今は確かに最初にテストを好むでしょう。私たちは「テストについて考えるだけ」ではありません。私たちは彼らが何であるかを知っています。彼らは「明日間違いを見せます」。そしてショー。しかし、もちろん-「テストについて考えます」。積極的なテストを作成します。 「回帰テスト」があります。要件をテストするテストがあります。また、品質に重大なダメージを与えることなくリファクタリングできます。



マキシム：私はアレキサンダーに同意しません、これらは補完的なものであり、どこから始めるかはそれほど重要ではないようです。むしろ、集団の内部文化と選好によって決定されるべきです。とにかくモデリングから始めて、最終的にはテストを生成できますし、手動で作成する必要はありません。



Vsevolod：アレクサンダー、私が理解しているように、最初はあなたはUMLの反対者でしたか？振り返って（おそらく笑顔で）、あなたはこのように思ったと言うことができます：「なぜUMLが必要なのか、 すでにコードをコントロールしているのか？」



Alexander：私は個人的に「問題がある」という認識を持っていました。しかし、コード生成とモデルとの一定の同期がなければ、UMLが個人的にどのように役立つか理解できませんでした。今-私は毎日それを理解して使用していますが、上で言ったように、確かに簡単なUMLではありません。



Vsevolod：「あなたのUML」はプログラムコードを文書化する別の方法になりましたか？



アレキサンダー：もちろん。さらに、すべてのモデルが共通のハイパーテキスト知識ベースに統合されています。また、バグ追跡と要件も含まれています。



マキシム：...そして、私たちのノウハウはもっとたくさんあります。ところで、統合も同じテンプレートに基づいて構築されます。データベースのhtmlは、ソースコードのようにモデルから生成され、自動的にサーバーに配置されます。



Vsevolod：UMLモデルはどのような形で統合されていますか？写真ではありません！



アレクサンダー：ハイパーリンクと説明資料を備えた写真の形式。しかし、この図から、UMLを操作するためのツールの実際の図にいつでもアクセスできます。



マキシム：およびその逆、および変更タスクとコミットは、リポジトリ内で自動的にアタッチされます。



Vsevolod：UMLダイアグラムは「非プログラマ」と対話するために使用されますか？



マキシム：実装の開始時に、相互作用にUMLを使用しようとしました。すべての要件は、ユースケース図とシーケンス図として設計されました。私たちに思われたように、最も専門的な形式ではない、最も理解しやすいものです。 F1システムの最初のバージョンである、同僚である弁護士やマーケティング担当者は、タスクを設定し、正直に図から読み込もうとしましたが、成功しました。しかし、...、練習が根付いていないとしましょう。



アレクサンダー：まだ、技術者ではなく（教育ではなく、職業による）、彼らはあらゆる種類の正式な言語が本当に好きではありません。 UMLよりもロシア文学の方が無意識のうちに簡単です。これはすでに心理学のカテゴリーからのものです。



Vsevolod：どのUMLダイアグラムが使用され、どの程度ですか？



Alexander：まず、クラス図とユースケース。



ヴセヴォロド：他の図はあまり役に立たないと思いますか？たとえば、プログラマの「頭脳」は「オブジェクト」図を省くのに十分ですか？



マキシム：いいえ。状態図を使用してそれらを記述し、状態マシンのコードを生成することもあります。しかし、これは非常にまれです。正式なレベルでの有限状態マシンの使用には、脳の特定の鮮鋭化も必要です。あちこちで、シーケンスが使用されますが、それは単に例として、つまり「デッドチャート」のように、それらからは何も生成されません。これは、アレクサンダーが前述したように、彼女の寿命が非常に短いことを意味します。



アレキサンダー：シーケンスは、適切なコード生成を実際に手に入れるまで、さらに便利な場合があります。 「オブジェクト」の図は、まさにSAXフィルターのチェーンです。クラスではなく、そのインスタンスを操作するとき。



Vsevolod：古典的なRADアプローチは、プログラマーをかなり狭いフレームワークに狭めます。データベース、インターフェース、フォーム、コンポーネント、イベント、応答手順。このフレームワークをUMLでどの程度拡張しましたか？



アレクサンダー：開発された「メタモデル」のフレームワークでUML「ピンチ」。しかし、これは部分的に求められていました。 RADと比較して、不純物とAOP元素がはるかに積極的に使用されています。プロジェクトのいくつかの部分への命令的なアプローチではなく宣言的なアプローチと同様に。つまり「データモデル」は最大限にモデル上に描画され、物理的に変換されるべきものから引きちぎられ、コードジェネレーターの助けを借りて「アクティブコード」に変換できます。たとえば、プロジェクトの「ドキュメントアウトライン」または「設定」のセット。 SAXフィルターのさまざまなチェーンなど



マキシム：あなたが決めた場所をつまむことが重要です。メタマデルは作者にルールを課すのではなく、モデルとそれを作成するモデルにのみルールを課します。 1つの場所でクランプし、別の場所でレゴコンストラクターに独自の柔軟性と速度を与えます。



Vsevolod：モデルの使用は、アプリケーションのアーキテクチャとプログラムコードの構造にどのように影響しましたか？



アレキサンダー：もちろん、これはモデルの問題だけではありません。ポイントは「脳の衛生」です。しかし、モデリングを適切に使用することで強化されます。そして、はい、モデルはアシスタントです。改善する意志がない場合、私は予約をします、そして、モデルは助けません。ただし、その他の慣行として。

そして、UMLアーキテクチャとモデリングはプラスの影響を受けます:-)論理層が表示されます。寄生的な循環依存関係が消えるなど。



Vsevolod：「ブリッツ」モードで作業します。 UMLとモデリングを適用する必要がないのはいつですか？



Alexander：研究やその他の研究用。 「2〜3か月」プロジェクトの場合、ほとんどの場合、サポートする必要はありません。



マキシム：UMLが描画のみに使用される場合、Alexanderに同意しますが、メタモデリングとコード生成に使用される場合は、特にそれを行うことに慣れている場合は、常に使用できると考えています。もちろん、「hello world」ではない場合。 「hello world」を生成する方がおそらく簡単ですが、少なくともIDEで新しいプロジェクトを作成する方法を覚える必要はありません。プロジェクトもここで生成されるためです。



Vsevolod：開発のどの時点で、どのような理由でUMLの使用方法が効果的であると言えますか？



Alexander：いくつかの機能を「手動で」またはあなたのやり方で書く時間を比較するだけで十分です。



マキシム：唯一のことは、特定の楽器にはまだ技術的な制限があるということです。時には、非常に悪影響を及ぼすことがあります。



Vsevolod：生産プロセスにモデリングを段階的に導入する方法は？



Alexander：いつでも始められます。主なことは、「巨大なものを受け入れる」ことをすぐに試みないことです。



Vsevolod：タスクのどの部分をUMLおよびコード生成と密接に統合できますか。また、「現状のまま」残すことができるものは何ですか？



マキシム：あまり構造化されていない独自のアルゴリズム、テンプレートを持たないもの、再利用、形式化および再現可能なシステムを残すことができます。



アレキサンダー：私自身は、モデルに翻訳されるすべてのものとはほど遠い。私は主に新しいクラス/エンティティを翻訳します。または変更のプロセスに影響を与えるもの。または「リファクタリングされた」もの。



Vsevolod：おそらく、他のアプローチが試されました。今日のソフトウェア開発の世界にUMLに代わるものはありますか？



マキシム：私たちにとって、私たちがそれを使用する形で、いいえ。しかし、上で言ったように、具体的な方法で正方形の矢印を描く方法はまったく重要ではありません。私たちが彼とする主なことは、どのように見えるかではありません。



アレキサンダー：実際、UMLには多くの代替手段があることを明確にします。これは、私たちにとってモデルを記述するための単なる方法であるためです。基本的に必要な概念を持つ他のグラフィック表記を使用して使用できます。あなた自身を記述することができます。一般的には可能であり、私は積極的に考えています。モデルのテキストによる説明に切り替えます。別のDSLを作成します。多くのオプションがあり、それらを組み合わせることができます。



Vsevolod：アプローチの可能性に制限はありますか？



マキシム：独自のメタモデルの作成を開始するとすぐに、制限がなくなり、特に一般的なものを見るための想像力と能力が不足する可能性があります。



Vsevolod：すべてが本当に素晴らしく、問題はありませんか？私は最高の演劇の伝統で「私は信じない」と叫びたいです！



アレクサンダー：もちろんあります。まず第一に、ツールの制限。大規模モデルでの生成速度が不十分です。最適でないUMLエディターインターフェイスなど



マキシム：問題はイデオロギーではなく、技術的です。私たちはずっと前に作られたツールから徐々に成長しており、長年にわたって関連性を維持していました。ジェネレーターは更新、修正が必要です。しかし、これはおそらく「問題」ではなく「タスク」です。

別のパッケージをUMLスクライバーとして使用します。はい、すでに「コンベヤ」の一部ですが、それを改善したり、更新したりしても害はありません。



Vsevolod：あなたの計画は？



Alexander：独自のツールを完全に作成します-モデルエディター。いわば、既存の「間違いに取り組む」ことです。



マキシム：同時に-クロスプラットフォーム。一般に、この方向には、モデリングプロセスをさらに効果的にする方法に関する多くのアイデアもあります。



Vsevolod：次の記事では、DSLについて説明しますか？



マキシム：はい、もちろんです。



アレクサンダー：喜んで！



Vsevolod：Embarcaderoの従業員として、彼の公式の地位を利用して、私は尋ねます... Delphiを使用していますか？



アレキサンダー：はい、開発にDelphiを使用しています。 RADとUMLの矛盾については知っていますが、それぞれの技術の長所を活用して、大きな相乗効果を達成しようとしています。フォームにボタンを配置するための純粋なRADツールとしてDelphiを使用していません。これは、かなり複雑な技術チェーンの構成要素の1つです。現在、Delphi XE4に移行中です。 64ビットが必要です。



マキシム：私はC ++で育ちましたが、非常に異質な環境で、参加したプロジェクトでは、Delphi、C ++、python、javaなどが同時に使用されていたため、「ホリバー」のサポーターにはなりませんでした「より良い」もの-各衣服にはファスナーが付いています。プロジェクトマネージャーとしての主なことは、ソリューション全体の有効性です。当社は非常に長い間、集中的にDelphiを使用してきました。主なことは、各ツールの長所と短所、その可能性を把握し、この決定に基づいて正しい決定を下し、技術サイクルを構築し、ツールを最大限に一致させるように専門家を選択することです。この意味で、Delphiは私たちにぴったりです。



PSアレクサンダーとマキシムはVsevolodアカウントで回答し、コメントの冒頭に名前を追加します。