step4 : アプリケーションの概要・テーブル図

[smptmhr]

ペーパープロトタイプ

ER図

ペーパープロトタイプをもとに作ったER図

あっているか不安な点

• 外部キーの持たせ方
• 多重度の描き方、どっちからどっちを見る？
  参考 : 若手プログラマー必読！５分で理解できるER図の書き方５ステップ | NTTコミュニケーションズ 法人のお客さま

[KessaPassa]

ER図おっけー！ あとはログイン画面やユーザ管理画面など他の画面も作って欲しい。おそらく開発するときになってどうしようと困ることになると思うので

[KessaPassa]

このアプリがどのような形で利用されるか（インターネットに公開するのか、社内向けか、etc…）

さっき話していたと思うので、ここについてもどこかに明記しておいて欲しいです

[smptmhr]

アプリの使われ方

想定するユーザの属性

• 個人でタスク管理を行なっている
• 複数のカテゴリ(研究、授業、開発など)にまたがってタスクを管理する必要がある

使われ方

• 個人利用
• インターネットにて公開
• クライアントはスマホやPCなど
• どのクライアントからログインしても同じものが見れる

[smptmhr]

必要と思われるページ

一般ユーザ向け

• ログインページ
• タスク一覧表示ページ(メイン)
• タスク作成ページ
• タスク編集ページ

管理者向け

• 管理ページトップ
• ユーザ一覧ページ
• ユーザ詳細ページ

エラーページ

• 404
• 500

[KessaPassa]

エラーページ 404 500

これもあるの良いね！

ログインページ

ログインするだけのページと、サインアップするページもあると思いました！

一般ユーザ向け

ここはユーザ自身の名前変更やアイコン変更ができるようなマイページはないということでOK? つくらなきゃいけない！という訳ではなく、ともがつくるアプリケーションで必要ないと思っているのであればなしでも大丈夫です！

[smptmhr]

サインアップするページもあると思いました！

その通りです！

ここはユーザ自身の名前変更やアイコン変更ができるようなマイページはないということでOK?

確かにマイページは必要そうですね。 そこで確認・編集できる属性は以下の3つかなと思います。

• メールアドレス
• 名前
• パスワード

ユーザは自分のタスクしか見られないため、別のユーザを識別するためのアイコンは必要ないと考えてます。

・名前についての指摘を受けて 一人のユーザが異なるメールアドレスでアプリを使い分ける可能性もあると思い、
ワークスペース名(すなわちユーザ自身の名前とほぼ同義だが)を持たせるのはアリだと思いました。

[KessaPassa]

ユーザは自分のタスクしか見られないため、別のユーザを識別するためのアイコンは必要ないと考えてます。

お、どうしてそう思ったか書いてくれるのありがたい！その考えならアイコンはなしで良いね！

一人のユーザが異なるメールアドレスでアプリを使い分ける可能性もあると思い、 ワークスペース名(すなわちユーザ自身の名前とほぼ同義だが)を持たせるのはアリだと思いました。

なるほど。それはあるかもですね。 追加するのであればER図も更新して、ペーパープロトタイプも更新しちゃいましょう！

[smptmhr]

ペーパープロトタイプ修正

足りてなかったページも考慮してペーパープロトタイプを更新しました！

※「ユーザ一覧ページ」と「管理ページトップ」は合体させて問題なさそうなので一つにしました。

ユーザは自分のタスクしか見られないため、別のユーザを識別するためのアイコンは必要ないと考えてます。

どうしてそう思ったか書いてくれるのありがたい！

今回は想定される使われ方が個人で完結しているためです。
社内ツールのように複数ユーザが一つのワークスペースを使用する想定ならアイコンは必要かと思いますが、1ワークスペース 1ユーザなので！

[smptmhr]

ER図の修正

「ユーザ」エンティティに「ユーザ名」を追加 「タスク」エンティティから「カテゴリID」を削除

[KessaPassa]

あ、ER図なにも問題ないと言ってたんだけれど、1つのタスクに対して複数のラベルを扱えるようにするには今のままじゃダメだったのに気がついた もし今のER図のままラベルを複数つけようとするとこんな感じになると思います！

tasks テーブル	id	label_id
1	1,2,3

これはジェイウォークといってできるだけ避けたいアンチパターンです sqlで検索するときにとても大変になってしまいます 😣 https://qiita.com/aconit96/items/24f790662d9b88a3ab74

なので交差デーブルというラベルとタスクの間にそれぞれを紐づけるテーブルをつくるようにしてみてほしいです https://post-output.com/185/

[smptmhr]

交差テーブルというラベルとタスクの間にそれぞれを紐づけるテーブルをつくるようにしてみてほしい

中間テーブルのイメージですね。 Qiitaの記事読んでなんとなくですが理解しました。ER図更新します！

[smptmhr]

指摘部分を反映させたER図こんな感じでしょうか。 ラベルとタスクをつなぐ中間テーブルを追加しました。

[KessaPassa]

お、そんな感じ！ テーブルの名前も 中間テーブル ではなくちゃんとした名前を今のうちにつけてあげましょう！テーブル作成(マイグレーション)のときに困ると思うので あとはタスクテーブルにある ラベルID(FK) が要らなくなるね

[KessaPassa]

ちょっと疑問に思ったことで確認なんだけれども、タスクグループはカテゴリを跨いで存在することはありえない？ 例えば、タスクAとタスクBがあったとして、どちらもタスクグループ1に紐づいている。これがカテゴリ研究にどちらもあるならば問題なさそうだけれど タスクAはカテゴリ研究に、タスクBはカテゴリ授業に、みたいなことは起こり得ない？

[smptmhr]

更新しました！ こんな感じでしょうか？

• 「中間テーブル」→「ラベリングテーブル」に改名
• 「タスクテーブル」のラベルID(FK)削除

[smptmhr]

タスクグループはカテゴリを跨いで存在することはありえない？

使用方法によっては起こり得ると思うんですが、今回はそこまでカバーしない(同一カテゴリの中で収める使い方を想定する)つもりでした！ 今回、関連タスクという項目を設けた理由が、大きなタスクを分割して小さく管理することでタスクへの取り掛かりやすさをサポートすることなので、その目的であればカテゴリを跨ぐ必要はないかと思います。

[KessaPassa]

使用方法によっては起こり得ると思うんですが、今回はそこまでカバーしない(同一カテゴリの中で収める使い方を想定する)つもりでした！ 今回、関連タスクという項目を設けた理由が、大きなタスクを分割して小さく管理することでタスクへの取り掛かりやすさをサポートすることなので、その目的であればカテゴリを跨ぐ必要はないかと思います。

理解。であれば大丈夫だね！

あと気になったのはタスク編集ページとかにある 重要度 はER図にないけれど書き忘れ？ https://github.com/smptmhr/el-training/issues/3#issuecomment-1113196046

[smptmhr]

重要度は書き忘れです！ 追加したのがこちらになります！

[smptmhr]

変更点

• 締め切り → 必要日数(実装に合わせて)
• タスクグループの削除 このアプリの目的は、次にやることを一目で分かることであり、それにはタスクグループの機能は必要ないため。 もともとタスクグループを導入しようとした理由は、グループ化することで管理しやすくなることを狙ったためだったが、それはラベルによって実現可能であり、機能が重複している。