架构讲义1-2

 

第一章   软件架构设计思想与体系创建

 

 

第一节   软件架构师的角色和应掌握的知识体系

 

    一、软件架构

 

    软件架构（software archiecture）的一种定义是这样的：

    架构是一组有关如下要素的重要决策：

    软件系统的组织，构成系统的结构化元素，接口和它们相互协作的行为的选择，结构化元素和行为元素组合成粒度更大的子系统的方式的选择，以及指导这一组织（元素及其接口、协作和组合方式）的架构风格的选择。

   

软件架构可以有多种定义，不管对软件架构如何定义，所有的定义都有一个共同的主题，那就是必须考虑诸如原理、组织、风格、模式、职责、协作、连接、系统的动机和主要子系统等大尺度方面的问题。

 

软件架构实际上是两个层面的事情，一个是设计构造一个完整的软件系统，这里的架构也称作软件体系结构（Software Archiecture）。另一个层面是构造一个统一的共享的框架或者称架构（Framework），这种架构事实上是系统的一个基于服务的层。

软件架构在整个软件开发过程中，是处在软件体系结构设计阶段（设计），它的必要的输入，是来自需求工程（分析），而它的输出，是实现设计（编程），因此这是一个承上启下过程节点。

 

    在软件开发中，架构既可以是名词，也可以是动词。

    作为名词，架构包括上面所定义的内容。

    作为动词，架构一部分是调研，一部分是设计，更清晰的，是架构调研和架构设计。

 

    架构调研：

    是指识别对系统存在或可能存在重大影响的功能性或非功能性需求（特别是非功能性需求），例如市场趋势、性能、成本、维护和系统演进等。广义上，是对系统的重大设计决策有特别影响的需求进行分析。

 

    架构设计：

    是对软件、硬件、网络、运营、政策等软件设计中的需求和要素进行决策。

在统一过程里面，架构调研和架构设计统称为架构分析。

 

软件架构设计是一个系统工程，它需要系统构架师有很宽的知识面，从需求分析、架构设计到类设计甚至代码实现都需要有透彻的理解，这之间的关系是你中有我我中有你，是不可能截然分开的。

 

在这个课程中，我会站在相对抽象的角度，对软件系统设计的思想和方法做一些讨论，这些观点，也是不少资深系统架构师经验的集合。必须说明，软件系统设计的方法不是一个僵化的规则，我表达的一些观点你也不一定赞成，这不要紧，关键是在实践中实事求是的摸索规律，从而找出一些符合实际的方法来。

 

    二、软件架构师的角色

 

    尽管对软件架构师的角色有这样或那样的定义，但大体上下面几个职责是必需的。

    1、技术负责，解决方案的提供者

    2、与项目经理合作，制定计划，决定成员，组织团队

    3、保证项目按计划和走向完成

由于设计是由需求驱动的，所以，掌握需求分析的技巧，是一个好的架构师必备的能力。

 

    三、软件架构师最难处理的问题

 

1、不是做什么，而是不做什么

    2、不是从纯技术的角度来考虑整个项目

    3、预见客户走向，早期决定技术研发

    4、不能使用时髦但不可靠的技术

 

    四、如何成长为一个好的系统架构师

 

架构师必须关注需求、分析需求，有人认为架构师只是在需求出来以后，把它的实现模型做出来就行了，真要是这样，那做一个架构师未免也太容易了。

事实上，现代迭代开发所有的驱动力都在于需求变更，如果架构师不关注需求，不关注和用户的讨论和沟通，那是很难设计出真正有用的东西来的。

软件架构设计是一个非常严肃、细致、敏感而且困难 的工作，必须一点一滴认真做起，扎扎实实的努力，实实在在的积累经验，尤其是在失败中积累经验，这是一个软件架构师成功的必由之路。

为此，我们需要注意下面几点：

    1、首先必须是一个好的程序员，技术上要强

    2、知识结构：对象的观点，UML，RUP，设计模式

       关键不是懂得了原理，而是灵活融合的应用

    3、系统的观念：分析能力，把握抽象的能力

    4、沟通能力：与客户沟通能力，与项目其它成员的沟通能力

    5、知识面要广，把握行业流行趋势，但不要赶时髦

    6、灵活机动，不能教条

 

    五、几个观点

 

    1、要承认软件是不完美的

    2、要承认需求是不完全的

    3、关键是拥抱变化而设计

    4、各种性能标准，什么是架构师最关注的呢？

    5、架构师最重要的素质：把握重点。

 

注意：灵活的把握，实事求是的分析，

          善意和把握重点的沟通，

          有先见性的设计，

      这是一个优秀的系统构架师活的灵魂。

 

第二节   软件分析和设计的方法学问题

   

由于架构设计的源泉来自于软件分析，不同的分析与设计方法，将会带来完全不同的架构思路。从方法学的角度来讲，目前分析和设计方法主要分为面向过程的方法与面相对象方法两种。

 

一、面向过程的方法

 

面向过程方法又称为结构化方法，起源于20世纪70年代，主要由面向过程分析、面向过程设计和面向过程编程三部分组成。

面向过程分析：帮助开发人员定义系统需要做什么（处理需求），系统需要存储和使用那些数据（数据需求），系统需要什么样的输入和输出，以及如何把这些功能结合在一起来完成任务。面向过程分析的主要工具是 数据流图（ DFD ）,这是一种显示面向过程分析中产生的输入、处理、存储和输出的图形模型。

在现代面向过程设计中，也引入了事件的概念。

面向过程设计：面向过程设计是为下列事务提供指导：程序集是什么，每个程序应该实现哪些功能能，如何把这些程序组成一张层次图。面向过程设计的主要工具是 结构图，这是一种表达程序模块层次的图形模型。

面向过程编程：具有一个开始和结束的程序或者程序块，并且程序执行的每一步都由三部分组成：顺序、选择或者循环结构，实现这种思想的最典型的语言就是C。

整个面向过程设计的根本目标是：把复杂的系统分解成简单模块的层次图。

 

二、面向对象的的方法

 

面向对象的方法由面向对象分析（OOA）、面向对象设计（OOD）以及面向对象编程（OOP）三部分组成。

面向对象方法与面向过程方法根本区别，是把信息系统看成一起工作来完成某项任务的对象集合， 而对象是系统对消息作出做出响应的事物，所以面向对象方法中最值得关注的不是它该做什么，而是它如何做出反应，也就是消息，这是和面向过程方法的根本不同。

面向对象分析（OOA）：定义在系统中工作的所有类型的对象，并显示这些对象如何通过相互作用来完成任务，主要工具是 统一建模语言（ UML ）。

面向对象设计（OOD）：定义在系统中人机进行通讯所必需的所有类型的对象，并对每种类型的对象进行细化，以便可以用一种具体的语言来实现这些对象。

面向对象编程（OOP）：用某种具体语言（C++、Java、C#、C的对象模块等）来实现各种对象的行为，包括对象间的消息传递。

这里的关键是类图：用面向对象的方法显示系统中所有对象所属类的图形模型。

面向对象的方法起源于20世纪60年代挪威Simula编程语言的开发，80年代建立了整体框架，90年代由于C++的崛起和UML被广泛认可，逐步成长为一种主要的和现代的分析和设计方式。

面向对象的方法和传统面向过程方法有很大不同，它的思维方式不是以设备结构为基础，而是利用可感知的对象来思考，对人而言，这是更加自然或者直观的。但是，如果只是把传统概念简单包装一下换成对象方法（比如封装），并不能得到实实在在的好处，反而使OO很难理解，面向对象的方法关注的是事件、重用和继承，关注的多态，它自己有一整套独特的思维方式，这和面向过程方法是根本不同的。

90年代中期以后，这种关注带来了许多新的思维，有代表性的就是设计模式的提出，设计的质量更高，系统的优化空间更大，这就是说应用面向对象的方法，将会给我们提高设计质量带来巨大的好处

由于面向对象方法把对象看成系统对消息做出响应的事物，这种与面向过程完全不同的看待计算机系统的方法，必然导致完全不同的分析、设计和编程方式。有人认为，学会了UML几张图或几个符号，就会对象方法了，这是个误会，UML只是一个表达的工具，关键是在什么层面上去思考。

有个问题，是不是使用面向过程的程序语言（比如C），就一定要使用面向过程方法，实践表明并不是这样的，面向对象更多的是一种思维方式，面向过程的语言只需要略加改造就可以应用这种思想（继承、封装、多态），国外在这些方面有很多成功的案例和讨论，国内在一些大型嵌入式项目中也有很好的尝试。

一般来说，面向过程技术与面向对象技术是不能混用的，因为这两种设计技术基本思想是完全不同的，基本的原则也是不一样的，面向过程设计提供的是系统功能的体系结构，而面向对象技术是建立一系列交互对象的体系结构，思维不同，方式重点也必然不一样，这点是需要说清楚的。

在这个课程中，我们将沿着软件分析和设计的过程，重点研究面向对象的方法，同时与面向过程方法对比着，把思想方法和工作方法讨论清楚。

 

 

第三节   在信息技术战略规划（ ITSP ）中的软件架构

 

一、利用信息技术战略规划整合客户需求

 

信息技术战略规划（ITSP）的核心思想简述如下：

在信息时代，知识经济下，正确的结合IT规划，整合的核心竞争力，在新一轮的产生、发展中取得更大的市场竞争力是必要的。

信息化的问题首先是企业管理层概念的问题。企业管理层的重视，和对信息化的高度认同是企业信息化的关键所在。当前国内很多企业管理层很关心资本运作的问题，而对很多国企业而言，管理层最关心的是扭亏增盈。信息化建设投入大、周期长、见效慢、风险高，往往不是企业需要优先解决的问题，导致管理层对信息化的重视程度不够，无法就信息化建设形成共识

对企业管理信息化带来的管理模式变化不适应，又抵触心态，或者仅是为了形象问题，赶潮流搞信息化。国家提出信息化带动工业化，信息化成为一种时髦，信息化工程往往成为企业的形象工程。

有些公司缺乏统一完整的IT方向，希望上短平快的项目，立竿见影，跳过系统的一些必要发展阶段，导致系统后继无力，不了了之。20世纪末的电子商务热潮充分说明了这个问题。

有些公司对信息化建设的出发点不明确，在各个方案厂商铺天盖地的宣传下，不能很好的把握业务主线，仅是为了跟随潮流，既浪费了资源，同时也对后继的信息化造成了廖不良的影响，甚至直接导致“领导不重视”这样的后果。

如今国家正在大力推广企业信息化。然而人们大多从技术角度来谈论信息化和评价解决方案，他们往往脱离了企业的实际需要，以技术为本是不能根治企业疾病的。企业依然必须明确自己的核心竞争力。明确一切的活动和流程都是围绕让核心竞争力升值的过程。IT规划意识如此，必须也企业核心、业务为本。再结合公司的实际情况。开发自己需要的系统。

信息化的建设难以对投入产出进行量化，难以进行绩效评估，CIO们无法让企业管理切实感受到信息化带来的直接效益——经济效益、社会效益。

 

战略规划是一套方法论，用于企业的业务和IT的融合以及IT自身的规划。必须满足如下要求：

1. 先进性：采用前瞻性、先进成熟的模型、方法、设备、标准、技术方案，使建议的企业信息方案既能反映当前世界先进水平，满足企业中长期发展规划，又能符合企业当前的发展步调，保持企业IT战略和企业战略的一致性。

2 . 开放性：为保证不同产品的协同运行、数据交换、信息共享，建议的系统必须具有良好的开放性，支持相应的国际标准和协议。

3. 可靠性：建议的系统必须具有较强的容错能力和冗余设备份，整体可靠性高，保证不会因局部故障而引起整个系统瘫痪。

4. 安全性：建议规划中必须考虑到系统必须具有高度的安全性和保密性，保证系统安全和数据安全，防止对系统各种形式的非法入侵。

