需求与设计过程(1)-用例(转)

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是内部模块或系统的情况。

(转自http://blog.csdn.net/binyao02123202/article/details/8082387)

时间: 2024-08-06 00:15:18

需求与设计过程(1)-用例(转)的相关文章

采用[ICONIX] 方法实践分析和设计之二 [用例建模](转)

在上一篇文章中我们了解并进行了域建模,换言之我们有了一个好的开始,起码开发人员对自己要开发的软件已有了初步的认识,且也得到了进行交流时可以使用的术语表. 本章将会在前一篇的基本上进一步阐述使用ICONIX方法实践用例建模,同样在文章的最后还会有在这个阶段最容易犯的10个错误,以给大家提醒或在分析过程中进行参照.     本文在ICONIX方法中所处的位置如下图(红圈标记的地方)     在开始进行用例建模之前,我们需要对这一过程有一些粗线条的认识,如果您以前做过或学习过这方面的知识,可以把下面的

优云CMDB经验分享之 – 剖析CMDB的设计过程

作为IT管理的核心,CMDB逐渐成为系统管理项目实施的热点.在很多的案例中,由于忽视了CMDB的因素,ITIL的深入应用受到了极大的挑战.同时,由于CMDB是IT管理信息的集中,CMDB也是一个重要的工具和手段. 在CMDB落地过程中需要注意的是,CMDB项目不是一个简单的软件安装过程,而是一个咨询.培训.实施.优化密切结合的综合过程,涉及到平台工具采购.咨询服务.实施服务.培训.甚至扩展开发等内容.同时,一个成功的CMDB项目不能一蹴而就,而是一个循序渐进.持续发展的过程,需要企业后续的投入和

浅谈企业应用软件架构设计过程

1.引言 本文不是学术性文章,也不是某些标准化理论的阐述,而是根据所从事J2EE应用软件架构设计工作的经验,谈谈自己对软件架构设计过程的理解,希望能让一些徘徊于门口的同学能对企业应用软件架构设计的目标.价值与方法有个大致概念.文中所举例子及分析方法受个人经验背景约束,可能在一定程度上会存在误导性,软件架构设计过程大同小异,例子主要还是用于辅助说明设计过程. 对于架构设计,如果用建筑来比拟的话,有点类似这样:这是我们将修建一座大教堂,甲方有这样的一些特殊要求,比如大堂要能容纳5000人,中间不能有

从涂鸦到发布——理解API的设计过程(转)

英文原文:From Doodles to Delivery: An API Design Process 要想设计出可以正常运行的Web API,对基于web的应用的基本理解是一个良好的基础.但如果你的目标是创建出优秀的API,那么仅凭这一点还远远不够.设计优秀的API是一个艰难的过程,如果它恰巧是你当前的工作任务,那么你很可能会感到手足无措. 不过,优秀的设计绝对是可以实现的.本文所描述的流程将帮助你获得成功,我们将共同研究什么是优秀的设计,以及迭代式的流程如何帮助我们实现这一目标.我们还将叙

OO设计原则 -- OO设计的原则及设计过程的全面总结

这部分增加一点自己的感想,OO设计原则下面讲述的很清晰;看完之后有点感想如果我们在实际开发当中能够把这些原则熟烂于心的话那我们的代码质量和个人能力会有很显著的提神.根据自己的实际经验看很多开发者在开发过程中很多基本的知识确实没有熟烂于心导致开发的时候只有基本的内容.我所在的项目就是代码接口各种乱,可读性和可维护性特别差:当然自己在开发的时候也都没有做到,在后面的工作中尽量避免 前面发表了5篇OO设计原则的文章,在这里我将这个5个原则如何在我们设计过程进行应用进行一下总结, 这是我通过阅读和学习很

扫盲 HTTPS 和 SSL/TLS 协议[1]:背景知识、协议的需求、设计的难点

转自: https://program-think.blogspot.com/2014/11/https-ssl-tls-1.html 扫盲 HTTPS 和 SSL/TLS 协议[1]:背景知识.协议的需求.设计的难点 文章目录 ★相关背景知识★HTTPS 协议的需求是啥?★设计 HTTPS 协议的主要难点★结尾 ★相关背景知识 要说清楚 HTTPS 协议的实现原理,至少需要如下几个背景知识.1. 大致了解几个基本术语(HTTPS.SSL.TLS)的含义2. 大致了解 HTTP 和 TCP 的关

六大步骤分解产品原型设计过程

本教程将从整体和局部实例两个部分来讲解原型设计的步骤.产品的原型设计一般是基于文档的形式所表达出来的形象设计,想要把产品原型设计做好其实并不容易,想把原型做得比文档好更不容易,这里会结合一些产品原型设计的方法以及技巧来介绍原型设计的步骤,希望可以帮到有需要的朋友. 设计原型也是讲究方法步骤的,一是要提升原型设计的合理性,避免出现头重脚轻的保真程度不一致的情况:二是要减少原型设计所占用的时间,大家各自的工作时间都是很宝贵的,不可能在原型设计上投入过多的时间,因此掌握一些原型设计的方法和技巧相当必要

需求引导设计 切莫教条主义

对于懂得软件工程的人来说,标题就是一句废话,没有需求分析,哪来的设计?软件设计和实现中,开发者往往会在不知不觉中忽略用户的需求,站在开发者的角度,按照自己的意愿去设计软件.同样在为系统设计数据库的时候,也存在类似的现象,也许你设计的数据库满足三范式的原则,而且非常灵活,但是用户方的负责人一看就知道这种严格按照理论设计的数据库是不能用的,会给带来好多问题,尤其是性能方面的. 那么应该怎样去考虑数据库的设计呢?个人理解的是,应该以理论知识为基础,以需求为导向进行数据库的设计,不能只是将系统的实体抽象

数据库设计过程

之前完成了一遍机房收费,但是,数据库只是按部就班的把原版数据库抄下来,并没有按照步骤设计.这次.NET版机房收费,对我们的要求高了,完全按照步骤开发,数据库的设计也成了非常重要的一部分. 数据库技术是信息资源管理最有效地手段.数据库设计是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,有效存储数据,满足用户信息要求和处理要求. 数据库的设计的步骤和各阶段的主要内容如下: 数据库的设计过程主要包括着六个阶段: 1.需求分析 需求分析阶段应该对系统的整个应用情况作全面的.详细