系统分析与设计课程报告-----------------社团管理系统

一、业务概括

1.1社团性质

青年志愿者协会在学院党委的领导及团委的直接指导下，由学生自发组织，全校师生自愿参加的，志愿服务于广大师生，奉献爱心于社会的，倡导积极主流文化的群众性服务性团体。

1.2部门简述

（一）主席团

作为青年志愿者协会的领导核心，全面主持校青志的各项工作；负责校青志总体规划、协调与事务决议，代表校青志和党、团委进行沟通和联系等。

（二）策划部

负责各种志愿活动的策划、草拟协会有关文件、积极探讨、寻找新的志愿活动方案, 是校青协志愿活动的质保部门和志愿活动创新研发部门。

（三）外联部

其职能是对内联系各院青协以及其他组织，就彼此间的工作进行交流及深入学习。给各组织之间的学习及沟通创造良好的机会；对外作为与外校沟通与交流的纽带，为组织的探索与进步提供便利的信息条件。

（四）宣传部

负责校青协组织开办活动时的各项宣传工作。宣扬校青协组织活动的目的和意义，树立良好的青年志愿者形象，传达“奉献、友爱、互助、进步”的志愿者精神，吸引更多的师生加入到志愿者行列。

（五）服务部

服务部负责立足实践，日常志愿活动都由服务部的人员去进行开展。包括从志愿者学院中招募志愿者、为各个志愿者安排工作等。

（六）志愿者学院

志愿者学院是服务部是一个下属机构、其主要的性质就是一个志愿者库，每次活动的发布都会在志愿者学院里面进行招募。

1.3岗位设置

协会设置会长一名、副会长两名、各部门分别由一名部长和一名副部长以及若干个小干组成。

二、组织结构

由校党委和院团委领导主席团成员、主席团成员领导各个部门，其中志愿者学院归由服务部直接领导。

三、业务目标

该系统可以对社团工作进行快速、高效的管理、无论是指导老师、主席团成员，或者是部长，甚至是普通志愿者、学生都可登录系统，每一种角色都对应着不同的功能模块，所有志愿活动的发布、报名、审核等都可以在该系统中进行、同时对于机构内部的人员变动、新闻公告、在线交流等都能基于系统实现、完全取代了传统的线下人工管理模式。

四、涉众分析

4.1涉众概要

4.2涉众简档

4.3用户概要

4.4 用户简档

4.5 涉众评估

五、业务建模

5.1业务边界

注册业务的边界

系统管理业务边界

5.2获取业务用例

（1）普通学生用例关系

（2）教师用例关系

（3）志愿者学院成员用例关系

（4）社团负责人用例关系

(5)管理员用例关系

5.3 业务用例场景
（1）注册业务用例场景
用户通过用户端进入系统、未注册账户通过点击注册功能进入注册界面，需要填写基本资料，包括用户名、密码、邮箱、电话等信息。提交后后台会先验证用户名是否已经存在、如存在就返回“用户名已存在”的报错信息、存在就验证密码是否符合安全规范、满足就返回“注册成功”，不满足就返回“密码安全性不足”。

（2）登录业务用例场景
用户通过用户端进入系统、通过输入账号和密码提交后后台会先验证用户名是否已经存在、如存在就返回“用户名不存在”的报错信息、存在就验证密码是否符正确、正确就登进系统、不正确就返回“密码错误”。

（3）教师认证业务用例场景
教师进入系统后进行注册、注册流程和普通学生一致、注册成功后登录系统，选择教师认证、填写教师认证表、同时需要上传相关证明文件、由社团负责人在后台进行审核然后返回审核结果。

（4）申请加入志愿者学院业务用例场景
普通学生通过注册后登录系统、选择申请加入志愿者学院后填写申请表，等待社团负责人审批后通知线下面试、如面试通过则会通知已被录取，在平台上即可报名活动。

（5）活动报名业务用例场景
用户登录系统后，在活动列表中查看到合适的志愿活动即可点击填写报名表、填写完相关信息后提交、由社团负责人用过后台审核报名、报名成功则通过短信通知。

（6）新建活动业务用例场景图
社团负责人登录系统后、进入到活动管理界面、选择新建活动、填写完活动的相关信息后选择提交、指导老师通过管理员账号登录后即可对活动进行审批、审批完结果发回社团负责人、如通过审批即即可发布活动。

六、领域建模

6.1建立领域建模