5. 实用性：规划中建议的系统相关必须提供友好的中文界面的规范的行业用语，并具有易管理、易维护等特点，便于业务人员进行业务处理，便于管理人员维护管理，便于领导层可及时了解各类统计分析信息。

6. 可扩充性：规划不仅要满足现有的业务需要，而且还应满足未来的业务发展，必须在应用、结构、容量、通信能力、处理能力等方面具有较强的扩充性及进行产品升级换代的可能性。

 

为了实现这样的规划，我们必须注意到，软件设计既是面对程序的技术，又是聚焦于人的艺术，成功的软件产品来自于合理的设计，而什么是合理的设计呢？

一个软件架构师最重要的问题，就是他所设计的产品必须是满足客户战略规划的需求，能够帮助客户解决实际问题的，因此一个合理的设计，首先要想的是：

Who：为谁设计？

What：要解决用户的什么问题？

Why：为什么要解决这些用户问题？

这是一个被称之为3W的架构师核心思维，如果这个问题没搞清楚，就很快的投入程序编写，那这样的软件在市场上是不可能获得成功的。

Who? Waht? Why? 这三个问题看似简单，但实际上落实起来是非常困难的。我们经常会看到一些产品，看似想的面面俱到，功能强大，但为什么最终没有得到用户的广泛认可呢？一个专家感觉非常得意的东西，普通的使用者未见得感觉满意，这些情况在我的实践中屡见不鲜，即使一些知名的公司在设计的时候，往往都不能很好地把握，这足以证明我们必须下功夫来面对它。

那么，我们该怎么来做呢？

 

很重要的问题是，设计的目的是为了生存，设计的源泉是来自于用户，满足用户的需求，能够帮助客户产生可度量的价值，又便于用户使用，减少维护和培训的资源消耗，而且制作生产工艺尽可能简单，这就是设计之本。

 

二，错误设计的几个原因

 

但是我们的设计中，违背这样的原则的情况还是时有发生的，大致来说有这么几个原因。

 

1 ）新颖的技术成为设计之本

 

不少设计人员迷恋于新颖的技术，总是倾向于用刚刚流行的新鲜技术来设计他们的软件，他们总是认为只要用了新的技术，就能够写出最好的软件产品，用户也一定会喜欢。

其实这是个误会，人们购买软件产品，并不是购买它的技术本身，而是为了他的需求来购买，也就是说是市场决定了产品的设计，而不是技术决定产品设计，这一点千万不要本末倒置。

事实上美国每年倒闭的高科技公司，90%并不是因为技术落后而倒闭，而是因为没有正确的了解市场，换句话说，我们不能因为个人的兴趣而设计软件。

 

2 ）把软件当成自我表达的方式

 

由于软件工程师属于高智商群体，热衷于发明，热爱技术，这样往往不自觉地把软件设计当成自我表达的方式，用于表达自己的智慧，以及表达自己对于技术的理解。

这样的结果往往聪敏反被聪敏误。

原因很简单，市场的规则往往决定了产品的命运，而不是技术本身。

我们应该对市场和已有的产品作为模型来调查，搞清楚用户对产品的要求到底是什么？产品的设计应该来自于市场的调研，而不是对新技术的激情，新的技术只有用在合适的地方才有生命力，而不应该是一种无目的的自我表达。

新技术的采用只有在需要的时候才有意义。

 

3 ）把软件设计成万能的

 

最可怕的是，把软件设计成万能的，几乎能满足一切需要，而忽略了技术上的可行性。

没有进行可行性分析的软件产品，通常会导致软件的失败，而且浪费大量的人力物力。一个技术上不成熟的产品流入市场，必将被市场淘汰。典型的例子是日本的第五代计算机、语音翻译、人脸识别等等，听着好听，这些公司都倒闭了也是事实。

 

4 ）过分强调功能，而不是使用的方便性

 

给用户做一件事情，称为“有用的”；

如果一个功能是用户可以方便的使用的，称为“可用的”；

这是两个完全不同的概念。

如果过分强调“有用的”概念，把算法、系统等等放在思考问题的首位，而忽略了方便性，这样的软件往往并不能被用户接受。

软件可用性往往和对用户心理研究是紧密相关的，具体落实在界面设计上，在软件工程界往往有一种轻视界面设计的倾向，其实这是错误的。

现在的问题在于，很多设计者往往只注意需求文档甚至文档格式，但不注意挖掘需求过程用户所表达的思想内涵，这也是导致不恰当设计的一个重要原因。

 

三、利用 ITSP 提升企业竞争力的案例陈述

 

泛泛地说体系结构设计的理念是没有用的，所以整个课程贯穿一个简化的TB公司电源设备销售服务信息系统的案例，这个简化的例子可以认为是在信息技术战略规划（ITSP）项目中一个构思，根本的木的是企业利用信息化技术提升自己的销售业绩，信息化技术使企业利用信息系统对自己的业务过程和行为方式作充分改进成为可能，这种可能引发了企业建立信息化体系的强烈需求。

通过这个案例的研究，我们还可以发现更多的方法学知识。

 

1 ，问题陈述

 

在研究这个陈述的时候，请体会这里是如何体现 Who? Waht? Why?这三个W的。

 

 

项目名称：电源设备销售服务信息系统 项目单位：TB公司电源设备销售部 最后修改日期：****年**月**日
项目目标	TB公司电源设备销售部是一个以硬件系统配套设备提供商为基本客户的专业电源设备配套提供商，销售的设备来源一部分是自主生产，另一部分由多家国内外知名品牌的电源设备生产商组成供应链。本项目将开发新的业务过程以及相应的信息系统过程和服务，以支持该公司的产品和分级客户服务的战略。预期最终的系统将提供高度集成的过程和服务，这些过程和服务将跨越多个内部业务部门，直接到达客户。该项目预期将实现以下内容： 1，开发一个基于Web的网上销售系统，使销售渠道顺畅。 2，开发一个功能全面应用灵活的内部信息系统，使TB公司在高度竞争的市场中，带来显著的竞争优势。 3，与客户（硬件系统配套设备提供商）建立一种伙伴关系，其中包括购买电源方案、安装电源设备方案和定制电源设备配套方案，以产生竞争优势。注意，这个方案可能需要重新设计业务过程，这个替代方案假定客户的特殊需求可以和本公司的供应商（电源设备生产厂商）协作完成，并且允许供应商把这些修改加入到他们未来的产品中去，但是，设备生产商的改进将被合同限制在一定时间之后才能销售给本公司的其它竞争者。
项目概念	这个项目是在信息技术战略规划（ITSP）项目中构思的，战略信息系统规划为应用系统、数据库和网络（包括使用因特网作为战略平台）。因为市场被认为是优先级最高的考虑，所以，一个方便的网上订单处理系统，和一个跨部门的高度集成的客户服务系统被认为是最重要的系统之一，同时也和另一个高优先级的库存和供应链系统有合适的接口。
问题陈述	基于Web的网上订单系统主要用于是客户可以方便的自主组合订单。 客户服务系统主要与订单处理系统结合处理客户订单，并且可以按分级处理方式处理客户订阅，多年以来本公司主要使用Microsoft Excel作为主要的工具，所以现有的计算机处理只是一种初步的方式。该部门急需有一个方便的网上电源销售系统，另外灵活多变的销售策略是提升销售业绩的主要方法，但它们和现有的企业信息系统并不兼容，难以提升整体的效率，为此销售部门在讨论中提出了以下具体问题： 1，经常变化的产品组合导致的不兼容，应急配备的系统产生内部的低效率以及与客户关系复杂化。 2，产品构成的易于变化为建立新的基本客户创造了机会，这些易于变化的特征将会吸引未来的客户，但是目前的系统和工作方式并不支持这种易于变化特性。 3，在扩大业务的过程中由于积极的广告行为和基本客户量的大幅度增加，不久将会超出现有方式的实时事务处理的能力，向客户发货的延迟将会导致现金流动困难。 4，管理层建议实现一种“优惠级基本客户”制度，这种制度不能在现有的工作方式上实现，比如不同的业务人员接待具有“优惠级基本客户”资格的同一个客户的时候，难以使用相同的规则。 5，未付款的订单比两年前增加了2%，发现主要原因是业务量增大以后，由于未付款客户检查过程繁复而遗漏是主要问题。 6，两年中，无效合同增加了7%，根据分析主要原因是目前的工作方式对合同的有效性难以确认。 7，来自其它企业的竞争，迫使管理层提出了一个动态调整“优惠级基本客户”策略的方案，但现有的工作方式无法做这种动态的改变。 8，某些应急配备设备客户的订单没有得到及时处理，长时间的延时导致客户拒收或者后期处理耗尽仓库的库存。 9，TB公司的管理层意识到，电源设备销售目前部分使用了计算机处理营销服务渠道，但由于与公司其它营销模式不匹配，难以提升整体效率，但是网上电源销售的成功坚定了管理层的信心，改变这个现状事实上已经成为该公司未来发展战略的一部分。
项目影响范围	这个交叉功能项目将支持或者影响以下的业务功能或外部团体： 1，营销 2，订阅 3，销售和订单录入（对所有的销售办事处，工作方式应该是相同的） 4，仓储（对不同地域的仓储中心可以实现统一调度） 5，库存控制和采购 6，发货和验收 7，所有的不同级别的客户服务 8，外部团体    a,潜在客户 b,客户 c,曾经的客户 d,供应商 e.生产厂 项目范围在项目执行过程中可能会发生变化，但第一阶段尽可能的清楚界定。
项目构想	信息技术战略规划要求该系统必须做到： 1，通过改进数据收集技术、方法、渠道和决策支持加速订阅和订单的处理，管理层希望原有的因特网销售系统略加改造就能够加入到本系统中去，成为本系统的一个子系统。 2，到****年底，未付款的订单减少到2%。 3，到****年底，无效合同减少到5%。 4，到****年底，在现有人力资源基本不变的情况下，订单处理能力提高3倍。 5，系统将可以协助完成动态调整“优惠级基本客户”策略的方案，同时可以检查合同结构，并支持在线的动态合同修改。 6，便于重新考虑引起客户抱怨的底层业务过程、程序和策略。 7，提供改进的订单和应急配备设备客户的跟踪机制。
业务限制	新系统必须符合以下要求： 1，系统的第一个版本必须在9 个月内完成，后续的升级版本必须每6 个月发布一次。 2，没有会计部门的同意，不得改变现有系统的任何文件和数据库结构。 3，作为TB公司通过ISO 9000认证这个战略目标的一部分，所有的业务过程都需要接受业务过程重构，以改进全面质量管理并支持持续改进。 4，系统必须具备很好的可维护、可升级以及安全性。
技术限制	新系统必须符合下面信息技术架构标准： 1，局域网架构为基于服务的三层架构，客户端为Windows应用程序，服务器操作系统为Windows 2003 Server。因特网服务则使用Internet Information Server（IIS）。 2，该项目要求开发一个或者多个企业数据库，数据库服务器操作系统为Windows 2003 Server，希望能自动实现数据备份，从各种因素考虑，数据库采用Sql Server 2005。 3，该项目开发的应用系统采用Microsoft.net 2005，首推的语言为C#，在某些特殊的地方也可能使用VC++编写的结构块，但是，并不拒绝在必要的情况下使用Java语言。 4，外部客户所使用的环境一律使用浏览器，但并不限制操作系统，对不同级别的客户，权力要实现限制。 5，内部员工一律使用Windows XP或升级版本，除了浏览器外，还可能使用桌面应用程序，需要预装Microsoft.net Framework 2.0（或以上版本）。
项目组织方式	为此项目成立专门的开发管理班子，职责为： 1，任命项目经理 2，任命首席构架师和分析师 3，任命项目经理推荐的项目团队 4，评审并批准项目发布的内容 5，确保项目符合管理层的想法 6，认可所有的范围、预算和计划变更 要求项目团队每周召开情况工作会议，由项目经理组织，并把细节报告给管理班子。 开发团队需要建立自己的开发网站，其主要的内容为软件架构文档（Software Architecture Document SAD），用以公布项目决策的概要和架构的视图，便于开发成员了解项目的进程和主要思想。

 

 

