软件程序的知识点

1、UI层和逻辑层大家的讨论使我明白在设计多层结构的程序时，层与层之间需要多用接口少用继承，但为什么要用接口呢？比如逻辑层直接实例化一个数据访问层的类，然后调用数据访问层中相应的方法返回一个数据源不就可以了吗？这样做也不关接口什么事呀在企业级程序开发中，一般出于并发的考虑，可能需要较好的可伸缩性(就是可以把一套程序的不同结构层放在不同的服务器上，我是这样理解的)，这样的话以的最简单的三层结构举例子，UI层和逻辑层应该是放在同一台服务器上(我不知道能不能把它们分到两台服务器中去)，我把它叫做UI&逻辑服务器，而数据访问层放在另一台服务器中，我把它叫做数据访问服务器，还有一台是存放数据库

2、的服务器，这样 UI&逻辑服务器 与 数据访问服务器 中的程序可能就是2(或以上)个人开发的，两台服务器间的通讯一般是用WebService，这个我就不说了。按我上面说的，UI&逻辑服务器 中的程序应该是可以直接调用 数据访问服务器 中的类，这本身没什么问题，但到具体开发上时可能就会出问题了，比如 UI&逻辑服务器 中的程序开发人员甲在开始设计的时候需要调用一个 数据访问服务器 中的GetData()的方法，但这个时候 数据访问服务器 中程序的开发人员乙并不知道需要增加这个方法，那么甲的工作就继续不下去了，因为他的程序编译不了，假如这个时候甲定义了一个接口，然后在接口的定义中定义一个方法Get

3、Data()，当然这个方法里什么代码都不用写(具体的实现是由乙来做的)，然后乙写的程序都需要继承甲定义的这个接口，当乙的程序在编译的时候就会被提示哪些方法是必须被实现的，这样一来乙就随时都可以知道甲需要哪些方法来返回数据了，这样做最起码的好处是不用甲总需要告诉乙需要加哪些方法，而且也不会因为乙对数据访问层程序的误修改(比如误删除了GetData()这个方法)导致 UI&逻辑层的程序运行不正常，因为如果删除了GetData()的话，乙的程序是编译不了的。所以我的结论就是接口在层与层之间的作用主要是上层(比如UI&逻辑层)对下层(比如数据访问层)的一些限定，方便了开发，减少了不必要的沟通，也防止了

4、一些出错的可能。不知道这种理解是否正确，还请大虾指教需求分析的20条法则2009年08月27日 星期四 下午 11:272009-08-11 16:00需求分析的20条法则 邢学慧 -对商业用户来说，他们后面是成百上千个供应商，前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供应商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。软件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。 -经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。通过

5、通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营运的报告。” -分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。” -经理觉得奇怪：“我不是刚告诉你我的需求了吗？” -分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。” -经理：

6、“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？” -分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。” -经理坚持道：“行了，行了，我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发，并随时将你们的进展情况告诉我。” -风险躲在需求的迷雾之后 -以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业

7、务需求。在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴趣。这里所指的风险承担者包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。这部分工作做得到位，能开发出很优秀的软件产品，同时也会令客户满意。若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。因此可见需求分析奠定了软件工程和项目管理的基础。 -拨开需求分析的迷雾 -像这样的对话经常出现在软件开发的过程中。客户项目经理的需求对分析人员来讲，像“雾里看花”般模糊并令开发者感到困惑。那么，我们就拨开雾影，分析一下需求的具体内容： -业务需求反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定

8、义与范围文档中予以说明。 -用户需求描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。 -功能需求定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。 -非功能性的需求描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。 -需求分析报告报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。 -前面提到的客户项目经理通常阐明产品的高层次概念和主要业务内容，为后继工作建立了一个指导性的框架。其他任何

