社区
研发管理
帖子详情
初学用例,我做的轮渡售票管理系统需求,请大家指教。
mathematician
2006-06-27 04:21:11
初学用例,请大家帮忙看看用例方法是否有问题,多谢了!
需求说明:
http://blog.csdn.net/mathematician/archive/2006/06/27/840891.aspx
...全文
758
17
打赏
收藏
初学用例,我做的轮渡售票管理系统需求,请大家指教。
初学用例,请大家帮忙看看用例方法是否有问题,多谢了! 需求说明: http://blog.csdn.net/mathematician/archive/2006/06/27/840891.aspx
复制链接
扫一扫
分享
转发到动态
举报
写回复
配置赞助广告
用AI写文章
17 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
xiaoliangwh
2006-09-01
打赏
举报
回复
hao !
maseccc
2006-08-22
打赏
举报
回复
mark
mathematician
2006-07-13
打赏
举报
回复
为什么结了帖分数却显示不出来?点【管理】却能看到每个回帖的得分?
mathematician
2006-07-13
打赏
举报
回复
感谢以上网友的讨论,呵呵。
mathematician
2006-07-06
打赏
举报
回复
退票时要查询售票信息。退票用例里有说明:
扩展流
查询售票信息:
用户可以通过执行用例《查询售票信息》,查看可售票信息。
基本流:
1、售票员可选择查询售票信息,了解已售和未售船票状态。
扩展点
《查询售票信息》扩展点定义在基本流步骤2
usrsdh
2006-07-06
打赏
举报
回复
1关于用例描述语言,系统显示查询售票信息界面。应该是主用角选择查询售票,系统初始化售票信息,进行显示。
2看了你用例描述,很明显,不是多用角,因为他们的场景是一样,那就不需要增加备选流,对应的公司领导和财务人员,本来就是用业务人员的角色在执行这个用例,如果是不同的场景才需要抽象出不同的角色,进行描述。
3你这种处理方式,跟前面一样,没有明确用户和角色的关系。这里是售票员这个用户承担了订票员的角色,所以,对业务系统来说,对应的角色应该是订票员,同理,售票这个用例才是售票员做的事。
总结:抽象用例和角色时,先从业务系统出发,再按角色,对场景描述,也就是用例的基本流和备选流。当然,如果不是主用角,也可以不进行描述,在业务规则进行说明则可。
mathematician
2006-07-06
打赏
举报
回复
usrsdh(无恨):谢谢指点。有几个问题请教:
1、“系统显示查询售票信息界面,这不是用例描述语言。”那应该怎么描述呢?我在sawin上看到一个领用资产的用例他一上来就这么说的,所以我照搬了,呵呵,见笑了。
2、“一个用例多个主角时,说明不够清楚。如查询售票信息用例。公司领导,公司财务人员查询售票信息,应该是不同的备选流,不同的场景进行区分。”多主角应该怎么说明呢?我觉得如果改成下面这样,似乎不合适。
查询售票信息用例
基本流
1、系统显示查询航次信息界面。
2、业务人员选择船舶(默认为香雪兰)。
3、业务人员选择查询的航次。
4、系统显示查询航次的信息。
备选流
备选流一:业务人员可以在基本流中的任何一步选择退出,用例结束。
备选流二:公司领导在基本流步骤2中选择查询船舶,步骤3中选择查询的航次,系统显示查询航次的信息。
备选流三:财务人员在基本流步骤2中选择查询船舶,步骤3中选择查询的航次,系统显示查询航次的信息。
3、订票是旅客发起的,不过旅客不会接触本系统。他通过电话、传真、email等方式通知售票员,然后售票员进入系统订票,所以我没有将订票和旅客进行通讯关联。这样的考虑不知当否,请指教。
usrsdh
2006-07-06
打赏
举报
回复
另:include和extend不能用泛化的标记
用例说明,对应的触发事件说明也不正确如,订票的触发事件应该是旅客想要订票。
还有,用例图好象有问题,订票应该是旅客发起的吧,售票员只管售票才正确,如果按你描述的,订票应该是订票员,然后,售票员和订票员才从业务员那里一般化过来。
usrsdh
2006-07-06
打赏
举报
回复
一、用例说明问题较多,对用例来说,系统是透明的,主角应用主动语,如
1、 系统显示查询售票信息界面。
2、 选择船舶(默认为香雪兰)。
1系统显示,这不是用例描述语言。2选择船舶,是谁选择?不清楚。
二、一个用例多个主角时,说明不够清楚。
如查询售票信息用例。公司领导,公司财务人员查询售票信息,应该是不同的备选流,不同的场景进行区分。
三、include和extend关系不明
四、用例太粗,如订票应细分为email订票,电话订票,因为你的目标级别是业务级,而不是实现级。
jiezhi
2006-07-05
打赏
举报
回复
必须售票后才可以退票,应该有联系!是一种先后顺序。只是这个联系应该怎么表达?
-----------
使用前置条件和后置条件,而不是使用关联.用例都有发生的前提条件的.
mathematician
2006-07-05
打赏
举报
回复
上面又一个错误:
查询售票信息”和“售票”、“退票”存在扩展关系,更正。
floatbear
2006-07-05
打赏
举报
回复
--查询售票信息”和“售票”、“退票”存在扩展关系,更正。
似乎从逻辑上说不太通。售票、查询和退票属于一个操作序列的相关操作。为什么是扩展关系呢?查询对退票进行了什么扩展?
floatbear
2006-07-05
打赏
举报
回复
使用前置条件和后置条件表示顺序关系是可以的。不过用例图里面尽量少包含些顺序关系可能比较好。太多的操作细节最好放到系统内部。比如我感觉也许把售票作为一个用例比较好,其中可以使用订票、退票等相关用例。这样可以避免细节都暴露出来。个人意见,对本例不一定合适。
mathematician
2006-07-05
打赏
举报
回复
终于来人了!happy ing...
“售票员”既然已经使用了“订票”,那么为什么还要直接使用“售票”(而订票是对售票的扩展)。
--------
可以先订票再售票,也可以直接进行售票。所以会分别有“订票”和“售票”两个用例。
另外,订票和售票之间好像应该有扩展关系吧?不确定。
“退票”为什么和“售票”没有任何关系?
--------
必须售票后才可以退票,应该有联系!是一种先后顺序。只是这个联系应该怎么表达?
“查询售票信息”用例扩展了太多的相关用例。这种情况应该避免。
-------------------------
“查询售票信息”仅和“售票”存在扩展关系,和“查询航次信息”之间是包含关系,不算太多吧?呵呵!
(2)没看明白,为什么“业务人员”和“售票员”有联系。
-------------------
售票员的所有工作,业务人员都可以做,所以他们之间是泛化关系。
(3)用例图似乎还没画完。
比如“添加航次信息”和其他部分的关系好象没画完吧。
----------------------
添加航次信息以后才可以进行订票、售票等操作,它们之间也存在先后顺序。只是不知道在用例图中应该如何表达这种关系?
mathematician
2006-07-05
打赏
举报
回复
多谢jiezhi(风满袖)提醒!本来看书时感觉挺明白的,怎么写着写着就忘了,呵呵!
floatbear
2006-07-03
打赏
举报
回复
不一定正确,说点个人看法:
(1)用例间的关系有点乱
比如“售票员”既然已经使用了“订票”,那么为什么还要直接使用“售票”(而订票是对售票的扩展)。
再比如“退票”为什么和“售票”没有任何关系?
还有,“查询售票信息”用例扩展了太多的相关用例。这种情况应该避免。
所以个人感觉第一个问题就是用例分解的似乎不是非常恰当。
(2)没看明白,为什么“业务人员”和“售票员”有联系。
(3)用例图似乎还没画完。
比如“添加航次信息”和其他部分的关系好象没画完吧。
个人观点,不一定正确。
mathematician
2006-07-03
打赏
举报
回复
来人啊,我都没法结帖。
Vision-Language-Region-Grounding-Auditor-v1.0-原创源码与文档.zip
原创开发工具源码合集,包含可直接运行的完整源码、自动化测试、离线示例、HTML/JSON/SVG 报告、运行截图、README、使用说明、功能清单、MIT License 与原创声明。适合前端、JavaScript、AI 工具开发与工程实践学习,解压后按 README 即可运行。
Android期末大作业,校园失物招领App应用,采用微信风格 UI 设计,使用 SQLite 本地数据库存储
校园失物招领 Android 应用,采用微信风格 UI 设计,使用 SQLite 本地数据库存储 所有数据,无需网络即可使用。 功能特性 用户系统 用户注册(用户名 2-20 位,支持字母/数字/下划线/中文,密码 3-20 位) 用户登录/登出,支持游客模式浏览 个人资料编辑(修改用户名、密码) 基于 SharedPreferences 的会话持久化,应用重启自动恢复登录状态 失物招领 发布失物/招领信息,支持标题、描述、联系方式、图片 编辑已发布的物品信息 物品状态流转:进行中 → 已找到 → 已归还(支持回退) 分页加载(每页 10 条),滚动到底部自动加载更多 六维筛选:全部/进行中/已找到/已归还/寻物/招领 关键词搜索(模糊匹配标题、描述、联系方式、发布者) 诚信承诺机制:发布前必须勾选承诺 图片功能 支持系统图片选择器 自动压缩至最大 1024×1024,JPEG 质量 85% 图片保存至应用私有目录 手势缩放预览(PhotoView 库) 自动清理超过 30 天的旧图片 评论系统 发表评论(内容限制 500 字) 评论正序/倒序切换 删除评论(仅评论者或管理员)
基于 空调-电动汽车 联合虚拟储能的海岛微电网优化调度(Matlab代码实现)
内容概要:本文提出了一种基于“空调-电动汽车”联合虚拟储能的海岛微电网优化调度方法,旨在解决海岛地区可再生能源消纳难与电力供应不稳定的问题。通过充分利用空调负荷的热惰性与电动汽车的灵活充放电能力,构建联合虚拟储能系统,等效替代物理储能装置,实现对风电、光伏等间歇性电源出力波动的平抑。研究建立了融合
需求
响应机制与多时间尺度调度框架的优化模型,并采用Matlab进行仿真验证。结果表明,该策略能够有效提升微电网对分布式能源的接纳能力,降低系统综合运行成本,增强供电可靠性与能源利用效率。; 适合人群:具备一定电力系统分析、优化建模及Matlab编程基础,从事微电网、综合能源系统、虚拟储能、
需求
响应等领域研究的科研人员与工程技术人员,特别适合研究生及以上学历的研究者。; 使用场景及目标:①应用于海岛、偏远孤岛等孤立微电网场景,提升可再生能源渗透率与系统韧性;②为高比例新能源接入的配电网提供低成本、高灵活性的虚拟储能解决方案;③实现空调与电动汽车等柔性负荷的协同优化,达成削峰填谷、降低能耗与运行成本的目标; 阅读建议:建议结合Matlab代码深入理解模型构建与求解过程,重点关注虚拟储能建模逻辑、温控负荷动态特性刻画、电动汽车充放电约束处理以及多时间尺度滚动优化的实现机制,可进一步拓展至碳交易、绿证激励等复合政策情景下的优化调度研究。
YOLO算法建筑工地工人个人防护装备目标检测数据集-548张-包含 VOC 和 Yolo 格式标签-支持多种算法训练模型.zip
页面底部可查看数据集可视化效果; 该数据集可直接接入YOLOv5s/v5m/v5l、YOLOv8n/v8s/v8m、YOLOv10n/v10s、yolo11等轻量级至中型骨干网络进行端到端训练,支持从零训练(from scratch)与迁移学习(fine-tuning)两种模式;可直接使用
YOLO算法室内热成像篮球框目标检测数据集-260张-包含 VOC 和 Yolo 格式标签-支持多种算法训练模型.zip
页面底部可查看数据集可视化效果; 该数据集可直接接入YOLOv5s/v5m/v5l、YOLOv8n/v8s/v8m、YOLOv10n/v10s、yolo11等轻量级至中型骨干网络进行端到端训练,支持从零训练(from scratch)与迁移学习(fine-tuning)两种模式;包含voc格式和yolo格式标签可直接使用
研发管理
1,268
社区成员
28,281
社区内容
发帖
与我相关
我的任务
研发管理
软件工程/管理 管理版
复制链接
扫一扫
分享
社区描述
软件工程/管理 管理版
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章