交互流程(原创)
[来源:] 2009-07-18 22:31:00 编辑:海贼 点击: 次
前言
在程序设计领域有一句话“千言万语不如一张图”,在工作中我们也接触了各种各样的流程图,但总的来说,优秀的流程图不多,普遍存在几个问题:
1. 制图不规范,很多时候是自己随意而发,或者见到别人的范例照猫画虎,貌似规整,实则错漏之处颇多;
2. 张冠李戴,由于对流程图的定义和基本类型不太了解,所以在流程图制作和选择画法的时候,对各种流程图的特点混淆,常常出现综合产物,似是而非;
在研究定义交互设计组自己的设计流程图标准时,整理写下了以下文字,希望能对大家了解流程图的定义和来龙去脉有帮助,知其然且知其所以然。
流程图的渊源和定义
在了解流程图的之前,我们需要了解一下另一个设计领域(软件系统的分析和设计),了解一下可视化表达的概念。
注:在我的印象中,流程图的制作和应用最频繁的领域应该是软件设计方面,我见过最严谨和规范的流程图也是由系统分析师画出来的,这是一个很有趣的现象,一方面说明结构化的表达需要严谨的逻辑思维,另一方面说明好的工具是能事半功倍地帮助我们逐级分解一个复杂的事物的,对此现象的好奇使我有段时间非常沉迷于系统分析的研究中,特别是UML的理念,定义等等(什么是UML,有兴趣自己研究哈!)。
Use-case及usc-case图概念
“在很长一段时间里,无论是传统的软件开发方法还是面向对象的开发方法,都是用自然语言来描述对系统的需求的,即把预期的人和系统之间的交互编写成剧本(scenario),但是这样的做法没有统一的格式,缺乏描述的地形式化,随意性较大,常常容易产生理解上的含混和不准确性。”1992年的时候,一个叫jacobson的大牛在他的著作中提出了use case的概念及可视化表达方法-use case 图,作为软件项目的开发和规划的一个基本模型元素,use case的概念和方法受到了it界的欢迎,并被广泛应用到众多领域,特别是在软件系统的分析中。
use case的概念和use case 驱动的分析和设计已经成为当今面向对象的系统分析与设计方法中不可或缺的一部分,换句话说,要了解软件研发的分析和设计,请先了解一下use case 。
所谓use case其实是指系统的外部事物(活动者)与系统的交互,它表达了系统的工作,即系统所提供的服务。
Use case的定义比较罗嗦和抽象,我简单归纳一下基本上是两个重点:
1. 系统的外部事物包括人(hummer actor)和外部系统(system actor)
2. Use case是对系统的用户需求(主要是功能需求)的描述,use case表达了系统的功能和所提供的服务
Use case图的示例
Use case概念给我的思考:
Use Case图中每个符号都有确定的含义,Use Case图的绘制也有明确的画法和规定。也许很多人对Use Case的划分和Use Case Specification的写法有不同的看法,但至少在一个项目中应保持一致,而不能每个人各写各的。这方面自由度是不应该很大的。
另外Actor不是具体的某个用户,而是刻画了一种角色。这个和我们的角色定义相当一致!
交互图(interaction diagram)概念
交互图表达对象之间的交互,描述一组对象如何合作完成某个行为(注:慢慢有点接近我们设计流程图的概念了:)),交互图主要是对use case中的控制流的建模,表达的是单个use case的行为,以及该use case中若干个实例对象和对象之间所传递的消息。交互图可以有效帮助我们观察和理解系统内部的协作关系和过程行为。
交互图有两种:
一种叫顺序图,一种叫协同图,顺序图着重描述对象按照时间顺序的消息交换,协同图着重描述系统成分如何协同工作,不同角度表达系统的交互和行为而已。它们之间可以相互转化。
顺序图的示例
协同图/协作图的示例
交互图给我的思考:
在很早的时候(有据可查,1992年),在软件分析领域其实已经开始专注人和系统的交互,以及系统模块和模块之间的任务流转,当我们现在流行进行“定义角色”,“任务分析”方法论探讨时,不过是在另一个专业范畴把这些思想重新温习了一遍,视角不同而已,这些前人积累的分析技能和方法是应该可以被我们充分借鉴的,借鉴得好,可以和程序员产生良好的共鸣。
状态图(state diagram)概念
一个状态图表达一个状态机(),着重表现从一个状态到另一个状态的控制流。它表现了一个对象的生存史,关于状态图我们需要知道它的图形元素:
1. 状态(state)
2. 转移
3. 初始状态(initial state)
4. 终结状态(final state)
5. 判定(decision)
6. 同步(synchronization)
状态图
状态图给我的思考:
状态图其实是从外部的角度来看待整个系统,事情总是有始有终的,有它的生命周期,你可以不了解它内部具体怎么运作的,但这不妨碍我们通过对它的表现或状态的关注,分析得到它的流动趋势。同时对于状态,对于图像符号的定义它已经相当完整了。
活动图(activity diagram)概念
活动图也是一种行为视图,描述了参与行为的对象活动的顺序,包括依赖于条件的行为恶化并发行为,表现的是从一个活动到另一个活动的控制流。活动图也是一种特殊的状态图。
活动图示例
活动图中泳道的概念
泳道(swinlance)代表对象对活动的责任,泳道把活动图中的活动划分为若干组。并把这些组指定给对象,它的好处是明确表示了那些活动是由哪些对象进行的。
将模型中的活动按照职责组织起来通常很有用。例如,可以将一个商业组织处理的所有活动组织起来。这种分配可以通过将活动组织成用线分开的不同区域来表示。由于它们的外观的缘故,这些区域被称作泳道。
活动图给我的思考:
活动图其实是从内部的角度来看待整个系统,活动图的泳道概念实在是个伟大创举,可以将任务,参与对象区分得如此形象,而且分门别类,干脆利索。
包(package)
在一个大型软件系统建立模型时,通常会将设计元素进行分组组织。包其实是一组模型元素和图的集合。
包的示例
好了,关于软件分析系统中常见的可视化概念和基本的重要视图我逐一梳理了一下,我简单总结一下:
1. 基于对功能需求的描述产生了可视化图形元素表达的概念
2. 在软件的分析和设计中,可视化图形已经工具化,use case图,交互图(顺序图,协作图),状态图,活动图构成了系统的行为视图(behavioral view)
3. 流程图是一个统称,虽然形式多样,但在软件研发领域基本上属于系统行为视图的范畴。
4. 顺序图,协作图,状态图,活动图是最为常见的流程图形式,有着各自的侧重点和表达规范,也有着各自的优缺点,没有所谓完美统一的流程图。
常见的图形元素和符号:
对象类(object) 具有共同的结构特征,行为特征,联系和语义的集合,用实线矩形框表示。
活动者(actor) 用户作用于系统的一个角色(Role)。活动者有自己的目标,通过与系统的交互达到目标。
一般用人形表示人(hummer actor) 。
用对象图标表示外部系统(system actor)
创始状态(initial state) 代表一个状态图的起始点,初始状态用一个实心的圆表示。
终结状态(final state) 代表一个状态图的终止点,终结状态用一个圆中掏一个小实心圆表示。
状态(state) 状态用一个带圆角的矩形框表示。
关联(association) 对链接的描述,一根实线表示,关联的方向可以在关联段加箭头表示,可以是双向或者单向的,没有标注即是双向关联。
转移 转移用实箭线表示,箭尾连接出发状态,即源状态,箭头连接到达状态,即目标状态,在箭线上可以标准与该转移有关的选项:事件,触发条件(guard conditon)和动作。
判定(decision) 因工作流在此条件的取值而发生的分支。判定用空心小菱形表示。
同步(synchronization) 同步是定义并发工作流的分劈(fork)和 接合(join)。同步用一条粗短实线表示,称为同步杆/同步条。
我所理解的概念辨析,欢迎大家一起探讨:
·Use case只描述活动者和系统在交互过程中做些什么,并不描述怎么做。
·活动图与交互图相比:
活动图着重变现的是活动的控制流,描述在对象之间传递的操作。
交互图着重表现的是对象到对象的控制流,描述在对象之间转递的消息。
·状态图和活动图相比:
状态图描述的是对象响应事件的外部行为,状态图着重表现的是从一个状态到另一个状态的流程。
活动图描述的是响应内部处理的对象类的行为,活动图着重表现的是从一个活动到另一个活动的控制流,是内部处理驱动的流程。
最后show一个范例,这个范例是我曾经做过的一个项目,我的感受是借助于特定的工具,同时具备相应的概念,输出一个合格专业的流程图其实不是难事。
XXX系统门户登录系统流程(采用的是活动图类型)说明
-
【转】设计用户体验,能
用户体验设计师能够影响用户的感
- 在京东网购容易出现售后问
- 苹果,奸商
- 社交网络应故意设计得“不
- 白鸦:对“消费分享社区”的
- 酒仙网找茬:我也来吐槽
- 都是淘宝惹的祸?有木有?
- 电商如何提高网站的用户体
-
用户体验,我们在路
昨天老邢让我做咱们paidai的用户体验斑竹,不胜惶...
- 用户体验,我们在路上
- 改版与老用户
- 8月28日,淘宝推出Safari版本淘宝
- 推荐一个很强大的真人试穿的内衣
- 如果让你来面试电子商务网站的UE
- 如何安全收货的思考
- 最新消息 Google发布Chrome浏览
- 今天早上淘宝首页出现严重问题