| この課題はどのコースに属していますか | < クラスW、2020年春（福州大学） > |
|---|---|
| この求人はどこにありますか | < 職務要件 > |
| この割り当ての目標 | システム設計とデータベース設計 |
| 宿題 | < 宿題文 > |
| その他の参考文献 | <「建設の法則」 |
part.01チームの予想される開発スケジュール
今週のシステム設計とデータベース設計の作業が完了したら、コードの実装部分に入ります。私たちの計画は次のとおりです。
| 時間 | 配置する |
|---|---|
| 04.12-04.19 | |
| 優れたオープンソースプロジェクトを参照し、プロジェクトの構築を完了し、最初にサードパーティのライブラリを使用することを決定し、インポートとテストを完了します。 | |
| 04.20-04.26 | |
| バックエンド：最初に3つのモジュールのインターフェースを実装します：リリースタスク、遺失物発見、アイテムレンタル。 | |
| Webフロントデスク：最初に、リリースタスク、遺失物発見、アイテムレンタルの3つのモジュールのインターフェイスを実装します。 | |
| Webバックグラウンド：3つのモジュールのインターフェイス：リリースタスク、遺失物取扱所、アイテムのレンタルが最初に実装されています。 | |
| Android：最初に、リリースタスク、遺失物発見、アイテムレンタルの3つのモジュールのインターフェイスを実装します。 | |
| 04.27-05.03 | |
| バックエンド：プロジェクトを改善し、サーバーにバックエンドをデプロイして、フロントエンドがデータのやり取りを完了するのを支援します。 | |
| Webフォアグラウンド：プロジェクトを改善し、サーバーにデプロイされたバックエンドとやり取りします。 | |
| Webバックグラウンド：プロジェクトを改善し、サーバーにデプロイされたバックエンドとやり取りします。 | |
| Android：プロジェクトを改善し、サーバーにデプロイされたバックエンドとやり取りします。 | |
| 05.04-05.10 | |
| バックエンド：開発プロセス中に発生した問題に応じて、プロジェクトの詳細を最適化します。 | |
| Webフォアグラウンド：プロジェクトを最適化し、Webをサーバーにデプロイします。 | |
| Webバックグラウンド：プロジェクトを最適化し、Webをサーバーにデプロイします。 | |
| Android：プロジェクトを最適化し、Androidターミナルをパッケージ化して、アプリストアに公開します。 | |
| 05.11-05.17 | |
| テスト、小規模プロモーション、最適化、バグバージョンの更新。 | |
| 05.25-05.31 | |
| テスト、広範なプロモーション、メンテナンス、バグバージョンの更新。 | |
| 05.18-05.24 | |
| ユーザーのフィードバックに基づいて、プロジェクトの合理性を評価し、プロジェクトの機能を調整および拡張して、バージョンを更新します。 | |
| 06.01-06.07 | |
| メンテナンス |
part.02期待される開発計画分業
| 学生証 | 配置する |
|---|---|
| 221701412 | バックエンドアーキテクチャの完成を主導し、タスクファンクションモジュールの開発をリリースします。 |
| 221701414 | Android部分の開発を担当します。 |
| 221701417 | 潜在的なユーザーを掘り下げて、調査、プロモーションを行い、ユーザーのフィードバックを収集します。フロントエンドインターフェイスの設計に参加します。 |
| 221701418 | Webフロントデスクの開発を担当します。 |
| 221701420 | Webバックグラウンドの開発と保守を担当します。Webフロントデスクの開発を支援します。 |
| 221701429 | フロントエンドとバックエンドの作業の進行状況に精通し、バックエンドデータベースの開発に参加し、インターフェースドキュメントを作成して保守します。 |
| 221701431 | データベースの設計とメンテナンスを主導し、バックエンドの遺失物とアイテムのレンタルモジュールを完了します。 |
| 221701439 | フロントエンドプログラムとバックエンドプログラムを完全にテストして、テストドキュメントを生成します。 |
part.03設計図と説明
建築設計
汎用モジュール階層図
設計クラス図
ER分析チャート
テーブル構造設計
（一部列挙）
ユーザーテーブル
管理者テーブル
遺失物リスト
コメントフォーム
デリケートな語彙
報告フォーム
システムのセキュリティと権限の設計
データベースは、ユーザー名とパスワードを使用してユーザーのログインを認証します。ユーザー名が有効でパスワードが正しい場合、接続が確立されます。同時に、ログインには3つの異なるデータベースストレージ権限があります。
1.所有者の権限：データベース、ユーザー、またはオブジェクトが確立されているスペースの場合、システムはスペースの所有者に所有権を付与します。所有者は、新しいオブジェクトを作成したユーザーまたはデータベースです（CREATE DATABASE / CREATEUSERステートメントのFROM句で指定）。たとえば、データテーブルの所有者は暗黙的な権限を持ち、所有するデータテーブルに対する独自のSELECT権限を付与（GRANT）できます。
2.自動的に生成される権限：これは、データベース、ユーザー、またはオブジェクトの作成者の権限と、新しく作成されたユーザーまたはデータベースに付与される権限を自動的に付与するシステムです。
3.付与された権限を表示：これは、WITHGRANTOPTION権限を持つすべてのユーザーによって付与された権限です。明示的に許可された（コマンドによって宣言的に許可された）アクセス許可は、TeradataのSQL GRANTコマンドを使用して許可できます。
同时使用数据库存取日记进行安全管理：
通过存取日志记录使用者在数据库中的所有活动，如果使用者尝试存取某一数据库对象，且该对象已包含在目前的日志定义中，则系统会记录其使用者识别码、对象名称及此一存取动作是否被相应的存取权限所允许。所使用的 SQL 语句也可以选择性的被记录下来。
设计思路
前后端完全分离，仅通过http接口进行交互，实现各端完全透明，代码的维护升级互不干扰，使用mysql + springboot + html + Android + vue进行开发。
part.04 本次作业队员贡献度
-
为了调动成员积极性，增加团队成员之间的配合以及加强在今后的合理分工，本团队从本次开始，引入对成员分工的工作进行加权，用文档记录，最后按总权分配贡献比。
-
团队分工文档下载：<团队分工文档>
| 学号 | 工作内容 | 贡献度 |
|---|---|---|
| 221701412 | 系统设计和数据库设计答辩 PPT（1）、进行答辩（1）、类图设计（1）、参与各部分修改与建议（0.5） | 17.5% |
| 221701414 | 编写完成博客（2)、参与各部分修改与建议（0.5） | 12.5% |
| 221701417 | 答辩打分（1）、系统设计和数据库设计评审表（1）、记录 Q&A 记录（0.5）、系统设计和数据库设计答辩 PPT（1） | 17.5% |
| 221701418 | 系统设计说明书（2） | 10% |
| 221701420 | 泳道图（1）、数据流图（1） | 10% |
| 221701429 | 数据库设计说明书（2） | 10% |
| 221701431 | 数据库设计说明书（2） | 10% |
| 221701439 | 系统设计说明书（2）、记录 Q&A 记录（0.5） | 12.5% |
Part.05 答辩汇总
选题答辩
-
1.平台是否支持校友租赁物品？
- A：不支持校友，已步入社会的校友加入，会增加很多隐患，使用 orc 读取校园的学生卡和教师卡，仅支持在校师生使用，可以写一个 Timer 定时器，一年更新一次数据库的用户，对于正则匹配的学号往后移 3 年已过期的用户将限制其功能的使用。
-
2.这些平台重要的是“维护者”，这一点如何保证？
- A：在本团队成员在校期间，我们是维护者，当我们离校后现在的打算是传给学弟学妹们继续维护，一代一代的维护。后续我们会考虑产品的商业盈利问题，有了收益，更有利于维护和发展。
-
3.往届做类似产品的很多，但是限于时间和技术，都无法开发出预期的所有功能，你们有做技术可行性分析吗？
- A：团队成员项目经验较同级一些同学相对来说要丰富，有在 ppt 中展示，且这次产品考虑的主要的三个模块，在以前团队的成员都有写过类似，这次的开发主要是建立在复用以前代码基础拓展新的功能且优化，有较大可行性。目前团队已经开始着手准备这一项目。
-
4、新的思考
- A：作为旗山的骄傲，我们是一个团队，在开发中需要始终保持一致的目标、明确的分工。我们的目标是开发出一个可维护、可迭代、可投入现实中使用的产品。为此，我们开始着手准备相关的知识。
原型答辩
-
1.租赁涉及到费用，如何交易？
- A：我们的校园介子空间平台是一个综合性的校园平台，目前我们平台的定位是信息共享，是在对竞品（福大小黑板等一众公众号）进行对比分析得出的信息共享平台，区别于咸鱼等购物平台，买卖双方在我们的平台获取相关信息后，交易由双方自己线下协商完成。
-
2.如何处理交易争端？(租赁的物品被损坏并且租赁方不认为是自己的问题)
- A：我们的校园介子空间平台是一个综合性的校园平台，目前我们平台的定位是信息共享，是在对竞品（福大小黑板等一众公众号）进行对比分析得出的信息共享平台，区别于咸鱼等购物平台，买卖双方在我们的平台获取相关信息后，交易由双方自己线下协商完成，如果出现租赁的物品被损坏并且租赁方不认为是自己的问题，本平台可为双方的交易争端提供平台的聊天内容作为证据。
-
3.对于涉密等敏感话题，打算采用什么算法？
- A：对于涉及涉密等敏感话题，主要通过两个途径，一个是管理员在后台的初步审核，一个是在答辩老师提醒增加的举报功能，在前台界面当一条疑似涉密等敏感话题的发布举报次数达到一定次数（如 100 次）时，逻辑处理模块会将此条发布在后台报警，以进行人工核实。
-
4.是否涉及押金？
- A：我们的校园介子空间平台是一个综合性的校园平台，目前我们平台的定位是信息共享，是在对竞品（福大小黑板等一众公众号）进行对比分析得出的信息共享平台，区别于咸鱼等购物平台，买卖双方在我们的平台获取相关信息后，交易由双方自己线下协商完成，所以本平台并不涉及押金。
-
5、平台涉及的交易如何完成？
- A：我们的校园介子空间平台是一个综合性的校园平台，目前我们平台的定位是信息共享，是在对竞品（福大小黑板等一众公众号）进行对比分析得出的信息共享平台，区别于咸鱼等购物平台，买卖双方在我们的平台获取相关信息后，交易由双方自己线下协商完成。
-
6、建议平台能提供举报这一功能。
- A：在答辩老师提醒增加的举报功能，在前台界面当一条疑似涉密等敏感话题的发布举报次数达到一定次数（如 100 次）时，逻辑处理模块会将此条发布在后台报警，以进行人工核实。
需求分析答辩
-
1、单独设立 失物招领 和 寻物启事 两个类，是否存在重复，这样的关系是否准确。
- A：不重复，因为这两个东西容易混淆，考虑到易于理解性，并且两个类含有的属性并不完全相同，我们决定将这两个类分开。
-
2、在发布任务功能，一个任务要体现发布任务者和领取任务者吗？
- A：我们的目标是提供一个发布信息、获取信息的平台，原则上只对涉及违规违法的敏感信息进行处理，不会干涉任务的处理进度。比如：某个用户在朋友圈发布了一条任务信息，另外一个用户获取任务信息后想要领取任务，对于领取任务这些具体的细节交由双方通过发布的信息中留下的联系方式，自行协商。
-
3、类似的物品租赁类的属性是否不够？
- A：我们已经在任务详情中对属性进行了补充。
-
4、如果不记录谁完成的话对后续信誉记录什么的会有影响吗？
- A：针对这个问题，我们增加了举报功能，对于破坏信誉的行为，用户可以在举报功能中，上传相关的信息，经后台审核后，对被举报的账号进行封号等操作，对于涉及违法的问题，会提供相关信息，协助举报人报警。
-
5、敏感词建议单独放一张表。
- A：感谢老师提出建议，我们在系统设计的时候做出了相应的修改。
Part.06 github仓库地址以及下载链接
-
Github 团队仓库链接：<点击进入>
-
旗山的骄傲_系统设计说明书.pdf：<点击下载>
-
旗山的骄傲_数据库设计说明书.pdf:<点击下载>
-
旗山的骄傲_系统设计和数据库设计答辩 PPT.pdf: <点击下载>
Part.07 本项目目前的全部附件
如果您觉得一个一个下麻烦的话，可以在这里下载本项目目前的全部附件
-
本项目目前的全部附件下载（百度云链接：提取码（yjuf)）：<本项目目前的全部附件>
Part.08 本次答辩的评审表
-
项目系统设计与数据库设计评审表：<点击进入>
Part.09 本次答辩Q&A回答以及对答辩的补充
-
汪老师：
-
1、此处使用继承，请解释一下，能否考虑用组合？
- A:此处使用继承是因为在分析阶段的类图在提取需求时，这三个实体类均有公共的属性，于是提取了一个发布的总类类作为父类型，然后继承下去三个子类型再实现对应不同属性，所以此处使用继承，组合关系中的整体直接掌握部件的生灭，聚合关系中的整体并不具有生灭部件的权力。一旦组合中的整体不存在时，其组合部件也不能单独存在，必须同时消灭。另外，外界也不能直接与部件沟通，必须通过整体代为传达消息。然而在此系统中子类型仍与其他的部分有直接的关联，所以本小组讨论后还是认为使用继承更为恰当。
-
2、虚线表示什么含义？
- A:ER图的虚线应该是表示week entity，即需要借助外键和标有虚线的partial key来确定的实体，但是在之前的这个ER图的该场景这样使用并不恰当，现已在博客上传了修改后的版本。
-
傅老师：
-
1、举报表没有涉及user_id?
- A:举报表没有涉及user_id，在之前是打算设计为由举报表的table_id在对应的发布类的表查询对应的user_id，即进行一个多表查询，在答辩后小组有对此设计进行讨论，认为在后续的开发阶段应该在举报表加入user_id，这样的设计明显更为合理。
-
2、实体之间的关系没有标注
- A：实体之间的关系现已进行标注，现已在博客上传了修改后的版本。
-
乐助教：
-
1、总的来说设计的不错；评审表布局可以稍微优化一下；ER图绘制的不太规范
- A：评审表布局现已进行了一定的调整，er图确实绘制的不规范现已在博客上传了修改后的版本。这次我们小组拿出的成果确实有一些不尽人意的地方，现已在博客更新了第九部分对答辩q&a进行回答以及对一些我们组认为在答辩中不足的地方进行了一定补充，我们在下次将吸取问题教训在继续发挥我们的长处的同时改正问题，我们会加油的！！！
-
对于答辩的一些补充：在答辩阶段并没有给出具体的接口设计，本着得尽量完整每一次的设计，这样才能将这样的一个完整的项目环环相扣的设计下去，在此博客里我们小组还是重新给出了接口设计，亡羊补牢为时应该不晚！！