9、说明都应遵循“业务需求”的规定，然而“业务需求”并不能为开发人员提供开发所需的许多细节说明。 -下一层次需求用户需求，必须从使用产品的用户处收集。因此，这些用户构成了另一种软件客户，他们清楚要使用该产品完成什么任务和一些非功能性的特性需求。例如：程序的易用性、健壮性和可靠性，而这些特性将会使用户很好地接受具有该特点的软件产品。 -经理层有时试图代替实际用户说话，但通常他们无法准确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中。如果不这样做，产品很可能会因缺乏足够的信息而遗留不少隐患。 -在实际需求分析过程中，以上两种客户可能都觉得没有时间与需求分析人员讨论

10、，有时客户还希望分析人员无须讨论和编写需求说明就能说出用户的需求。除非遇到的需求极为简单；否则不能这样做。如果您的组织希望软件成功，那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面。 -优秀的软件产品建立在优秀的需求基础之上，而优秀的需求源于客户与开发人员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系。 -由于项目的压力与日俱增，所有项目风险承担者有着一个共同目标，那就是大家都想开发出一个既能实现商业价值又能满足用户要求，还能使开发者感到满足的优秀软件产品。 -客户的需求观 -客户与开发人员交流需要好的方法

11、。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。 -1、 分析人员要使用符合客户语言习惯的表达 -需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。 -2、分析人员要了解客户的业务及目标 -只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流

12、程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。s -3、 分析人员必须编写软件需求报告 -分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。 -4、 要求得到需求工作结果的解释说明 -分

13、析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。 -5、 开发人员要尊重客户的意见 -如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。 -6、 开

14、发人员要对需求及产品实施提出建议和解决方案 -通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。 -7、 描述产品使用特性 -客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价

15、值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。 -8、 允许重用已有的软件组件 -需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。 -9、 要求对变更的代价提供真

16、实可靠的评估 -有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。 -10、 获得满足客户功能和质量要求的系统 -每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。-11、 给分析人员讲解您的业务 -分析人员要依靠客户讲

17、解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。 -12、 抽出时间清楚地说明并完善需求 -客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。 -13、 准确而详细地说明需求 -编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但

18、烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。 -在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。 -14、 及时作出决定 -分析人员会要求客户作出

19、一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。 -15、 尊重开发人员的需求可行性及成本评估 -所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。 -16、 划分需求的优先级 -绝大多数项目没有足够的时间或资源实现功能性的每个细节。

20、决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。 -在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。 -17、 评审需求文档和原型 -客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建

21、议。 -更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。 -18、 需求变更要立即联系 -不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。 -19、 遵照开发小组处理需求变更的过程 -为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项

22、目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。 -20、 尊重开发人员采用的需求分析过程 -软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。 -“需求确认”意味着什么 -在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我

23、在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。” -这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。” -同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。” -这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确

24、方法，所以我们必须明白签字意味着什么。 -对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。 -需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人员的关系，为项目的成功奠定了坚实的基础。描述信息结构和交互设计的图示词

25、汇表 版本 1.1a (2001年9月17日) Jesse James Garrett (contact) 翻译于 2002年2月 Arky Tan 英语原版 目录：1. 摘要 2. 版本信息 3. 先决条件 4. 设计概念 5. 基本元素：页面、文件和相关文件组 6. 创建关系：连接和箭头 7. 同时发生：并发事件组 8. 分解：链接点 9. 元素集合：区域和区域叠代 10. 可再用模块：流程和流程引用 11. 基本的条件元素 12. 作出选择：决策点 13. 尝试：条件连接和条件箭头 14. 单项选择：条件分支 15. 多项选择：条件选择器 16. 一个决策，多条

26、路径：群组 17. 可能会涉及的限制：条件区域 18. 备注 19. 可以下载的图形库 摘要图表是网络应用开发团队（Web development teams）在沟通信息架构和交互设计方面最基本的工具。本文所讨论的是使用图表来描述系统时所要考虑的事宜、信息架构和用户交互设计时使用这些基本元素的要点，并且介绍这些元素的使用方法。 版本信息1.1aSC （2002年2月6日） 简体中文译本 1.1a （2001年9月17日） Macromedia FreeHand 新图形库 添加PDF的图形模板 1.1 （2001年1月31日） 增加文件组元素 增加条件选择器元素 修改箭头元素，增加多箭头说明路径

