フォーマルUMLはどのくらいの頻度で使用しますか？

アドホックMUML（メイクアップモデリング言語）を使用して、システムをかなり頻繁に設計および説明しました。それはUMLに似ており、かなりよく理解される傾向があります。

しかし、可能な限り仕様に近い、厳密で正式なUMLの使用を重視する教授が1人か2人いました。私は常に、厳密なUMLは彼らが主張したほど一般的ではないと疑っていました。それでは、どのように「どのように」、適切な行末、多重度、メンバータイプシンボルなどをすべて使用する完全な図を実際にどれくらいの頻度で描画しますか？

決して。

私が最後に作成以来ヘック、それは年をされている任意の UMLを。ホワイトボードの線図や紙くずはカウントされません。

実際、インタビューの中で使用するガイドからUMLの唯一の質問を削除しました。答えを本当に気にかけている人はいなかったからです。

自分や他の誰かがシステムやサブシステムを実装できるようにするために、十分な数のUMLを使用して（ダイアグラムのタイプとダイアグラムの情報の内容の両方の観点から）理解を深めます。UMLを使用する唯一の理由は、それぞれが非常に具体的なものを意味する広く知られているシンボルのセットであるため、あいまいさがないことです。システム。

皮肉なことに、UMLは柔軟であることになっています。

現実の世界では、1つの正しい方法でそれを行うための訓練的な運動であるとは想定されていません。それは、システム/プロセス/アイデアを効果的に伝達し、文書化することです。

あなたの質問に答えるために、私は他の人と一緒にいます。完全な正式なUMLを完全に活用したことはありません。

Rational Roseからすべての（ほとんどの）コードスケルトンを生成した製品で、約4年間UMLを非常に頻繁に使用しました。

過去5年間、その場で発明された「箱と矢」の多くがあり、通常は一般的なアイデアを広めるのに十分です。この間にUMLを正式に数回修正するだけです。

しかし、可能な限り仕様に近い、厳密で正式なUMLの使用を重視する教授が1人か2人いました。

教授が実際のシステムでそのアプローチを最後に使用したのはいつかを尋ねてください。真剣に。

UMLに関しては可能な限り形式的になるようにしますが、それが理にかなっている場合に限ります。カウボーイから厳格なフォーマリストまで、スペクトルの両側の熱狂者はそれを理解していません。

あまり厳格ではないアプローチ（個人的に使用するアプローチなど）が最善のアプローチであるコンテキストがあります。良い例は、要件が小さく完全に定義されていない小規模なシステムまたは変更の場合です。担当グループは効率的かつ効果的です。それを完璧にするよりも、それを取り出すことが重要です。それは繰り返し行われ、いくつかの欠陥は許容されます。

または、完全な正式なモデリングフェーズとは対照的に、ゲスト化とスケッチを行っている段階にいる可能性があります。それらは思い浮かぶであろう例です。

また、厳密な形式のUMLアプローチが必要な場合もあります。たとえば、契約上拘束される場合があります。複数のチームに非常に多数の開発者がいる（おそらく分散している）。プロジェクトの範囲は数年になる場合があります。非常に大規模なシステム（ソフトウェアおよびハードウェアコンポーネントを含む）。失敗のコストが高いなど。

他の回で、あなたは、UMLに加えて/代わりに何か他のものを使用する必要があります（ペトリネットのような実際の数学的形式モデル、CSPまたは一時的なロジック。）この例は、リアルタイム・システムは、障害が壊滅的なシステム（医療機器）または契約上拘束されている場所（例：輸送システムを開発するヨーロッパの場合）

それはすべて、状況と各アプローチから得られるものに依存します。フォーマルに固執することを思わせる教授は、盲目の熱狂者です。エンジニアリングの世界は、黒と白の正しい/間違った二分法ではありません。これは、インテリジェントなトレードオフの世界です。

あなたが仕事を成し遂げるのに効果的で適切な方法で、カジュアルで非公式なモデルを使用するのに十分な知性を持っているなら、そうしてください。同様に、あなたは時に認識することが予想されますしない非公式のアプローチおよび/または時に使用する、NOT正式いずれかを使用しています。

そうは言っても、あなたは教授と耳でそれを演奏しなければなりません。彼らにあなたに等級を与えるように骨を与えてください、そしてそれが最終的に彼らの熱狂的なマントラに屈することを意味するなら、それは結構です。あなたは何があなたのために働くかを知っています、そして、願わくば、あなたは現実世界で何をどのように使うべきかを知っているでしょう。

私は博士号の研究の一環として、経験豊富なデザイナーがUMLをデザインコラボレーションで使用する方法を研究しました（ただし、人工的な設定では）。

私の調査結果では、UMLのメタファーと表記は借用されていますが、ツールの厳格さにはほとんど従いません。

後に、コード生成のために要求の厳しいCASEツールが関係する場合、多くの場合、一部のモデルはより厳密なUMLに繰り返し変換される場合があります。

もちろん、学術研究の通常の警告が適用されます:)

論文の要約と論文自体へのリンク（ACMアクセスがない場合）。