2 ，子系统组成

 

下面只列出了本课程作为案例的子系统说明。

 

电源设备销售服务信息系统各子系统功能说明
编号	子系统	功能说明	要求
1	订单处理子系统	1，客户直接利用因特网构建电源设备购买订单。     2，客户可以选择标准配置，也可以在线建立自己的配置。 3，对每一种配置，系统通过客户服务系统提供客户相关信息计算销售价格。 4，订单通过仓库服务系统获取发货策略。	订单生成使用Web页面。 内部服务使用桌面程序。
2	客户服务子系统	1， 实现客户分级管理策略。 2，处理客户订阅。 3，处理客户资料。 4，处理订单和客户资料。 5，查询客户购买历史。 6，处理促销方案。 7，每日生成默认合同报告。 8，向订单处理子系统发送价格处理结果。	客户订阅和查询使用Web页面。 内部处理使用桌面程序。
3	仓库管理子系统	1，处理库存。     2，处理进货。     3，决定发货策略。     4，有供应链子系统获取供货信息。	使用桌面程序。

 

 

第四节   软件生命周期设计与统一软件开发过程

 

一、软件设计的生命周期与基本过程

 

软件开发过程描述的是软件构造、部署还有维护的一种方法，成功的软件设计过程更多的是研究用户和市场，而不是技术本身。

经典的瀑布式过程大致的情况是这样的：

1）收集市场数据，做市场分析。

2）确定用户，与用户交流，理解用户，理解用户的工作并与用户建立良好的关系，以便将来的设计和开发过程中经常得到他们的反馈意见。

3）建立典型用户群，通过对用户工作的了解，发现和自己设计工作有关的典型用户群。这些典型用户群应该能够描述用户工作中的一个或者几个重要环节。

4）与用户交流进一步细化典型用户群，并写出场景脚本。

5）确定软件的主要功能。

6）确定这些功能的主次，并确定优先级。

7）确定需求并写出说明书。

8）由用户群检查需求说明书，看需求说明能不能满足用户的需要。

9）进行软件体系结构设计。

可以看出来，在这个过程中软件分析占了软件设计很大一部分工作量，用户、市场、分析、设计，是整个软件设计中密不可分的几个部分，这样一个过程也称之为“瀑布式”过程，可以用图形描述如下：

 

 

成功的软件开发过程的最显著的特点，是把“研究和开发”活动与“生产”活动明确的分开。

 

不成功的项目大多具有以下特点：

1，过分强调研究和开发，进行太多的分析和书面研究，因此工程基线被推迟。这种状况，在传统的软件过程中倍受推崇，也是传统软件过程需要改进的原因。

2，过分强调生产，匆忙做出判断和设计，编码人员过分卖力的做不成熟的编码，造成持续不断的删改。

 

成功的项目，当从研究阶段到生产阶段的转变的时候，有十分明确的项目里程碑。

较前期的阶段，侧重于功能的实现，较后期的阶段，侧重于如和实现交付给客户的产品。

 

由此形成了如下过程。

1 ，立项管理流程

2 ，项目规划流程

3 ，需求管理流程

4 ，需求开发流程

5 ，技术预研流程

6 ，系统设计流程

7 ，实现与测试流程

8 ，系统测试流程

9 ，配置管理流程

10 ，质量保证流程

11 ，结项管理流程

12 ，服务与维护流程

二、顺序“瀑布”生命周期所带来的问题

 

经典的软件开发生命周期是顺序的、线性的或“瀑布”的生命周期，最常见的步骤如下：

1）澄清、记录和承诺一组完整的已经冻结的需求。

2）设计基于这个需求的一组系统。

3）基于设计，实现系统。

但是，这样的开发过程往往带来了很多问题，这些问题促使了统一软件开发过程（UP）的提出，这是一种流行的构造面向对象系统的软件开发过程，并已经被广泛采纳。

统一过程（UP）把普遍接受的最佳实践（迭代生命周期和风险驱动开发），合并为内聚和具有良好文档的过程描述。而迭代开发是在统一过程中最有价值的实践，它是软件开发的一种巧妙的方法。

MIT Sloan Management Review（麻省理工学院项目管理评论）所刊载的一个为时两年对成功软件项目的研究报告指出，软件项目获得成功的共同因素，排在首位的是迭代开发，而不是瀑布过程。

（其它的因素是：

 2，至少每天把新代码合并到整个系统，并且通过测试，对设计变更做出快速反应。

 3，开发团队具备运作多个产品的工作经验。

 4，很早就致力于构建和提供内聚的架构。

 这四个因素中有三个在UPO中有显式的实践。）

为什么会是有这样的结果呢？

 

三、迭代开发希望能解决的问题

 

需求变更对项目过程的影响

所谓需求，是系统必须提供的能力和必须遵从的条件。

需求最根本的挑战在于：

寻找、交流并记录什么是真正需要的，并能够向用户和开发团队讲解。

一个关于影响项目进展的因素的研究如下图。

（Jim Johnson 1994 Chaos:Charting the Seas of Information Technology. Published Report .The Standish Group）

 

 

可见37%的问题都与需求有关，这就需要“需求管理”。

早期需求管理是瀑布式的，也就是说在项目的第一阶段，在任何设计和实现工作之前，尽可能的推敲，把需求完全定义清楚，并把它稳定下来，并且实际开发前冻结需求，但历史证明这种方式是失败的，在项目很大的时候，冻结需求几乎没有可能。

正是这种困难，迫使人们在项目过程控制中，转而使用迭代式方法，所谓迭代式方法，是用一种条理化的方法来寻找、记录、组织和跟踪不断变化的需求。

这里的关键是“不断变化”这个词，把需求变化作为项目进展的不断驱动力，另一个重要的词是“寻找”，可以通过写出用例和召开需求研讨会等手段巧妙的得出需求。

整个问题都来自于，用户往往对自己的愿望并不清晰，需求会不断的变化。

所以，我们必须使用一种处理过程，这种处理过程的特点就在于适应这种需求的变化。

很多单位为什么放弃了多年使用面向过程方法，转而研究面向对象的方法，需求变化的困扰是一个主要原因，而面向对象的设计和分析，所有问题的焦点都聚焦于如何适应变化上，这是一个值得我们关注的课题。

 

统一过程（UP）提倡了几种最佳实践，其中影响力最大的实践，那就是迭代开发。

什么是迭代开发？

 

1）开发被组织成一系列固定的短期（如四个星期）小项目，称为迭代。

2）每次迭代都产生经过测试的，经过集成的，和可执行的系统。

3）每次迭代都有自己的需求分析、设计、实现和测试活动。

 

迭代生命周期贯穿多个迭代，系统在这个过程中被持续扩展和精化。

系统迭代过程的驱动力有两个：

循环反馈；

适应调整。

随着一次又一次的迭代递进，系统增量式的发展完善，因此这一过程也称之为迭代增量开发。

我们来看一个简单的实例：

讨论一个两周的迭代。

星期一：分析和澄清本次迭代的任务和需求，同时由一人对上次迭代的代码进行逆向工程，形成UML并打印出重要的图。

星期二：在白板上进行分组设计工作，画出UML草图，使用数码相机记录，并写出一些伪代码和设计注释。

剩余的八天：

实现；

测试（单元测试、验收测试、可用性测试）；

进一步设计；

集成；

每日的构造工作；

系统测试及部分系统的稳定；

与项目相关人员进行演示和评估；

计划下一步迭代。

 

注意：

 

1）不要匆忙编码。

2）不要试图在编程前完善所有设计细节的长期持续的设计步骤。

3）少量超前设计使用粗略和快速的UML可视建模来完成。

4）开发人员大概用半天或一整天的时间进行分组的设计工作。

 

每次迭代的结果是一个可执行但不完善的系统，一般需要10到15次迭代系统才可能投入生产。

迭代输出不是实验性的，也不是即将丢弃的原型，迭代开发也不是原型开发。与之相反，它的输出是最终产品的子集。

一般来说，尽管每次迭代需要扩展新需求并增量扩展系统，但迭代偶尔也会重新审视现有的软件并对它进行改造，例如，并不增加一个子系统的新特性，而致力于提高它的性能。

 

四、初始阶段

 

大多数项目需要一个简短的初始阶段来考虑以下几种问题：

 

1）项目的构想怎么样？业务的案例是什么？

2）可行性怎么样？

3）购买还是开发？

4）粗略估计一下成本：一万到十万？还是上百万？

5）项目是否停止或者继续进行？

 

想要定义构想和获得一个粗略的（不一定可靠）的预测结果，就必须研究需求。

但是，初始阶段的目标并不是要定义所有的需求，或产生一个真实可信的项目估计或计划。

简而言之，初始阶段的目标：

只进行一定的研究，得到未来新系统的可行性以及实现系统总体目标的合理判断，并确定是否值得继续深入研究系统即可。

深入研究是细化阶段的工作。

初始阶段的时间：

大多是一周到几周，太长就失去了初始的意义。

注意：重要的问题是，确定这个项目是不是值得深入的去研究。

在统一过程中，真正的项目研究在细化中。

 

下面列出初始阶段的工件以及各个工件需要完成的工作：

 

1）构想和业务案例：

   描述高层的目标和约束、业务案例、并提供一个执行摘要。

2）用例模型

   描述功能需求和非功能需求。

3）补充规范

   描述其它需求。

4）术语表

   关键的领域术语。

5）风险列表和风险管理计划

   描述业务、技术、资源和进度上的风险，以及如何减轻这些风险，以及如何应对。

6）原型个概念验证

   阐明构想，验证技术问题。

8）迭代计划

   描述第一此细化迭代中应该做些什么。

9）阶段计划和软件开发计划

    对细化阶段的持续时间和工作量进行抵精度的猜测，开发涉及的工具、人员、培训和其他资源。

10）开发案例

    描述为本项目定制的统一过程的步骤和工作，在统一过程中，总需要为项目定制一些步骤和工作。

 

在上面的工作中，需要我们关注的是所谓“用例模型”。

迭代开发的一个关键理解就是：

这些工件在初始阶段只是部分完成，在之后的迭代中再逐步精化和提炼，甚至在认定某个工件确实有用之前，根本无需来创建它，所以初始阶段进行的研究和工件内容都很少。

 

注意：

初始阶段会有一些编程，其目的是创建“概念验证”，通过面向用户的界面原型，来澄清一些需求，或者对关键的技术问题作一些编程实验。

 

初始阶段关注的是确实对项目有价值的工作，要放弃那些不必要的工作。工件的关键不是文档本身，而是其中蕴含的思想、分析和前期准备。

 

五、精化阶段，反馈和调整

 

注意：

迭代开发不是试图在实现以前完成所有的设计，“冻结”所有需求的变更。

而是用拥抱变更、适应调整的态度来作为迭代开发真正必要的驱动力。

 

但这并不表明迭代开发和UP鼓励不受控制的、反应式的“特性蔓延”驱动过程，事先，我们必须和相关人员认真探讨他的构想和需求，以及市场变化的时候，UP如何平衡需求。另一方面，我们也需要认清需求会变更这个事实。

 

每次迭代都选择一小组需求，并且快速的设计、实现和测试，在早期迭代中对需求和设计的选择可能并不准确，也可能不是最终的需求，但这样可以迅速得到来自用户、开发人员或者测试人员的反馈。

 

