問題タブ [use-case]

コルーチンの概念は非常に興味深いように思えますが、実際の生産的な環境で意味があるかどうかはわかりません。コルーチンの実装が他の方法よりもエレガント、シンプル、または効率的であるコルーチンのユースケースは何ですか?

自動車修理工場がどのように機能するかを図とドキュメントでシミュレートすることで、UML を学んでいます。私が抱えている問題の 1 つは、事後条件 (または GOTO) ステートメントに関するものです。

破線の << include >> 関係は前提条件のみですか? ユースケースのバブルは互いに接続してロジック パスをたどることができますか?

だから、これは私がこれまでに持っているものです.. 1) 「支払いの決済」バブルは間違った場所にありますか? 他のバブルに << インクルード >> するべきでしたか? 2) 車を修理するのは技術者なので、'request service' バブルを技術者にも関連付ける必要がありますか?

画像

数年前にユース ケースに関するハウツー本を読んだことを覚えています。(これはおそらく、ユーザー ストーリーが用語のこの部分に取って代わる前のことです。)

当面のタスクは、新しい顧客を追加するようなものでした。

「悪臭を放つユースケースは必要ありません。これを常に行っています。数時間以上かかることはありません。」

翌日、彼らはあなたの古典的な CRUD タイプのテーブル メンテナンス画面に戻ってきました。その結果、優れたユース ケースから開発された UI と比べて使い古されました。

誰もこれを認識していますか？それは当時大きな印象を与えましたが、今でも良い警告の物語です. また見つけたいです。

ユースケースは単なる複数のユーザーストーリーですか？

ユースケースよりもユーザーストーリーを使用することの利点は何ですか..およびその逆...どちらか一方を使用する場合...すべてのアジャイル手法はユーザーストーリーを使用しますか？

ユースケースを書く責任者は誰ですか?

ユース ケース図でアクターとユース ケースの関連付けを示すために「矢印」を使用することは絶対に必要ですか?

最近、ソフトウェア エンジニアリングの課題のために絵を描かなければなりませんでした。しかし、他の多くの大学からの多くの記事、論文、オンライン ブック、および講義ノートについてオンラインで少し調査した結果、ユース ケース図の大部分は、何らかの「フロー」または「ナビゲーション可能性」を示す可能性に関係なく、 "、矢印はありませんが、一部の例には矢印があります。

そこで私は、最終学年の友人に相談しました。友人は、アクターとユース ケースの間に矢印を入れるべきではないと私が言ったことを既に研究しており、要求工学の講師でさえ、学生に矢印を使用しないように教えていました。そこで、意識的に矢印を使用しないことに決め、代わりに実線を使用してユース ケースの関連付けを示しました。

これが私の図です-クリック

しかし、課題の点数をもらったとき、矢を使わないことでゼロ点が与えられたことに驚きました。それらを使用することが必須であったとしても、双方向の関連付けに実線を使用できるという豊富な証拠があります。それで、少なくともいくつかの点数を受け取るべきではありませんか？

明らかに、この点について議論するために来週会う予定の講師に説明を求めましたが、もし彼女が私に矢印を使うべきだったと言ったら、それに対してどのような反論をすることができますか? 専門的な情報源を適切に参照して、誰かが親切に私に良いアドバイスをくれるとありがたい.

読んでいただきありがとうございます。すぐに返信を読みたいと思います。

編集

君たちありがとう。あなたがくれた答えに本当に感謝しています。この全体的な混乱は、講師が提供した唯一の表記が、講義ノートの 1 つにある矢印付きのライブラリ ユース ケース図の非常に単純な例であったために始まりました。しかし、それが決定的な表記法であることはあまり明確にされていませんでした。必須ではないと思ったもう 1 つの理由は、データ フロー ダイアグラムを描画するための表記法を説明する際に、彼女が特定の表記法を使用することを十分に明確にしていたためです。さまざまな情報源がありましたが、ユースケース図で矢印を使用する必要があるという証拠はほとんど見つかりませんでした.

そうは言っても、矢印なしで進む前でさえ、チュートリアルセッション中にチューターの1人（講師ではない）に、矢印付きの線と実線の違いは何ですかと尋ねたのを覚えています。明らかに、私は自分の言葉しか持っていません。皆さんが言ったことからすると、学問的立場にある人が、自分を防御的な立場に置く可能性のあることを言うことを認めるとは思えません. 私の間違いは、講師に直接話しかけなかったことですが、後から考えると、明らかにそうしていたでしょう。

いずれにせよ、私は彼女にこのすべての情報について話し、この「正直な過ち」を考慮に入れるように彼女に依頼します。また、ユースケース図だけでなく、特に私の回答が彼女が提供したモデルの回答とほぼ同じである場合に、異常な量の点数を失った他のいくつかの質問でもあります. また、課題をリクエストした他の多くの学生がリマークされることも知っています。

うまくいけば、彼女は親切で、私の成績を向上させるために適切な判断を下すでしょう. 分かり次第またここに投稿します。

ご協力いただきありがとうございます。他の情報や提案があれば投稿してください。:)

編集2

申し訳ありませんが、別の質問があります。

以下は、ユースケース図を描くという課題で与えられたシナリオです。

