Open seiya303 opened 2 years ago
ユースケース図です。抜け漏れもあると思うので、確認お願いします🙏
分かりやすいですありがとうございます!!:raised_hands: 販売者も表品へのコメントありかなと思いました!コメント欄で購入者とのやりとりができるかなと、どうでしょうか?:eyes:
あと管理者は商品管理の権限も必要かなと思いますがどうでしょうか? 昔メルカリで一時期現金が売られていてそれを管理者に削除されたことがあったと思うんですが、そういう場合があるので管理者が直接操作することも必要かと思いました!(投稿する際に画像認識とかで判断できれば問題ないかなと思いましたが一応…)
@gwonin-kenji こういった意見とてもありがたいです!
コメントでチャットする機能ですが、別窓にするか、その商品のコメント欄で展開するか迷って敢えて反映させていなかったのですが、後者の方が良いですかね?前者は당근마켓、後者はTwitterと似たような形になる認識でいます
商品削除の権限あった方がいいですね!商品一覧等の権限も入れ忘れていたので併せて反映させていただきます 昨日急ぎで描いたもので細かいところ漏れがあると思いますので二重チェック頂けるとありがたいです🙏 また、plantumlもオンラインでコード書き換え可能なので、気づいたところ反映させてリンク共有いただいても大丈夫です(その方が認識のずれを防ぎやすいと思います!)
[追記] 管理者への利用者の削除権限も足しておきます
利用者削除と同時にその利用者の商品削除もincludeするように描いたのですが、こちらは外した方が良いですかね? というのも、商品データは今後有用なデータとして残せるという意見があったからです。 商品データにフラグデータを持たせて(こちらをER図・クラス図に反映)、利用者削除と同時にフラグをFalseにするという流れでも良いですかね?
ユースケース図更新しました!
商品一覧等の権限も入れ忘れていたので併せて反映させていただきます 管理者への利用者の削除権限も足しておきます ユースケース図更新しました!
@seiya303 修正&機能追加ありがとうございます!より見やすくなりました!
利用者削除と同時にその利用者の商品削除もincludeするように描いたのですが、こちらは外した方が良いですかね? というのも、商品データは今後有用なデータとして残せるという意見があったからです。 商品データにフラグデータを持たせて(こちらをER図・クラス図に反映)、利用者削除と同時にフラグをFalseにするという流れでも良いですかね?
@seiya303 includeで同時に削除されるものと認識していましたが おっしゃる通り今後有用になりそうだと思いました!フラグ管理する方針でいいと思います!
コメントでチャットする機能ですが、別窓にするか、その商品のコメント欄で展開するか迷って敢えて反映させていなかったのですが、後者の方が良いですかね?前者は당근마켓、後者はTwitterと似たような形になる認識でいます
@seiya303 @yuikateraoka 自分もどちらでもいいかなと思いました!もし別窓にした場合の開発工数ってどのくらいかかりそうですか?自分がやったことなくてまだ想像がついていませんmm もし要以上に工数がかかるのであれば別窓にしなくてもいいかなと思いました! あとここは、UI/UXと関わってくると思うのでUI/UX専門家としてユーザにとってどちらが最適なのかご意見頂戴できればと思いました!
メルカリはコメント欄でやりとりするように実装してますが、これも何か戦略があるんですかね...? ref: https://jp.mercari.com/item/m25035806364
また、plantumlもオンラインでコード書き換え可能なので、気づいたところ反映させてリンク共有いただいても大丈夫です(その方が認識のずれを防ぎやすいと思います!)
承知しました!触ってみます~~~!
@gwonin-kenji 開発工数的には別窓にしない方が楽かな。
というのも、別窓にすると、lineとかと同じように、データベース上でそのユーザーが今どの人とどういったやりとりをしているかの情報を持って紐付けを行わないといけないので。
あとは、DMで別窓設けると、その取引が進行中なのか他のユーザーが分かりづらくなるのと、取引中のフラグ持たせてわかりやすくしても、取引中止(またはキャンセル)の基準を設けるのに追加の工数がかかるのも懸念点になるかな。
つまり、別窓にしない方が、
ただ、別窓にしないデメリットもあって、
といった点が今思う懸念点かな。ただ、メルカリが戦略的に別窓を設けていないとなると、そのメリット・デメリット含めて改めて調査したいですね。
ひとまずは、別窓にしない方向性が実装工数的に良いかなと思うのですが、 @yuikateraoka はどう思われますか?
@seiya303 販売者と購入者の会話記録をログとしてデータベースに保存する認識でしょうか? その場合データベースをアクターとして表示するのは下記の記事であまり良くなさそうだったのでどうなのかと思いました。
@dumbled0re [ask] こちらで指摘をしているのはユースケース図の話でしょうか?
販売者と購入者の会話記録はログとしてデータベースに保存する方式で合っています。 ただ、その会話を第三者が閲覧可能にするか、DMとしてお互いの会話しか閲覧できないようにするかはまだフィックスしていない状況です。
現状、アクターは、管理者と、利用者を継承した販売者、購入者の計3つとなります。 こちらの中でデータベースをアクターとするものはない想定ですが、どちらの箇所の指摘となりますでしょうか。
@seiya303 ユースケース図の話をしていました。
販売者と購入者の会話記録はログとしてデータベースに保存する方式で合っています。 ただ、その会話を第三者が閲覧可能にするか、DMとしてお互いの会話しか閲覧できないようにするかはまだフィックスしていない状況です。
了解です。 第三者が閲覧可能する方向で行くのかと思ってしまいました。
現状、アクターは、管理者と、利用者を継承した販売者、購入者の計3つとなります。 こちらの中でデータベースをアクターとするものはない想定ですが、どちらの箇所の指摘となりますでしょうか。
会話記録のログを残すユースケースを表現する時にデータベースが必要なのかなと思ったんですけど必要なさそうですかね?
@dumbled0re
第三者が閲覧可能する方向で行くのかと思ってしまいました。 会話が途中で途切れてしまっていたので方針がフィックスせず、ペンディング状態になっていました。
実装工数も考えて、商品のコメントに関しては第三者が閲覧可能
な状態にするのが良いと思いますが、こちらどう思われますでしょうか。
会話記録のログを残すユースケースを表現する時にデータベースが必要なのかなと思ったんですけど必要なさそうですかね?
第三者が閲覧可能とするのであればこちらのユースケースは必要と思われるので、追加お願いできますでしょうか。
データベースに関しては必要ないと思います。 ユースケース図はあくまでアクター(ユーザーや外部システム等)とシステム(内部システム)とのユースケース単位でのやり取りを表すのに主に使われるので、データベースのようなミドルウェアはここで登場させず、より下位の設計(シーケンス図など)で記載をするのが良いと思います。
変更点
変更点
商品購入と商品へのコメント閲覧のユースケース追加
確認しました。ひとまず本マイルストーンでは上記のユースケース図でフィックスして進めて良いと思います。
https://github.com/Pionier2027/SMGT/issues/14 こちらのイシューにてシーケンス図の作成お願いいたします。
また、口頭でも挙がったように、欲しいものリストに関するユースケースに関しては次マイルストーンで展開する形で進めましょう。
[目的] 当プロジェクトのユースケース図を作成
[ツール] plantuml
[ルール] 下記のURLで修正後、Submitボタンを押し、URLを修正後のものに置き換える
[UML]