这种早期的反馈十分重要，这种来自实际构建和测试的反馈，提供了实际的洞察力，以及修改或者调整需求或设计的机会。

最终用户将有机会看到部分系统，并说：“不错…..但是…..”。

这种“不错…..但是…..”的循环，正是改进软件或者获得相关人员认可的巧妙方式，不过，注意这里并不是认可混乱的反应式开发。

 

另外，负载测试也可以验证部分设计是不是正确，这可以决定下次迭代是不是要改变核心架构，最好在早期解决和验证关键设计，以规避决策风险，迭代开发正好提供了这种机制。

 

因此，通过一系列有序的“构造-反馈-调整”循环，工作不断向前推进，早期迭代偏离“正确轨迹”会大于后来的迭代，随着时间的推移，系统将沿着这一轨迹推移。

 

 

六、迭代开发的优点

 

在早期而不是晚期缓解高风险（技术、需求、目标、可用性方面的风险）；

早期可见的发展；

早期反馈、用户参与和调整，会得到一个更接近用户真实需求的经过精化的系统；

可控复杂性，开发组不会被“分析瘫痪”或者长期复杂过程所淹没；

在一次迭代中所学到的知识，可以被有系统的运用于改进开发过程本身。

 

七、迭代的长度和时间分区

 

UP（或有经验的迭代开发人员）建议，迭代长度在2-6周之间比较好。

小步骤、快速反馈和调整，是迭代开发的主要思想。

长期迭代复杂性会变得不可收拾，反馈也会延迟, 会增加项目风险。

短于两周的的迭代不足以产出和反馈。

 

一个关键思想：

时间分区是固定的，每次迭代不鼓励时间推迟，如果无法完成，可以除去一部分任务转移到下一次迭代中去。

 

大型开发团队（几百人）可能需要6周以上的迭代时间。

例：

20世纪90年代，加拿大空中交通系统。

首席架构师：Philippe Kruchten

150个程序员被组织到6个月的迭代中。

但是，即使在6个月的迭代中，10 – 20 人的子系统，仍然把任务分解成一连串6 个为其一个月的迭代。

6 个月迭代是大型开发团队的特例，但不是准则。

UP的建议普通的迭代应该在 2 – 6 周之间。

 

八、统一软件开发过程最佳实践和概念

 

UP所欣赏和实践的主要思想是：短时间分区式的迭代和适应性开发。

UP的另一个核心思想是使用对象技术。

其它一些UP 的关键概念是：

在早期迭代中解决高风险和高价值的问题；

不断的让用户参与评估、反馈和需求；

在早期的迭代中建立内聚的核心架构；

不断的验证质量，提早、经常和实际的测试；

应用用例；

可视化建模（UML）；

仔细的管理需求；

实行变更请求和配置管理。

 

九、统一过程阶段和面向进度表的术语

 

一个UP项目跨越4 个主要阶段：

1）初始阶段：

大体构想、业务案例、范围、模糊评估。

 

2）细化阶段：

已经精化的构想，核心架构的迭代实现，高风险的解决，大多数需求和范围的识别，更为现实的评估。

 

3）构造阶段：

迭代实现遗留下来的风险较低的和比较容易的元素，准备部署。

 

4）移交阶段：

beta测试，部署。

 

UP和过去“瀑布”或顺序生命周期不同，它不是一开始就定义全部需求，然后进行全部或大部分设计。

初始阶段不是一个需求阶段，而是一个类似于可行性阶段，在这个时候需要进行充分的调查，以确定是否继续或终止项目。

同样，细化阶段也不是一个需求或设计阶段，而是一个迭代实现核心架构并降低高风险的阶段。

下图是UP中常用的面向进度表的术语，注意，一个开发周期（以系统投运作为结束标志）由多个迭代组成。

 

 

 

十、UP 流程（工作流）

 

UP描述了流程（discipline），简短的说，流程是在一个主题域中的一组活动，例如需求分析中的活动。

工件（artifact），是对任何工作产品的通用术语，比如：代码，Web图形，数据库模式，文本文档，图，模型等。

需要说明，在2001年，为了与OMG SPEM的国际标准化工作一致，过去的UP 术语“工作流”（workflow）改成了流程（discipline），术语“工作流”（worlflow）有新的含义，并且和UP 的含义稍有不同，在一个特定的项目中，工作流是特定顺序的一组活动，可能跨越流程（工作的流转），但现在在UP中还有人使用“工作流”这个名词，尽管这并不严格正确。

 

Up中有多个流程，但下面我们将专注于以下三个流程的建模。

 

1）业务建模

在开发单独的应用的时候，业务建模包括领域对象建模。

在从事大规模业务分析和业务过程再工程的时候，业务建模包括跨越整个企业的业务过程的动态建模。

2）需求

对应的需求分析，比如写出用例，和识别非功能性需求。

3）设计

设计的所有方面，包括总体框架、对象、数据库、网络连接等。

下图列出了更多的UP 流程。

 

在图中:

实现：表示编程的构建系统，而不是部署。

环境：实质建立工具，并为项目定制过程，也就是说设置工具和过程环境。

 

十一、流程和阶段

 

在上面的图中，在一次迭代中，工作会在大部分流程或全部流程中进行。但随着时间变化，这些流程的相对工作量会变化。

早期迭代更多的工作量在需求分析和设计。

后期迭代这种需求的变化会减少，表明需求和核心设计通过反馈和适应调整过程已经稳定。

对于UP阶段（初始、细化、构造、移交），各阶段相对工作量如下图。

 

 

比如，在细化阶段，迭代趋向于相对高层的需求和设计工作，尽管同时有一些实现。

在构造阶段，工作的重点更多的是放在实现而非需求分析上。

 

十二、敏捷UP

 

方法论者谈起过程是这样来区分的：

重量级过程和轻量级过程；

预测性过程和适应性过程。

 

重量级过程（heavy process）是一个贬义词，它的含义如下：

1）在官僚气氛中创建工作。

2）刻板和忧郁。

3）细化的、长期的、详细的计划。

4）预测的而不是适应性的。

 

预测性过程（predictive process）：

试图在相对长期的时间（例如项目的大部分时间）内详细的计划和预测活动和资源（人员）分配。

预测性过程通常具有“瀑布”或顺序生命周期的特点：

1）定义所有需求。

2）定义详细的设计。

3）实现。

 

适应性过程（adaptive process）：

认为变化是不可避免的驱动因素，鼓励灵活的改写。

它通常具有迭代生命周期。

 

敏捷过程（agile process）：

通常意味着轻量级和适应性过程，敏捷的反映不断变化的需要。

 

UP 的作者不想让UP成为重量级和预测性过程，尽管大量可选的工件和活动集中在这个方面导致这种印象，敏捷UP由以下的应用示例：

1）推荐一小组UP活动和工件：

一般来说，应该尽可能保持简单。

2）UP是一个迭代过程：

需求和设计实现之间并不是完全的，它们是基于反馈，通过一系列的可适应迭代完成。

3）对整个项目没有详细计划：

项目的一个高层计划（阶段计划）确立项目完成日期和其它主要里程碑，但它没有详细描述这些里程碑的细粒度步骤。

详细计划（迭代计划）只是预先对迭代进行的更详细的计划，详细计划从迭代到迭代是可适应的。

强调相对小量工件和迭代开发，是敏捷UP的精髓。

 

 

十三、何时你会知道你并不了解UP

 

你如果是用如下方式之一处理问题，就表明你并不了解UP。

1）认为初始=需求，细化=设计，构造=实现。

2）为细化的目的，是完整的细致的定义模型，这些模型在构造过程中会转化为代码。

3）试图在开始设计或实现之前定义绝大部分需求。

4）试图在开始实现之前定义绝大多数设计，试图在迭代编程和测试之前完整的定义和确认架构。

5）在编程开始之前进行“长期”的需求和设计工作。

6）认为合适的迭代长度是4个月，而不是四个星期（除非上百人开发一个项目）。

7）认为UML绘图是完整而且详细的定义设计和模型，认为编程就是把这些设计图简单而机械的转变成代码。

8）认为采用UP意味着实行大量可能的活动和创建许多文档，认为UP是一种形式化的繁琐的过程，这个过程有许多要遵守的步骤。

9）试图从头到尾详细计划一个项目，试图投机的预测所有迭代和每次迭代可能发生的事情。

10）在细化阶段结束之前，想要可信的项目计划和评估。

 

 

 

 

 

第二章   需求过程与分析的核心理论

 

架构设计过程分为 两个阶段：高层设计阶段和详细设计阶段。

 

 

高层设计阶段的重点是软件系统的体系结构设计。详细设计阶段的重点是用户界面设计、数据库设计和模块设计。

而高层设计的信息，主要来自于需求分析。

 

第一节   需求过程在软件架构中的重要作用

 

作为一个架构师，工作的主要舞台是系统设计，但设计的输入来自于需求工程，什么样的需求思想，就有什么样的架构思维。

这就是说，合理而且正确的需求分析过程，是架构设计过程的一个有机的组成部分，所以，我们首先必须讨论需求分析的领域建模的有关问题。

需求开发与需求管理是相辅相成的两类活动，它们共同构成完整的需求工程。需求工程结构图如下所示：

 

需求工程 需求开发 需求变更控制 需求管理 需求确认 需求跟踪 需求调查 需求分析 需求定义

 

需求开发和需求管理的流程下所示。

 

需求分析 用户需求说明书 产品需求规格说明书 用户需求调查 输出 输出 产品需求定义 需求 变更 控制 需求确认 需求跟踪 需求 开发 过程域 需求 管理 过程域

 

其中，需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，确保需求的变更不会失去控制而导致项目发生混乱。

 

需求的类型：

作为一个检查表，需求可以按照FURPS+模型进行分类的，每个字母含义如下：

F：

功能性（Functional）：特性、能力、安全性。

U：

可用性（Usability）：人性化因素，帮助，文档。

R：

可靠性（Reliability）：故障周期，可恢复性，可预测性。

P：

性能（Performance）：响应时间，吞吐量，准确性，有效性，资源利用率。

S：

可支持性（Supportability）：适应性，可维护性，国际化，可配置性。

+：

辅助和次要的因素，比如：

实现（Implentation）：资源限制，语言和工具，硬件等。

接口（Interface）：与外部系统接口所加的约束。

操作（Operations）：系统操作环境中的管理。

包装（Packaging）：

授权（Legal）：许可证或其它方式。

事实上，FURPS+模型并不是唯一的，但用它来作为需求范围检查表是很有效的，这可以降低考虑系统的时候遗漏某些因素的风险。

还有一些分类方式和FURPS+模型类似，比如ISO9126，它主要来自于美国软件工程研究所(SEI)。

 

第二节   面向过程的需求分析核心知识

 

传统的面向过程需求分析与面向对象分析是不同的，传统方法把系统看成一个过程的集合体，由人和机器共同完成一个任务，计算机与数据交互、读出数据、进行处理又把结果写回到计算机里面去。

在讨论事件的时候，过程方法强调组件的过程模型。

而对象方法把系统看成一个相互影响的对象集，对象重要的是具有行为（方法），行为发送消息请求另一个对象做事情，就本质而言，对象方法不包括计算机过程和数据文件，而是对象执行活动并记录下数据，当为系统响应建模的时候，对象方法包括响应模型、模型行为以及对象的交互。

两种方式的不同点如下图：

下面我们先简单讨论一下面向过程分析的特点，一般来说，面向过程的分析必将导致面向过程的架构（设计）。

 

一、数据流程图 DFD

 

1 ，DFD 的符号

面向过程的核心理念是数据流，所以它的模型主要是数据流程图（DFD），它只用了5个符号。

概念：

外部实体：在系统边界之外的个人和组织，它提供数据，或者接受数据输出。

过程：在DFD中的一个符号，它代表数据输入转换到数据输出的算法或者程序。

