2016 大作业
题目
| # | 需求方 | 联系方式 | 题目 | 简介 |
|---|---|---|---|---|
| 1 | 岳星兆 | yuexz AT pku.edu.cn | 麦得劳汉堡套餐系统 | 一个个性化汉堡定制系统 |
| 2 | 王柯翔 | 1501111326 AT pku.edu.cn | 餐厅点餐系统 | 一个完整的、符合餐厅需求的点餐系统 |
| 3 | 文吉 | 1501214416 AT pku.edu.cn | 互助平台 | 一个大家能寻求帮助与提供帮助的平台 |
| 4 | 易晓涵 | chlxyd AT pku.edu.cn | 麻将游戏 | 一个较完善的麻将对战平台 |
| 5 | 曹兴超 | caoxingchao AT pku.edu.cn | 校园图书漂流系统 | 一个二手图书共享平台 |
| 6 | 张舒汇 | zhangshuhui AT pku.edu.cn | 志愿树系统 | 一个方便志愿者参与志愿活动的平台 |
题目１麦得劳汉堡套餐系统
1. 项目背景和目标:
“麦得劳”是一家风靡全球的汉堡快餐公司，它为全球提供卫生、便捷、可口的快餐服务。随着生产条件的不断优化，产能已经可以为顾客提供个性化的服务。因此为了推出全新的个性化自创汉堡，“麦得劳”公司需要打造一个：个性化汉堡定制系统。
个性化汉堡以美味的自创汉堡、贴心的餐厅服务和数字化点餐，为消费者打造全新的用餐体验。消费者只需在自助点餐机上通过简单六步，以 24 种精选食材，创造出上亿种汉堡组合。消费者点餐后可以随意就坐，专属大厨将根据消费者要求现点现做，顾客的自创汉堡将由专属接待员使用木质托盘提供送餐服务。本系统将为自创汉堡用餐提供流畅、完整的业务流程服务支持。
2. 功能概述:
- 消费者点餐：系统告知可选材料的信息及价格，消费者根据自身爱好点餐，点餐分为以下 6 步选择，其中每步初步定义的可选项有：
- 1.1 面包：松软面包、白面包、巨菜叶；
- 1.2 肉饼：牛肉、鸡腿肉、鳕鱼肉、虾肉；
- 1.3 蔬菜：生菜、番茄、辣椒圈、洋葱；
- 1.4 芝士：黄芝士、白知识、芝士条；
- 1.5 酱料：芥末酱、蛋黄酱、烧烤酱、香辣酱、千岛酱、番茄酱；
- 1.6 其他：培根、牛油果泥、玉米脆片、香煎蘑菇、煎蛋。
- 消费者点餐结束后提示订单，显示价格，支付后订单生效。
- 厨师确认消费者下的订单，进行烹饪，制作汉堡结束后，通知接待员取餐。
- 接待员取到餐送至顾客处，确认订单交易完成。
- 为方便顾客自创汉堡，提供主厨推荐以供参考：
题目2 餐厅点餐系统
1. 项目背景和目标: 长久以来,餐饮被看做是老牌的传统行业,其经营管理和餐饮服务等基本上是依靠专门负责的人员进行手工分类和管理。面对餐饮企业继续发展的需求所带来的更复杂和苛刻的要求,人工管理的传统方式显然已经不适合了。在这种形势下,高质量、高可靠的餐厅点餐系统对于保证餐厅的日常经营活动至关重要。该系统能够克服传统人工方式的各种缺点,并且具有快速检索、高可靠、大存储、强保密性,长寿命和低成本的特点。
餐厅点餐系统能够在极大程度上提高餐厅管理的效率,也是餐厅规范化经营和正规化管理的必要条件。待开发的餐厅点餐系统针对的就是餐饮企业的实际需求,结合软件工程的指导原则和面向对象的方法,最终获得一个完整的、符合餐厅需求的点餐系统。
2. 功能概述:
本系统需要服务顾客、餐厅服务员和餐厅老板。下面分别就这三类服务对象分别进行说明：
- 顾客 （1） 查看菜品 可以查看当前餐厅提供的所有菜品，包括菜品名字、菜品图片、菜品介绍、菜品推荐度、菜品评价等信息以及当日推荐菜和餐厅招牌菜等。默认展示的为菜品名字、菜品图片和菜品推荐度（系统自动根据近一个月顾客点菜情况给出推荐度），顾客点击菜品名字或图片会进入菜品介绍的界面，方便查看进一步的菜品信息。 （2） 搜索菜品 可以根据条件搜索当前餐厅提供的菜品。搜索的条件包括：菜品名字和菜品推荐度，支持部分匹配搜索和混合条件搜索。如果满足顾客搜索条件的菜品无法找到，则为顾客显示当日推荐菜和餐厅招牌菜。 （3） 初始点菜 可以进行初始的点菜操作。顾客可以通过增减菜品数量、选择菜品做法的操作将相应的菜品加入到点菜列表里，并且顾客可以及时查看点菜列表、增减菜品、修改菜品做法。系统会为顾客实时显示已点菜品总份数和金额。最终顾客点好菜之后可以下单，单子会被后厨响应。 （4） 加菜 可以进行后续的加菜操作。顾客可以在初始点菜流程结束后继续点菜，支持的操作和初始点菜阶段类似。系统会为顾客实时显示加上初始点菜的菜单之后的总份数和金额。最终顾客点好菜之后可以下单，单子会被后厨响应。 （5） 退菜 可以进行有时限的退菜操作。顾客可以在初始点菜流程结束五分钟内进行退菜操作，不允许顾客将所有菜品退掉的情况。退菜成功后，系统会将退的菜品从已点列表里删除，并重新计算总金额。后厨会在顾客退菜的时候及时得到需要退掉的菜品。 （6） 买单 可以进行买单操作。顾客可以在初始点菜流程之后选择买单操作。系统会为顾客展示菜品列表、菜品单价和总份数、待付款总金额信息。餐厅服务员会收到顾客需买单的信息，及时为顾客买单。 （7） 评价、建议和投诉 可以进行建议和投诉操作。顾客在买单之后可以对这次已点列表里的菜品进行评价，并对服务员和餐厅环境进行建议和投诉。
- 餐厅服务员 （1） 查看菜品 同顾客的查看菜品需求。方便服务员为顾客讲解和推荐菜品。 （2） 搜索菜品 同顾客的搜索菜品需求。方便服务员为顾客讲解和推荐菜品。 （3） 上菜 一旦后厨完成一道菜的制作时，系统会提醒服务员及时上菜，提供包括菜名、桌号在内的信息。 （4） 为顾客买单 一旦顾客选择买单操作，系统会提醒服务员为顾客及时买单，提供总份数和应收金额的信息。 （5） 返台 顾客离开餐厅后，系统会提醒服务员进行返台操作。
- 餐厅老板 （1） 查看菜品 同顾客的查看菜品需求。方便老板了解餐厅当前提供的菜品信息。 （2） 选择当日推荐菜和餐厅招牌菜 可以选择或调整当日推荐菜和餐厅招牌菜。 （3） 查看顾客建议和投诉 可以查看顾客的所有建议和投诉信息。 （4） 查看点菜情况、营业额 可以按天、月份、年度等查看点菜情况和餐厅营业额。
- 性能要求 易用性、安全性、支持大流量访问
- 系统平台要求： 要求以网页的形式呈现，方便使用者通过各种终端访问（最好考虑到针对手机屏幕的优化）。
3. 需求变更:
针对实际的餐厅点餐系统处理的业务流程和面临的问题域,餐厅点餐系统需要为顾客提供及时的点餐服务,同时需要辅助餐厅服务员在顾客点餐后为其上菜以及为其买单的操作。由于餐厅提供的菜品随季节时令等改变,点餐系统也需要为餐厅老板提供更新菜品列表和更换每日推荐菜和餐厅招牌菜的操作。总体来说,点餐系统的目标是使得点餐服务自动化,同时完成附带的提醒服务员上菜、买单和调整菜品列表等必备的功能。从性能上而言,点餐系统的访问量呈现分布不均匀的特点,例如到用餐高峰期和节假日系统访问量会激增,为此系统需要适应这种访问量不均匀且短时访问量可能非常大的实际情境;点餐系统存储的是每桌顾客的点菜信息,包括菜品数量和总价等,为此系统需要提供严格的隐私保护和数据安全服务。
- 评价和建议修改
说明：原来的系统中，只要求顾客可以对每道菜输入自己的评价文本内容，需要修改为系统自动检测并删除负面评论（即根据关键词过滤掉多于5个负面词的评价），且为老板提供手动删除评论和调整评论展示顺序的功能。
考察点：考察面向对象的封装思想。菜品类已经封装好了，可能有抽象父类，其中有新增顾客评价的方法。可以通过修改这个方法来满足变更的需求。老板的手动删除和调整评论需要新增加相应的方法。
- 菜品管理新增
说明：原来的系统中，菜品列表是固定不变的，现需要修改为老板可以添加菜品、删除菜品和修改菜品描述信息。
考察点：考察面向对象的聚合和松耦合的思想。原先的实现可能有DishList类（菜品列表类），属性是菜品里的每道菜的对象（体现聚合），方法有搜索菜品列表、查看菜品描述信息。可以增加一个管理菜品列表的方法。松耦合体现在只修改菜品列表这个类，不修改老板类，减少菜品列表类和老板类间的耦合。
题目 3 互助平台
1. 项目背景和目标:
从进入大学之后，我们中的许多，远离了家人，远离了熟悉的环境，与其同时，也失去了生活中的很多依靠。从只用关心学习，到现在生活完全自理，也许，多一些帮助会更容易。慢慢的，我们的生活丰富了起来，我们有了理想，有了目标，更明确的，有了短期的规划与安排，但是仅仅自己一个人，也许不太容易坚持下来，也许，多一些帮助会更有动力。随着日子越走越远，我们的日程安排也慢慢的受到各方面的牵制，那今天要到的快递怎么办，还有欠费停电的房间该如何是好，也许，多一些帮助会更温馨。
本项目的目标是： - 建立一个大家能寻求帮助与提供帮助的平台 - 使得短期紧急的需求能够及时得到响应与获得帮助 - 设计合适的制度，使得平台内用户能够得到客观的【靠谱】程度评价 - 能够长期发布常见问题及通知信息
2. 功能概述:
- 用户注册：
- 用户选择注册
- 输入手机号，系统发送验证码短信
- 用户使用验证码进行验证
- 验证通过
- 用户输入校内住址与学号
- 注册成功
- 用户登陆：
- 用户选择登陆
- 用户输入手机号，系统发送验证码短信
- 用户使用验证码进行验证
- 验证通过，登陆成功
- 发布任务：
- 用户选择进入任务界面
- 用户选择任务类型
- 用户填写任务标题和内容
- 用户选择任务消亡时间（在此时间之后，任务将不再有效）
- 用户确认发布任务
- 查看已发布求助状态：
- 用户进入个人页面
- 用户选择已发布任务列表
- 用户选择需要查看状态的任务
- 显示任务当前状态
- 领取任务：
- 用户进入主页，选择希望提供帮助的模块
- 进入模块后，显示当前任务列表
- 选择愿意提供帮助的任务
- 查看任务详细内容
- 确定提供帮助，领取任务
- 查看已领取求助状态：
- 用户进入个人页面
- 用户选择已领取任务列表
- 用户选择需要查看状态的任务
- 显示任务当前状态
- 确认求助完成并评价：
- 寻求帮助者在确定提供帮助者完成任务后进入任务页面
- 确认任务已完成
- 对提供帮助者进行评价
- 确认帮助完成并评价：
- 提供帮助者在帮助完成后进入任务页面
- 确认任务完成
- 对寻求帮助者进行评价
- 查看常见问题或者通知：
- 用户选择常见问题或者通知模块
- 现实常见问题或者通知
- 查看个人评分：
- 用户进入个人页面
- 选择查看个人评分
- 分别显示作为寻求帮助者和提供帮助者的评分
系统展现形式：
- 页面形式可以类似于论坛，分为多个模块，分别是：紧急求助，校内通知，常见问题，以及各个不同领域的模块
- 将希望寻求到的帮助，以【任务】的形式发布
- 提供帮助者可以领取【任务】，完成任务后需要被帮助者的反馈和确认任务完成
- 提供帮助者可以选择领域，接受系统的相关领域求助的推送
- 提供帮助者会在完成任务后有评分，并有累计评级，以决定 ta 的【靠谱】程度
2. 需求变更:
- 增加每个版块内对于求助信息的排序功能。
每个用户都有作为求助者和帮助者的评分，综合这两个得分，总得分为（作为帮助者得分70% + 作为求助者得分30%）。在每个版块内部，总体按照发布日期排序，最近发布的在最前，同一天的发布的求助信息，按照发布者的总得分排序。新注册的用户，两项评分都默认为4分（满分5分）
考察点：每个版块都会包含若干条求助信息，他们可以是关联的关系（或者说是聚合的关系）。可以通过修改“版块”这个类来实现对于其中求助信息的排序。
- 平台广播
当学校发布重要通知时，使得每个同学都能在个人主页接收到通知的内容。
考察点：可以通过修改用户类的方法，使得每次用户登录时都会主动获取平台广播，并显示在个人主页。
- 定向求助
说明：用户在发布求助信息时，可以输入期望的帮助者（下面成为用户E）的账号（或手机号）。求助信息发布之后，会给用户E发送系统消息，当用户E登录平台时，该系统消息会显示在个人主页。
考察点：用户类的对象之间可以通过发送异步消息的方式来完成定向求助。也可以通过建立特殊的关联来实现这样的求助。
题目 4 麻将游戏
1. 项目背景和目标:
随着移动网络的不断发展，各类移动端应用不断涌出，涵盖了人们的生活，出行，社交，医疗等方方面面。但是除了应用类的移动软件，作为移动端应用的另外一大版块——游戏版块，也是当今移动网络的一个重要组成部分。
麻将起源于中国，原属皇家和王公贵胄的游戏，其历史可追溯到三四千年以前。在长期的历史演变过程中，麻将逐步从宫廷流传到民间，到清朝中叶基本定型。直到今天仍然是很多人们娱乐活动的一个重要部分，在线的麻将平台也有广泛的需求。
在这种背景下，本系统的目的在于建立一个完善的麻将游戏平台，满足玩家的需要。
2. 功能概述:
- 玩家能进行注册和登录。
- 玩家能够选择进行单机/联网游戏。
- 对于单局游戏，应该满足提出的所有游戏应有的功能要求，比如出牌，摸牌，吃，碰，胡等。
3. 术语约定
庄家：每局开始首先发牌的人。
上家：在你的回合之前操作的人是你的上家。
下家：在你的回合之后操作的人是你的下家。
吃牌：当你的上家打了牌，且这张牌可以与你手上的牌构成连续的三个数时，这时可以吃牌，即将这三张牌单独拿出来亮出。吃牌后轮到你出牌。
碰牌：当其他玩家打了牌，且你手上有两张这样的牌时，这时可以碰牌，即将这三张牌单独拿出来亮出。碰牌后轮到你出牌。
杠牌/明杠：当其他玩家打了牌，且你手上有三张这样的牌时，这时可以杠牌，即将这三张牌单独拿出来亮出。并摸一张牌。杠牌后轮到你出牌。或者你又有一张已经碰过的牌，也可以杠牌。
杠牌/暗杠：在你的回合，你手上有四张一样的牌时，你可以将这四张牌盖上亮出，并摸一张牌。杠牌后轮到你出牌。
胡牌：当自己的回合摸牌，或者其他玩家打了牌，这张牌与你手上的牌组合满足胡牌条件，即可以选择胡牌获胜。
宝牌：每局存在一张牌作为宝牌，宝牌可以替代其他任意一张牌。
牌头：当前发牌的位置。
牌尾：可发牌的最后一张的位置。
4. 游戏规则
由于麻将的游戏规则种类繁多且差异巨大，这里并不要求实现很多奇奇怪怪的游戏规则，而只实现基本的麻将游戏规则。
4.1 发牌顺序规则 游戏可以循环进行，一局结算后自动进入下一局，第一局随机一个人作为庄，从庄开始按逆时针顺序发牌，之后每局的胜者作为下一局的庄。 4.2 发牌规则 游戏开始时，从随机位置开始发牌，从庄开始，逆时针一人发四张牌，这之后，庄拿之后的第一张和第五张牌，其余人依次拿第2,3,4张牌，发牌完后，庄有14张牌，其余人各13张。开局发牌后轮到庄出牌。 之后按顺时针轮转，对应的玩家开局先摸一张牌，再进行出牌。 对于杠牌，一律从牌尾得到杠牌。 4.3 翻宝牌 发牌完后，从牌尾的随机1-6张的位置选择一张翻开正面亮出，这一张的下一张牌作为当局的宝牌。 4.4 胡牌规则 a) 当手上有七对牌时可以胡牌，牌型“七对”，如果有两对牌是一样的，牌型“豪华七对”。 b) 当手上加上牌/吃/杠满足33332的牌型时，可以胡牌，其中2代表一对牌，3代表杠，或者三张一样的牌，或者三张连续的牌。 c) 其中对于b)，如果所有牌花色一样，牌型“清一色”，如果所有的3都是三张一样的牌，牌型“碰碰胡”，如果胡牌过程中没有使用其他人打过的牌，牌型“门前清”。 d) 如果胡牌的时候有宝牌，称为“白胡”，否则如果没有宝牌或者宝牌没有当做其他牌，称为“黑胡”。 e) 具体算番方式暂略。 4.5 宝牌限制规则 a) 当手牌有两张或者两张以上的宝牌时，禁止吃/碰/杠操作。 b) 宝牌禁止打出。
题目 5 校园图书漂流系统
1. 项目背景和目标:
高校图书馆中有大量的有价值的图书，尤其是各种年代久远的经典书籍，然而，图书馆也有其劣势，那就是书籍更新速度不够快，热门书籍数量不够多，增加购书数量又会使图书馆的购书成本大大提高，读者往往需要预约很久才能拿到，所以就会有很多人选择自己买书，然而往往看完之后又会搁置，不仅增大了个人的开销，又会造成图书资源的浪费。
学生的教科书一般只需要使用一次，大部分人的教科书会在自己使用完之后搁置几年，然后在毕业的时候将教科书贱卖，这样又会造成图书资源的浪费。
本系统的目的在于建立一个平台，使得学生能够将不再使用的图书漂流起来或者捐赠出去，实现资源共享。使知识能够低成本的在同学之间传递，把闲散的书籍收集起来，构建一个知识全面的共享资源库，使书籍充分体现它的价值。 用户还可以交流读书体会，以书会友，在此可以找到志趣相投的朋友。 分享电子资源，用户可以分享稀缺的电子资源。 书籍推荐，有两部分，其一为用户向别人推荐书籍，其二为系统根据用户评价、热门以及读书爱好来为用户做出书籍推荐。 二手书籍出售，出售闲置书籍，减少浪费。
2. 功能概述:
本系统会为每个用户建立唯一的身份，为每本书籍建立唯一的图书ID，并会为每个用户建立读书历史信息记录，为及每本书籍建立漂流足迹。还会根据读书分享、用户评价等信息为用户建立评价体系。
本系统由以下几个模块组成：图书漂流，读书分享，电子资源分享，二手交易，个人。
- 图书漂流：
- 求漂区：用户可以在此区域发布求漂书籍信息。
- 放漂区：用户在此区域发布将要放漂的书籍信息。
- 推荐区：根据用户间评分高的读书分享，在此为用户推荐对应书籍。
- 热门区：热门的求漂书籍，在此可以发现最新的读书潮流。
- 公共书架：此处的书籍为用户捐赠的不再保留所有权的书籍。
- 读书分享:
- 用户可以在此分享自己的读书笔记，并为书籍做推荐
- 电子资源分享：
- 如果某些书籍很难买到实体书籍，但是大家又有阅读需求，那么有电子资源的用户就可以在此模块下分享电子资源。
- 二手书籍交易：
- 用户可以在本模块下出售自己的书籍，本模块比较适合于教科书等书籍的交流。
- 个人：
- 此模块下包括用户注册，个人信息，个人书架（外漂书籍），读者足迹（读过别人的书籍），个人读书分享，个人推荐书籍等。
3. 需求变更:
- 系统中所的读者分享要显示在书籍的详细信息页面下，并且能够对该分享评分（星级）；
考察面向对象中类的组织，之前的版本中只需要能够实现读者分享，可以仅仅是一段文本信息，而现在要实现对分享的评分（星级），就需要将读者分享抽象为一个独立的类才能够实现变更
- 读书分享要当做一个大的模块来实现；在此模块下要显示系统中所有书籍的读者分享，可以根据最新或者（1）中对该分享的评分做排序。
考察同类不同实体间的相互关系，需要能够处理好同类不同实体间的关系，才能实现对分享的排序。
题目 6 志愿树系统
1. 项目背景和目标:
志愿树的使命，是连接人与志愿活动，重构互联网志愿服务场景。
志愿树要用移动互联网的方式，推动志愿者事业以更低的传播成本、更高的效率、更科学的方式向前发展。志愿树致力于做“互联网+志愿服务”的行业标准，坚持以用户为核心的战略，对志愿服务的各个环节逐个击破，致力于为用户和志愿服务团体提供完整的志愿服务体验。
一方面，志愿树要为志愿者提供海量的志愿服务信息，方便志愿者筛选与自己相关的志愿活动，并且一键报名参与，免除从前问卷、短信、邮件报名的困扰；另一方面，志愿树要为志愿活动组织方提供最优质的志愿者资源，方便他们的管理。
同时，志愿树要革新志愿服务的概念，不再局限于传统的志愿服务方式，而是应该以人人参与的方式，让每个人都成为志愿活动的发起者和响应者，让身边的每一件小事都成为爱的源头，让帮助他人蔚然成风。个人发起的活动与组织发出的活动有不同：个人发起的活动多是一种倡导，例如光盘行动、冰桶挑战、上传街边小摊贩的美食照片，帮助他们招揽生意等，其他用户不需要通过传统的报名、审核等流程，就可以通过点赞、转发等方式表示支持。志愿树要让每个人都成为志愿者，在生活的每个场景中共同探索发现志愿活动的契合点，营造国内的志愿服务氛围。
2. 功能概述:
志愿者 :
- 注册 志愿者在注册是需要提供的信息包括： 必填：姓名、性别、学校、专业、学校、电话、邮箱、用户名、密码 选填：微信、英语能力、关注领域、特长、爱好
- 登录 用户可以选择使用用户名/密码登录，也可以选择关联微信账号登录（微信账号关联登录功能可以视作业要求的系统难度决定是否做，也可以作为课程实践的加分项）。
- 查看活动 查看正在招募中的活动列表，选择自己喜欢的活动报名。
- 报名活动 向活动组织方提交报名申请。报名的过程中，可能需要填写活动组织方要求的，除了基本信息之外的其他信息（例如参加活动的理由等）。
- 查看活动状态 活动的状态分为报名中/待参加/审核未通过/已完成4种，志愿者可以查看自己报名过的活动的状态。
- 发布活动 用户填写活动的主题、内容、时间要求，上传照片，号召其他人一起进行一次以身边场景为基础的志愿活动。此类活动不需要招募志愿者，其他用户通过点赞、转发、留言、传照片表示支持。
- 点赞 为支持的志愿活动点赞
- 转发 获得该活动的链接，转发到微信、微博等社交平台。
- 评论 通过上传照片、文字描述两种方式进行活动的评价。
- 导出个人志愿服务简历（可选做） 导出志愿服务简历，包含志愿者参与活动的记录，以及每次活动志愿组织给志愿者的评价等信息。可以保存或分享简历。 【说明】此功能的实现方式由易到难有几种，同学们可以选择零种或几种完成，对应不同的评价结果： a) 生成简历链接。生成一个包含身份关键字参数（如用户名）的链接，网页上有用户参加活动的文字记录，用户可以复制此链接，在浏览器中打开，或者与朋友分享； b) 生成简历PDF文件。将生成的简历导出为PDF文件，可以保存到本地或者发送到用户邮箱； c) 分享给微信好友或者分享到朋友圈。
志愿组织管理者
- 注册 组织注册是需要提供的信息包含：用户名、密码、组织名称、负责人姓名、负责人电话、负责人邮箱、组织介绍、关注领域、成立时间.组织完成注册之后，并不能马上开始使用网站，需要等待管理员审核通过
- 登录 组织用户通过用户名、密码登录
- 发布活动P 组织发布活动时需要提供的信息包含： 活动名称、活动时间、报名截止时间、活动城市、活动所在区、活动地点、活动详情、选择活动类别、是否提供证书（是或否）、是否提供礼品（是或否）、志愿时长 可供选择的活动类别为：赛会服务、应急救援、城市救援、文化教育、关爱服务、社区服务、绿色环保、医疗卫生、在线志愿服务、京外服务、国际服务、其他
- 编辑活动信息 组织管理员可以更改活动信息。
- 查看报名志愿者基本信息及活动记录 查看报名某次活动的志愿者资料，决定是否录取该志愿者。
- 接受/拒绝志愿者 接受/拒绝志愿者，让志愿者可以查看结果（选做：短信或邮件通知志愿者报名结果）。
- 评价志愿者 组织管理员可以对参与活动的志愿者进行评价。本功能包含： 1-5星评价 文字评价（可不填） 一键评价（可选做）
系统管理员
- 登录 系统管理员登录帐号
- 审批组织 查看申请中的组织，审批通过/不通过
- 审批活动 查看申请中的活动，审批通过/不通过
- 删除活动 删除某次活动，并删除相关的报名记录
系统要求： 以网页的形式的呈现，可以选择做PC版、移动版或者适配PC和移动的版本。由于甲方独特的喜好，要求页面的主色调必须是绿色。
3. 需求变更:
需求更改方案一： - 评价修改
原来的系统中，只要求用户可以使用文字对活动进行评价，需要修改成用户可以从活动的真实性、活动收获度、志愿者福利三个方面对活动进行1-5星的评分，同时还要保留活动文字评价的功能。
考察点：考察面向对象的组合思想。由于之前的评价仅仅是一句话，所以在进行面向对象设计的时候，很有可能是直接放在评价类里面的一个属性。这样设计的可扩展性就有限制，需要把当时的属性变成一个类，然后再进行组合。
- 权限修改
说明：原来的系统中，发布的活动直接就可以被所有人看到，但是这样存在一定的问题，很有可能很多人会发布与志愿服务无关的活动，导致系统生态的混乱。因此需要增加系统管理者，对活动进行审查和审批。
考察点：这是甲方在实际工作中非常有可能提出的一种修改。前期因为经费预算不足、或者需求考虑不周等情况，没有提出系统管理员的需求，在项目实施到一半需要为系统增加一个角色。乙方应考虑增加的角色与系统原有角色的关系，可以考虑设计一个用户的接口，然后志愿者和系统管理者分别实现这个接口；或设计一个用户的类，志愿者和系统管理者分别继承这个类。此外需要为活动类添加一些属性，并修改原有活动类和志愿者类的交互、加入活动类和系统管理者类的交互等，是一个较为复杂的改动。
需求更改方案二： - 功能增加：志愿者发布活动。
说明：之前的活动只是组织者可以发布，需要改成志愿者也可以发布的。志愿者发布的活动和组织者发布的活动有所不同，大家只是通过加入、点赞和声援在网上进行这样的活动，志愿者无权看到加入者的个人信息。
考察点：考察活动设计的可扩展性。志愿者发布的活动与组织发布的活动多数功能相同，只有一个功能不同，因此，程序员应该会选择在原来的类上进行改动，而不是新建一个类重复所有的
作业展示
下载密码为：oo
| # | 各组作业下载链接 |
|---|---|
| 1 | 麦得劳汉堡套餐系统 |
| 2 | 餐厅点餐系统 |
| 3 | 互助平台 |
| 4 | 麻将游戏 |
| 5 | 校园图书漂流系统 |
| 6 | 志愿树系统 |