それ以外にも、Amblerの「アジャイルモデリング」を強くお勧めします。

休止状態のORMのコード生成には、正式なUMLを使用します。他のほとんどのものは非公式またはホワイトボードです。フォーマル性の欠如はそれを壊すので、コード生成において私たちにとってのみ重要です。

頻繁に技術的なレビューが必要な顧客（PDR、CDRなど）で働いている場合、彼らはアドホック表記法よりも何らかの標準化を好みます。特に政府の仕事。誤解や、あなたが発明した記法の最初の15分間の説明を防ぎます。

また、UMLを使用しているからといって、標準に従ってすべてのiにドットを付け、tごとに交差させる必要があるわけではありません。何らかの自動コード生成/実行を行いたい場合のみです。複数のプロジェクトでこれを行った人は誰も知りません。

一方、あなたがあなた自身の開発者のチームであなたの会社のためだけに働いているなら、あなたはあなたがどんな表記法を使うか気にします。ただし、適切なツールを選択すると、リアルタイムの節約になります。

とはいえ、一部の業界では、UMLを使用して設計することができないため、うまくいくのは難しいでしょう。他の業界では、あなたはそれを見ることは決してないでしょう。

また、修正のコストはUMLのヘビーユーザーであるため、それに応じて高いため、設計が正しいことを必要とするこれらの業界の間には相関関係があると思います。業界とは対照的に、UMLはおそらく決して使用されない場所であるため、設計修正のコストはドキュメント/コードの変更にすぎません。

元の質問に関して。ほとんどの大学は、学生を最も頻繁に採用する企業のために学生のトレーニングを調整する傾向があります。UMLが重要であると教授が考えている場合、学校から採用する企業の多くがUMLを使用していることは驚くことではありません。したがって、それを使用することを学ぶ必要があります。

UMLについて読んだとき、C ++コースで解決しようとしていたすべての問題でこれを試しました。幸いなことに、私が最初に試みた例の1つは、リンクリストを記述することでした。
うまくいきませんでした。
とはいえ、優れたモデリングプロセスとUMLを組み合わせると便利です。それは、良いか悪いかの基準だからです。
テンプレートメタプログラミングの記述言語が見たいです。<<< >>> -landで何が起こっているのかを理解するのに大いに役立つと思う

モデル駆動型開発も試してみると、UMLは苦痛です。つまり、UMLは非常に便利なグラフィカルな表記法であり、他のすべては役に立たないということです。モデリングに費やすのではなく、プロジェクトの構造を作成するために毎日UMLを使用しています。私がやることは、要件レベルで基本的なユースケース図をすばやく描画し、すぐにクラス図に切り替えることです。ユースケース図とクラス図の間に要件のトレーサビリティを追加します。クラス図もライブ同期されているため、コードを作成します。すべてのモデルのコードにタグはありませんが、JavaプロジェクトにマップされているUMLモデルに保存されます。

クラス図をほとんど持たないアプリケーションのスケルトンを作成してから、コードに切り替えます。コードを完成したら、モデルにマージします。コードがモデルを実行するのは、コードとモデルの間の一種の反復です。そのため、クラスダイアグラムは抽象化とコードをより高いレベルで提供し、コードはビジネスロジックの実装（メソッドなど）を提供します。

UMLモデリングには1日あたり10分未満しか必要ありません。これは、何をどのように開発する必要があるかを考える時間が必要なときに行われます。

UMLは素晴らしく、素晴らしく、本当に便利ですが、モデル駆動型の開発は役に立ちません!!

実装したシステムを文書化する場合は、完全な正式なUMLを使用してシステムを作成しようとします。しかし、残りの時間は、アイデアを伝えるために必要なだけ使用します。また、最近設計しているシステムに適していると思われるUMLよりも多くのDFDを使用していることに気付きました。

過度に時間のかかるビジュアルモデリングアクティビティ、フォーラムの雑用、コンピューターの周りで育った人や思慮深く振る舞った人が過度に冗長なソフトスキルを堅持しているため、私はおそらく一流大学から（少なくとも一時的に）中退しました。ユーザーインターフェースへの移行は、借金を深く掘り下げることを考えると、欲求不満で物事を壊したいと思うようになるのに十分です。

私はエントリーレベルとジュニアレベルの仕事が要求していることを学ぶか、CESが大学のABET認定のために設定するフープを学ぶかを選択しなければなりませんでした。 PERT評価により明らかになります。大学は教えていることを実践していません。

私の意見では、統一プロセスには多くのメリットがありますが、視覚的なアーティファクトを作成する全体的なプラクティスは、モデリング言語が少しばかげていることです。Word、Workflowy、Evernote、OpenOffice、またはワードプロセッサの名前で作成されるようなセリエテッドリストを含む繰り返し洗練されたドキュメントは、統合プロセスに必要なものを完全にドキュメント化できます。このプレーンジェーンは、バージョン管理された複数のユーザーが簡単に操作できるものであり、適切なツールを選択して作業を行うと、チームは同時に作業することさえできます。これは、UMLが大群を統合するのに必要なモードのように思えたときよりもはるかに簡単に実行できます。