数据流：在DFD中的箭头，它表示在过程、数据存储和外部实体间的数据移动。

数据存储：保存数据的地方，将来一个或者多个过程来访问这些数据。

 

 

2 ，关联图

 

系统内部在单个过程符号中概括所有处理活动的DFD。

下面是客户支持系统的关联图简单例子：

注意，箭头表示数据的流向。

二、事件划分的系统模型（0 层图）

 

DFD的细节称作片段，片段的组合有多种方式，现代过程分析也是以事件为基础，所以完全集可以组合到一个事件划分系统模型或者称为0层图中去。其中，每个过程为一个事件的处理。

三、分解过程

 

如果一个DFD片断包括更多的处理，可以把过程进行分解，以便作更详细的研究。

 

 

四、评估DFD 的质量

 

高质量的DFD是可读的、内部一致的以及能准确表示系统需求的。

 

复杂性最小化：

 

人们对复杂信息处理是有局限性的，当太多的信息同时出现的时候，人们把这种现象称作 信息超量。在这样的情况下，可以把信息划分为小的相对独立的子集，这样便于单独考察和理解信息，这也是建模最根本的目的。

 

7 ±2 原则：

 

这个原则也称之为Mille数，由心理学研究，一个人可同时记住或操纵的信息块的数目大约在7到9之间，也就是一个模型的过程数不要超过7±2个。

另外数据流进、流出一个过程、数据存储或者数据元素的个数不要超过7±2个。

这不是强制原则，但可以给我们提供一个警告。

 

接口最小化：

 

这里的接口是指一个问题或者描述中的一部分与其它部分的连接。源于7±2原则，连接数应该保持最小，如果超出了这个原则，可把一个过程分解为更多的过程，以使得分析简单。

 

数据流一致性：

 

通过分析数据流的不一致，可以找到错误。

下面的例子使用了过程描述（面向过程英语）来描述内部过程，流入的B、C没有任何处理，也没有流出，被称之为“ 黑洞”。

 

下面的例子，流出的B、Y和内部的X并没有流入，被称之为“ 奇迹”。

面向过程的分析已经有了一套完整而且成熟的方法，像决策表和决策树等等，这里就不再讨论了。

 

五、案例：订单处理子系统

 

1 、问题陈述：

 

项目名称：电源设备订单处例子系统 项目单位：TB公司电源设备销售部 最后修改日期：****年**月**日
系统目标	1，客户直接利用因特网购买电源设备，客户选择设备，设备分为普通不间断电源、服务器专用不间断电源和专业级不间断电源加自主供电设备等。     2，客户可以选择标准配置，也可以在线建立自己的配置。 3，可配置的构件显示在一个下拉列表中，对每一种配置，系统可以计算价格。
系统要求	1，发出订单时，客户需要填上运送和付款信息，系统可接受的付款方式为信用卡和支票，一旦订单输入，系统将向客户发送一个确认e-mail信息，并且附上订单细节，在等待电源设备送到的时候，客户可以在任何时候在线查到订单状态。 2，后端订单处理包括下面所需的步骤：由客户服务系统提供这个客户的等级以及根据等级和促销策略计算出的相应折扣方式，验证客户的信任度和付款方式，向仓库请求所订购的配置，打印发票，并且请求仓库将电源设备运送给客户。

 

1 ，功能分解图

 

功能分解显示了一个系统自顶向下的分解结构，也为我们绘制数据流图（DFD）的提纲。

2 ，过程事件图

 

现在我们的眼睛盯住具体的细节，为每个事件过程绘制一个事件图，这实际上是一个事件的上下文流图。在研究事件图的时候，往往需要了街所有的数据存储。必要的时候，数据库分析和设计可以提到前面先来完成，我们将在后面的章节来讨论这个问题。要说明的是分析的时候并不需要数据库的详细设计，而只是把数据存储用实体的方式从大的方面规范清楚，以此作为详细设计的一个必要的输入。

大多数事件图包括一个单一过程，并且需要说明以下内容：

1）输入及输入来源，来源被描述为外部代理。

2）输出及输出目的地，目的地被描述为外部代理。

3）必须读取记录的任何数据存储都应该被加入到事件图中，事件流应该加入命名。

4）对数据的任何增、删、改、查都应该加入到事件流中，事件流应该加入命名。

事件图的敏感性和简单性，使它成为专家和用户沟通的强有力的工具，下面是一个简单的外部事件图。

一个简化的“订单处理子系统”的过程事件图如下。

 

参与者	事件（或者用例）	触发器	响应
客户	选择产品（由Web页面驱动）	产品查询	生成“目录描述”
客户	发出订单	新客户订单	生成“客户订单确认”，在数据库中创建“客户订单”和“客户订购的产品”。
客户	修改订单	客户订单修改请求	生成“客户订单确认”，修改数据库中 “客户订单”和“客户订购的产品”。
客户	取消订单	客户订单取消	生成“客户订单确认”，在数据库中逻辑的删除 “客户订单”和“客户订购的产品”。

 

3 ，系统DFD 图

 

事件图并不是孤立存在的，它们集合在一起定义了系统和子系统，所以，构造一个或者多个系统或者子系统中所有事件相互关系的系统图也是有意义的。在绘制系统图的时候，必须平衡不同详细程度的事件图，以保证一致性和完整性，必要的时候可以扩展为多个DFD。系统图更多的是从宏观的角度看为题，更多的考虑相互关系，这点很重要。

 

 

4 ，基本图

 

系统图中的某些重要的事件过程可以扩展为一个基本的数据流图，以揭示更多的细节，这对比较复杂的业务过程（比如订单处理特别重要），有些事件比较简单（比如报告生成），所以不需要进一步扩展。

 

 

 

5 ，完整的规格说明

 

上下文图、系统图、事件图和基本图的组合构成了过程模型，一个工艺良好的完整过程模型可以在最终用户和计算机软件设计者以及程序人员之间有效的沟通需求，消除大部分系统设计、编程和实施阶段出现的混淆。

注意，完整的过程模型并不仅仅是这些图，更多的是文字说明，把图形和文字结合起来，设计就会非常的清晰而且避免歧义，这非常重要。

 

 

第三节   面向对象的需求分析和用例

 

在面向对象的需求分析中，对象、事件和响应成为分析的主体，分析的着力点转向了交互。但是，还是有相应的方法来描述功能，这就是用例，这也是需求分析的重要部分。

 

一、 用例及用例图的基本概念

 

用户一定会有自己的目标，并且希望计算机能够帮助他们实现这些目标。

用例就是表达如何使用系统达到目标的一组情节。

 

用例的几个概念

 

参与者（actor ）：具有行为能力的事务，可以是个人（由其扮演的角色来识别），计算机系统，或者组织。

 

场景（scenario ）：是参与者和被讨论系统之间一系列特定的活动和交互，通常被称之为“用例的实例”。通俗地讲，场景实际上是在说故事。一般来说，一个用例就是描述参与者使用系统达成目标的时候一组相关的成功场景和失败场景的集合。

用例分析的关键是专注于“怎样才能使系统为用户提供可观测的数据，或帮助用户实现它们的目标”，而不是仅仅把系统需求用特性和功能的细目罗列出来。

在需求分析中，我们必须专注于考虑系统怎么才能增加价值和实现目标。

用例的主要思想是：为功能需求写出用例（而不是老式的为“系统会怎么做”的功能列表），在统一过程中用例是发现和定义需求的主要方法，是功能性行为。

参与者 的发现:

发现参与者对提供用例是非常有用的。因为面对一个大系统 ,要列出用例清单常常是十分困难。这时可先列出参与者清单 ,再对每个参与者列出它的用例 ,问题就会变得容易很多。

 

二、用例（UseCase）及其定义

 

    1 ）用例：

1．用例是关于单个活动者在与系统对话中所执行的处理行为的陈述序列（Jacobson）。它表达了系统的 功能和所提供的 服务，用例的图示如下。

 

2．它描述了活动者给系统特定的刺激时系统的活动， 是 活动者 通过系统完成一个过程时出现的一组事件，最终以实现一种功能。

3．通常，用例侧重于功能，但不重点描述该功能的实现细节。

4．所有的用例必须始于参与者（ Actor），而且有些用例也结束于参与者。

 

2 ）用例的分类

 

1．业务用例（Business Use Case）

指系统提供的业务功能与参与者的交互，表现问题领域中各实体间的联系和业务往来活动（如果某个用例的范围包含了人以及由人组成的团队、部门、组织的活动，那么这个用例必然是业务用例）。

2，系统用例（System Use Case）

指参与者与系统的交互，它表现了系统的功能需求和动态行为（如果仅仅是一些软件、硬件、机电设备或由它们组成的系统，并不涉及到人的业务活动，那么该用例是系统用例）。

 

3 ）用例的联系（横向方面）

 

1 ．泛化关联

 

泛化关联代表一般与特殊的关系，它充分体现了面向对象的继承性：子类具有父类的所有属性，还可以拥有自己的属性特点及行为。泛化关联包括用例之间及活动着之间的关联关系。例如，修改员工资料和修改开发部员工资料就是用例的泛化关联。泛化关联用空心三角箭头的实线表示：其方向从特殊指向一般。

2 ，包含关联（include ）

 

包含关联指一个基本用例的行为包含了另一个用例的行为，这种关联是一种依赖关系， 被包含的用例不能独立存在，只能作为包含它的用例的一部分。

例如，一个信息维护的模块，无论是录入人员信息还是修改人员信息，都必须对当前登录者进行验证，因而录入及修改人员信息这/两个用例都用到了对当前用户的权限验证的用例。

其表示方法为用一条虚箭线从基本用例指向被包含的用例，并标有构造型<<include>>：

      

3 ，扩展关联（ extend ）

 

扩展关联的基本含义与泛化关联类似，但是对于扩展用例有更多的规则，即基本的用例必须声明若干新的规则---扩展点（Extension Points），扩展用例只能在这些扩展点上增加新的行为并且基本用例不需要了解扩展用例的如何细节。

例如， 保存人员信息用例可以是删除人员信息及新增和修改人员信息用例的扩展，它们之间存在着扩展关系。如果特定的条件发生，扩展用例的行为才能执行。

其图形表示方法为在用例图上用一条从基本用例指向扩展用例的虚箭线表示，并在线上标注购造型<<extend>>：

      

三、用例图及其表达原则

 

用例图主要表现各个用例之间宽泛的关系，如下图所示。

 

在上面的图中，计算机系统的参与者有两种表示法，其中有些人喜欢用不同于人型的方框表示外部计算机系统参与者，<<actor>>称作UML构造型，这是用某种方式分类元素的方式够造型的名称被书名符号包住，这本来就是法文印刷中表示引用的符号。

注意：主要参与者和用户目标和系统边界有关

有个问题，在“处理销售”用例中，为什么主要参与者是收银员而不是顾客呢？

这和系统边界有关，我们定义的销售系统边界，服务目标是收银员。

如果把系统边界定义为企业交款服务，那顾客就是一个主要参与者了。

 

我们也可以通过事件分析找出参与者。

 

第四节 用例的事件流与用例文档

 

用例的事件流是对完成用例行为所需的事件的描述。事件流描述了系统应该做什么，而不是怎么做。

可以通过一个清晰的，易被用户理解的时间流来说明一个用例的行为。

在事件流中包括用例何时开始和结束，用例何时和参与者交互，什么对象被交互以及该行为的基本流和可选流。

 

一、 用例的事件流的组成

 

（1）用例事件流所应该包含的内容

 

简要说明：描述该使用案例的作用（可以不写出）；

前置条件：开始使用该用例之前必须满足的系统和环境的状态和条件（必要条件而不是充分条件）

主事件流：用例的正常流程（ 事件流是关注系统干什么，而不是怎么干），也称为用例的路径。

其它（备选）事件流：用例的非正常流程，如错误流程

