タグ付けされた質問 「uml」

大学にいたとき、コード開発におけるUMLの利点とその将来について教育を受けました。 しかし、業界での経験から、ERダイアグラム、クラスダイアグラム、状態ダイアグラムからワークフローダイアグラムに至るまで、ダイアグラムを使用している間は、すべてコミュニケーション用であることがわかりました。 つまり、ダイアグラムからコードを自動的に生成したことは一度もありません。また、通信の観点から、通常はダイアグラムをできるだけシンプルで理解しやすいものにしようとしています。 しかし、VisioとEnterprise Architectを見ると、多くの異なる種類のグラフ、図形、プロパティオブジェクトがあり、そのほとんどは使用していません。 UMLを使用して、コードやデータベースの生成など、より洗練された処理を実行しますか？

39 uml  diagrams  visio 

UMLクラス図の表記法のいくつかについて混乱しています。 協会が何を意味するのか、私はよく知っています。2つのクラスのインスタンス間の関係（1つのクラスのインスタンスが作業を実行するために2番目のクラスのインスタンスを知る必要がある場合）は、関連関係です。関連とは、クラスAがクラスBのインスタンスへの参照（フィールド）を持っていることを意味することがよくあります。 しかし、集計と構成の矢印の意味を理解するのに苦労しています。私の混乱の一部は、これらの表記法の異なる定義に遭遇したことが原因でした。 集計表記法の2つの定義： 定義1： 2つのクラス間の集約表記は、クラスA のインスタンスがクラスBのインスタンスのコレクション（リスト、配列など）を保持する場合に適しています。 定義2：クラスAのインスタンスがクラスBのインスタンスへの参照を保持し、BインスタンスがAインスタンスのライフサイクルに依存している場合、2つのクラス間の集約リンクが適しています。意味：クラスAのインスタンスが削除されると、クラスBのインスタンスも削除されます。クラスBのインスタンスは、クラスAのインスタンスに完全に含まれます。クラスB（通常のAssociation）。 構成表記の意味と、それが集約表記とどのように異なるかについては、わかりません。 定義を明確にして、理解してください。具体的な例を歓迎します。

39 object-oriented  uml  class-diagram 

アドホックMUML（メイクアップモデリング言語）を使用して、システムをかなり頻繁に設計および説明しました。それはUMLに似ており、かなりよく理解される傾向があります。 しかし、可能な限り仕様に近い、厳密で正式なUMLの使用を重視する教授が1人か2人いました。私は常に、厳密なUMLは彼らが主張したほど一般的ではないと疑っていました。それでは、どのように「どのように」、適切な行末、多重度、メンバータイプシンボルなどをすべて使用する完全な図を実際にどれくらいの頻度で描画しますか？

33 uml  diagrams 

UMLがほとんどのフリーソフトウェアプロジェクトで使用されていない理由を理解しようとしています。たとえば、私のDebian / Linuxシステムにはおそらく1万を超えるフリーソフトウェアパッケージがあり、明示的な UMLフレームワークと方法論を使用して開発されたものであっても名前を付けることはできません。例えば、Qtの、GCC、Linuxのカーネル、bashの、GNUのメイク、OCamlで、Gnomeの、ユニゾン、lighttpdの、libonion、ドッキングウィンドウは、すべてのUMLを言及していない（私の知る限り）のフリーソフトウェアプロジェクトです。 （私の推測では、UMLは開発タスクの正式な下請けに非常に適していると思いますが、それはフリーソフトウェアの開発方法ではありません） UMLに関する資料を読みましたが、それについて十分に理解しているとは主張していません。 実際、UMLが使用されているフリーソフトウェアに簡単に名前を付けることはできません（おそらく、フリーソフトウェアとして実装された一部のUMLツールを除く）。おそらくopenstackは例外です（UMLに言及しているものがあります）。 （古いフリーソフトウェアプロジェクトでさえ、開始後にUMLを採用したかもしれませんが、採用していませんでした） Papyrusに取り組んでいる一部の同僚は、ほとんどのフリーソフトウェアプロジェクトは、明確な（そして十分に深い）形式化されたモデルを最初から持っていないと述べました。また、UMLはJavaが主張するよりもはるかに関連しているように見えます（Ocaml、Common Lisp、Haskell、Javascript、さらにはC ++ 11でも意味がないかどうかはわかりません）。おそらく、アジャイルなソフトウェア開発はあまりUMLフレンドリーではありません。 何らかの形で関連する質問に対するこの回答も参照してください。M.ファウラーのブログはデザインが死んでいますか？洞察力があります。 PS。主に意見の問題だとは思わない。いくつかの客観的な理由と、フリーソフトウェアの本質的な特性があるはずです。UMLは、正式な下請けにのみ有用であり、独自のプロジェクトのように、開発されたソフトウェアの一部が隠されている場合にのみ有用であると推測する傾向があります。もしそうなら、UMLはフリーソフトウェア開発と互換性がありません。 NB：私は自分でUMLファンではありません。私はUMLを紙の文書としてのみ定義するのではなく、ソフトウェアツールの [メタ]データ形式としても定義します

