1.前言
看过太多的称得上“三无”的软件,就是无需求、无设计、无注释。严格的说来,他们的需求和设计其实还是有的,只是没有用文档记录下来而已,但是注释确实真的没有。这些软件从大到小都有,但是他们都有一个共同的特点,就是“难维护”。前几天和同事聊天,听说一个XAML的实现要重写了,用本地协议代替,然后再去考虑和XAML兼容。虽然我没有看过这个项目的代码,但是我知道这个项目基本也是“三无”。当然这个情况也是三无的重大特征之一,就是前脚走人之后,后脚是“看不懂、下不了手”,结果是还不如重写来得简单。从员工角度,当然不会有什么不妥,但是从公司和产品的角度,则是属于“无谓的损失”。
一个对自己有要求的程序员,应该保证自己不出产“三无”项目
“规范化”可以解决项目的“三无”问题。而且这个一直是我所推崇的,正好有网友开始了12306ng项目,所以也就拿这个例子过来,跟大家汇报一下我的设计思路,同时也作为我在公司开设此类课程的备课。
2.关于设计
软件的设计过程其实也是一个推导的过程,这个过程的每一个步骤之间都有着各种关系:要么细化,要么印证,要么补充。我之前学习设计的时候,以为看着课本,依据什么“自顶向下”或“自底向上”就可以一步一步将系统设计出来,可是后来发现我错了。相信正在学习设计的朋友也应该会有这样的感受。
电脑和人脑相比,最大的区别是前者一个线性系统,而后者是一个非线性系统。所谓的非线性,通俗点讲,就是颠三倒四,左右开弓,文艺点讲,就是讲究“螺旋式上升”,总之就是说“机械式”的“一蹴而就”动作,人脑是不擅长的,当然,天才除外。
设计也是如此,它本来就是人脑的处理结果,所以它的过程也必然是非线性的。一种设计方法,要想被人容易学习和接收,它本身就要是一种包含“螺旋式”改进的机制,也就是戴明环的PDCA过程(Plan-Do-Check-Adjust),不过在设计过程中Plan的因素不明显,主要是DCA的过程。
在做系统设计的过程中,最大的感受就是不要限制自己。记得当年我为了完成设计,满足“自顶向下”的要求,刻意地限制自己不去深入地思考,结果当然是失败。当然,“限制”不仅是刚谈到的思考层次的限制,更重要的是突破工具的限制。所有的工具都会给思想甚至工作进度带来限制。迄今为止,最好的设计工具依然是“带橡皮头的铅笔”和“纸”,所以诸位要好好地利用它。
3.需求
12306是目前最著名的公认的人机交互体验较差的网站,如何做出一个比它更好的系统呢?答案就是“更仔细地设计”。在“更仔细地”设计之前,我们需要“更仔细地”收集好需求。
软件的需求就是软件要实现的“目的”。各位千万不要一提到“需求”就当作了“需求文档”,文档只是需求的一种表现形式而已,另外一种常见的表现形式就是程序员们大脑中的记忆。蹩脚的程序员经常通过嘴传递需求,他们宁可不厌其烦、一遍又一遍地说,也不愿意花一点时间一次性写下来,他们无法忍受客户的一次次需求变更,但却不在意自己每次说出的同一个需求都有些走样。
3.1.第一步:用例分层
这里我们用UML的用例图(UseCase)来表示需求。
用例图也是分层次描述的。所有系统最顶层的用例图(零级用例)都差不多,都是一个圆圈围绕着很多角色,区别就是角色有多少,以及圆圈里写的字不一样。这次我们的圆圈里写的是“12306ng火车票订票系统”,外围的角色只有2个:用户和管理员。
一级的用例图就完全不一样了。我把它分为了7个部分,一级用例名称和其包含的二级用例名称说明如下:
1. 用户管理:注册,登录,退出,密码找回,信息查看,信息修改,用户验证,用户查询
2. 查询:时刻表,余票,联程规划,晚点
3. 订单:下单,取消订单,修改订单,订单查询,预订
4. 票务:订票,取票,改签,退票,车票查询
5. 资金:付款,退款,查询到帐,银行对账
6. 票池:入票,出票,查询票池,修改票池
7. 维护:参数设置,词典维护,拓扑管理,日志查询,备份,恢复
以上直接列出是为了方便大家阅读,实际上我也是用这样提纲来思考的。然后补图如下:
当然,以上的部分既不是最初的状态,也不是最终的状态,而是我经过多次调整和改进之后,到现在的状态,未来还会根据分析的情况进一步调整。另外,大家一定要注意,一个系统的用例表示不是唯一的,不同的人给出的用例是不同的,但是理论上应该是等价的。
用例图中的每一个部分,都必须是真实存在的,而且是可以面向客户的东西,它所描述的最小单位应该是业务模块。评判用例的标准是“具有业务意义”,所谓的“业务意义”就是指这个业务模块完成之后,可以将整个业务或者业务流程向前推进,这个“推进”的结果应该包含了角色的转变或者目标的变化。
从以上的定义来看,“资金.查询到帐”和“票池.锁票”可能就不是一个用例。直到写本文的时候,我依然还在犹豫,但后来还是决定剔除,因为他们没有外部关联的actor,虽然确实这两个用例能够推动业务向前推进。从这里我还得到一个经验,就是在一级和二级用例最好不要出现actor是内部模块或系统的情况。
(未完待续)
分享到:
相关推荐
这里提到的“设计功能-用例表1”可能是某个项目的需求分析文档的一部分,用于描述不同角色和功能模块之间的关系。下面将详细阐述这个用例表中涉及到的各个知识点。 首先,我们看到“功能对应逻辑包运输1-9 23”,这...
总之,性能测试用例设计是性能测试成功的关键,它要求我们深入了解业务需求,精确模拟用户行为,明确测试目标,并通过持续监控和分析,找出并解决性能问题。只有这样,我们才能确保软件在实际环境中具备优秀的性能...
在面向对象(OO)开发中,用例与RUP(统一软件开发过程)相结合,可以帮助将需求分析与软件过程有机融合,确保系统的业务需求得到充分满足。 本系列文章将逐步深入用例分析的各个方面,包括如何识别和定义用例,...
规格导出法是指根据软件的规格和需求,设计测试用例来验证软件的正确性。 输入输出组合法是指根据软件的输入和输出,设计测试用例来验证软件的正确性。 ATM测试用例设计实例是指根据自动化测试的要求,设计测试...
面向对象分析与设计(Object-Oriented Analysis and Design,简称OOAD)是一种软件工程方法论,用于指导软件开发过程中的需求分析、设计及实现等阶段。在OOAD中,用例分析扮演着至关重要的角色,它是连接需求分析与...
用例实现规约是软件开发过程中的关键文档,它提供了系统功能的详细描述,指导设计和开发工作,同时帮助管理需求变更和风险。通过对规约的深入理解和执行,可以提高软件项目的成功率,确保最终产品满足用户需求。...
在这个过程中,用例分析是理解系统功能需求的关键步骤。用例图描绘了系统的主要参与者与他们之间的交互,以及参与者如何通过系统实现特定的目标。 在需求分析阶段,我们识别了网络教学系统中的主要功能。首先,学生...
《优团App用例文档》是针对社区团购应用程序的一个详细需求分析资料,旨在为软件工程1801和1802班级的学生提供一个实践平台,深入理解和掌握软件需求分析的原理与实践。该文档由G14团队的刘书宇、梁泽生、彭昕怡、张...
此用例文档的编写遵循了软件需求分析的原则,通过详尽地描述用户与系统之间的交互,帮助开发团队理解并实现用户的需求,从而确保最终产品能够满足用户的实际需求,提高用户体验。这样的文档对于项目的成功至关重要,...
这样的用例规约说明书对于软件开发团队理解业务需求、设计系统架构和编写代码至关重要。它不仅确保了开发过程中对业务逻辑的准确把握,也使得非技术团队成员能够清晰了解系统将如何服务于公司的各个部门。同时,通过...
看过太多的称得上“三无”的软件,就是无需求、无设计、无注释。严格的说来,他们的需求和设计其实还是有的,只是没有用文档记录下来而已,但是注释确实真的没有。这些软件从大到小都有,但是他们都有一个共同的特点...
总结来说,《渔乐生活APP用例文档》详尽地列出了各个角色与APP的交互,为开发团队提供了清晰的需求定义,是软件开发过程中不可或缺的一环。通过用例的描述,我们可以预见APP的核心功能和用户体验,从而更好地规划和...
在IT行业中,需求分析是软件开发过程中的关键环节,它为后续的设计、编码和测试提供了清晰的指导。本文将深入探讨“需求--编写有效的用例”这一主题,结合UML(统一建模语言)和相关框架,以帮助需求分析师、项目...
这些用例规约对于软件开发至关重要,因为它们定义了系统的功能需求,确保了系统能够满足不同角色用户的期望,并为系统设计、编码和测试提供了明确的指南。同时,非功能需求如安全性、操作简便性等也是必须考虑的因素...
在实施过程中,开发团队需要按照用例表来构建应用程序,确保每个功能的实现都符合用户需求。同时,版本历史记录表明,团队在不断地对计划进行迭代和优化,以提高项目的质量和效率。 此外,文档还包括了文件标识、...
总之,《优团App用例文档 V0.1.101》是软件工程领域中一个典型的用例驱动的需求分析示例,它详细地定义了社区团购App的各项功能,为软件设计和开发提供了明确的蓝图。通过这样的文档,团队可以更好地理解用户需求,...
- **维护与演化**:用例模型在系统维护和升级过程中,作为参考,帮助理解和修改现有功能。 #### UML中的用例图元素 UML用例图主要包含三个元素:系统、参与者和用例,以及它们之间的关系。 - **系统**:用一个...
《优团App用例文档》是针对社区团购应用程序进行需求分析的重要文档,主要用于指导软件工程1801和1802班级的学生进行软件开发。这份文档详细列出了用户在使用优团App时可能涉及到的各种操作场景,旨在确保开发团队能...