問題タブ [rational-unified-process]

スクラムとの対話における RUP

アジャイルとRUPには関係があります。実はアジャイル開発はRUPの一種だと思っていました。上記の IBM の記事では、モデルを RUP に適合させていることがわかります。

誰かがこれら 3 つの興味深い概念間の関係について実用的な説明を持っていますか?

統一モデリング言語 (UML) と、他の OOA/D 方法論の中で (R)UP によって承認されているさまざまなモデリングの観点 (概念、仕様、および実装) との関係について、少し確信が持てません。

私が理解していることから、同じ表記法を使用した同じタイプの図は、使用されている視点*に応じて異なる意味を持つ可能性があります。たとえば、クラス図は、概念的な観点から実世界のシステム/現象の抽象化を表すことができ、後で観点が仕様/実装に変更されると、クラス図はコンピュータープログラムの構造を抽象化するために使用されます。

質問:

1) 一般に、UML クラス図には特定のルールが存在することを理解しています。たとえば、クラスは別のクラスを拡張できますが、関連付けを拡張することはできません。クラス図の実体と、それらがどのように関連付けられるかについての規則はどこで定義されていますか? すべては UML メタモデリング アーキテクチャの M2 層で行われますか (ウィキペディアのメタモデル アーキテクチャの図を参照) 。

2) 関連する質問。私の見方では、特定のダイアグラムの一般的なルールはモデリングの観点にまたがっていますが (クラスが関連付けを拡張するのはばかげています)、さまざまなモデリングの観点が特定のタイプのダイアグラムに特定の意味を重ね合わせます。たとえば、ドメイン モデルのクラス図 (概念の観点) での関連付けは本質的に双方向ですが、設計モデルのクラス図 (仕様/実装の観点) では双方向または単方向のいずれかになります。

先ほど説明したシナリオでは、スーパーインポーズされたルールが関連付けのプロパティを制限しています。パースペクティブによって重ね合わされたルールは、常に UML メタモデルによって定義されたルールのサブセット/制限であり、決してスーパーセットではないというのは正しい仮定ですか?

これらのルール/制限は、(メタモデルと同様の方法で) 形式化されたパースペクティブによって定義されていますか? それとも、OOA/D 文献で説明されている単なる規則ですか?

*パースペクティブは、 10.8項で説明されています。

ユースケース図におけるincludeとの違いは何ですか?extend

RUPを学びたい...

あなたの提案は何ですか？始める方法は？どのリソース？.....

私は新しいプロジェクトを懇願しています（ああ、私は新しいプロジェクトの新鮮な味が大好きです！）そして私たちはちょうどそれを設計し始めています。つまり、このアプリケーションは、ユーザーが実行フローをモデル化できるようにするUIです（Visioのようなドラッグアンドドロップインターフェイス）。したがって、私たちの最大の関心事は、ユーザーが実行フローを迅速かつ明確にモデル化するのに役立つ使いやすさと機能です。

私たちの確立された方法論は、プログラマーとユーザーの間でアプリケーションの調和のとれたビューを作成するために、ユースケースを広範に利用します。これは実際にはビジネス上の懸念事項です。ユーザーケースではなくユーザーストーリーでアジャイル手法を使用したいのですが、クライアントに製品を販売するための明確な範囲を定義する必要があります。

ただし、ユースケースにはいくつかの欠陥があり、そのほとんどは、ここに表示されているように、UIなどの技術的な詳細が含まれているという事実に関連しています。ただし、ユーザーストーリーと完全にインタラクティブなデザインを使用できないため、妥協することにしました。これらの詳細を非表示にするために、エッセンシャルユースケースを使用します。

今、私は別の問題を抱えています：UIの相互作用の明確な説明を持っていることが不可欠です（しゃれは意図されていません）、それで、それをどのように文書化する必要がありますか？言い換えると、UIの相互作用が不可欠な必須のユースケースを使用してアプリケーションを指定するにはどうすればよいですか？

私はいくつかの選択肢を見ることができます：

• 問題を正しく表していないため、ユースケースの使用を中止します
• ユースケースにインターフェースの説明を含めないでください。ただし、別のドキュメント（ストーリーボード）を作成してから、基本的なユースケースにリンクしてください。
• ユーザーとアプリケーション自体の観点から見たビジネスルールの一部であるため、UIインタラクションの説明をエッセンシャルユースケースに含めます

私はおそらくここで必死に素朴ですが、何かを片付けたかったのです。RUPは、IBMが所有する独自のプロセスのようです。それを実装したいプロジェクトにはどのような影響がありますか？

論理的には、「プロセス」を独自仕様にする方法を見つけるのに苦労しています。つまり、一連のタスクを所定の順序で実行しているだけです。これに加えて、AUPやOpenUPのように、非常によく似た方法で機能するがオープンソースである同様の方法論があるようです。

私が得ることができる唯一の結論は、プロプライエタリの側面は、これらの実装を支援するために利用できるようになったツールと図を参照しているということです。

私が言ったように、私はおそらく必死に素朴ですが、私は混乱を解消したかったです。

RUP 方法論の十分な影響の範囲を知りたい。MIS や HIS などの IS システムでは非常に効率的であることはわかっていますが、制御監視システムなどのシステムを設計および開発する場合、IS システムと同じくらい優れたもので十分でしょうか。つまり、RUP が焦点を当てている、そのようなシステムのほとんどの課題が、合理的、リレーショナル、および情報ではなく技術的なものである場合でも、それでも効率的であるということです。そうでない場合は、その代わりにどのような方法論を提案しますか?

なぜ他のものよりもUPプロセスを採用するのですか？相対的な利点は何ですか？私はそれがUMLと密接に関連していることを知っていますが、明らかにこれが唯一の利点ではありませんか？なぜ他のアプローチよりもこのアプローチを選ぶのですか？

このような質問で検索しましたが、存在しないと思います。

タイトルにあるように... (R)UP と XP でシステムを開発する方法には大きな違いがあることは知っていますが、実際にはどうなのでしょうか? 他の人が違いを簡単に理解できるように、他の人に提供できる素敵な説明を書こうとしています.

次の項目を比較したいと思います。

• デザイン
• ドキュメンテーション
• プロトタイピング
• ユーザーの関与
• 使いやすさ
• 技術的品質
• テスト

議論を始めようとしているわけではありません。私が探している情報が掲載されているサイトをご存知かどうか、またはテーマの 1 つに対する回答があるかどうかを知りたいだけです。私はすでにそれのいくつかを自分で書いていますが、それを主観的な比較にしたくないという事実のために、私はあなたに尋ねます.