系统目标
给用户提供一个展现自我的空间
高
中
2
预算
成本控制在3万元以下
中
中
3
功能性需求
管理内容
通过后台管理系统进行文章、留言、图片、链接的管理
中
中
4
阅读内容
阅读文章、评论、留言,查看图片,访问链接
中
中
5
非功能性需求
平台限制
基于Windows2003Server
中
低
6
操作方式
浏览器
中
低
2.2业务流程分析
本系统是将现代化的计算机技术与博客服务技术相结合,按照博客技术的服务流程设计完成的。为了使系统在实际运行中发挥更大的作用,实现工作过程的计算机化,提高工作效率和工作质量,现提出如下系统开发目标:
其工作流程为:系统启动并调用默认的博客模版类型,所有用户浏览博客主页面,之后的操作通过权限判断。普通用户只能浏览、评论和查询博客信息。管理员分为系统管理员和博客管理员,前者可以对系统管理的所有功能进行操作,后者只有对博客进行写入、修改和删除的权限,并且其权限也受到系统管理员的限制,他只能在自己的权限范围内进行对博客的管理操作。
具体目标如下:
(1)操作简单、界面友好:完全控件式的页面布局,使得用户写博客的工作更简便;许多选项包括博客类别、作者等只需要点击鼠标就可以完成;另外,跟踪出现的提示信息也让用户随时清楚自己的操作情况。
(2)即时可见:对博客的处理(包括写入、修改、删除)将立即在主页的对应栏目显示出来,达到"即时发布、即时见效"的功能。
(3)功能完善:不仅包括常见网站的博客功能的各个方面:写日志、浏览、删除、修改、检索等各个方面,而且,还能进行对会员的管理,对用户推荐的博客进行审核,以及上传文件的管理。同时,为了能有效方面的更新系统的界面,系统还增加了调用博客界面模版的功能。
(4)动态管理:对系统数据库实行动态操作,能实现对数据库信息的动态查询、动态更新修改和动态录入数据。
2.3系统数据流图
本系统主要完成博客的浏览与管理的功能,因此,在逻辑上可以将系统分为博客浏览系统和博客管理系统两部分,同时,系统的所有数据都需通过一个数据库系统来实现查询、更新和输入,所以在总体上可将总系统分为博客浏览系统、博客管理系统和数据库系统三个系统,对本系统操作的数据源有普通浏览者、博客用户和管理员三种。
根据上述对新系统的初步分析和开发目标的分析,初步分析了一套博客系统的总体流图,如下图所示:
由于系统数据较多现举出用户登陆数据流如下:
2.4系统功能需求分析
2.4.1功能划分
根据上一节的流程图,把系统划分成两个大的模块来完成:前台模块和后台管理模块。模块划分如表所示。
序号
功能模块类别
功能模块
备注
1
前台模块
阅读日志功能块
博客列表功能块
注册功能块
登陆功能块
公共模块
2
博客管理模块
用户模板管理功能块
博客管理功能快
3
系统管理模块
用户管理功能块
系统模板管理功能块
公告管理功能块
系统参数设置功能块
数据库管理功能块
2.4.2功能描述
上面两节把建立一个博客系统的流程图和功能模块的划分进行了介绍,下面将各个功能模块的功能做详细的描述,即对上述的模块功能进行设计与细化,以便我们下一步的开发。系统功能的详细描述如下:
前台功能列表
序号
功能列表
功能明细
1
首页
最新日志列表
热门日志列表
日志分类列表
2
阅读日志功能块
全部日志列表
日志内容页
日志评论功能(发表评论)
3
博客列表功能块
全部博客列表
博客内容页
4
注册功能块
用户注册页
5
登陆功能块
验证用户权限
6
公共模块
日志和博客关键字搜索
列出博客、日志、评论的总数
博客排行榜
博客管理功能列表
序号
功能列表
功能明细
1
写博客
写日志,管理日志
管理评论
专题分类管理
修改公告
修改个人博客信息
2
模板管理
添加、删除和修改用户模板
系统管理功能列表
1
系统模板管理
添加、删除和修改系统模板
2
管理用户
修改用户信息和密码
添加和删除用户
3
系统参数设置
设置系统的一些名称和数据
4
数据库管理
数据库的备份和还原
有了这些功能明细后,我们就把整个系统的框架确定下来了,也就确定了系统数据的基本结构。
2.5系统功能需求分析
2.5.1创建用例图
系统管理员,参与了管理博客账号、登陆、修改密码3个用例。
博客使用者,参与了登陆、修改密码、管理文章、管理连接、管理图片5个用例。
博客访问者,参与了阅读博客、发表评论2个用例。
博客系统参与者:
博客系统用例:
2.5.2详细描述用例
用例图是系统的高层试图,仅仅是用例图还不能支撑项目组进行设计工作,对于每一个用例,都需要确定用户如何使用这个系统,我们以用户的角度进行事件流设计,描述用例提供的价值和工作流程。我们按照主流博客网的模板进行设计。
◆名称:表明用户的意图或用例的用途。
◆标识符:惟一表识,如UC1234,在项目的其他元素中可以用来引用这个用例。
◆描述:概述用例的几句话。
◆参与者:与此用例相关的参与者列表。
◆状态:指示用例的状态。
◆频率:参与者访问次用例的频率。
◆前置条件:一个条件列表,如果其中包含条件。则这些条件必须在访问用例之前得到满足。
◆后置条件:一个条件列表,如果其中包含条件。则这些条件必须在用例成功完成以后得到满足。
◆被扩展的用例:此用例所扩展的用例。
◆被包含的用例:此用例所包含用例的列表。
◆假设:对编写此用例时所创建的域的任何重要假设。
◆基本操作流程:参与者在用例中所遵循的主逻辑路径。
◆可选操作流程:用例中很少用到的逻辑路径,那些在变更工作方式、出现异常或发生错误的情况下所遵循的路径。
◆修改历史记录:关于用例的修改时间、原因和修改人的详细信息。
◆问题:如果存在,则为与此用例的开发相关的问题或操作项目的列表。
◆决策:关键决策的列表,这些决策通常由你的SME做出,并属于用例的内容。
用户登陆用例
用例名称
用户登陆
用例ID
UC-12
参与者
用户、管理员
描述
用户登陆系统过程
风险
低
优先级
高
难度
低
启动
主动进入用户登陆画面或会话超时转入用户登陆画面
前置条件
用户需在登陆状态
后置条件
将用户信息放入会话中
将用户相关的博客信息放入会话中
显示博客阅读主画面
主事件流
用户
系统
1.进入或转入用户登陆画面
2.用户输入用户名和密码
3.系统检查用户名和密码是否合法
4.系统检查用户名是否存在,密码是否正确
5.读取用户的基本信息、博客的基本信息放入会话中
6.转到管理博客的主画面
异常流
异常流
系统中不存在该用户或用户名错误
系统
转入登陆画面
异常
用户不存在或密码错误
修改密码用例
用例名称
修改密码
用例ID
UC-15
参与者
用户、管理员
描述
用户、管理员进行密码修改
风险
低
优先级
高
难度
低
启动
单击"用户修改密码"
主事件流
用户
系统
1.进入用户修改密码,输入旧密码一次,新密码两次
2.检查密码格式是否相符
3.检查旧密码是否正确
4.如果正确就进行密码修改,转入密码修改成功画面
异常流
异常流
密码检查不通过
系统
返回
上一篇:
asp医药连锁店管理系统ASP+源代码+可执行程序+论文(论文和程序)
下一篇:
试析影响公路路面平整度的因素及应采取的施工措施