29 uml  free-software 

シングルスレッドアプリケーションの場合、クラス図を使用して、そのアプリケーションのアーキテクチャの概要を取得します。ただし、このタイプのダイアグラムは、たとえば、異なるスレッドでクラスの異なるインスタンスが「ライブ」であるため、重いマルチスレッド/同時実行アプリケーションを理解しようとするときにはあまり役に立ちません（つまり、インスタンスへのアクセスは、それが住んでいるスレッド）。したがって、クラス間の関連付けは、必ずしもそれらのオブジェクトのメソッドを呼び出すことができるという意味ではありませんが、代わりにターゲットオブジェクトのスレッドで呼び出しを行う必要があります。 Hassan GomaaによるUMLを使用した並行、分散、およびリアルタイムアプリケーションの設計などのトピックについて掘り下げたほとんどの文献には 、スレッド境界をオブジェクト図に描画するなどの素晴らしいアイデアがありましたが、本当に便利です。 これらの図を問題ドメインの高レベルのビューとして使用するのではなく、クラス/オブジェクト、それらの相互作用、および前述のスレッド境界による制限の詳細な説明として使用します。 したがって、私は知りたい： マルチスレッドアプリケーションの理解に最も役立つとわかったのは、どのような種類の図ですか？ マルチスレッドアプリケーションの特性を考慮したクラシックUMLの拡張機能はありますか。たとえば、 一部のオブジェクトは特定のスレッドに存在し、他のオブジェクトはスレッドアフィニティを持たない場合があります。 オブジェクトの一部のフィールドは、任意のスレッドから読み取ることができますが、1つのスレッドからのみ書き込むことができます。 いくつかのメソッドは同期して結果を返しますが、他のメソッドはリクエストをキューに入れて、たとえば異なるスレッドのコールバックを介して結果を返す非同期です。

25 architecture  uml  multithreading  concurrency 

UMLがオブジェクト指向へのより古典的なアプローチを指向していることを考えると、JavaScriptシステムを設計するための信頼できる方法でまだ使用可能ですか？ 私が見ることができる特定の問題の1つは、実際にはクラス図がシステムの構造図であり、JavaScriptがより多くの動作駆動型であるということです。どうすれば対処できますか？ ここでは、現実世界のドメインについては話していないことに注意してください。私が達成しようとしているソリューションのモデルです。

23 design  object-oriented  javascript  uml 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け入れていません。 私はプロジェクトの途中で、UMLダイアグラム（ユースケース、クラスダイアグラムなど）を書くように頼まれました。プロジェクトはそれほど複雑ではありません。 これは私の時間の無駄なのだろうか？コードを書くような他の楽しいことをやるだけですか？そして、すべての概念フェーズを経ずに何かを構築することは大丈夫ではないのはいつですか？複雑さがすべてですか？もしそうなら、それを測定する方法？

22 uml  modeling 