后置条件：用例成功结束后系统应该具备的状态和条件（但不是每个用例都有后置条件）

 

（2） 主事件流（用例的路径）

    可能包含有基本路径、备选路径、异常路径、成功路径和失败路径等几个方面的内容。

 

二、描述用例的事件流的主要方式

1，面向过程语言：

每个用例只描述没有大的分支的行为的单个线索，在事件流中要对事件流进行面向过程说明（主事件流和备选事件流）。

2，UML的活动图（系统活动图---和用例活动图）：

使用活动图可以表示由内部生成的动作驱动的事件流，活动图能提醒您注意并展示并行的和同时发生的活动。这使得活动图成为建立工作流模型、分析用例以及处理多线程应用程序的得力工具。

 

三、事件流描述文档的基本要求

 

1 ）首先写出基本的路径

这是最主要的事情，因为它是用户最关心或者最想看到的内容。

2 ）用例交互的四步曲

1，参与者产生某个行为动作；

2，然后系统对此动作进行响应；

3，响应成功后再根据动作的要求进行状态的改变；

4，最后将改变后的结果再回馈给参与者。

3 ）模板格式

 

用例的模版可以有不同的形式，关键是要表达清楚：

 

作者: _______________                                                        日期: ___________

                                                                                          版本: ___________

用例名 :		用例类型
用例 ID:
主要业务参与者 :
其它参与者 :
项目相关人员兴趣 :
描述：
前置条件：
后置条件：
触发条件 :
基本流程 :
扩展流程：
结束 :
业务规则：
实现约束和说明：
假设：
待解决问题 :

 

对于上述一些时间流，以及一些关键和重要的问题，需要对用例进行详细设计，这是需要使用文档而不是图。

 

四、用例文档中几个元素的解释

 

1 ）序言元素

要把最重要的元素放在一开始。而把一些不重要的“标题”材料放在末尾。

用户兴趣列表：

这个列表很重要也很实用。

用例作为行为的契约，扑获所有与满足客户兴趣有关的行为。

这就回答了一个问题，用例应该包含什么？

答：

用例应该包含满足所有客户感兴趣的内容，另外，在写出用例所有部分之前，需要确定用户及其兴趣。

例如，如果我们没有列出“销售人员提成”的兴趣，在开始部分我们可能会漏掉这个职责。以客户兴趣作为视点来观察，会给我们提供一种彻底的、系统化的程序，用来发现和记录所有必需的行为。

例：

项目相关人员的兴趣：

收银员：希望能够准确快速的输入，没有支付错误。

售货员：希望自动更新销售提成。

等。

 

2 ）前置条件和后置条件（成功后的保证）

 

前置条件：

规定了用例一个场景开始之前必须为“真”的条件。

前置条件在用例中不会被检验，我们假定它已经被满足，通常前置条件是已经成功完成的其它用例的一个场景。

比如：

“系统已经被登录”或“收银员已经被识别和授权”。

但不要包括没有价值的条件，比如“系统已经被供电”。

前置条件主要表达读者应该引起警惕的或者值得注意的那些假设。

后置条件：

后置条件也叫“成功后的保证”，表达了用例成功结束以后必须为真的条件，这个“保证”应该满足所有客户方的需要。

这里所有的客户方，指的是所有参与使用项目的人员。

例：

前置条件：收银员已经被识别和授权。

后置条件：存储销售信息，准确计算税金，更新账目和库存，记录提成，生成收据。

 

3 ）基本流程

 

我们可以把主要成功场景成做“基本流程”，它描述了能满足客户兴趣的典型成功路径。

一般它不包括任何条件和分支，而把条件和分支放在“扩展”部分说明。

场景记录以下三种步骤：

1）参与者之间的交互。

2）一个验证动作（通常由系统来完成）。

3）由系统完成的状态改变。

例：

注意表示重复的习惯用法

主要成功场景：

1．顾客携带购买的商品到达POS机收费口

2．收银员开始一次新的销售

3．收银员输入商品标识

4．…..

重复 3 – 4 步，直到结束。

5．………

 

3 ）扩展

 

扩展又称之为“替代流程”，它说明了所有其它的场景和分支。

扩展往往比主要成功场景长而且复杂，这正是我们所希望的。在写完整用例的时候，基本流程加上扩展能满足几乎所有客户的兴趣。

扩展场景是从主要成功场景中分离出来的，所以标记方式应该相同，比如，第3步的一个扩展就被标记为3a。

 

扩展：

3a.非法标识

   1．系统指示错误并拒绝输入。

3b.多个具有相同类别的商品，不需要跟踪每个商品的唯一身份

1． 收银员可以输入商品类别的表识和数量。

3c.顾客要求从艺术如商品中减去一个商品

 1．收银员输入商品标识并将其删除。

 2．系统显示更新后的累加值。

……..

 

一个“扩展”有两部分组成：条件和处理，处理的步骤可以有多个。

有时候扩展可能会非常复杂，这就需要用单个用例来完成扩展。

下面看看怎么标记扩展中的失败：

 

7b.信用卡支付

1.顾客输入信用卡账号

2.系统向外部信用卡授权服务系统请求支付验证

2a系统检测到和外部信用卡授权服务系统通信故障

1.       系统向收银员知识发生了错误

2.收银员向客户请求更换支付方式

3…….

 

如果想要描述一个可能在任何一步（至少是绝大多数步骤）都会发生的条件，那么应该使用类似“*a”、“*b”这样的标记。

 

*a.任何时刻，发生一下状况，系统将会崩溃。

1．收银员重启系统，登录，请求恢复上次状态。

2．系统重建之前的状态。

 

4 ）特殊需求

 

如果有一些与这个用例有关的非功能性需求（质量属性或约束条件），那么应该把他们记录在一起。

例：

特殊需求

在大型平板显示器上触摸屏界面，文本信息要能在一米之外看清。

90%信用卡授权机构的响应，应该能在30秒之内收到。

支持多种语言显示。

在步骤2和步骤6种可以插入新的业务规则。

经典的统一过程建议，第一次写出用例的时候，把特殊需求和用例写在一起。

但现在更通用的做法是把所有非功能性需求放在“补充规范”中，这样更容易进行内容管理，也更容易读，因为这些需求通常要求在进行系统整体架构分析的时候通盘考虑。

 

5 ）技术和数据的变化列表

 

系统通常有一些技术上的变化是关于“应该怎样做”，而不是“应该做什么”，需要在用例中把这些变化记录下来。

比如，数据表示方案可能会有不同的变化，在列表中应该记录这种变化。

技术和数据的变化列表：

3a. 商品标识可以用条码扫描也可以用键盘输入。

3b. 商品表识可以采用UPC、EAN、JAN、SKU等不同的编码方式。

7a. 信用卡账号信息可以使用读卡器或键盘输入。

7b. 记录在纸面收据上的信用卡支付签名，但我们预测，两年内会有许多顾客希望使用数字签名。

 

五、示例：销售系统

 

这里为了把问题表达清楚，添加了一些项目。

举个例子。

POS 销售系统

作者: _______________                                                               日期: ___________

                                                                                                   版本: ___________

用例名 :	Process Sale	用例类型
用例 ID:	TB-SALE2.00	业务需求
主要业务参与者 :	收银员
项目相关人员兴趣 :	收银员：希望能准确、快速的输入，而且没有支付错误。      售货员：希望自动更新销售提成。      顾客：希望购买过程能够省力，并得到快速服务，希望得到购买证明，以便退货。      公司：希望准确的记录交易，并满足顾客要求，希望保证支付授权服务的信息被记录，希望有一定的容错性，即使某些服务不可用也能允许收款，希望能自动快速的更新账目和库存信息。      政府税务机关：希望从每笔交易中抽取税金。      支付授权服务：希望按照正确的格式和协议收到数字授权的请求，希望准确计算给商店的应付款。
前置条件：	收银员已经被识别和授权。
后置条件：	存储销售信息，准确计算税金，更新账目和库存，记录提成，生成收据。
触发条件 :	当客户开始验证购买的商品的时候，该用例被触发。
基本流程：	1．顾客携带购买的商品到达POS机收费口 2．收银员开始一次新的销售 3．收银员输入商品标识 4．….. 重复 3 – 4 步，直到结束。 5．……… ……. 10．顾客携带商品和收据离开
替代流程	*a.任何时刻，发生以下状况，系统将会崩溃。 1．收银员重启系统，登录，请求恢复上次状态。 2．系统重建之前的状态。 3a.非法标识    1．系统指示错误并拒绝输入。 3b.多个具有相同类别的商品，不需要跟踪每个商品的唯一身份 2． 收银员可以输入商品类别的标识和数量。 3-6a.顾客要求从已输入商品中减去一个商品  1．收银员输入商品标识并将其删除。  2．系统显示更新后的累加值。 …….. 7b.信用卡支付 1.顾客输入信用卡账号 2.系统向外部信用卡授权服务系统请求支付验证 2a系统检测到和外部信用卡授权服务系统通信故障 2.     系统向收银员指示发生了错误 2.收银员向客户请求更换支付方式
结束 :	当客户完成支付，该用例结束。
特殊需求：	1，在大型平板显示器上触摸屏界面，文本信息要能在一米之外看清。 2，90%信用卡授权机构的响应，应该能在30秒之内收到。 3，支持多种语言显示。 4，在步骤2和步骤6种可以插入新的业务规则。
技术和数据的变化列表：	3a. 商品标识可以用条码扫描也可以用键盘输入。 3b. 商品标识可以采用UPC、EAN、JAN、SKU等不同的编码方式。 7a. 信用卡账号信息可以使用读卡器或键盘输入。 7b. 记录在纸面收据上的信用卡支付签名，但我们预测，两年内会有许多顾客希望使用数字签名。
发生频率：	可能会持续发生。
待解决问题 :	1，什么是税法的变化？ 2，研究远程服务的恢复问题 3，不同的业务需要什么样的定制？ 4，收银员是否必须在退出系统以后带走他的现金抽屉？ 5，顾客是否可以直接使用读卡器，而不需要收银员代劳？

 

这个例子虽然不完整，但是一个实际的例子，足以给我们提供一个真实的感受。

在统一过程中提倡一种简朴的书写风格，也就是不考虑用户界面，而专注于他们的意图，只对用户意图和系统职责这一级描述，这点很重要。

 

六、案例：订单处理子系统

 

1 、问题陈述：

 

与过程分析相同。

 

2 、参与者

 

通过如下分析，把问题条理化，发现参与者，注意，描述的时候不要使用隐语。

比如：要e-mail给客户；

正确的：销售人员要e-mail给客户。

 

1， 客户使用公司的的Web页面查看所选择的电源设备标配，同时显示价格。 2，客户查看配置细节，可以更改配置，同时计算价格。 3，客户选择订购，也可以要求 销售人员在订单真正发出之前和自己联系，解释有关细节。 4，要发出订单，客户必须填写表格，包括地址，付款细节（信用卡还是支票）等。 5，客户订单送到系统之后， 系统由 客户服务系统取得该客户的等级，以及由销售策略决定的折扣。 6，销售人员发送电子请求到 仓库管理系统，并且附上配置细节。 7，事务的细节（包括订单号和客户帐户号），销售人员要e-mail给客户，使得客户可以在线查询订单状态。 8，仓库从销售人员处获取发票，并且向客户运送电源设备。

 

从中我们可以发现四个参与者：

客户；

销售人员；

仓库管理系统；

客户服务系统。

 

3 、建立用例

 

用例表示一个完整的给用户传值的功能单元，不与用例通信的参与者是没有意义的，但用例可以只为泛化，而不与参与者通信。

我们可以建立一个表来分析，把功能需求赋予参与者和用例。注意，有些潜在的业务功能可能不在应用范围只内，它们不能被转换为用例，比如仓库装配电源设备并且把它运送给客户，这个任务已经超出这个系统的业务范围，不能作为用例。

 

