软件流程图
软件设计之业务流程图一
业务流程图第一部分：什么是流程图1. 定义那什么是流程图呢流程图=流程+图,如下图：图2 流程图的定义流程：Flow,是指特定主体为了满足特定需求而进行的有特定逻辑关系的一系列操作过程,流程是自然而然就存在的;但是它可以不规范,可以不固定,可以充满问题;所以就会造成看似没有流程;前不久,团队每个人对接一个业务团队去调研流程,反馈给我的流程有一些缺失;询问时,负责人反馈给我的答复是：这一块业务他们没有流程;其实严格意义上讲,业务已经开展,不可能没有流程,只是说没有固定的流程或者你调研的对象也讲不清楚;图：Chart 或者Diagram, 是将基本固化有一定规律的流程进行显性化和书面化,从而有利于传播与沉淀、流程重组参考;从定义可以看出,只要有事情和任务,流程就会有,但是并不是所有的流程都适合用流程图的方式去表现,适合用流程图去表现的流程是一定程度固定的有规律可循的,流程中的关键环节不会朝令夕改的;工作中我们还用到或听到很多其他类型的图表,比如交互设计师们经常说的线框图Wireframes,信息架构图或站点地图Site Map,,开发工程师们经常说的用例图Use Case或E-R图;这些不同的图表要表达的内容有何种差异呢简单做个对比,如图：图3 流程图VS其他常用图表如果要串到某一个项目来说,可以理解成：用例图Use Case：表现了一个角色在系统里要完成的活动是什么,比如用户这个角色与ATM取款机的交互过程中,用户需要完成的活动有存钱,取钱,查询等;而存钱这个活动再可以进一步细分为插卡,输入密码,输入金额,ATM吐钞,用户收款,退卡等活动;用例图可以不考虑用户动作的前后次序,而仅仅提取一些关键的动宾短语,映射出系统应该满足的功能点;常用用例图的人是产品经理和开发工程师;流程图则表示用户每一个活动的前后次序,比如用户必须要先插入银行卡,才能够输入密码,且流程图必须直接表现出各种异常判断,比如当密码错误时,出现什么提示,密码输入错误超过多少次时,出现什么提示和动作;常用流程图的人是产品经理,设计师,或者任何需要讲述业务如何运作的人;信息架构图,站点地图Site Map：表现为了做一个这样的系统,功能与内容的展现层次是什么,比如用户一进去后,欢迎页面的导航如何设计,是否直接出现取款,存款,查询,或者还有别的导航常用信息架构图的是设计师;但是常用组织架构图的是HR;线框图Wireframe：将具体每个界面的内容布局和权重表达出来,且标注出一些交互细节的设计,比如当密码错误后,如何提示下一步动作;常用线框图的人是设计师;实体关系图E-R图：则是数据库架构的工作,表示一个业务系统或场景中的实体时间的关系,比如储户与银行卡的关系是归属1对多,通过开卡事件产生关联;一般来讲,用矩形来表示实体,椭圆标识这个实体的属性,比如储户这个实体的属性有：姓,名,号码,住址等;而银行卡的属性有：开户行,开户名称,银行卡号等;那么流程图要体现出他的差异定义,要素是什么总结出了流程图的6大要素,希望大家能够记住,这6个要素可以在以后的文章里不断回顾,你也可以拿来判断你所看到的流程图是否专业;图4 流程图6大要素•参与者：谁在这个流程中可以是系统,可以是个打印机,更多的指什么角色——一般是有某种工种的人;比如客服同时有小A和小B两人,但是若他们的工作性质完全一样,那么在流程图里只需要写一个客服角色就可以了;•活动：做了什么事,比如点餐,结帐等活动;•次序：这些事情发生的前后顺序如何,哪个任务是其他任务的前置条件比如客人不结帐,就不会产生送他优惠卡的活动;•输入：每项活动开始取决于什么样的输入物或数据,比如做饭的师傅开始做菜时,需要拿到具体的点菜单;•输出：每项活动结束后,会输入什么样的文档或数据传递给下一方,比如师傅做好菜后,如何让负责传菜的人知道菜已经做好•标准化：采用一套标准化的符号用以传递你的流程图,从而使受众更快明白;关于流程图的标准化,并不是强制的,事实上,我们见过很多种类的流程图,只要能够传递明白任务和次序其实已经归类于流程图了;如下面的图：但是若在一个公司的环境下,你的流程图的受众又非常多的话,采取标准化的符号会带来很多交流上的好处,总之你懂的;第二部分：流程图的分类常见的流程图有业务流程图Transaction Flow, 页面流程图Page Flow;在工作中,作为UED,你可能会发现PD经常谈的是业务流程,而作为交互设计师,我们更多产出的是页面流程图;页面流程图和业务流程图到底有什么关系呢先有谁,其次再有谁呢先讲个故事：假设你的梦想是开个中高档的全国连锁餐馆,那么首先你想到的应该不是如何去选址,而是将为何要开连锁餐馆这件事情,以及你的定位,核心竞争力想清楚;是快餐,还是点餐,是连锁还是加盟定位于社区还是繁华商圈是川菜还是江浙海鲜是面向中老年还是年轻人是家庭主题还是动漫主题竞争对手是谁需要什么样的投资可能的风险是什么这些都想清楚了,问题都有答案了,所谓战略层要清晰了吧;然后假设你现在分析来分析去,与主要投资方决定了一个方向：面向年轻人的时尚动漫茶餐厅,连锁,但是先在杭州开始第一家,选址定位于年轻人约会,扫街的地域,比如风景区,著名商圈,电影院旁……那么,接下来呢接下来就是想办法让这些实现吧那么需要做什么事情呢选址拉投资搞装修选餐饮菜单雇佣员工每一步怎么去做,时间点是什么等等的任务拆解以及计划,就需要到战术层了;这些事情的执行,总是需要请人的吧先是核心团队分工去部署各项建设任务,当餐厅开设起来后,就需要组织稳定的运营团队,如服务、卫生、厨房、采购、人事等等,厨房里面还得分工,白案,热菜,冷菜等等吧每个部门需要设置管理层以及汇报关系吧所以你的组织结构就诞生了;那具体每种角色是如何顺畅合作完成日常稳定的以及突发的各项任务呢比如,当顾客上门时,谁去引导客人入座,谁去点菜,怎么将点菜的讯息迅速传递到厨房,并分发到酒水间、冷菜间、热菜间并保证客人尽快能够吃到所点的菜你必须要考虑各种人员的协作流程,优化效率,所以业务流程就出现了;人肉运营了一段时间,没有借助任何点餐系统,你发现也还可以;客人点菜时,服务员手抄写下客人的要求,因为有复印纸,所以服务员能够将副本送入厨房,同时写下餐桌号码;厨房规模较小,负责分配任务的员工看下菜单,分别往冷菜处的黑板上写下需要他们处理的,以及跑到热菜区的黑板上写下待处理的菜品,以及去酒水间报下品名即可;可是随着经营的扩大,以上的人肉方式出现了很多问题,首先,手抄效率太低,顾客频繁换菜,响应来不及,手抄出错,导致经常报错菜;厨房很混乱,不得不多招了几个人专门跑堂;而一旦顾客要加菜,撤菜就更麻烦了,需要找出他们当时点的菜,再进行人工的批注和修改,同时要修改厨房后端的各个黑板……所以你们想要开发一套智能系统,取代很多人肉工作,你们请了系统开发团队,他们经过评估,判断从点菜开始,一直到传菜都可以用系统解决;手持终端,能够快速传递顾客点菜需求到打印机,打印系统能够根据顾客点菜的类型进行自动的分单打印,所以热菜间看到自己的热菜菜单,冷菜间看到自己的冷菜菜单,而酒水间看到酒店菜单;当他们准备完毕后,送出,传菜员可以根据菜名与打印出来的单据进行传菜并根据顾客的点菜小票进行核对;这套系统同时必须配备结算系统,将最终确认掉的菜单及消费价格传递到结算前台,收银员能够快速进行操作;这套系统最终是需要展现出来的,那么手持终端的界面如何设计服务员能够用更少的点击完成一个菜的点餐吗结算中心的界面如何设计通过以上的故事,是不是更明白从战略、战术、业务流程图到页面流程图的关系了总结下：•先是有一个业务需求和业务目标,也即我们的愿景是什么战略•然后就诞生了我们需要分解出什么样的任务,如何执行战术战术•然后就诞生了需要架构什么部门,岗位去分工协作组织架构•然后就诞生了不同的部门在协作完成某件任务时的业务流程业务流程•业务流程基本稳定后,往往会考虑优化效率,所以会诞生出系统来支持流程,减少人肉环节,促进数据采集系统愿景•为了设计这个系统,PD需要思考什么功能能够取代某个环节的人肉工作功能需求,系统流程•不管是怎么样的功能最终都会以界面的方式呈现,设计师们会关注用户在系统里的任务流,行为路径,让用户完成任务更加高效愉悦;页面流程当然,除了业务流程,系统流程,页面流程,还有数据流程被人关注;我们平时工作中,还会经常听人谈到泳道图、任务流程图等等概念,究竟是神马关系呢图5 流程图的分类本文着重于上述流程中的“业务流程图”——并会分享如何绘制泳道图——也即是PD们最多使用,技术们最多参考,UED们最多看到的流程图;本来在第四部分会对泳道图的图示以及绘制方法、原则做更详细的说明,但是看目前的篇幅情况,预计会放到下篇,所以先在这里简单说明下吧;在工作中,我们经常能够看到两种业务流程图,从表现形式来看,一种很好区分,俗称为“泳道图”的它,在样子上也确实像个泳道,可以有横向的泳道,也会有纵向的泳道;泳道图在某些文档里会被称为“以活动为单位的流程图”,浮在泳道中的都是一个个活动;另外一种类型是以部门和岗位为单位的流程图,下图中的圆形就代表一个个部门或岗位;矩形代表活动;这种流程图关注事情如何完成的逻辑,但是在体现各个部门的责任上比较弱;如果是某个岗位的人来看,很难像泳道图那样一眼就能看到自己部门的职责和任务;所以现在用得比较少;再回过头来说泳道图,泳道图有几个关键点：两大维度,活动流转,流程要素;我们会在以后详解;第三部分：为什么需要业务流程图流程图可以提供一种简单扼要的“缩略俯瞰图”,帮助观众快速了解业务如何运转;它包含了几个关键词：谁,什么时候,在什么条件下,做了什么事情,输入什么,输出什么,输出给谁……与系统流程不同,业务流程更关注于业务本身如何运作,讲的是业务故事,包含的是业务规则;而系统流程则是满足业务流程,实现部分流程或全部流程的信息化和系统化;所以业务流程是所有环节的前置条件——软件需求分析,信息系统建设也会先进行业务流程的梳理;下面表现了业务流程图是如何在三个主要场景中发挥作用的：1. 员工培训图6 流程图的应用场景之一：培训在此场景中：流程图能够提供一种快速了解业务如何运作的视图,通过业务流程图,新员工能够快速明白业务的最终目标是什么,中有哪些角色在参与以及他们的职责,以及彼此之间的联接;除了培训新员工,在员工轮岗、调职场景中,员工也需要业务流程图参考,明白新的工作内容如何开展,以及自己所处的位置,自己的上游是谁,下游是谁,自己需要交付的工作内容是什么;2. 流程优化与重组图7 流程图的应用场景之二：流程优化业务流程重组Business Process Reengineering的存在可以明确反驳：存在即合理;事实上,存在的业务流程并未是合理的,有可能是参与的多个角色习惯了某种做法,有可能是变革尚未影响到末端的操作,也有可能缺乏对于运行中的业务流程问题的洞察以及强有力的变革推动——因为要推动业务流程变革,不是某个部门的事情,而是需要流程中各个部门的通力配合;更多时候,业务流程优化是自上而下的,但是老板们未必对实际运作的业务流程那么心知肚明,业务流程图能够很好去表现这个“运作模型”;通过看业务流程图,找关键节点的人访问,能够直接切入：为什么要这么做,为什么不这么做从而探索出更深层次的问题,而不是问：你们现在怎么做通过调研,分析业务流程图,引入更多角色,能够分析出目前业务流程的问题：缺失,重复,风险,效率等等;从而制定相应的优化方案;3. 信息化的基础图8 流程图的应用场景之三：信息化基础正如上文所述的餐馆梦想的案例,信息系统的一项任务就是解放员工的手脚,取代一些重复的人力劳动工作;系统上了之后,不是说业务流程不需要而是经过了一些调整,其中某个参与者变成了系统,或手持设备,或打印机而已;那么在做系统的功能设计和系统流程设计时,是不是必须先要了解目前业务是如何运作的呢从而更好分析分析,更好说明系统在什么环节取代了什么类型的人肉工作所以我们看到的PRD往往也会先以业务流程图开始说明,而叙述一个系统建设的好处时,也可以用以前的业务流程与系统上了之后的业务流程进行对比;根据分析,将愿景中的新的业务流程图背后需要系统的功能点撰写清楚;第四部分：如何绘制业务流程图首先绘制业务流程图本身有没有流程一定是有的;在软件工程学里听说一句话叫：万物皆对象;那么在流程学里,万事皆流程;吃饭难道没流程吗就吃饭的动作而言,就有流程：拿筷子——夹菜——入口——咀嚼——吞咽;有不少同学在这一部份很快想会问一个问题：Heidi,请介绍画流程图的工具吧我个人是工具派,从不否认人工欲善其事,必先利其器的道理;好的工具本身就是一名好的老师,除了技能,也能够教会我们一些理论与理念,这些理念也是“器”中很重要的一部分;其次才是具体的工具应用技能;所以我并不建议直接跳转到工具应用;对于初学者而言,笔与纸永远是最好的入门工具,因为你无需和任何一个陌生的软件较劲;那么,绘制业务流程图有没有可遵循的流程呢我建议可以从下面4步着手;1. 调研如何快速了解业务运作真相有没有调研的技巧放送2. 梳理与呈现•能否快速将调研得到的文字和问题,快速转化为业务流程图•业务流程图的标准图示是什么•怎么评价一个业务流程图的好与坏3. 评审与确认——能否真正让业务流程图反映现实中的业务4. 归档维护——流程不断变更,业务流程图如何快速响应。
UML的流程图
UML的流程图UML是一种面向对象的统一建模语言，用于快速地描述软件系统的结构、行为和交互。
而流程图是UML中的一种图形语言，用于对系统中的流程进行描述和设计。
本文将为大家介绍UML流程图的概念、种类、结构和使用方法。
概念UML流程图，也称UML活动图，是一种图形化的表示算法、流程和业务过程的工具，它可以直观地表达系统中的任务、动作、决策和控制流程。
UML流程图常用于软件开发过程中的需求分析、业务流程设计、系统架构设计等领域。
种类UML流程图包含四种基本类型：1.基本活动图基本活动图可以用来表示操作的顺序或并行方式，其中每个操作都是基本动作，例如读取、写入、计算等。
基本活动图通常用于领域建模和系统流程的初步设计。
2.流程状态图流程状态图是对系统中复杂操作的一种表示，可以用来展示操作的状态和转换方式。
流程状态图主要包括状态、转换和起始状态，它通常用于描述系统中的复杂业务流程。
3.并发活动图并发活动图可以用来表达系统中多个处理程序的并发执行过程，它通常使用平行线表示并发执行的多个处理程序。
4.条件活动图条件活动图是一种用于表示系统中动态交互的活动图，其中条件是关键的组成部分。
条件活动图通常用于强制执行程序在满足一定条件的情况下才能执行，例如软件开发中经常用到的循环结构和分支结构等。
结构UML流程图的结构由一系列基本元素组成：1.开始节点开始节点，在UML流程图中表示整个活动图的起点。
一般情况下，开始节点在活动图的左侧上方，使用一个表示圆圈中心的空心点表示。
2.结束节点结束节点，在UML流程图中表示整个活动的结束点。
一般情况下，结束节点位于活动图的右侧下方，使用一个表示实心点的圆圈表示。
3.动作节点动作节点是一种执行操作的元素，可以进行计算、赋值、IO操作等。
动作节点在UML流程图中通常用长方形表示。
4.决策节点决策节点用于表示一个条件分支，并根据条件的结果选择一个或多个分支行动。
在UML流程图中，它通常使用菱形表示。
流程图软件免费
流程图软件免费流程图软件是指用于绘制流程图的专用工具，包括在线工具和安装在计算机上的软件。
这些软件通常提供多种图形符号和模板，帮助用户轻松绘制各种类型的流程图，如程序控制流程图、数据流程图、组织结构图等。
以下是几款免费的流程图软件的介绍。
1. Microsoft Visio：这是一款常用的流程图软件，可以帮助用户快速创建各种类型的流程图。
Visio提供了丰富的图形符号和模板，并支持与其他Microsoft Office应用程序的无缝集成。
虽然Visio本身是商业软件，但Microsoft提供了Visio Online，用户可以免费使用在线版本。
2. Lucidchart：这是一款在线的流程图软件，提供了直观易用的界面和大量预定义的模板。
用户可以通过拖放操作来创建和编辑流程图，并分享给团队成员进行协作。
Lucidchart还支持与其他应用程序的集成，如Google Drive、Microsoft Office等。
3. Draw.io：这是一款开源的在线流程图软件，拥有简洁的界面和丰富的功能。
它支持多种图形符号和模板，并可以将图表保存为多种格式，如PNG、SVG、PDF等。
Draw.io还支持将文件保存到本地或云存储服务中，方便用户进行文件管理和共享。
4. Pencil：这是一款免费的桌面应用程序，适用于Windows、Mac和Linux操作系统。
它提供了丰富的绘图工具和预定义的模板，用户可以创建各种类型的流程图和示意图。
Pencil还支持导入和导出多种文件格式，如PNG、JPEG、PDF等。
5. Dia：这是一款开源的流程图软件，适用于Windows、Mac和Linux操作系统。
它提供了各种绘图工具和符号库，用户可以轻松创建各种类型的流程图和结构图。
Dia还支持导入和导出多种文件格式，如SVG、EPS、PNG等。
总的来说，以上所介绍的流程图软件都提供了丰富的功能和易于使用的界面，可以满足用户绘制各种类型的流程图的需求。
常见的软件研发基本流程图
模型图模型名称测试介入点测试范围优点瀑布模型全部代码编写完后整个软件产品1、测试成本低2、测试范围小3、简单、高效螺旋模型1、一个功能代码完成后，进行单元测试2、一个模块代码完成后，进行集成测试3、产品全部功能完成后，进行系统测试1、单元测试--代码2、集成测试--接口3、系统测试--整个软件产品1、应对变更和风险能力强2、测试介入时间早3、测试较充分4、软件质量有所提高和改善RUP模型（Rationalunified process ）Rational统一开发过程每个阶段编码完成后每个阶段业务建模时定义的功能范围+上一阶段完成的所有功能1、将系统进行分解，简化了测试的难度2、每个阶段提交个半成品a、提高客户的信心b、控制变更范围c、可以提早进行变更IPD模型（Integration product development）集成产品开发过程1、硬件研发完成后--硬件测试2、软件研发完成后--软件测试1、硬件2、软件所有部门的数据都进行了充分的数据共享，提高了决策的准确性常见的软件研发基本流程图缺点适用范围1、测试介入晚，发现缺陷较晚，软件质量不可控2、上有成果物未完成时下游的人力资源闲置3、简单、高效1、项目小2、需求明确3、公司规模小1、需要专业的风险识别专家2、成本高与人的生命和财产相关的系统需要专业的软件构架师不适合功能模块联系较紧密的系统管理成本较高大型的软硬件集成厂商。
软件开发流程图
软件开发流程图 (Programmer):程序员 EU (End-User):最终用户TE (Test Engineer):测试工程师 GM (General Manager):总经理
硬件开发流程图
PM:根据GM 安排编制简略/详细的建设方案 PM:获取EU 主要的关键性需求 PM:基于内部预算对EU 提供费用报价 PM:与EU 确认需求变动及方案、费用调整 PM:完成详细内部预算并提交给GM PM:通过内部项目管理系统配置详细人员、进度安排 PM:移交EU 需求给PG,安排PG 开发任务 PG:根据EU 需求及PM 要求,执行开发任务 PM:通过内部项目管理系统审核PG 工作日志,确认EU 需求变动,执行进度控制,必要时变更人员安排及内部预算 PG:技术调测及修改;根据TE 测试文档调试修改 TE:进行集成测试,编制测试文档,提交PM,送达PG PG:部署至外部服务器 PM:系统初验 EU:试用 PM:获得试用意见
PG:部署正式上线,编制开发字典,提交PM TE:编制系统操作手册、功能列表,提交PM PM:提交开发字典、操作手册、功能列表给EU,通过内部项目管理系统结项,向GM 汇报。
用友软件最全ERP流程图
销售助理
总调室调度人员
库房记账员
材料成本会计/往来会计
具体工作流程
结转销售成本
流
程
描
述
1、销售业务员与客户签订销售协议，销售助理根据签审完毕旳销售协议审批单在【销售管理】模块录入销售订单并审核。
2、产品生产完毕竣工入库后，总调室调度人员在【销售管理】模块根据销售订单生成销售发货告知单（见表：PR-SA-03）；
材料、商品销售发货：总调室调度人员在【销售管理】模块根据销售订单生成销售发货告知单，进行打印［一式五联，财务部、总调室、销售部、客户、库房保管］，由财务部拟定与否已经收款；总调室告知库房保管人员发货出库，实物出库后，库房保管人员在销售发货告知单上进行签字确认；销售发货告知单回执给销售部门作为索要欠款旳根据；给客户作为出门根据。总调室调度人员根据经各部门签字确认后回执旳销售发货告知单，在【销售管理】模块中对销售发货告知单进行审核；
操作要点：
1、销售发货分三种状况：
机加产品发货：由总调室调度人员先发组装告知到机加工程部，机加工程部从仓库领取散件进行组装。组装完毕后，凭总调室调度人员下达旳销售发货告知单由机加工程部发货。总调室调度人员在【销售管理】模块根据销售订单生成销售发货告知单，进行打印，一式六联［财务部、总调室、销售部、机加工程部、客户（代出门证）］，分别由财务部拟定与否已经收款；由机加车间工程部进行发货，实物出库后，机加车间工程部在销售发货告知单上进行签字确认；销售发货告知单回执给销售部门作为索要欠款旳根据；给客户作为出门根据。总调室调度人员根据经各部门签字确认后回执旳销售发货告知单，在【销售管理】模块中对销售发货告知单进行审核；
财务项目核算员
具体工作流程
描
述
1、销售部门销售业务员签订销售协议（参见公司协议审批流程）。所有旳销售订单必须填写销售协议审批单（见表：PR-SA-01）,进行各部门审批。总调室调度人员在接到销售协议审批单后，根据订单内容、存货状况、产品技术设计状况在【物料需求筹划】模块增长存货档案并建立有关旳产品构造；根据销售协议审批单上总调室增长旳存货档案、产品构造状况财务部门项目核算人员在【总账】模块增长成本对象项目旳项目目录；
软件设计中流程图的画法标准版文档
活动的层一次个级别事要一务致的； 流程图往往不只一个，可由浅及深分层表述。 五画、UM流L程活不图动同说图明，起(专sh因业uō的m的设ín计g如)信工果息具(能gōn合gjù)并，面(向hé对象b，ì组n件g可)重则用合，便并于业(h务é分析b。ìng)，不能合并(hébìng)的画 不三要、把 选不择同画流图单程(hu的独à业tú的务)工合具流并(程héb。ìng)成一个流程。
第七页，共10页。
四、流程图的表示(biǎoshì)
开始、结束标记 过程或活动 判决或决策 业务(yèwù)流、操作流 流程合并拆分
第八页，共10页。
五、流程图说明(shuōmíng)信息
基本说明 活动主体，活动内容、状态变更条件， 谁、因为什么（输入）、做什么（内容）、得到什么（输
一个事务的流程图往往不只一个，可由浅及深分层表述。
第五页，共10页。
二、选择(xuǎnzé)表现形式
基本(jīběn)流程框图 适合表现基本(jīběn)的业务流程，通常是顺序的。 UML活动图 适合表现软件过程活动，可以是并行的。 其他方式 数据流程图、UML协作图、UML状态图
第六页，共10页。
如何进行的，以及(yǐjí)决定应如何改进过程极有帮助
第二页，共10页。
三、确定(quèdìng)业务
确定业务原因及目的 因为什么原因开始做这件事？最终要达到(dádào)什么目的？ 也就是输入（激发）条件，输出结果 确定业务边界 即流程的开始、结束标记，结合原因、目的 筛选业务活动 必须是与业务目的相关的；活动的层次级别要一致； 注意流程的详细程度
出）。 分析性说明 输入条件、输出结果(jiē guǒ)、业务约束、场景、实现方式
软件测试流程图案例
软件测试流程图案例在线购物场景测试:第一步:确定基本流和备选流第二步:确定场景场景流的组合场景1—成功购物基本流场景2---账号不存在基本流备选流1 场景3---账号或密码错误基本流备选流2 场景4---余额不足基本流备选流3 场景5---账号没有钱基本流备选流4第三步:设计用例(v:有效;I:无效;n/a:不相干)输入用例场景/条件预期结果编号账号密码余额1:成功购物成功购物 1 V V V2:账号不存在提示账号不存在 2 I n/a n/a3:账号或密码错误(账提示账号或密码错误，返回到3 V I n/a 号正确，密码错误) 基本流步骤33:账号或密码错误(账提示账号或密码错误，返回到4 I V n/a 号错误，密码正确) 基本流步骤3提示账号余额不足请充值，充4:余额不足 5 V V I 值后返回到基本流步骤4 提示用户绑定银行卡或充值，5:账号没有钱 6 V V I 充值后返回到基本流步骤4第四步:设计数据，填入用例表(前置条件:所购商品价格150元) 假设Sue是注册用户，密码1s2，余额200;Jim未注册用户;Sun是注册用户，密码1234;Van是注册用户，密码1v2，账号余额1;Tom是注册用户，密码123，余额为0;用例输入场景/条件预期结果编号账号密码余额1:成功购物成功购物 1 Sue 1s2 2002:账号不存在提示账号不存在 2 Jim -- --3:账号或密码错误(账提示账号或密码错误，返回3 Sun 12345678 -- 号正确，密码错误) 到基本流步骤33:账号或密码错误(账提示账号或密码错误，返回4 Sunny 1234 -- 号错误，密码正确) 到基本流步骤3提示账号余额不足请充值，4:余额不足 5 Van 1v2 1 充值后返回到基本流步骤4课堂练习:旅馆住宿系统房间网上预订业务• 需求:游客访问网站进行网上房间预订操作，选择合适的房间后，进行在线预订;此时，需使用个人账号登录系统;待登录成功后，进行订金支付(订金额为1天的房款);支付成功后，生成房间预订单，完成整个房间预订流程。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
程序流程图独立于任何一种程序设计语言，比较直观、清晰，易于学习掌握。
但流程图也存在一些严重的缺点。
例如流程图所使用的符号不够规范，常常使用一些习惯性用法。
特别是表示程序控制流程的箭头可以不受任何约束，随意转移控制。
这些现象显然是与软件工程化的要求相背离的。
为了消除这些缺点，应对流程图所使用的符号做出严格的定义，不允许人们随心所欲地画出各种不规范的流程图。
例如，为使用流程图描述结构化程序，必须限制流程图只能使用图所给出的五种基本控制结构。
图流程图的基本控制结构
任何复杂的程序流程图都应由这五种基本控制结构组合或嵌套而成。
作为上述五种控制结构相互组合和嵌套的实例，图示给出一个程序的流程图。
图中增加了一些虚线构成的框，目的是便于理解控制结构的嵌套关系。
显然，这个流程图所描述的程序是结构化的。
图流程图的基本控制结构
N-S图
Nassi和Shneiderman 提出了一种符合结构化程序设计原则的图形描述工具，叫做盒图，也叫做N-S图。
为表示五种基本控制结构，在N-S图中规定了五种图形构件。
参看图。
为说明N-S图的使用，仍用图给出的实例，将它用如图所示的N-S图表示。
如前所述，任何一个N-S图，都是前面介绍的五种基本控制结构相互组合与嵌套的结果。
当问题很复杂时，N-S图可能很大。
图 N-S图的五种基本控制结构
图 N-S图的实例
PAD
PAD是Problem Analysis Diagram的缩写，它是日本日立公司提出，由程序流程图演化来的，用结构化程序设计思想表现程序逻辑结构的图形工具。
现在已为ISO认可。
PAD也设置了五种基本控制结构的图式，并允许递归使用。
图 PAD的基本控制结构
做为PAD应用的实例，图给出了图程序的PAD表示。
PAD所描述程序的层次关系表现在纵线上。
每条纵线表示了一个层次。
把PAD图从左到右展开。
随着程序层次的增加，PAD逐渐向右展开。
PAD的执行顺序从最左主干线的上端的结点开始，自上而下依次执行。
每遇到判断或循环，就自左而右进入下一层，从表示下一层的纵线上端开始执行，直到该纵线下端，再返回上一层的纵线的转入处。
如此继续，直到执行到主干线的下端为止。
图 PAD实例
判定表
当算法中包含多重嵌套的条件选择时，用程序流程图、N-S图或PAD都不易清楚地描述。
然而，判定表却能清晰地表达复杂的条件组合与应做动作之间的对应关系。
仍然使用图的例子。
为了能适应判定表条件取值只能是"T"和"F"的情形，对原图稍微做了些改动，把多分支判断改为两分支判断，但整个图逻辑没有改变。
见图。
与图表示的流程图对应的判定表如图所示。
在表的右上半部分中列出所有条件，"Ｔ"表示该条件取值为真，"Ｆ"表示该条件取值为假，空白表示这个条件无论取何值对动作的选择不产生影响。
在判定表右下半部分中列出所有的处理，画"Ｙ"表示要做这个动作，空白表示不做这个动作。
判定表右半部的每一列实质上是一条规则，规定了与特定条件取值组合相对应的动作。
图不包含多分支结构的流程图实例
PDL(Program Design Language)
PDL是一种用于描述功能模块的算法设计和加工细节的语言。
称为设计程序用语言。
它是一种伪码。
一般地，伪码的语法规则分为"外语法"和"内语法"。
外语法应当符合一般程序设计语言常用语句的语法规则；而内语法可以用英语中一些简单的句子、短语和通用的数学符号，来描述程序应执行的功能。
使用PDL语言，可以做到逐步求精：从比较概括和抽象的PDL程序起，逐步写出更详细的更精确的描述。
PDL就是这样一种伪码。
它具有严格的关键字外语法，用于定义控制结构和数据结构，同时它的表示实际操作和条件的内语法又是灵活自由的，可使用自然语言的词汇。
下面举一个例子，来看PDL 的使用。
从上例可以看到，PDL 语言具有正文格式，很像一个高级语言。
人们可以很方便地使用计算机完成PDL的书写和编辑工作。
PROCEDURE spellcheck IS 查找错拼的单词
BEGIN
split document into single words 把整个文档分离成单词
lood up words in dictionary 在字典中查这些单词
display words which are not in dictionary 显示字典中查不到的单词
create a new dictionary 造一新字典
END spellcheck
PDL作为一种用于描述程序逻辑设计的语言，具有以下特点：
·有固定的关键字外语法，提供全部结构化控制结构、数据说明和模块特征。
属于外语法的关键
字是有限的词汇集，它们能对PDL正文进行结构分割，使之变得易于理解。
为了区别关键字，规
定关键字一律大写，其它单词一律小写。
·内语法使用自然语言来描述处理特性。
内语法比较灵活，只要写清楚就可以，不必考虑语法错，以利于人们可把主要精力放在描述算法的逻辑上。
·有数据说明机制，包括简单的（如标量和数组）与复杂的（如链表和层次结构）的数据结构。
·有子程序定义与调用机制，用以表达各种方式的接口说明。
HIPO图(Hierarchy plus Input Process Output)
HIPO最初只用做文档编写的格式要求，随后发展成比较有名的软件设计手段。
HIPO图采用功能框图和PDL 来描述程序逻辑，它由两部分组成：可视目录表和IPO图。
可视目录表给出程序的层次关系，IPO图则为程序各部分提供具体的工作细节。
1、可视目录表
可视目录表由体系框图、图例、描述说明三部分组成。
(1)体系框图
又称层次图（H图），是可视目录表的主体，用它表明各个功能的隶属关系。
它是自顶向下逐层分解得到的，是一个树形结构。
它的顶层是整个系统的名称和系统的概括功能说明；第二层把系统的功能展开，分成了几个框；第二层功能进一步分解，就得到了第三层、第四层，…，直到最后一层。
每个框内都应有一个名字，用以标识它的功能。
还应有一个编号，以记录它所在的层次及在该层次的位置。
(2)图例
每一套HIPO图都应当有一个图例，即图形符号说明。
附上图例，不管人们在什么时侯阅读它都能对其符号的意义一目了然。
(3)描述说明
它是对层次图中每一框的补充说明，在必须说明时才用，所以它是可选的。
描述说明可以使用自然语言。
例如，应用HIPO法对盘存/销售系统进行分析。
得到如图所示的工作流程图。
分析此工作流程图，可得如图所示的可视目录表。
图(a)是系统的层次图，图(b)是后面IPO图的图例，图(c)是描述说明。
图盘存/销售系统工作流程图
图盘存/销售系统的可视目录表
2、IPO图
IPO图为层次图中每一功能框详细地指明输入、处理及输出。
通常，IPO图有固定的格式，图中处理操作部分总是列在中间，输入和输出部分分别在其左边和右边。
由于某些细节很难在一张IPO图中表达清楚，常常把IPO图又分为两部分，简单概括的称为概要IPO图，细致具体一些的称为详细IPO图。
概要IPO图用于表达对一个系统，或对其中某一个子系统功能的概略表达，指明在完成某一功能框规定的功能时需要哪些输入，哪些操作和哪些输出。
图是表示销售/盘存系统第二层的对应于H图上的1.1.0框的概要IPO图。
图对应H图上1.1.0框的概要IPO图
在概要IPO图中，没有指明输入―处理―输出三者之间的关系，用它来进行下一步的设计是不可能的。
故需要使用详细IPO 图以指明输入―处理―输出三者之间的关系，其图形与概要IPO图一样，但输入、输出最好用具体的介质和设备类型的图形表示。
图是销售/盘存系统中对应于1.1.2框的一张详细IPO图。
图对应于H图1.1.2框的详细IPO图
3、利用HIPO进行迭代式细化设计
在软件设计时，解决设计问题通常需要经历一个认识逐步发展的过程，并且对一些问题还要经过反复的考虑才可能达到比较满意的设计效果。
我们称此为迭代式细化设计。
HIPO能很好地适应这一要求。
图是利用HIPO进行迭代式细化设计的示意图。
从图中可看到，把可视目录表和IPO图结合起来，反复交替地使用它
们，可使得设计工作逐步深化，最终取得完满的设计结果。
其实这正是自顶向下，逐步求精的结构化程序设计思想。
HIPO有自己的特点。
首先，这一图形表达方法容易看懂。
其次，HIPO的适用范围很广，绝不限于详细设计。
事实上，画可视目录表就是与概要设计密切相关的工作。
如果利用它仅仅表达软件要达到的功能，则是需求分析中描述需求的很好的工具。
因为HIPO是在开发过程中的表达工具，所以它又是开发文档的编制工具。
开发完成后，HIPO图就是很好的文档，而不必在设计完成以后，专门补写文档。
图利用HIPO进行迭代式细化设计。