私が知っているすべてのIT担当者ではないにしても、ほとんどの場合、コーディングの前にUMLまたは他のタイプのダイアグラムでソフトウェアをモデル化することが有益であると考えています。（私の質問は、特にUMLに関するものではなく、ソフトウェア設計のグラフィックまたはテキストによる説明です。） 私はそれについてはよくわかりません。主な理由は次のとおりです。コードは嘘をつかない。コンパイラーまたはインタープリターによってチェックされます。自動化されたテストがあり、静的コード分析に合格する必要があります。モジュールが別のモジュールと正しくインターフェイスしていない場合、エラーメッセージが表示されるため、通常はコードで明らかです。 このすべてを図や他のドキュメントで行うことはできません。はい、UMLをチェックするツールはありますが、これまで見てきたことはすべて非常に限られています。したがって、これらのドキュメントは不完全、一貫性のない、または単純な偽である傾向があります。 ダイアグラム自体が一貫していても、コードが実際にそれらを実装していることを確認することはできません。はい、コードジェネレーターはありますが、すべてのコードを生成することはありません。 モデリングの強迫観念は、コードが不可解に不可解な混乱であり、建築家、デザイナー、または全体像をつかむ他の有給の人々が対処する必要がないという前提から生じることに執着するように感じることがあります。そうでなければ、あまりにも高価になってしまいます。したがって、設計上のすべての決定は、コードから移動する必要があります。コード自体は、それを書くことができる（そしておそらく読むことができる）専門家（コードモンキー）に任せるべきですが、他に何も処理する必要はありません。これはおそらくアセンブラが唯一のオプションであったときに意味をなしましたが、最新の言語では非常に高いレベルの抽象化でコーディングできます。したがって、モデリングの必要性は実際にはありません。 ソフトウェアシステムをモデル化するための引数がありません。 ところで、図はソフトウェア設計の特定の側面を文書化して伝達するのに最適な方法であると考えていますが、それはソフトウェア設計をそれらに基づいて行うべきではないということです。 明確化： この質問は不明確であるとして保留されています。したがって、いくつかの説明を追加しましょう。 私は、ソフトウェア設計に関する真実の主要な情報源としてソフトウェアをモデル化する（コードではない）ドキュメントを使用することが理にかなっているかどうかを尋ねています。コードの大部分がこれらのドキュメントから自動的に生成されることを念頭に置いていません。この場合、ドキュメント自体をモデルではなくソースコードと見なします。 この手順の欠点をいくつか挙げたので、（私の経験では）なぜ多くの人がこの手順をソフトウェア設計の好ましい方法と考えているのか疑問に思います。

20 design  architecture  uml  modeling 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 2年前に閉店。 私は学部レベルでソフトウェア工学を教えており、UML実践者に質問があります。 ほとんどのソフトウェアエンジニアリングの教科書は、UMLダイアグラムのカバーに真剣に取り組んでいます。しかし一方で、多くの卒業生から、UMLはもはやトレンチで使用されていないようだと聞きました。 どのUMLダイアグラムが現在でも専門的な実践で広く使用されていますが、その理由は何ですか？使用されなくなった図はありますか？その理由は？ NB：意見に基づく議論や議論を避けるために、事実と客観的な要素（可能であれば、検証可能）または個人的な経験に関する中立的な観察で答えを説明してください

19 development-process  uml 

この投稿を改善したいですか？引用や回答が正しい理由の説明など、この質問に対する詳細な回答を提供します。十分な詳細のない回答は、編集または削除できます。 プログラムのデザインと動作の落書きをもっと合理化して、他の開発者と共通の言語にしたいです。 私はUMLを見て、原則としてそれが私が探しているもののようですが、それはやり過ぎのようです。私がオンラインで見つけた情報も非常に肥大化しており、学術的だと思われます。 UMLを同僚に説明するのに十分な英語の平易な方法で理解するにはどうすればよいですか？地上レベルでUMLを理解するための標準的なリソースは何ですか？

18 design  uml 

私はCSの学生です。現在、客観的な分析と設計を教えている講義に参加しています。ほとんどの場合、ユースケースの記述、クライアント用のアプリケーションを作成するときに直面する問題の分析、拡張可能で開発者にとって明確であり、クライアントがいくつかについて議論するときに問題が発生しないようにプロジェクトを設計する方法特徴。「客観的」なので、OOPの観点（クラスなど）から学習しています。 現在、ヘルパーツールとしてUMLを使用しています。私はOOPを十分に理解していると思いますが、機能的なパラダイムも学び、いくつかの小規模なプロジェクトでうまく使用しました。 私たちの先生は、「機能的なパラダイムについてはどうですか？」質問では、彼は関数型言語でより大きなプロジェクトをプログラミングしておらず、関数型プログラムがどのツールを使用しているのかを知りません。 それで、彼らは何を使うのでしょうか？このための方法論はありますか？それとも、そのようなことの必要はありませんか？

18 design  functional-programming  uml  modeling 

