智联招聘系统需求用例建模Word格式.docx

智联招聘系统需求用例建模Word格式.docx

《智联招聘系统需求用例建模Word格式.docx》由会员分享，可在线阅读，更多相关《智联招聘系统需求用例建模Word格式.docx（8页珍藏版）》请在冰豆网上搜索。

用户管理功能模块的关系如图2.2所示。

图2.2用户管理功能模块关系

系统流程分析可分为职位的申请流程和企业用户管理流程

（1）职位的申请流程，如图2.3所示

图2.3用户申请职位流程

（2）企业用户管理流程，如图2.4所示

图2.4企业管理流程图

2.2UML建模

根据网上求职招聘系统的需求分析，使用UML进行系统建模，再用可视化的模型将该系统用直观的图形显示出来，包括用例图、类图、交互图和行为图。

2.2.1用例图

用例在需求分析阶段有很重要的作用，他是作为参与者的外部用户所能观察到的系统模型图，整个开发过程都是围绕需求分析阶段的用例进行的。

首先，根据网上求职招聘系统的功能结构图，确定系统的参与者。

参与者包括三类。

分别是求职者、招聘者、管理员。

其次，根据参与者的职能划分、确定系统的用例。

求职者包括更新个人资料用例、搜索招聘信息用例、发布求职意向用例、下载简历模板用例、投递简历用例、查看个人信箱用例、修改密码用例等。

招聘者用例包括更新企业资料用例、发布招聘信息用例、搜索招聘信息用例，浏览求职简历用例、回复求职简历用例、查看企业信箱用例、修改密码用例等；

管理员用例包括更新个人资料用例、管理用户用例、管理简历用例、管理信息与新闻用例、修改密码用例等最后，得出网上求职招聘系统的总体用例功能，如下图所示

图2.2系统总体功能用例图

用例图建好后，需要编写用例说明描述，用例描述就是对系统各个功能进行描述，这是系统分析的一个重要过程。

准确地描述系统的功能有助于不同用户之间进行有效的沟通。

（1）用户注册系统

新用户要先进行注册，注册通过后才能登录上该系统

（2）用户登录系统

不管是求职者、招聘者还是管理员都是系统的用户，需要验证用户的合法性，判断是否允许进入该体系

（3）用户更新个人资料

此功能用户登录成功后才能使用，用于更新注册时填写的个人信息。

（4）用户修改密码

此功能必须在用户登录成功后才能使用，用于修改用户的密码。

（5）求职者搜索招聘信息

求职者登录系统成功后，根据需要搜索招聘信息，可以用关键字搜索，搜索的招聘信息会显示在前台页面中供求职者浏览。

（6）求职者发布求职意向

求职者在登录成功系统后，根据需求发布求职信息，求职信息会根据求职者的意愿在前台页面中供招聘者浏览。

（7）求职者投递简历

求职者在下载简历模板并填写完成简历后，可以投递简历供招聘者浏览。

（8）求职者查看个人信箱

求职者可以通过个人信箱查看自己是否被用人单位录用，以及其他具体相关信息。

（9）招聘者发布招聘信息

招聘者在登录成功系统后，根据用人单位的需要发布招聘信息，招聘信息会显示在前台页面供求职者浏览。

（10）招聘者搜索应聘信息

招聘者在成功登录系统后，根据用人单位的需求搜索求职信息，可以用关键词搜索，搜索的求职信息会显示在前台页面供求职者浏览。

（11）招聘者浏览求职简历

招聘者可以通过快速浏览求职简历，更精确地找出符合用人单位条件的求职者及用人信息。

（12）招聘者回复求职者

招聘者找到符合条件的求职者时，可以向该求职者发送，如果有多个人入选时，还可以向群体发送E-mail。

（13）招聘者查看企业信箱

招聘者可以通过企业信箱去求职者联系，获取求职者更多的信息。

（14）管理员管理用户

管理员在成功登录系统后，可以对求职者、招聘者的基本信息进行管理。

如果删除某一个求职者或招聘者的基本信息，则其他发布的信息页一并删除。

（15）管理简历

管理员在成功登录系统后，可以对求职者投递的简历进行管理。

（16）管理新闻与信息

管理员在成功登录系统后，可以对求职者、招聘者发布的求职或招聘信息进行管理，同时岁网站的新闻进行管理。

2.2.2类图

类是对现实世界中具有相同属性和行为的一类对象的抽象，他封装了这一类对象所共有的属性和操作。

类图是使用UML建模最常用的图，他显示类、接口以及他们之间的静态结构和关系，通常用来描述系统的静态结构。

类图是系统设计最核心的部分。

在获得系统的用例建模后，根据用例图，通过与用户进一步沟通，识别出所有关键类及类与类之间的关系，用类图对系统的静态结构建模，从系统数据库角度分析类，对部分实体进行分析，得到7个实体类：

用户实体类（UserBean）、求职者实体类（PersonBean）、企业实体类（CompanyBean）、管理员实体类（AdminBean）、求职信息实体类（ApplyInfoBean）、新闻实体（NewsBean）、招聘信息实体类（JobInfoBean）、对于PersonBean、CompanyBean和AdminBean，他们首先都是用户，因此他们与UserBean存在泛化关系。

PersonBean与ApplyInfoBean之间存在发布关联关系，AdminBean与NewsBean之间存在管理关联关系，Company与JobInfoBean之间存在发布关联关系，该系统的部分类图如图2.3所示：

图2.3系统部分类图

2.2.3顺序图

顺序图描述了对象之间传递消息的时间顺序，他用来表示用例中的行为顺序，是强调消息时间的交互图。

用户进入系统之前，首先要用户进行登录，登录时要验证用户名和密码是否匹配，验证后允许用户进入本系统进行操作。

用户的密码需要进行加密算法，且密码保存在数据库中；

用户登录后需要记入到日志库中。

用户登录系统的顺序图向UML用户提供事件流随时间推移的、清晰的可视化轨迹，她描述了用例随时间顺序执行的事件流，如图2.4所示

图2.4用户登录顺序图

2.2.4活动图

活动图用于展现参与行为的类的活动或动作。

它主要描述方法实现中所完成的工作及用例或对象中的活动；

他的目的是描述动作及对象改变的结果。

活动图中的动作可以放在泳道中，泳道聚合一组活动，并指定负责人和所属组织。

使用活动图描述用户登录活动图如图2.5所示

图2.5用户登录活动图

求职者（Person）和系统（System）两个活动对象分别对应两个泳道Person和System，每个泳道内的活动代表一个对象的所有职责。

首先，求职者在搜索工作时需要输入关键字；

然后，系统获取关键字所包含的关键字工作；

最后系统显示关键字的工作信息，求职者搜索招聘信息活动图如图2.6所示

图2.6求职者搜索招聘信息活动图

使用活动图描述修改密码用例的业务流程；

求职者、招聘者和管理者都有修改密码用例，以求职者修改密码用例为例。

首先求职者在自己的泳道内登录系统，单击修改密码菜单，填写旧密码填写新密码；

然后在自己的泳道内检查旧密码格式，包括旧密码长度、字符等，如果旧密码格式错误则转移到求职者泳道内求职者填写旧密码的活动；

如果旧密码填写正确，则系统继续检查新密码格式，如果新密码格式错误则转移到求职者填写旧密码活动；

如果新密码格式正确则继续验证旧密码，和数据库存储的密码进行比较，修改密码活动结束，修改密码活动图如图2.7所示

图2.7求职者修改密码活动图