CONTHETICKETは、コンサートや劇場のチケットを取り扱うチケット代理店です。コンサートや劇場の会場は、CONTHETICKET に今後のイベントに関する絶え間ない情報の流れを提供します。マネージャーはこの情報を使用して、販売スタッフが顧客の電話に対応する際に使用する備品リストを編集します。マネージャーは、CONTHETICKET が事前に多数のチケットを購入するいくつかのイベントを選択します。これにより、会場と交渉した割引の恩恵を受けることができます。

彼は個人的にチケットの注文と同意した支払いを会場に送信し、チケットを受け取るとチケット ファイルにファイルします。

顧客が営業チームに電話をかけると、チケット要求がチケット ファイルと照合されます。事前に購入したチケットがある場合は、顧客の名前と住所を記入した封筒に入れ、仮注文ファイルに保管します。そうでない場合は、販売チームがチケット リクエスト フォームに記入し、郵便局員が回収できるようにトレイに入れます。

支払セクションは仮注文ファイルを毎日チェックします。彼らは顧客に請求書を送り、支払いを待ちます。請求書のコピーはファイルに保管されます。支払いが受領されると、支払いセクションは支払いと適切な請求書を照合し、問題がなければ、請求書の別のコピーをチケットの発送指示とともに発送ファイルに入れます。

郵便局員は毎日、発送ファイルをチェックし、仮注文ファイルから適切なチケットを取り出して、適切な顧客に送ります。

私の図からわかるように、私は俳優として「コンサートと劇場の会場」を持っています。

The Elements of UML 2.0 Style、Scott W. Ambler から:

「アクターとは、システムとの 1 つまたは複数の相互作用において役割を果たす人、組織、または外部システムです (アクターは通常、UML ユース ケース図で棒人間として描かれます)。」

しかし、私のマークされた課題で、講師は俳優であってはならないとコメントしました。俳優であるべきだと思うかどうか、またその理由を教えてください。

その背後にある私の理論的根拠は、CT&V が提供するイベント情報であり、マネージャーはそれを使用してチケットを注文/ファイルし、これも CT&V が提供します。

どうもありがとうございました。

学校の課題では、ユースケース図を作成する必要があります。しかし、私たちが持っているドキュメントはあまり拡張されていません。ユースケースを構成するコンポーネントと、1 つの例を説明するだけです。
図書館システムについてのユースケースを作成する必要があります。11 のユースケースが見つかりましたが、それらすべてを気にすることはありません。

IIRC、ユースケースはシステムの典型的な使い方を説明していますよね? しかし、ユースケース図にはどのようなものが属し、それらはどのように接続されるのでしょうか?

現在、4 つのアクター (メンバー、従業員、マネージャー、会計士) が存在します。私たちが最も問題を抱えているのは、メンバーと従業員です。
システムを利用するのは従業員です。メンバーはまだ俳優としてここに所属していますか?

私たちが持っているいくつかのユースケース:

• メンバーがライブラリに参加します。
• メンバーが自分の記録を変更します。
• メンバーは本を借ります。
• メンバーはライブラリを分割します (購読を解除します)。
• メンバーは記事を予約します。
• メンバーは本を返します。
• メンバーは、手数料および罰金の（一部）を支払います。

それらは図のユースケースになります。しかし、従業員が会員番号を入力する、従業員が書籍番号を入力するなどのユースケースがもっとあるはずです（使用しますか？）。

誰かがこれに光を当てることができますか？

編集: 一連のアクションはどのように記述されていますか? ある種の繰り返しのルーチンへのメソッド呼び出しのように、uses アソシエーションを見ることができると聞いたことがありますか? これは正しいですか？また、extended はどのように使用されますか?

さて、真の偽の質問について：

a) システムのアクターは、人間または別のソフトウェア コンポーネントによってのみ表されます。

私が TRUE と答えると、先生はそれを間違っているとマークしました。それは、私がハードウェア コンポーネントを見逃したと彼が考えたからではなく (部分的に認めると思います)、彼の言葉によると:

「TIMEも俳優です。」

ユース ケース図では、TIME をアクターとしてどのように考えますか??

時間を役者とみなす参考文献があれば参照してください。私は何も見つけていません。正直なところ、意味がないと思います。時間はそれ自体では機能しません。システムまたはスケジュールに従って働く人です。

今のところ、経験に基づいて、最近はファンクションポイントを使用して労力見積もりを行っています。

私は現在UCPを調査しています。この記事を読んでくださいhttp://www.codeproject.com/KB/architecture/usecasep.aspx。次に、ユースケースポイント（UCP）に基づいて他のさまざまな記事を確認しました。私はそれがどのように正確に機能するのか、そしてそれが正しいのかを知ることができません。

たとえば、ユーザーがユーザーIDとパスワードを提供するログイン機能があり、データベース内のテーブルをチェックしてログインを許可または拒否します。ユーザーアクターとログインをユースケースとして定義します。

UCPに従って、ログインのユースケースをシンプルに分類し、GUIインターフェイスを複雑に分類します。UCPファクターの表によると、5と3を取得するため、合計は15になります。技術ファクターと環境ファクターの調整を適用すると、7になります。生産性ファクターを20とすると、140時間になります。しかし、私はそれが文書化とテストの努力と一緒にせいぜい30時間かかることを知っています。

ここでユースケースを定義する際に何か間違ったことをしていますか？UCPによると、インターフェイスがGUIの場合は複雑ですが、ここではGUIが十分に簡単なので、その要素をダウングレードする必要がありますか？また、単純の係数は5です。別のレベルを非常に単純と定義する必要がありますか？しかし、私はここで問題を複雑にしませんか？