ウィリアムクックはツイートで次のように書いています。 「UMLはMDDにとって最悪の事態です。幸いなことに、多くの人々がこれを認識しています...」 私はその主張の背後にある理由を知りたい（明らかに、彼の個人的な意見に言及していない）。 私は、世の中の多くの人々がUMLをそれほど好きではないことに気付きました。また、UMLが効果的な設計とモデリングの聖杯である学界にいることを言及する価値があります。

17 design  uml  mdd 

この質問は非常によく似ているこのいずれかが、答えは私のニーズと一致していません。特定のUMLツール（Papyrus）に焦点を当てていますが、私の質問はUMLについてより一般的です。 ネストされたアクションをアクティビティ図で表現したいと思いますが、それを行う一般的な方法はわかりません。考え方は、他のアクションと同じスコープのアクションがありますが、その実行はより複雑であるということです。他のレベルと同じレベルでこのアクションを表示できるようにしながら、その実行に関する詳細を表示したいと思います。 ある種の「バックホーム」アクティビティを示すアクティビティ図である以下の例では、ネストされたアクションがアクションに含まれていPet the catます。この図には別の潜在的なエラーがあることに注意してください。質問の最後の正誤表を参照してください。 構造化ノードを使用しましたが、それが正しい方法であるかどうかはわかりません。そのため、質問です。ステートチャートでは、同等のものは複合状態になりますが、複合アクションについては何も見つかりません。構造化されたノードについては、それに関するいくつかのドキュメントを読んだ後、それがどのように使用されるべきかをまだ本当に理解していないので、この図ではまったく間違っているかもしれません。 また、下の画像のように、トライデントシンボルで別のサブアクティビティを参照する可能性があることも知っていますが、同じ図にすべての情報が必要なので、ニーズに一致しません（印刷できるようになります情報の損失なし） では、そのようなネストされたアクションを表す標準的な方法は何ですか？標準では、一般的に見られ、可能であればほとんどのUML設計ツールで実行可能な有効なUMLを意味します。 無関係な正誤表：私の図では別のことが間違っています。同じアクション（Scratch behind the ears）に来る矢印は、アクションに入る前にマージノードに移動する必要があります。このJOTの引用を含む、以下のコメントを参照してください。

16 uml  modeling 

4 + 1アーキテクチャビューモデルがUMLにどのようにマッピングされるかについて、少し混乱しています。 ウィキペディアは次のマッピングを提供します。 論理ビュー：クラス図、コミュニケーション図、シーケンス図。 開発ビュー：コンポーネント図、パッケージ図 プロセスビュー：アクティビティ図 物理ビュー：展開図 シナリオ：ユースケース図 「オブジェクトライフサイクルコンセプトにおけるUMLシーケンス図の構造の役割」というペーパーは、次のマッピングを提供します。 論理ビュー（クラス図（CD）、オブジェクト図（OD）、シーケンス図（SD）、コラボレーション図（COD）、状態図図（SCD）、アクティビティ図（AD）） 開発ビュー（パッケージ図、コンポーネント図）、 プロセスビュー（ユースケース図、CD、OD、SD、COD、SCD、AD）、 物理ビュー（展開図）、および 上記の4つを組み合わせたユースケースビュー（ユースケース図、OD、SD、COD、SCD、AD）。 WebページUML 4 + 1 View Materialsは、次のマッピングを提示します。 最後に、ホワイトペーパー「UML 2で4 + 1ビューアーキテクチャを適用する」では、さらに別のマッピングを提供しています。 論理ビュークラス図、オブジェクト図、状態図、複合構造 プロセスビューシーケンス図、コミュニケーション図、アクティビティ図、タイミング図、相互作用概要図 開発ビューのコンポーネント図 物理ビュー展開図 ユースケースビュー、ユースケース図、アクティビティ図 さらに検索すると、他のマッピングも明らかになると確信しています。 通常、さまざまな人々が異なる視点を持っていますが、ここでなぜそうなのかわかりません。特に、各UML図は、特定の側面からシステムを説明しています。それで、例えば、なぜ「シーケンス図」はある著者によってシステムの「論理的見解」を記述すると見なされ、別の著者は「プロセス図」を記述すると見なされるのでしょうか？ 混乱を明確にするのを手伝ってもらえますか？

15 architecture  uml  model  view 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 プロジェクトで一人で作業する開発者の場合、UMLはどの程度役立ちますか？

15 uml  solo-development