問題タブ [use-case]

クラスを使用せず、単に関数とmain(). どんな図が描けるのか知りたいです。ここに私が心に留めていることがいくつかあります。

1. 活動図
2. シーケンス図
3. クラス図 - クラスを使用していないため、明らかにこれを描画できません
4. システムアーキテクチャー
5. 状態図
6. ユースケース図

これらのうち、何を描くことができますか？

プロジェクトでZeroMQを使用することに興味がありますが、他の人の経験について聞きたいです。いくつか検索しましたが、mongrel2プロジェクトしか見つかりませんでした。それが使用されている他のプロジェクトについて聞いたことがありますか？どの企業が本番環境でZeroMQを使用していますか？

仮想学校システムのユースケース図を作成するとします。

私はこれに到達するまでうまくやっています:

「学生はシステムにサインインし、入学試験を行い、サインアウトして応答を待ちます。試験の最後に、システムはノートを計算し、最終ノートに従って ITが学生に通知するレベルを設定します」結果、料金の支払い日、およびクラス プログラム. THE SYSTEMは、他の料金とその支払い方法を計算するために、学生の情報を学校の会計システムにも送信します. 料金の支払い後、THE SYSTEMはユーザーを変更する必要があります. （学生）種別は「在学中の学生」から「学生」まで。

今、そのシステムと言っているとき、アクターと接続 (関連付け) されていないスタンドアロンのユースケースを作成するにはどうすればよいですか?! それをしてもいいですか ？

誰でも例にリンクを投稿できますか?私はたくさん見つけましたが、完璧な例を見つけることができる場所を知っている場合は提供してください.

事前に感謝

ピクルスのドキュメントを見ましたが、ピクルスがどこで役立つのかわかりません。

ピクルスの一般的な使用例は何ですか？

Web サービスの仕様について考えていたときに、この質問が頭に浮かびました。

次の使用例:

• ユーザーは他のユーザーの投稿に投票して、他のユーザーの評判を変更することができます

2 つのユース ケースに分割されますか?

• ユーザーは他のユーザーの投稿に投票できます
• ユーザーが投票されると、それに応じて評判が変わります

どちらがより良い処方ですか？

C＃4.0がリリースされる前は、共変性と反変性に非常に興奮していました。それは理論的な正しさのために私の愛情に甘んじました！

しかし、それが終わって、私は通常の、毎日の、退屈なコードを書くことに戻ったので、私は疑問に思い始めています：私はまだそれを使用したことがありますか？そして、私はそれを意識的に使用していないことに気づきました。それ以来、私が定義したインターフェースやデリゲートはどれもその恩恵を受けていません。

後で無意識のうちに共分散を使用していることに気付いたのは1つのケースだけですが、それは非常に微妙であり、気付かなかった可能性もあります。想像してみてくださいX。これは基本クラスでYあり、その子孫です。

共分散または反変性を実際の非考案のユースケースで使用し、見事に「正しい」ことで1日を本当に節約した、興味深いまたはエキサイティングな例はありますか？

まず、この質問が以前に尋ねられた場合は申し訳ありませんが、これに直接答えるものは見つかりませんでした。

これが私の問題です。私は非常に柔軟に設計された製品を継承しており、(silverlight) フォームのほぼすべてのコンボボックスとテキストブロックにデータを入力するにはサービス リクエストが必要です。一部の画面では、入力するだけで 15 回以上の個別のリクエストが必要になります。

現在、私は WCF Web サービスを何度も使用してきましたが、サービス コントラクトを小さな個別の操作に分割することは、あまりヒットしたことはありません..悲しいことに、これはこのプロジェクトには当てはまりません。それで、それは私に疑問を残しました...

私たち自身の壁の外にサービスを公開する計画はありません。この特定のサービス用に別のクライアントを作成する予定はありません。では、サービス エンドで「ユース ケース コントローラ」を作成することはできませんか? したがって、「苦情の作成」画面では、次のようなリクエストのリストを表示する代わりに...

1. GetComplaintTypes
2. GetCustomerTypes
3. GetAreaDetails
4. 等々...

フォームに入力するには、'GetCreateComplaintData' という単一の操作コントラクトが必要です。クライアントが 1 つしかない場合に、これほど多くの操作がこのような粒度で公開されるのは、クレイジーに思えます。クライアントは、これらすべてのリクエストを集約して同期し、意味のあるものにする必要があります。そもそも意味のあるものを公開しないのはなぜですか？

さらに言えば、サービス API をサードパーティに公開するつもりがない場合、これは DB 内のテーブルの CRUD ops を公開するよりも優れた戦略ではないでしょうか?

すべてのヘルプと意見をお待ちしております。前もって感謝します。

過去数日間、Mongo DB に固有のドキュメントを読んだり、スクリーンキャストを見たりしてきましたが、このようなソリューションが典型的な pg または mysql 環境よりも優れているのはいつなのか途方に暮れています。

具体的には、私の質問は、どのような状況（ユースケースがあればいいでしょう）でnosqlルートに行きたいですか？

ありがとう！

いくつかのユースケース/シナリオを念頭に置いて、実際にはフレームワークであるアプリケーションを設計しました。他のいくつかのユースケースで設計を検証したいですか?

そこにあるユースケースが私たちの設計に適合するかどうかを検証するためのツール (おそらくプロセスツール) はありますか?

動的プロキシが通常のプロキシよりも役立つシナリオについてアドバイスが必要です。

私は、動的プロキシを効果的に使用する方法を学ぶことに多大な努力を払ってきました。この質問では、AspectJ のようなフレームワークが基本的に動的プロキシで達成しようとするすべてのことを実行できること、または動的プロキシのいくつかの欠点に対処するために CGLIB を使用できることは脇に置いておいてください。

ユースケース

• デコレータ - たとえば、メソッド呼び出しのロギングを実行したり、複雑な操作の戻り値をキャッシュしたりします
• 契約を維持する - つまり、パラメーターが許容範囲内にあり、戻り値の型が許容値に準拠していることを確認します。
• アダプター - これがどのように役立つかを説明する巧妙な記事をどこかで見ました。ただし、このデザインパターンに出くわすことはめったにありません。

他は？

動的プロキシの利点

• デコレーター: すべてのメソッド呼び出しをログに記録します。

デコレータ パターンは、すべてのプロキシ メソッドに副作用を与えることができるため、間違いなく便利です (ただし、この動作はアスペクトを使用する本の例です)。

• コントラクト: 通常のプロキシとは対照的に、完全なインターフェイスを実装する必要はありません。例えば、

一方、コントラクトには、完全なインターフェイスを実装する必要がなくなるという利点しかありません。繰り返しますが、プロキシされたメソッドをリファクタリングすると、動的プロキシが暗黙のうちに無効になります。

結論

ここで私が目にするのは、実際の使用例と疑わしい使用例の 1 つです。あなたの意見は何ですか？