タグ付けされた質問 「use-case」

Steve VinoskiによるREST、Reuse、Serendipityに関するこの講演を見た後、（XML-）RPC-ishセットアップのグリーンフィールドプロジェクトにRESTがより良い方法で解決できなかったビジネスケースがあるのではないかと思います。 彼が言及したいくつかのRPC問題： 言語に焦点を当てる（分散システムをその言語に適合させ、その逆ではない） 「ローカルに見えるようにする」（およびルールではなく例外として障害と遅延に対処する） 言語に依存しないことを意図しているが、依然として主要な成分として言語間で「関数呼び出し」を持っている IDLボイラープレート 型の安全性の錯覚 そして、さらにいくつか... 少しドラマ化するために、RPC vs RESTのGoogleインスタント結果をいくつか示します。

33 web-services  rest  use-case  rpc 

プロジェクトの入札段階では、多くの場合、潜在的な顧客からソフトウェアシステムの要件をさまざまなソース[メール、ワードドキュメント、Excel]から非常に非構造化された形式で受け取ります。通常、彼らが抱えるビジネス上の問題に対するこれらの「提案された解決策」を考え出すのは、顧客側からの「製品開発」担当者の集まりです。彼らはビジネス分野の専門家ですが、多くの場合、彼らは正しい解決策を持っていません。 これにより 同じ要件の複数のバージョン 2つの要件を1つに混ぜる 後の要件のいくつかのバージョンでは、一緒に結合された要件が再び分離され、それぞれが新しい追加の一部を取ります 開発を開始する前に、このような要件をどのように処理し、適切なユースケースに分類しますか？特定の要件の履歴を追跡するために、最初に考案されてから適切なユースケースに結晶化するまで、どのツールを使用できますか？このような方法で受け取った要件に対する作業の見積もりは、要件を正しく理解し、それに対する作業を正しく見積もるのを間違えてしまうという悪夢です。 私たちがプロジェクトに勝った後、顧客は自分の要件をさらに考え、適切にそれを明確にすることができました。この場合に発生することは、一部の機能が削除され、一部が機能強化され、一部がまったく新しい方向に進むことです。これは基本的に、プロジェクトに勝つ前に行われた作業項目の見積もりの​​一部を無効にする可能性があります。特定の要件のツリーを構築できるシステムがあるかどうか、および各ブランチがどのように異なる推定値をもたらすかを知りたいと思います。 このアクティビティをより管理しやすくするためのヒント、ツール、トリックはありますか？要件管理や労力の見積もりよりも経験豊富な人から洞察を得ようとしています。

21 requirements  development-methodologies  use-case  requirements-management  engineering 

私はクリーンアーキテクチャに入り、AndroidレベルをMVCからMVPに上げ、Dagger 2でのDI、RxJava 2での反応性、そしてもちろんJava 8を紹介します。 でMVPクリーンなアーキテクチャが存在し、エンティティ間の層（データストア内）とプレゼンターそれらにアクセスする必要があります。このレイヤーが「ユースケース」です。使用例は、理想的には1つのエンティティに1つの操作を実装するインターフェースです。 また、Clear Architectureは「悲鳴を上げている」ことも知っています。そのプロジェクトの意味では、クラスの数が多いため、非常に読みやすくなっています。 今、私のプロジェクトでは、6つの異なるエンティティのようなものがあり、もちろん、各エンティティリポジトリには、それらにアクセスするための少なくとも4つのメソッド（通常はget、add、delete、update）があります。つまり、6 * 4 = 24です。 Clean Architectureのこれまでに理解できたとしたら、24のUseCaseがあります。 MVCの6つのコントローラーと比較すると、これは多くのクラスです。 本当に24のユースケースを作らなければならないのですか？ 私はすでにそれを成功裏に使っている誰かによる説明を本当に感謝します。 ありがとう、ジャック

14 java  android  use-case  mvp 

シナリオはユースケースよりも詳細な全体像ですか、それともどのくらいの違いがありますか？私はシナリオという言葉を好むところにレポートを書きますが、私のトレーニングではユースケースという言葉を使用しました（OOPに関するコースで）。 OOPではないSMVでプログラミングしています。IIUC SMVは、ハードウェアのモデルチェックに特化したドメイン固有の言語です。実際のコードは私のgithubにあります。

8 use-case  test-scenarios 

ユースケース（図ではなく説明について話している）と、要件を収集してより適切に整理するために使用されるユーザーストーリーの両方について聞いたことがあります。 私は一人で仕事をしているので、要件を整理し、開発で何をすべきかを理解するための最良の方法を見つけようとしています。巨大なドキュメントなどを扱う正式な方法論はありませんし、必要もありません。 私が製品バックログを作成するために使用されているように見えるユーザーストーリーには、開発で実行する必要があるすべてのものが含まれています。 一方、ユースケースは、システムでの処理方法、外部のアクターとシステム間の相互作用のフローの説明を提供します。 1つのユースケースに複数のユーザーストーリーがあるように思えます。 これは私に次の質問を導きます：要件を見つけるとき、最初に何をすべきですか？ユーザーストーリーを見つけて書いたり、ユースケースを見つけて書いたりしますか？それとも、何とかして「同時に」行う必要がありますか？ 私は実際にはかなり混乱しています。ユースケースとユーザーストーリーに関して、単独で作業する開発者にとって、より良い開発を行うためにこれらの方法論を正しく使用するには、良いワークフローとは何ですか？

8 agile  requirements  user-story  use-case 

ログを国際化するための有効なユースケースは何ですか？特に、Webアプリケーションにとって意味のある用途はありますか。 私はからWebアプリケーションが使用するロギングAPIの変換に取り組んでいるlog4jのをslf4j、インターフェイスが上抽象的に使用されていることに気づいたlog4jの実装をサポートする国際化。また、との両方が国際化log4jをslf4jサポートしていることにも気付きました。 現在、国際化は、エンドユーザーがログを表示できるデスクトップアプリケーションをプログラミングするときに役立ちますが、このロギングファサードは、一般的に英語を使用する必要がある開発者が、いくつかのWebアプリケーションのサーバー側でのみ使用します。 。

8 design  web-applications  logging  internationalization  use-case