（1）用户档案领域对象
用户档案主要分为三部分、一部分是在注册时候填写的基本资料，包括账号、密码、邮箱、学号等；第二部分是来自申请加入志愿者学院时面试的简历、包括电话号码、活动经历、兴趣爱好等。第三部分来自报名活动时填写的资料、包括身份证号（购买保险）、住址等。

（2）活动档案领域对象
活动档案主要分为两个部分，第一部分是社团负责人在申请活动的时候填写的活动详细信息、包括活动目的、时间、地点、简介等，是活动档案的核心内容。第二部分是活动的报名情况、主要记录已报名该活动的用户。

6.1领域模型场景

（1）用户档案领域模型场景
a．将用户档案领域对象代入用户注册业务用例场景

b．将用户档案领域对象代入申请志愿者学院成员用例场景

（2）活动档案领域模型场景
a．将活动档案领域对象代入活动申请用例场景

b．将活动档案领域对象代入活动报名领域用例场景

七、业务规则

7.1 全局规则

7.2 交互规则

7.3内禀规则

八、概念建模

8.1获取概念用例

基于系统的业务用例较为繁杂，找出系统最核心的业务是认证身份、报名参加活动。这就是撑起系统的业务主线，几乎所有的业务用例都围绕这条主线展开、于是找出了关键业务用例。

有了核心的关键业务用例之后，根据其绘制出它们的概念用例图：
（1） 申请加入志愿者学院概念用例图

（2） 教师认证概念用例图

（3） 参与活动概念用例图

8.2分析概念用例

当概念用例被确定后以后，需要对概念用例进行分析，在这里通过绘制概念用例的场景图（活动图）来分析概念用例。
（1） 申请加入志愿者学院概念用例场景图

（2） 教师认证概念用例场景图

（3） 参与活动概念用例场景图

8.3建立概念模型

概念模型从抽象的系统对象视角来解释业务主线如何在计算机中运行，通过以上获取的概念用例对象、建立以下概念模型：
（1） 创建志愿者学院申请表

（2） 创建活动报名表

（3） 创建教师认证表

（4） 社团负责人审核

九、系统建模

9.1明确系统用户

本系统是面向本校全体师生的志愿者活动平台，主要的用户是校内学生、教师、经过注册和认证后加入志愿者学院，即可参与各种志愿活动。系统的管理者主要包括社团负责人和指导老师。

9.2活动内部系统用例

9.3活动外部系统用例

9.4软件架构和框架

软件架构是一种思想、一个系统蓝图，是对软件结构组成的规划和职责设定。在本系统设计中决定使用包图来描述软件架构，同时给出了交互图。对于系统的框架使用，使用Spring 、SpringMVC、Mybatis，基于MVC设计模式进行架构


9.5 系统分析模型
建立分析、要将系统主要用例的分析类与软件架构结合起来。首先要确定这些类在软件架构的哪个层次中，所以先逐个分析这些分析类所在的层次，以及当软件架构引入以后分析模型的变化情况。
（1） 各类申请分析类图

（2）各类申请WEB层分析模型

（3）各类申请Controller层分析模型

（4）各类申请service层分析模型

（5）各类申请dao层分析模型

十、系统设计

10.1 系统设计

系统的web层使用jsp构建用户交互界面，使用标签设计申请表单，使用JavaScript的ajax来负责表单的提交。

Controller层执行前，由于系统后端使用SpringMVC进行架构、会先执行以下操作：前台请求被DispatcherServlet捕获，然后调用HandlerMapping，进而执行HandlerAdapter。

dao层使用了MyBatis框架实现，设计模型如下：

10.2包/接口设计

（1）包设计
对于软件层次包、在系统设计分析阶段已经针对软件架构及框架完成了设计、在系统设计就只剩下微调工作，设计代码包。

（二）接口设计
系统采用Spring框架，在service层设置各种业务处理接口，规范方法参数,返回值,另外可以实现多态,结合Spring来说接口对于使用Spring的各种功能也是不可或缺的。dao层使用Mybatis框架、需要设计接口来映射mapper映射文件。

10.3数据库设计

数据库设计了五张表来实现系统数据的存储、分别是admin表、user表、activity表、activity_user表、role表，其中，admin表用来存储管理员账号信息、user表是储存用户档案信息、其中的role字段是外键、其含义是标识用户为何种角色、有普通学生角色、志愿者学院成员角色、教师角色，角色的对应信息都保存在role表中。activity_user表用来保存活动报名情况的，活动和用户是多对多关系，一个用户可报名多个活动（时间不冲突），一个活动由多个用户参与。