27、方向 修改群组元素，说明其可作为条件分支或条件选择器的下游元素 修改条件分支元素，增加其可能出现空结构的情况 修改图形库中的一些元素 增加Adobe InDesign 的图形库 1.0 （2000年10月17日） 首次发布 先决条件 图示词汇表是一套用于描绘某些事物（通常可能是一个系统、结构或过程）的符号库。本词汇表可能在信息结构和交互设计方面，在一个宏观程度上描述网站中用户体验的结构抑或过程。 本文中的描述、图表适用于以下五点主要角色： 项目主持人和项目经理 通过本文所描述的工具能够对项目的范围和形态有所了解。 内容制作人 以获得系统中的内容需求。 视觉传达和界面设计师 使用本工具能够计算出

28、设计工作量，并且初步了解系统的导航结构和界面设计的需求。 技术专家 以了解系统在技术方面的需求 信息结构和交互设计师 通过本工具能够对系统中的每个具体界面设计详细的导航和界面设计要求。 除项目主持人以外，其他四种角色的人员在进行自己的工作中多需要获得大量的详细信息，但问题在于每种角色所需要了解的信息都各不相同，而且差异很大。并且各个角色所需要的信息的数量与该角色的需求并不成正比。因此对于每个对象确实有效的功用是限定本图表的详细程度。从而能够使得采用本方法所描述的系统结构能够成功项目开发中每个角色所涉及的更详细的描述的基石。 此外，在信息架构和交互设计中对于本图示词汇表还有其他几个重要的要求，包

29、括： 易于书写 图表要足够的简单以便于用户能够快速手绘草图，同时每个图表元素之间需要有明确的区别，这样即便制图破损污染了也不会影响图表被清晰识别。 工具无关性 图示词汇表需要设计成为不需要特殊的软件工具来绘制图表。而虽然使用图示词汇表不需要用户使用特殊的软件工具但需要能够在各种用户的常用软件中能够方便绘制。 精练而系统完整 由于使用本方法的每位用户未必都很深入了解本方法（甚至未必有很大的兴趣），因此本图示词汇表应当不要求客户需要那样专业的知识和兴趣。所以整套元素必须尽可能的精练，严格地将概念和符号一一对应起来，以使图示词汇表能够快速地被用户学会和使用。无论所要描述的系统如何负责，每个表达符号作

30、为基本元素都必须具有自己简单明确的含义。 设计概念信息结构和交互设计好比是硬币的两面（在本文中所定义的条款请参见用户体验的原理（The Elements of User Experience） 。目前大多数网站和基于Web的应用系统都会涉及这两方面，而对任何一面来说，流程图表的目标是显然和另一方面所不同的。在这两方面，流程图表都从宏观结构上以一个适当的详细程度，让团队成员能够了解项目的大致描述。而系统构架师的职责就是决定流程图表 所说明项目目的适当详细程度。而详细到页面的内容，或微观结构将在以后的开发过程的文档中体现出来。 在描述信息结构时，图表应当着重于项目概念的结构和内容的组织。值得主意的

31、是项目概念的结构不同于导航性的结构，设计信息结构的流程图表的目的不是为了说明详细的导航性结构，因而最好 使用其他相关的文档来描述导航性结构的详细信息。 在描述交互设计时，需要注重于描述用户在系统定义好的任务和任务的每个过程中的行动流程，因此导航条、界面元素等详细信息将不会出现在流程图表中如果您发现自己在绘制按钮、文字域等元素的时候，可能您已经涉足过分细节的内容了。 因此本图示词汇表同时包含信息构架和交互设计的简单的概念模型为基础，用来描述： 系统提供给用户的可行路径； 用户在所有路径中的行为； 用户行为在系统产生的结果； 基本元素: 页面, 文件和相关文件组网络中用户交互的最基本单元是页面，因