编号	需求	参与者	用例
1	客户使用电源部的Web页面查看所选择的电源设备标配，同时显示价格。	客户	显示标准电源配置
2	客户查看配置细节，可以更改配置。	客户	构造电源配置
3	系统由 客户服务系统取得该 客户的等级，以及由销售策略决定的折扣，同时计算价格。	客户 客户服务系统	获取销售策略
4	客户选择订购，也可以要求 销售人员在订单真正发出之前和自己联系，解释有关细节。	客户 销售人员	订购配置了的电源设备 请求与销售人员联系
5	要发出订单， 客户必须填写表格，包括地址，付款细节（信用卡还是支票）等。	客户	订购配置了的电源设备 效验和认可客户付款
6	销售人员发送电子请求到 仓库管理系统，并且附上配置细节。	销售人员 仓库管理系统	通知仓库关于订购信息
7	事务的细节（包括订单号和客户帐户号）， 销售人员要e-mail给客户，使得 客户可以在线查询订单状态。	销售人员 客户	订购配置了的电源设备 更新订购状况
8	仓库管理系统从 销售人员处获取发票，并且向客户运送电源设备	仓库管理系统 销售人员	打印发票

 

可以建立如下用例：

 

4 、用例图

 

用例图的作用是把用例赋给参与者，用例图是系统行为模型的主要可视化技术。还可以建立用例之间的关系，比如图中Extend表示“订购配置了的计算机”可以被“客户”扩展为“请求与销售人员联系”。而订购配置了的电源设备包含了（include）获取销售策略的行为，这种依赖关系，表达了获取销售策略的用例不能独立存在，只能作为包含它的订购配置了的电源设备用例的一部分。

 

 

5 、编写用例文档

 

用例必须用 事件流文档来描述，这个文档表达了系统必须做什么和参与者什么时候激活用例。用例文档大概10页左右，需要完整的表达用例的过程。

 

用例名 :	订购配置了的电源设备	用例类型
用例 ID:		业务用例
主要业务参与者 :	客户
描述：	该用例允许客户输入一份购物订单，该订单包括提供运送和发票地址，以及关于付款的详细情况。
前置条件：	客户通过浏览器进入订单输入的Web页面，该页面显示已配置电源设备及价格的详细信息。 当客户在订单信息已经显示在屏幕上的时候，选择“客户”或者相似命名的功能键来确认订购所配置的电源设备的时候，该用例开始。
后置条件：	如果用例成功，购物订单记录进系统的数据库，否则系统的状态不变。
基本流程 :	1．系统请求客户输入购买细节，包括销售人员的名字（如果知道的话）、运送信息（客户的名字和地址）、发票细节（如果运送地址不同的话）、付款方法（信用卡和支票）以及任何其它注释。 2．客户选择计算价格功能键来发送购买细节，系统通过客户服务系统获取这个等级的客户销售策略，然后计算购买价格。 3．客户选择购买功能键来发送订单给系统。 4．系统给购买订单赋与一个唯一的订单号码和客户账号，系统将订单信息存入数据库。 5．系统把订单号和客户号与所有订单细节一起e-mail给客户，作为接受订单的确认。
扩展流程：	2a，客户对计算的价格有疑问，可以查阅客户服务系统的相应页面，以查询自己的客户等级及当前的销售策略 3a，客户在提供所有要求录入的信息之前，激活购买功能键，系统将显示错误信息，它要求提供所漏掉的信息。 3b，客户选择Reset（或其它相似命名）功能来恢复一个空白的购物表格，系统允许客户重新输入信息。

 

 

七、用例的目标

 

1 ）基本业务过程的用例

基本业务过程（EBP）是这样定义的：

由一个人在某个时间某个地点执行一项任务，这项任务是对某一业务事件的反应，而且可以增加可度量的业务价值，并且能够保持数据状态的一致。

其实这个定义过于教条，业务只能由一个人完成？两个人就不行？

所以对原则的理解不应该教条主义的处理问题，用例强调了能够增加可见的和可度量的业务价值，而且能够使系统和数据处于稳定和一致的状态中。

其实我们使用EBP原则的时候，主要是在对应用进行分析的时候来寻找主要用例。

 

2 ）用例和目标

 

参与者都有自己的目标（或需要），因此，一个EBP级别上的用例，通常被称之为一个 用户目标级别上的用例。

因此，处理问题的过程应该是：

首先找出用户的目标，然后为每个目标定义一个用例。

 

3 ）用EBP 指导原则的实例

 

作为一个系统分析师，在需求分析会上可以这样了提出问题：

系统分析师：在使用POS系统的时候，你的目标是什么？

收银员：快速登录还有收款

系统分析师：你认为登录更高级别上的目标什么？

收银员：我要向系统证明身份，这样才能允许我使用系统

系统分析师：比这更高的目标呢？

收银员：防止盗窃、数据崩溃，不显示不宜公开的企业信息。

 

我们分析一下这段对话。

“防止盗窃、数据崩溃，不显示不宜公开的企业信息”实际上比起用户目标要高，可以认为是企业目标，所以在此不做考虑。

“我要向系统证明身份，这样才能允许我使用系统”看起来接近于用户目标，但它不是EBP级别上的行为，因为它不会增加可见的或者可以度量的业务价值，它是为期它目标服务的。

而“完成一次销售”是符合EBP原则的更高一级目标。

 

第五节   非功能性需求的识别

 

仅仅写出用例还是不够的，还需要识别其它种类的需求，这些将被包含在补充规范中。

例如：

简介

功能性

日志和错误处理

安全性

人性因素

可靠性

   可恢复性

性能

适应性

可配置性

实现约束

    比如开发的领导层坚持要使用Java开发。

采购的组件

免费开放源码的组件

接口

值得注意的硬件和接口

触摸屏

条码扫描仪

数据打印机

信用卡读卡器

签名读取器（第一版中不支持）

术语表

 

术语	定义和相关信息
商品	销售的产品或服务
支付授权	一外部的支付授权服务提供验证，保证销售者得到支付
支付授权请求	以电子方式发送到支付授权系统的一组元素，通常是字符串，这些元素包括：商场ID，顾客账号，数据和时戳

 

术语表也可以作为数据字典使用。

 

第六节   合理的应用活动分析

 

一、为什么要应用活动建模

 

上面用文字表示用例事件流，可以很细腻的表达一些用例的过程，但是，当用例的事件流比较复杂的时候，单纯用文字表达难以清楚的表示相互之间的关系，特别是一些并发关系，这时，可以借用活动图来表示，活动图更善于表达流程和并发关系。

活动图表示了计算的步骤，每一步都是一个关于干什么事的状态。因为这个原因，执行步骤被称之为活动状态。

这个图表示了哪步应该按次序执行，哪步可以并行进行，从一个活动状态到另一个活动状态的转换，称之为“转换”。

如果用例文档完成了，活动状态可以从主要的和附加的流中间发现。

但是用例描述和活动模型之间存在着一些重要的区别，用例描述是从外部参与者的角度出发来编写的，而活动模型则采用内部系统的观点。

活动图也可以在用例编写以前，在一个高的抽象层次来理解业务进程。

 

活动

 

如果活动建模是为了表达可视化用例中活动的次序，则活动状态可以根据用例文档来建立，这时，活动应该从系统的角度，而不是参与者的角度来命名。

活动图形也可以表达活动状态和活动行为。

活动和行为的区别在于其时间跨度，活动是要花时间来完成的，而行为则可看成快照，被认为是不花时间的。

 

活动视图（Activity Diagram）主要用于对计算流程和工作流程建模，它很类似于面向过程建模中的流程图。

使用活动图可以表示由内部生成的动作驱动的事件流，活动图能提醒您注意并展示并行的和同时发生的活动。比较适合建立工作流模型。

下面是一个订单处理的活动图。 

 

 

泳道：

 

将模型中的活动按照职责组织起来通常很有用。

例如，可以将一个商业组织处理的所有活动组织起来。这种分配可以通过将活动组织成用线分开的不同区域来表示。由于它们的外观的缘故，这些区域被称作泳道。

下图表示了一个销售过程的活动。 

 

 

活动图并没有表示出计算处理过程中的全部细节内容。

它只是表示了活动进行的流程但没表示出执行活动的对象。

活动图是设计工作的起点。为了完成设计，每个活动必须扩展细分成一个或多个操作，每个操作被指定到具体类。

这种分配的结果引出了用于实现活动图的设计工作。

 

二、 案例：订单处理子系统

 

1 ，发现活动

 

针对上面已经建立了用例的关于电源设备采购的例子，我们从系统用例的描述，来找出活动，注意，活动是站在设备的角度来描述的。

 

编号	用例描述	活动状态
1	当客户在订单信息已经显示在屏幕上的时候，选择“客户”或者相似命名的功能键来确认订购所配置的电源设备的时候，该用例开始。	显示当前配置； 获得客户请求
2	系统请求客户输入购买细节，包括销售人员的名字（如果知道的话）、运送信息（客户的名字和地址）、发票细节（如果运送地址不同的话）、付款方法（信用卡和支票）以及任何其它注释。	显示购买窗体
3	系统由销售服务系统取得客户的等级以及当前销售策略，计算客户购买的实际价格。	显示购买价格
4	客户选择Purchase（购买，或者相似命名的）功能键来发送订单给TB公司。	获得购买详细资料
5	系统给购买订单赋与一个唯一的订单号码和客户账号，系统将订单信息存入数据库。	存储订单
6	系统把订单号和客户号与所有订单细节一起e-mail给客户，作为接受订单的确认。	Email订单资料
7	客户在提供所有要求录入的信息之前，激活Purchase（或者相似命名的）功能键，系统将显示错误信息，它要求提供所漏掉的信息。	获得购买详细资料 显示购买窗体
8	客户选择Reset（或其它相似命名）功能来恢复一个空白的购物表格，系统允许客户重新输入信息。	显示购买窗体

 

把标识的活动画出来。

 

2 ，活动图

 

把活动用转换连线连接起来，就成为活动图。

 

 

“显示当前配置”是初始活动状态，在这个活动上有一个 递归转换的表达，描述在进行下一个活动以前，这个活动一直在反复执行。这个方式强调了这是活动而不是行为。

当活动转换为“显示购买窗体”的时候，timeout将终止这个活动模型的执行，或者“获得购买详细资料”的活动被激活。

如果购买资料不完全，系统又回到“显示购买窗体”，否则进入“存储订单”。并且接着进入“Email订单资料”，然后活动结束。

一般来说，只有“退出”活动状态被显示出来，一般活动内部的分支，可以推断出来。有时候重要的分支可以使用分支，并附上监护条件。

 

三、客户服务子系统用例分析

 

下面，我们来研究一下另外一个重要的子系统，客户服务子系统的用例分析。

 

1 ，发现参与者

 

客户服务子系统主要实现客户分级管理策略，而且可以灵活的处理促销策略，从项目影响范围的研究中，我们可以发现参与者。

 

参与者词汇表
参与者	描述
基本客户	已经有稳定业务往来的公司。
潜在客户	预计可能有业务往来的公司。
曾经客户	过去有业务往来，但是最近6个月内没有购买设备，但仍然保持良好的身份记录。
市场部	响应创建折扣和订阅程序，并为公司进行销售的组织部门。
客户服务部	按照合同为客户提供联系服务的组织部门。
财务部门	处理客户付款和收费，以及维护客户账户信息的组织部门。
时间	触发时序事件的参与者。
仓库管理子系统	存储和维护TB公司产品库存，并且处理顾客发货和退货的实体。
网上销售子系统	实现基于Web的电源产品销售。

 

2 ，确定业务需求用例

 

