8000114209欧阳天雄UML课设报告.docx
- 文档编号:6849057
- 上传时间:2023-05-10
- 格式:DOCX
- 页数:19
- 大小:196.34KB
8000114209欧阳天雄UML课设报告.docx
《8000114209欧阳天雄UML课设报告.docx》由会员分享,可在线阅读,更多相关《8000114209欧阳天雄UML课设报告.docx(19页珍藏版)》请在冰点文库上搜索。
8000114209欧阳天雄UML课设报告
南昌大学
课程设计报告
课程名称UML分析与设计
课题名称外卖订餐系统的设计
专业软件工程
班级软件工程147班
学号8000114209
姓名欧阳天雄
2016年5月25日
UML
课程设计任务书
课程名称面向对象分析与UML课程设计
课题外卖订餐系统的设计
专业班级软件工程147班
学生姓名叶蒙
学号8000114206
小组成员叶蒙,欧阳天雄,雷轩,
宋佳雷,冯晨耀
一、设计内容与设计要求
1.设计内容:
面向对象系统分析与设计课程是计算机科学与技术本科专业(软件方向)的一门重要的专业课。
通过本课程的学习,使学生在已有的计算机软硬件基础知识、程序设计知识、数据库和网络通信知识的基础上系统掌握面向对象系统分析与设计的基本方法和技术,并具有针对特定环境下的应用问题进行信息系统开发(包括系统分析、设计与实现)的能力。
通过学习本课程学生可以理解和掌握面向对象系统的分析和设计的方法和分步过程、掌握面向对象系统分析和设计的建模标准UML语言,能够利用RationalRose(或MicrosoftViso、StartUML)软件以某一信息系统为例进行系统分析和设计。
目前,大家在学习阶段缺乏工作方面的实践,对很多领域的业务不熟悉。
但是熟悉业务是软件开发的基础,没有人生来就什么都熟悉。
于是,拟订了如下几个题目,它接近大家的学习和生活环境,以便大家去熟悉其中的业务。
希望大家分组完成,选出本组的组长,作好分工与合作。
每组一题,各组题目不能相同;同组成员的负责的模块(子系统)不能相同。
题目1:
高校图书馆管理系统
题目2:
高校教务管理系统
题目3:
高校学生信息系统
题目4:
高校后勤管理系统
题目5:
高校学生工作管理系统
题目6:
高校教学管理系统
题目7:
人事考勤管理系统
题目8:
高校教材管理系统
题目9:
高校科研管理系统
题目10:
高校宿舍管理系统
题目11:
高校实验室管理系统
题目12:
学生成绩管理系统
或自选题目
2.设计要求:
(1)用例建模
完成对系统的需求建模,得到用例模型后,应针对每个用例进行业务分析,说明其具体的业务流程,对其中主要功能的用例书写书面用例。
对每个用例的进一步描述可以活动图,这一部分在动态建模来完成。
(2)静态建模
系统的静态结构模型主要由类图和对象图表达。
对于复杂的系统可能还要用到包图。
其中类图是静态建模的核心。
(3)动态建模
系统的动态结构模型主要由交互图(顺序图和协同图)、状态机图和活动图表达。
在系统的分析和设计中应当对主要的UseCase和对象类绘制这些图形。
(4)物理建模
系统的组件图和部署图
(5)小结
对本课程设计进行总结。
目录
一.需求分析…………………………………………………6
二.用例建模…………………………………………………7
三.静态结构建模……………………………………………11
四.动态行为建模……………………………………………10
五.物理模型…………………………………………………14
六.课程设计心得与体会……………………………………15
一.需求分析
现在,越来越多的人通过网络购物和支付,这已经不是一件新鲜事了。
现在,就连一日三餐,很多人都更愿意通过网络解决。
因为人们有时不愿意或没有时间出门就餐,这时候,人们会考虑外卖订餐,这种方式避免了外出用餐的麻烦,而且方便快捷。
所以,外卖订餐时下成为了一种非常受欢迎的用餐方式。
而我们这里就为一个餐饮店设计了一款外卖订餐软件,此软件在移动终端上运行。
一、业务建模
网上外卖订餐系统的业务建模是对其环境的业务过程进行建模。
它能使系统分析人员了解系统所处的环境和业务过程,能使系统分析人员、设计人员、开发人员和用户能够迅速获得关于业务范围和活动的总体印象,一般通过业务过程图来描述。
网上外卖订餐系统的业务过程如下;
二.需求模型
顾客为了订餐,需要完成一个简单的流程,我从这一流程中提取出用户的功能性需求和系统管理员的功能性需求:
1.用户需求:
需求
备注
注册
顾客需要注册才能获得一个唯一的用户名。
信息管理
顾客需要输入自己的详细信息以完成订餐
登录
顾客需要以用户的身份登录才能使用后续功能
浏览菜单
顾客需要在菜单界面里浏览挑选喜欢的菜
订单
顾客需要能挑选自己喜欢食物并生成订单
订单管理
顾客需要能查看和管理自己的订单
支付
顾客需要能以方便安全的线上支付方式支付
送餐
顾客需要该软件能及时地将订单实现,并送至顾客所在地
其他服务
顾客需要该软件支持反馈,投诉,更新软件版本等功能
2.系统管理员需求:
需求
备注
商户管理
系统管理员可以进行商户管理。
客户管理
系统管理员可以进行客户管理
系统维护
系统管理员可以进行系统数据备份、恢复等维护工作。
系统登录
系统管理员可以通过这个用例登录
除了功能性需求外,非功能性需求也同样重要:
1.可用性:
系统必须界面友好,能让用户很快地掌握如何使用,不能让顾客茫然不知如何应用该系统。
2.可靠性:
系统必须能在出错后尽快地恢复到正常状态,这要求系统具有很强的自我调整机制。
3.安全性:
系统在涉及到用户信息,支付等敏感操作时必须保证用户信息的安全,不能让用户的信息和财产安全受到威胁。
二.用例建模
在本软件中,系统的用例可以细化为多个,参与者也有多个:
1.参与者:
参与者
备注
用户
即顾客,使用该软件的都可称为用户
控制端
包括系统管理员、店员和主机控制系统
支付端
线上支付端(网银或其他),具体操作流程不在本软件的建模范围内
2.用例:
用例
备注
用户注册
这一部分让顾客注册一个用户名
用户登录
这一部分让顾客以已注册的用户名登录
输入用户信息
这一部分让顾客完善信息以正确订餐
储存用户信息
系统将用户信息存入数据库
选择订餐
顾客浏览菜单并选择食物,提交给系统
生成订单
系统生成一个相应的订单
支付订单
系统连接支付端,用户在支付端支付
送餐
在顾客支付后,系统通知店员做好并送出食物,完成订单
更多服务
顾客在这一用例中可以更新软件,反馈,投诉等。
系统管理员在这一用例中进行系统维护
由此,可画出系统顶层的用例图如下:
图1:
顶层用例图
在这里,我们小组将用例合并概括为五个模块:
序号
用例
1
用户注册/登录
2
订单管理
3
资金管理
4
物流管理
5
系统维护
我分析的是系统维护子系统。
将会对系统维护这个用例进行细化。
系统维护这个用例大致可分为:
系统登录,商户管理,客户(订餐者)管理,系统维护。
用例图如下:
即便是这样,可以看出有些用例实际上还是可以继续细化的。
下面将选二个用例--系统登录,系统维护进行细化:
一、登录用例细化
用例名称:
管理员登录
管理员在浏览器地址栏输入系统的URL(网址),该用例启动。
1基本流
1.进入登录页面
如果管理员没有通过身份验证,则在浏览器地址栏内访问任何一个页面的URL都自动进入登录页面。
2.输入用户名和密码
系统提示以管理员身份登录必须勾选,用户名和密码必须输入。
用户名符合数据结构要求,密码符合密码长度以及复杂度等要求。
3.登录成功,进入系统消息页面
在系统消息页面可以查看客户给商家的反馈,投诉信息,以及系统检测到的恶意投诉,虚假投诉客户方便进行客户管理。
4.进入菜单页面。
在菜单页面,管理员可进行反馈投诉给商户,用户管理,商户管理,以及推送更新等系统操作
2备选流
A2.用户或密码错误
在基本流的步骤3中,用户输入的用户名或者密码错误,提示用户重新输入。
然后继续执行基本流的步骤3。
三次输入用户名和密码无效后,该管理员帐号被锁定,需要去后台解锁,用例结束。
A3.退出系统
无条件关闭浏览器。
用例结束。
3用例场景
1成功场景
登录成功:
基本流
取消操作:
备选流,退出系统。
2失败场景
没有输入用户和密码:
备选流,用户和密码输入。
输入用户或密码错误:
备选流,用户或密码错误。
4用例要求
1.不显示上次登录的用户名。
2.在超过会话状态时强制注销。
3.密码满足密码复杂性要求。
4.用户名必须是合法的字符和数字,不能包含特殊的符号,如:
?
、!
、-、~等。
在用例规约的基础上,画出对应的用例图如下:
图2管理员登录用例图
二、系统维护用例细化
1、基本流
1、系统管理员登录
2、输入用户名和密码进行身份验证
3、系统将验证结果显示并返回给管理员
4、管理员进入系统维护界面开始对系统进行维护
5、提交维护操作
6、系统将提交结果返回
7、提交成功,退出系统
2、备选流
A1:
在基本流步骤3中,若是用户名,密码输入错误可以重新输入,若是超过三次未成功应该锁定该用户名。
A2:
在基本流5中出现维护异常中断的情况,要能保存任务进度,以便管理员处理好异常继续恢复。
A3:
在基本流6中若是维护操作失败,要能恢复系统维护前的状态,不能让系统出于瘫痪的状态
A4:
无条件推出系统维护
3、用例场景
成功场景
1、更新成功:
基本流
2、取消操作备选流退出更新
3、任务异常暂停备选流保存进度,继续更新
失败场景
1、维护失败备选流发送更新指令给服务器
4、用例要求
1、更新版本需选择深夜等客户不使用系统的时间段。
2、更新的版本必须兼容旧的版本,不能影响用户体验
5前置条件
1、管理员成功登录了系统
2、系统成功布置到了远程服务器
3、有可发布的版本
6、后置条件
1、用户可以使用更优化,体验度更高的新版本
(特别标注:
在系统维护用例中的更新系统是系统维护的一个具体事例,并不是一个不同的用例,我用它来表示一个特定的系统维护事例)
在用例规约的基础上画出的系统维护用例图如下:
三.静态建模结构
类图(Classdiagram)是显示了模型的静态结构,特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。
类图不显示暂时性信息。
在管理员登录这一过程中,包含多个类,分别为:
登录界面(LoginInterface),管理员(Manager).其中,每个类具有多个属性,列表如下:
类
属性
管理员
用户名(name),性别(sex),密码(password),电话号码(phone),
权限(authority)
管理员地址
区(district),街道(street),门牌号(doorNum),楼层(floor)
登录界面
用户名(name),密码(password),类别(type)
整理完每个类的属性后,可以画出类图如下:
图3管理员登录类图
在管理员系统维护这一过程中包含有几个类,分别是:
维护界面(updateinterface),管理员(Manager)、文件类(File)、用户类(User)
类
属性
用户
用户名(name),性别(sex),密码(password),电话号码(phone),
文件
内容(content)
更新界面
无
系统维护类图
四.动态行为建模
1.时序图
在系统维护用例中可画出用例图如下
图更新系统时序图
2.协同图
图系统维护协作图
3.状态图
在管理员系统维护用例中,可以绘出状态图如下:
图6系统维护状态图
4.活动图
在管理员系统维护用例中,可以绘出活动图如下:
图7更新系统活动图
五.物理建模
1.组件图
在系统更新用例中,可以绘出组件图如下:
图8系统更新组件图
2.部署图
在用户注册/登录用例中,可以绘出组件图如下:
图9用户注册/登录部署图
6.课程设计心得与体会
经过我们小组五个成员的讨论,我们分析出了我们小组的项目--网上订餐系统的业务模型,需求模型,
并且得到了系统顶层用例。
并给每个人分配了一个业务模块的分析设计。
然后经过自己认真的分析,我得出了自己这个子系统的需求分析,确定了系统维护模块的主要参与者以及各自的主要活动,主要是系统管理员的活动。
通过学习UML建模的有关知识和RationalRose工具,我亲自动手练习最终画出了系统部分有代表性的系统用例模型(各自用例的用例图)、系统静态模型(系统类图)、系统的动态模型(系统时序图、活动图以及状态图),以及系统部署模型(系统构建图以及系统部署图)。
通过自己的亲手操作,使我进一步了解并掌握了UML的建模过程和RationalRose工具的使用。
同时,也发现了自己思考问题不全面,对事物一个总体分析的能力欠缺等一些不足,促使自己不断改正、不断进步。
我觉得最重要的莫过于体验到了团队分工与协作完成一个项目的过程,如何去分工,如何去承担自己的任务,如何及早完成自己的任务而不影响团队的进度,如何与队友交流,如何运用团队的能力达到“1+1>2”的效率。
总之很感谢这门课程,老师的耐心解答和同学们的无私帮助。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 8000114209 欧阳 UML 报告