32、此我们采用一个矩形符号来表示页面。值得注意的是，在此我们所提到的页面是一个表达单元，而不仅是网络交互过程中的一个 实际元素。因此流程图中的一个页面符号可能代表多个HTML文件（比如在一个采用帧的页面中集合了多个HTML文件）或多段程序代码文件（比如在服务器端调用的嵌入文件或数据库存储执行过程等）。 除页面之外，还有不具备网站导航属性的文件。通常文件都是给用户用于浏览器以外的操作（比如声音和图象文件、类似与PDF的独立格式的文档或可执行文件等）。对于文件，我们采用一个卷角的文档图标来表示。 图1a： 左侧 “页面”和“文件” 图1b: 右侧 “页面组”和“文件组” 我们采用页面组的符号来表示在宏

33、观结构上导航属性一致的一组功能类似的页面。同样的，文件组用来表示在网站的导航结构中被单一入口指向的一系列文件（ 比如一个可供下载的游戏集合或一个PDF说明手册库等等。）我们在页面和文件上加以标注用来鉴别他们，这些标注不必和实际名称（比如HTML中的“”标签）或文件名相互关联，但每个名称必须是在整个信息结构中唯一的。采用唯一的数字标识和类型名称是在整个信息结构中跟踪页面和文件的一个好方法。 创建相互关系：连接和箭头对于元素之间的关系，我们采用连接来描述。这种概念上关系将不可避免地别描述为导航关系，但是不是所有的导航关系都会出现在信息框架图表中。 在描述信息结构时，页面之间的层基组织关系通常被描绘

34、为一个树形的结构，但这种方式决不是唯一的而恰好是推荐使用的。 图 2a: 左 一个简单的树形结构 图 2b: 右 与2a同样的结构，但是表述方法不同。 当使用流程图表来描述交互作用时，每个连接都需要具有方向以表述用户是如何在系统的每个任务中移动，因此将连接改成箭头将有助于说明。对于移动的过程，我们采用下游和上游方向条件来描述元素的相对位置关系。值得注意的是这些箭头不似那些用来单行道的箭头，而更象超级市场里指示食品部的那种箭头。因为指示箭头的目的不是禁止用户向别处同行，而是仅仅说明用户想要行动的方向。 可能出于某些原因，我们可能要禁止用户向上游移动（比如在进行象删除数据库记录之类不可撤销的操作的

35、时候），采用一个在箭头的反向终点加一个横条（一条相垂直的短线）来描述。 在某些情况下，我们可能需要在上游附近加一个箭头以在更复杂些的结构中说明流的方向。（一个实用提示：不少制图程序不允许用户将箭头画成这样。为了解决这个问题在图形库中已经包含了一个名为“gluedot”的元素。这是一个隐藏的单个锚点元素，使用这个元素可以将箭头链接在一起。） 图 3a: 左上 描述任务过程中用户向下游移动的箭头 图 3b: 左下 横条说明向上游的移动是被禁止的 图 3c: 右 表明方向的多个箭头 连接和箭头同样也可以加上标注，但是最好只有在用户行为需要被说明时才使用标注，否则冗长和笨拙的标注会使整个流程框架变得混

36、乱。但必须加以很长的说明时，我们可以采用脚注或附录的方式。 在本文给出的示例中，脚注和附录的参考说明可以使用圆括号中数字与字母结合的方法来说明。数字用于说明当前注释在图表中的出现的页面，字母用于说明是该页中的第几项。比如在流程图表的第三页中的第一个的注解可以表示为：(3a)，第二个可以表示为：(3b)，依此类推。 图 4a: 左 一个失败的标注 图 4b: 中 一个有用的标注 图 4c: 右 一个脚注或附录的标注 同时发生: 并发事件组并发事件组（表示为一个半圆形符号）是用于描述一个同时产生多个结构得用户行为（比如出现一个弹出窗口得同时主窗口下载页面，或者显示一个页面的同时开始文件下载。）和箭

37、头一样，并发事件组等元素都是具有方向性的。出于上游的元素链接到并发事件组符号的曲线边，而处于下游的元素链接到并发事件组的平边上。 图 5: 并发事件组符号的使用 分解：链接点描述信息结构的图表通常希望能够有足够大幅面的图纸用来绘图。但是即便采用绘图机等大型的输出设备，一些结构也可能仅因为太复杂而无法使用单一的图表中全部囊括。因此为了链接图表页面的间隙，我们采用链接点（表示为方括号）使用户易于将图表拆分成容易消化的模块。 单个链接点可以根据需要被链接至一个和多个资源图表或目的图表。同时方括号的方向（垂直或水平）并没有特别的含义，至于采用什么方向的方括号完全取决于设计师的审美。 图 6a: 左 一