与已经建立的网上订购项目相比，这个新系统的最大特点，是把市场行为作为系统的重要功能，所以功能上和以前的系统有诸多不同。

首先我们需要记录项目的初始范围，也就是定义一个系统应该准备支持的业务方向，这就是所谓系统上下文数据流图，其方法是：

1，区分内部和外部，忽略内部工作，专注于外部功能。

2，询问最终用户系统需要响应什么业务事务，这些业务事务就是系统的 净输入。

3，询问最终用于系统需要有什么响应，这些相应就是系统的 净输出。

4，确定外部数据存储，以实体的形式表达，数据库和文件一般是属于外部的。

注意：系统上下文并不是越复杂越好，而是要把握系统功能的重点，细节问题可以在后面的详细分析中解决。

下面是这个项目子系统的上下文。

在这个系统中定义边界的时候，可以考虑把网上销售子系统暂时排除在外，也就是把网上销售子系统定义成外部接受者。我们可以建立一些用例并定义它的词汇。

 

编号	用例名称	用例描述	预期的参与者和角色
1	提交订阅订单	描述一个潜在客户通过订阅加入本系统，这个潜在客户至少答应在两年内购买一定数量的本公司设备。	潜在客户
2	提交订阅更新订单	描述一个过去的客户通过订阅加入本系统，这个客户过去是本公司的基本客户，尽管6个月内这个活动一度中断，但现在准备恢复商业活动。	曾经客户
3	提交客户资料修改	描述一个基本客户修改他的个人资料，包括公司地址、e-mail、密码和基本购买配置方式。	基本客户
4	处理订单和客户资料	描述一个客户通过网上销售子系统提交一个TB公司产品订单，以及有关的客户资料，等待客户服务子系统返回相关的折扣信息。	网上销售子系统 市场部
5	查询购买历史	描述一个基本客户查阅他三年内的购买历史。	基本客户
6	建立新客户订阅程序	描述市场部建立一个新的客户订阅计划（在什么情况下可以得到更大的优惠）来吸引新的客户。	市场部
7	提交订阅程序修改	描述市场部为基本客户修改订阅计划，比如优惠期的延长等等。	市场部
8	提交曾经客户重新订阅程序	描述市场部建立一个重新订阅计划，比如曾经客户可以更短的时间内享受到优惠，以吸引回曾经客户。	市场部
9	提交新促销	描述市场部建立一个新的促销计划，以吸引不同的客户来购买。需要注意，促销计划一般有专门的名称，以表明在某种情况下可以以特殊的价格来购买。这些促销产品可以集成到一个特殊的目录中在网上公布，并且通过e-mail发送给基本客户。	市场部
10	修改促销	描述市场部修改促销条件。	市场部
11	每日生成默认合同报告	描述每天生成一个报告，列出还没有达到“优惠级基本客户”购买量的基本客户，这些客户购买量以30天、60天、120天过期三个级别排序。	时间（发起） 客户服务部（外部接收者）

 

注：参与者没有标注的为主要业务参与者，表达他收到了某些可度量的价值。

这样就可以画出系统的用例图。注意这个图中，并没有致力于包含和依赖关系的研究，这是因为图形比较复杂的时候，有些事情单独考虑更有利，比如我们会在后面单独考虑依赖关系，并且以此生成开发策略。

 

3 ，撰写用例文档

 

为了更清楚的表达用例的事件流，需要写出用例文档，这里只列出了“处理订单和客户资料”用例的文档。

电源客户服务系统

作者: _______________                                                                           日期:      ___________

                                                                                                               版本:      ___________

用例名 :	处理订单和客户资料	用例类型
用例 ID:	TB-ES2.00	业务需求
主要业务参与者 :	网上设备销售子系统
其它参与者 :	基本客户，曾经客户，潜在客户 销售部（外部接收者） 财务部（外部接收者）
项目相关人员兴趣 :	客户：对自己的级别能得到的优惠感兴趣。 市场部：对销售活动感兴趣，同时也为了计划新的促销。 采购部：对销售活动感兴趣，为了补充库存。 管理层：对销售活动感兴趣，为了评估公司业绩和客户满意度。
描述：	该用例描述一个客户提交一个TB公司产品订单和客户资料，由客户服务系统根据客户级别和销售策略计算销售价格。 客户的资料信息以及他的帐号被验证，订单提交后系统需要查询客户所处于的级别，再根据促销策略，提供则扣信息，然后计算销售价格。
前置条件：	客户已经登录，由网上设备销售子系统传送来客户资料和购买细节。
后置条件：	订单被记录，向网上设备销售子系统发送具有折扣的付款信息。
触发条件 :	当新的客户订单被提交的时候，该用例被触发。
基本流程 :	1，由“网上设备销售子系统”传递过来客户提交的资料信息、订单信息和支付信息。 2，系统验证所有信息。 3，根据客户信息验证客户优惠级别。 4，对于订购的每件产品，系统验证产品标识。 5，对每件产品，系统根据客户优惠级别和当前促销政策计算价格。 7，系统计算总价格 8，系统检查客户付款帐号的状态。 9，系统检查客户支付状况（如果是网上支付）。 10，系统记录订单信息，向“网上设备销售子系统”返回价格和优惠信息。
替代流程：	1a，客户没有提供足够的信息，通知客户重新提交。 4a，如果客户需要的产品和TB公司提供的商品不符，则要求客户澄清。 8a，如果客户帐号信用不良，则把订单挂起，并且通知客户，退出用例。 9a，如果标准支付方式无法完成，则通知客户，并希望客户提供另一种支付方式。
结束 :	当“网上设备销售子系统”收到价格信息的时候，该用例结束。
实现约束和说明：	“网上设备销售子系统”客户为Web界面，内部工作人员为GUI界面。
待解决问题 :	需要研究客户对优惠级别或者促销政策有疑问，能够快速的和有关销售人员联系，该销售人员能够迅速查阅信息，并作出解释。

 

4 ，风险分析和优先级的考虑

 

为了发现最重要的用例，需要对用例的重要性或者开发风险进行评估，可以采用用例分级和评估矩阵来做这个初步分析，数据的来源可以采用项目相关人员和开发团队打分法来完成。

 

用例名称	分级标准（1-5 ）						总分	优先级	构造周期
	1	2	3	4	5	6
提交订阅订单	5	5	5	4	5	5	29	高	1
处理订单和客户资料	4	4	5	4	5	5	27	高	2
建立新客户订阅程序	4	5	5	3	5	5	27	高	1
每日生成默认合同报告	1	1	1	1	1	1	6	低	3
修改促销	2	2	3	3	4	4	18	中	2
提交新促销	3	2	3	4	2	1	15	低	2

 

从上面的表中，发现“提交订阅订单”优先级最高，应该首先开发。但这还不能完全确定，还需要考虑用例的依赖关系。

所谓用例的依赖关系，表达的是这个用例完成的状态（后置条件）恰恰是这个用例的前置条件。从下面的图可以看出来，建立“新客户订阅程序”虽然优先级并不是最高的，但它处于依赖关系的最前端，所以应该最先开发。

 

四、客户服务子系统的过程分析

 

从方法学的角度，尽管很多情况下我们提倡面向对象的分析，但对于系统功能来说，面向过程的分析有时还是有其优点的，因为它直接对应于工作流程和系统的结构，事实上现代分析中，通过引入用例和事件的概念，使这种改进的过程分析仍然具有生命力，下面对于我们所研究的课题，采用过程来细化分析。

 

1 ，上下文数据流图

 

这个问题已经在前面讨论过，这里就直接画出这个系统的上下文来。

 

 

2 ，功能分解图

 

功能分解显示了一个系统自顶向下的分解结构，也为我们绘制数据流图（DFD）的提纲，下面是图中的数字含义：

1）整个系统。

2）系统最初的子系统/功能块。并不要求和实际的组织系统对应，分析员和用户越来越多的被要求忽略组织边界，构造并且理顺过程和数据共享的交叉功能系统。

3）区分系统的运行部分和报告部分。

 

3 ，事件响应或用例清单

 

我们可以借用面向对象的用例分析来进行这一步的研究，主要是确定系统必须响应什么业务事件，从本质上说，系统存在三类事件：

1）外部事件：该事件发生时，产生一个到系统的事件流。

2）时序事件：以时间为基础的处罚过程。

3）状态事件：系统由一个状态转换为另一个状态时触发的事件。

当使用用例分析的参与者的时候，引发事件的参与者，将成为DFD中的外部代理，而事件将由DFD中的某个过程来处理。

下面，我们部分的列出在这里比较合用的用例清单。

 

参与者	事件（或者用例）	触发器	响应
市场部	制定一个新的客户关系订阅计划，把潜在客户变为基本客户。	新客户订阅程序	生成“订阅计划确认”，在数据库中创建合同。
市场部	制定一个新的客户关系订阅计划，以把曾经客户重新变为基本客户。	曾经客户订阅计划	生成“订阅计划确认”，在数据库中创建合同。
市场部	为当前客户改变订阅计划（例如延长优惠时间）	订阅计划改变	生成“合同修改确认”，修改数据库中合同。
（时间）	一个订阅计划过期。	（当前日期）	生成“合同修改确认”，在数据库中逻辑的删除（置空）合同。
市场部	在达到计划的过期日期之前取消一个订阅计划。	订阅计划取消	生成“合同修改确认”，在数据库中逻辑的删除（置空）合同。
客户	潜在客户通过订阅加入本系统，这个潜在客户至少答应在两年内购买一定数量的本公司设备。	新订阅	生成“合同目录修改确认”，在数据库中创建“客户”，在数据库中创建第一个“客户订单”和“客户订购的产品”。
客户	修改地址（包括电子邮件和密码）	地址修改	生成“客户目录修改确认”，修改数据库中的“客户”。
财务部	修改客户的信用状态。	信用状态修改	生成“信用目录修改确认”，修改数据库中的“客户”。
订单处理系统	输入订单和客户资料，获取针对具体客户的销售策略	客户确认产品	生成“客户订购产品优惠价格”发送给订单处理系统。
（时间）	市场部决定停止销售一个商品后90天。	（当前日期）	生成“目录修改确认”，在数据库中逻辑的删除（失效）“产品”。
（时间）	订单处理后90天	（当前日期）	在数据库中实际的删除 “客户订单”和“客户订购的产品”。
客户	查询自己购买历史记录（3年为限）	客户购买查询	生成“客户购买历史”。
客户服务部	生成月末报告	（当前日期）	生成“月度销售分析报告” 生成“月度客户合同例外情况分析报告” 生成“客户关系分析报告”

 

认真把这个通过这个表思考清楚：

1）引发事件的参与者，它们将成为DFD的外部代理。

2）事件，它们由DFD的某个过程处理。

3）输入或者触发器，它们将成为DFD中的一个数据流或者控制流。

4）所有的输出响应，它们也将成为DFD中的数据流，注意我们是用括号来表达时序事件。5）输出，注意这里不要暗示实现方式，当我们使用 报告这个词的时候，并不一定指的是书面报告。输出包括了修改数据模型中存储的实体模型，比如创建新的实体实例、修改实体的现有实例以及删除实体实例等。

一个系统的用例可能很多，对于设计者来说详细的列出是非常有必要的，仔细研究这些用例，然后给每一个事件分配一个子系统功能，可以绘制出事件分解图。

 

4 ，事件分解图

 

为了进一步分解功能，我们把每个用例的事件处理过程分解到图中，这个图可以认为是前面功能分解图的一个细化，如果太复杂，必要的时候可以多页来绘制。这个图可以作为分析和设计的一个提纲。

 

5 ，事件图和系统图

 

现在我们的眼睛盯住具体的细节，为每个事件过程绘制一个事件图，它们集合在一起定义了系统和子系统，系统图更多的是从宏观的角度看为题，更多的考虑相互关系，具体的绘图学员可以自己来完成。