38、个“链接至”的链接点将读者引向下一个图表 图 6b: 右 一个“链接自”的链接符号说明表6a是从何处离开本图表的。 元素集合：区域和区域叠代区域元素（表示为圆角矩形）用以表示一组共享一个或多个基本属性的页面的集合（比如同在一个弹出窗口中显示的页面或者具有一些独特设计规定的系列页面等）。在区域元素上加上标注以说明这些属性，同我们在链接器的说明使用方法类似，如果有很多属性需要说明的话可以使用标注连接到其他文档中的其他注释。 图 7: 使用一个区域元素来表达弹出窗口的示例 不少设计师常会反复使用相同的基本机构来描述大量功能相同的信息元素，比如您可能遇到一个产品目录，其中每个产品都有若干的页面与之相关

39、联。此时，您当然可以使用为每个产品绘制一个信息结构的引例，但是这样做难道不是很浪费时间吗？因此遇到类似的情况时，请使用区域叠代（表示为一堆圆角矩形）。 图 8: 使用区域叠代来表示产品目录中重复的结构。 值得注意的是链接器和箭头实际上并不是指向区域元素的，区域元素仅仅用于封装一些页面。因此使用区域元素时需要小心使用区域元素能够很方便地表述各种用户体验中无法表明地细节信息（比如哪些文件是存放在哪台服务器上的），但是同时不当的使用也可能会混淆流程图表在宏观结构上的说明能力。 可再用模块：流程和流程引用一些用户交互功能的设计师常常需要在不同的过程中反复描述一系列相同的步骤（比如用户登录过程）。通常这

40、些步骤是系统的一个功能模块或者一个需要用户完成的较大的任务，就这一点与计算机程序设计中的子程序非常类似。 这样一个可以重复步骤叫做流程，在图表中我们使用两个元素来表示流程：第一部分是用于说明流程本身结构的流程区域；另一部分是流程引用，作用类似于一个占位符，在系统结构中每个出现被引用的流程的地方作为。这两个元素都具有相同的基本形状一个去角的矩形（如果你愿意，也可以使用变形的八边形）。流程区域需要两个特殊的链接点：进入点和退出点，它们都位于流程区域之外用于说明流程的开始处和截止处。 图 9a: 左 流程引用的使用示例 图 9b: 右 图9a中引用的流程区域 流程引用就其本身而言和链接点很类似，它们

41、的作用都是让设计师将图表分散成不同的模块。它们的区别在于流程引用是同时链接在两个过程之中，它具有“链接自”和“链接至”的步骤，而一个链接点仅能具备一个步骤。因此如果您需要使用模块但并不同时具备来源和去向那么就不必使用流程元素。 基本的条件元素伴随机构分析问题的深入，在信息结构和交互设计的构成中我们往往需要根据用户在系统中行动而动态地调整系统的功能结构。一般这种动态调整都通过条件逻辑来实现，因此在本文的后半部分我们将讨论条件逻辑结构的表达方法。当然我们在此所论述的都是系统应用中基本模块的条件元素： 系统将跟踪以下一个或多个属性，这些属性可能是： o 用户，或用户类型； o 对话时间，比如登陆的状态； o 被访问的内容，比如主题内容； o 日期或时间； 每个属性都具有值（“3p.m.”可能意味着一天中的时间）。 一个属性的特殊值所关联的内容被成为条件。 条件将由系统来判断是否正确。 在静态的结构中，每条系统中的行动路径都被呈现给每种情况下的每个用户，而且每条路径都指向相同的结构。在一个动态结构中，系统根据对一个或多个条件的判断来决定哪条路径应当递送给用户。为了精简结构的流程图，这些条件在伴随整个文档的注脚或附录中说