北京大学出版社96年底所出的《微软的秘密》一书是目前我所见到的对微软公司软件产品开发过程介绍的最专业、最深入的一本书。通过本书，我们可以看到微软公司是如何对科学地对软件产品开发进行有效地管理，我想这些经验对于中国的广大软件开发人员，尤其是关心中国软件产业发展的各位朋友是大有益处的。所以特将此书中涉及软件产品开发的部分内容摘录出来(第四章"产品定义与开发过程")，与大家共同分享。本文作为摘录，自然是挂一漏万，所以建议大家若有时间还是找来原书一读。

在产品定义与开发过程中，微软遵循着一种可称之为"靠改进特性与固定资源来激发创造力"的战略。该战略可分为五个原则：

一、 将大项目分成若干里程碑式的重要阶段，各阶段之间有缓冲时间，但不进行单独的产品维护。

二、运用想象描述和对特性的概要说明指导项目。

三、根据用户行为和有关用户的资料确定产品特性及其优先顺序。

四、建立模块化的和水平式的设计结构，并使项目结构反蚋产品结构的特点。

五、靠个人负责和固定项目资源实施控制。

原则一：将大项目分成若干里程碑式的重要阶段，各阶段之间有缓冲时间，但不进行单独的产品维护。

项目进度安排与里程碑

微软通常采用"同步－稳定产品开发法"。典型项目的生命周期包括三个阶段：计划阶段完成功能的说明和进度表的最后制定，开发阶段写出完整的的源代码，稳定化阶段完成产品，使之能够批量生产。这三个大阶段以及阶段间内在的循环方法与传统的"瀑布"式开发方式很不相同，后者是由需求、详尽设计、模块化的代码设计与测试、集成测试以及系统测试组成的。而微软的三个阶段更像是风险驱动的、渐进的"螺旋"式的生命周期模型。

计划阶段的产品是想象性描述与说明文件，用来解释项目将做什么和息么做。在管理人员拟定进度表、开发员写出代码之前，这些东西都促进了人们对设计问题的思考与。 讨论开发阶段围绕三次主要的内部产品发布来进行；称定化阶段集中于广泛的内部与外部测试。在整个产品生产周期中，微软都使用了缓冲时间的概念。缓冲时间使开发组能够对付意外的困难和影响到时间进度的变故，它也提供了一种手段，可以缓和及时发货与试图精确估计发货时间之间的矛盾。

在开发和稳定化阶段的所有时间中，一个项目通常会将2/3的时间用于开发，1/3的时间用于稳定化。(Office部门副总裁曾这样概述通常的进度："一般说来，在总的进度表中，用一半的时间写出产品，留下另一半的时间调试或应付意外事故。这样，如果我有一个两年的项目，我会用一年来完成事先想好的东西……如果事情有点麻烦，我便去掉我认为不太重要的特性。")这种里程碑式的工作过程使微软的经理们可以清楚地了解产品开发过程进行到了哪一步，也使他们在开发阶段的后期有能力灵活地删去一些产品特性以满足发货时期的要求。

计划阶段

计划阶段是在一个项目的生命周期中，所有于开发前进行的计划所占用的时间。计划阶段产生出想象性描述、市场营销计划、设计目标、一份最初的产品说明、为集成其他组开发的构件而规定的接口标准、最初的测试计划、一个文档策划(印刷品和联机帮助形式的)以及一份可用性问题清单。计划阶段从想象性描述开始。想象性描述来自产品经理以及各产品单位的程序经理；它是对产品作业的市场营销设想，包括了对竞争对手产品的分析以及对示来版本的规划。想象性描述也可能讨论在前一次版本中发现面必须解决的问题以及应添加的生要功能。所有这些都基于对顾客和市场的分析以及从产品支持服务组处得到的资料。

说明文件从一个大纲开始，然后定义出新的或增加的产品特性，并对其赋以不同的优先级。说明文件只是产品特性的一个预备性概览；从开始开发到项目完成它要增加或变化20% – 30%。虽然在生命周期的后期说明变化一般较小，但越到后期，开发员就越是必须具充分的理由来作改变。

通常程序经理使用VB创建项目原型。他们也开展设计可行性研究以了解设计中的取舍情况，尽快做出涉及产品说明的决定。

对于重要产品的说明需由公司高层领导进行复审。对于不太生要的产品，则由部分经理去完成。

开发阶段

开发阶段的计划对三四个主要的里程碑版本都个咖分配一组特性，规定出特性的 细节 和技术上的相关性，记录下单个开发员的任务以及对进度的估计。在开发阶段中 ，开 发员在功能性说明的指导下写源代码，测试员写出测试项目组以栓查产品的特性 与工 作范围是否正常，用户教育人员则编写出文档草案。

当测试员发现错误时，开发员并不是留待以后处理，而是马上改正，并在整个开 发阶 段内使测试不断地、自动地进行。这就改善了产品的稳定性并且使版本发布日期 更易 估计。当达到项目中的一定阶段点后(40%时)，开发员就试图"锁定"产品的主要功 能 要求或特性，从此只允许小的改动。如果在此点之后开发员想作大的改动，他们 必须 与程序经理以及开发经理，问题也许还要征求产品部门经理的意见。

一个项目是围绕着3或4个主要的内部版本，或"里程碑子项目"来组织开发阶段的 。 一般用2至4个月来开发每一个主要的里程碑版本。每个版本都包括其自身的编码 、 优化、测试以及调试活动。项目为意外事故保留总开发1/3的时间，即"缓冲时间 "。 (苹果公司的小组是割裂的，独立的，各自开发各自的东西。在还有3个月就要发 货时， 才会将所有的东西集成起来；Boland公司以一种渐近的方式进行开发，即把工作 分成 许多小的部分，并且总是让开发的东西能够运转。看起来似乎这种渐进的方法费 时较 长，但实际上几护没有用过很长时间，因为这使你总是能掌握住事情真实的情况 。)

当对最后一个主要的里程碑版本做了测试与稳定化之后，产品就要进行"外观固定 "， 即确定产品的主要用户界面，如菜单、对话框以及文件窗口等。此后有关用户界 面将 不再进行大的改动，以免引进同步修改相应文档的困难。

稳定化阶段

稳定化阶段着重于对产品的测试与调试。项目在此阶段尽量不再增加新的功能， 除非 是竞争产品或者市场发生了变化。稳定化阶段也包括了缓冲时间，以应付不可预 见的 问题或者延迟。

项目进度表中的缓冲时间

微软使用缓冲计划，以在最高的效率与较好地对未来作预计之间求得平衡。这种 应付 突发事件的时间在开发和稳定化过程中是每一个主要里程碑的一部分。缓冲时间 主要 用于弥补由于对特性的不完全理解，或者是技术困难或是由于疏忽而忘记把任务 写入 进度，或者是未料到的难题而形成的漏洞。缓冲时间有助于一个项目适应意料之 外的 事件。

原则二：运用想象性描述和对特性的概要说明指导项目

为了给出足够的开发框架以使工作能持续进行，并且能容纳开发过程中出现的变 化并 保持足够的灵活性，微软采用想象性描述和概要的说明来指导项目开发，而不是 在一 开始就努力写出一份完整和详细的说明。所谓想象性描述是由程序经理和来自市 场营 销组的产品计划人员共同编写的一份非常短的文件，在其中主要是定义产品开发 的目 标(不涉及产品的具体细节！)。通常对一个全新的产品，想象性描述一般会相对 较详 细，在其中还含有一份粗略的说明文件。总的来说，微软对于想象性描述的要求 是： 越短越好，尽量说明"产品不做什么"(而不是"产品要做什么"！)。

运用想象性描述，程序经理开始编写功能说明文件，该文件解释产品的特性是什 么以 及这些特性如何与其他特性及产品发生关系。最初它只是一个概要性的说明文件 ，随 着项目的进展，程序经理会随时向其中添加更多的细节，最终的说明文件将变得 象用 户手册一样。完整的说明不只起着对产品最新功能的描述作用，而且它还是在产 品投 产与发货之前进行测试与评估的主要依据。

想象性描述有助于决定删除哪些特性

微软内的各个开发组采用想象性描述帮助细化产品版本的规定主题，然后以此主 题来 决定是否需要增加产品各个可能的特性。通常不要轻易改变所确定的主题，否则 可能 造成产品开发上的混乱。

编写说明文件

说明文件在产品小组的所有成员之间，产品小组之间以及产品小组与管理部门之 间起 着传递产品的设想与要求的作用。在说明文件中必须清楚地描述产品特性(描述每 个特 性如何工作，外观如何以及从用户的角度出发如何与用户交互。如果特性有一个 界面， 还应包括一张示意图，以显示出界面的效果)并赋于其相应的优先级。程序经理据 此建 立起项目的开发起度表。此外在其中还应包括以下各项内容：用一句话表示的项 目开 发目的，关于产品是什么与不是什么的清单，对顾客的定义，对竞争产品的定义 ，产 品对系统的要求(包括操作系统版本、最小内存要求、硬盘空间、处理器速度以及 显示 器分辩率)，对第三方(如打印机驱动程序、组件)的任何依赖性。

程序经理负责协调并"写下"说明

程序经理应考虑以下问题：

＊这项特性的要点是什么

＊用户如何使用该特性

＊这项特性有意义吗

＊该产品中或微软的其他产品中有类似的特性吗

＊有哪些问题补遗漏了

＊组内的交流令人满意吗

最终程序经理通过与组内开发人员的共同讨论决定有关特性的内容，并将其 写下来。

构造原型

构造原型是程序经理具体说明一件新产品或一个新版本的最好方法，这从许多方 面来 说都使开发前测试成为可能，尤其在可用性方面，并且有助于对与用户交互情况 作出 好的理解，它也能使产品说明更紧凑。

微软的开发人员通常采用VB构造用户界面原型，但是对于构造计算机屏幕模型之类的工作，画笔(Paintbrush)也是一个很好用的工具。

死板的说明变成有生命的文件

说明不应过于详细以至限制了发明创造。在项目开发过程中，说明文件的早期版 本会 有相当大的增加与改变。由于说明的变动可能会导致相应开发工作的极大变动， 所以 微软通常是将精力首先集中于那些没有什么用户界面的特性上，因为在完成开发 前不 必去了解用户对它们有何反应，也就是说这些特性不大可能改变。然后再面对其 它特 性。

但是当产品开发到一定程序后，例如40%之后，程序经理必须严格控制对特性的修 改(主 要是指增加新的特性)，否则不光会造成开发延迟，而且会压缩可用的测试时间。

原则三：根据用户行为和有关用户的资料确定产品牲及其优先顺序

对于一个开发项目而言，如何确定最终产品中应包含什么特性通常是比较困难的 一件 事。为此微软采用了一个称之为"基于行为制定计划"的方式来进行特性选择 与优 先 级安排。

基于行为制定计划法从对用户行为，诸如写信或做预算，做系统研究开始。然后 ，根 据某一特性在支持重要的或者是经常的用户行为上的程序对其进行评价。这样做 的优 点是对特性取舍的更理性的讨论，对顾客想要做什么的更好的安排，对某个给定 特性 是否方便了特定任务的更集中的辩论，可读性更强的说明，以及在市场营销、用 户教 育和产品开发中更好地同步。

特性选择和优先级安排中的基于行为制定计划

基于行为制定计划法中的关键点在于按用户行为、产品特性以及行为和特性之间 的内 部联系来分析产品。程序经理和产品计划者把产品试图支持的用户任务或方案分 成大 约20个"行为"，然后他们努力把行为(以及任何子行为)映射入微软的现行特性和 竞 争对手产品的特性中去。他们也把行为映射到不同的顾客形象或不同的市场部分 中去。

当说明产品的新版本时，基于行为制定计划法帮助程序经理和开发员集中他们的 精力 与创造力。向Excel之类的项目争取在每个新版本中加入的主要行为不超过四个。 绝 大多数制性直接映射入这些行为之中。该做法使项目可以按特性对用户的价值来 进行 分级。

通过分级，促使程序经理和开发人员都行动起来，使他们的特性支持尽可能多的 行为。 这种良性竞争对于用户有益，同时也利于提高生产率。

为顾客行为而非产品特性惧资料

基于和为制定计划进，项目在计划阶段首先集中于和为，其次才是特性。程序经 理和 市场营销人员并不去思考和排除他们喜爱的特性，再围绕它们搞出想象性描述的 草案。 他们真正做的是列出一份顾客都做些什么的清单，然后把想象性描述集中于支持 那些 行为的特性上。

以行为为中心对产品进行全面考虑

由于基于行为制定计划法是从整个产品的观点着眼，因此有助于在不同职能上工 作的 项目成员理解产品做什么，以及其他产品的相应特性如何可能支持那些需要或不 需要 其他应用软件产品的行为。

做市场营销研究以支持基于行为制定计划法

为支持基于行为制定计划法，从市场营销组来的产品经理与程序经理、开发人员 一起 开展一些联合的研究，如指导对用户的研究工作。然而，一般来说是产品经理做 大多 数的研究，并可使其更明确地影响微软产品的演进。

原则四：建立模块化的和水平式的设计结构，并使项目结构反映产品结构的特点

微软产品设计中的一个关键概念是产品的基础结构，尤其是生命周期短的应用软 件， 应随项目的进展变得更加单一(而不是错综复杂)。当开发组构造产品的第一版时 ，他 们更多地使用分级式结构，好为产品设计规定出一个最初的架构。随着时间推移 ，他 们向单一的结构迈进，以使项目能集中于特性开发。项目需要逐渐的啬和删除我 ，鬃 着时间改变和发展我，以及增加产品间特性表现和运作的一致性。微软越来越强 调不 同产品间的特性共享。共享有助于使不同产品的"性能与感觉"都统一协条起来； 它 也方便了需要不只一个应用软件的用户，减少了代码的重复书写，缩小了单独一 个应 用软件的规模。

微软用特性小组组织产品开发，这种方法使得每个人都容易明白小组是如何与整 个产 品相关联的。项目从规定概要说明开始。概要说明的形式是一份已确定了优先级 安排 的内容清单，涉及产品下一版本将要开发的相对独立的特性，以便由分开的特性 小组 加以开发。

程序经理和开发员把项目分成特性子集，再将之分配给每个特性小组，让他们在 3到 4个主要的内部项目里程碑中进行生产。这种产品组织与开发法使微软能靠简单地 增 加开发员和创建一个大的小组来渐进地增加产品的功能。

把特性(与函数)作为开发单位

微软件产品的特性是用户最终可见的相对独立的功能单位，就如建筑材料一般， 对应 用软件产品更是如此。系统软件产品，如NT或者95的特性，对最终用户通常不直 接 可见。微软和其他公司有时简单地称这些不直接可见的特性为"函数"。

程序经理承担开发一组特性或函数，实现从说明经测试、文档化直到最后完成的 过程。 他们必须开开发员合作，后者负责估计进度表与完善每个特性。开发员还要在一 台联 网开发计算机上存储一到几个文件，用以保存特性的程序源代码。

大多数特性的开发与改进只要一名开发员，而有的大型特性则要一个小的小组。

产品结构是决定其长期结构完整性的基石

产品结构是产品内部的基干，它规定了重要的结构构件以及这些构件如何组装到 一起。 产品结构及用于组装结构的构件，提供了实现产品特性(即做详细设计与编码)的 支柱。 产品的结构对最终用户而言，通常并非直接可见。只有结构要实现的特性是可见 的。 产品结构也是决定产品长期结构完整性的基石。产品功能的任何改变都不应造成 潜在 的产品结构散 架。

产品的层次结构

对于产品，也可以采用层次结构的方法加以分析。通常定义良好的层次结构有助 于对 产品特性进行灵活的增加、删除与改进。此外良好的层次结构有助于产品在不同 平台 上的移植。(例如Excel总共定义了五层，其中只有最底层的操作系统层是与平台 相关 的，其它各层均是通过调用其下层所提供的API接口加以实现的，所以其移植极其 方 便。而在Windows 95中通过"虚拟机"的概念实现了对16位、32位以及DOS程序 的支持。)

小的结构文档：源代码是唯一文件

除了API文档，微软不对其产品结构生成相应的文档，虽然有时高级开发员可能会 写 下高层结构。对复杂的特性，许多开发员在某些点记录并复查特定于他们所负责 的结 构细节，但此工作是可选的，并不强制执行。除了源代码文件与特性说明，为数 不多 的组为新程序员准务了描绘某层结构的文档(主要的数据结构，如何工作等等)。 但是 这些文件并不时常更新，经理们也不要求项目组生成此类内部文档。在有关的说 明文 件中，并不涉及实现问题。开发员应该知道如何去实现，或者能够去学会。记录 的关 于结构的文档如此之少是因为"一个开发员的工作是编写我们要卖的代码，而不是 花 时间写高水平的设计文件"，"设计文件不应与源代码分离"。

分割代码与"保持事情的简单"

特性小组和作为"内容专家"的小组领导

特性小组一般由一个领导和3至8名开发人员组成，工作于相关的特性领域。小组 的 规模常常视小组领导的经验和能力而定。特性小组领导向项目开发领导汇报并负 责荐 目的全部开发工作；而项目开发领导则拥有对产品的更为全局性的观点，从而最 有可 能发现部部互相关联的问题。在特性小组中的每个人均是此领域的"专家"，他们 了解 如何使用产品、了解竞争对手的产品、了解未来将向何处去。通常为便于交流， 提高 软件的组织结构(软件倾向于映射出构造 它的组织的结构)，应保持特性小组的小 规 模。

原则五：靠个人负责和固定项目资源实旋控制

对于软件项目而言，精确估计产品的开发与交付进度是很困难的。对此微软采取 的方 法是将进度安排和工作管理的责任推到最底层，即单个的开发人员和测试人员那 儿去。 这保证了每个人除了作为小组的一部分外，还负有个人的责任。单独的开发人员 设立 他们自已的进度表，程序经理把单独的进度表汇总起来，再加上缓冲时间，以制 定出 一个全面的项目进度表。顶层的总经理也固定人员与时间等基本资源，以确保项 目集 中并限制其努力与创造程序。

关键的目标，尤其对应用软件，是指明产品的目标出品日并争取尽可能长久地坚 持它。 程序经理和开发员从出品日回溯，规定中间的项目里程碑的日期。这个"固定的出 品 日"法的中心在开发员身上。以避免因为项目没有固定的结束点，导致在最终无用 的 设计、再设计和测试的循环中消耗一年或更多的时间。

开发人员做出他们自已的进度估计

比尔犯谴那康魑⑷砣每⒃焙托∽樯瓒ㄋ亲砸训哪勘辏骸八姓庑┤掌诙际切 ∽槎ǖ 娜掌凇Ｃ挥衅渌速彩酝忌瓒ㄕ飧鋈掌凇Ｎ颐窃诖笤?0年前就抛弃了那种自目而 下的 日期设定方法"。但是开发人员一般会做出较乐观的估计，因此开发经理还需对他 们所 提供的日期进行调整并加上缓冲时间以避免因因信息不完全而出现的问题。微软 这种 制定进度的方法的优点在于：它从人们那儿得到更多的合作，因为日期是自已定 的， 不是经理定的；进度总是富有进取性，因为开发人员不可避免地会低估他们真正 需要 的进间。

对细致的任务的进度估计

微软的第二个进度排方法是，对要完成之任务做非常详尽的考虑，在此基础上请 开发 人员给出他们对"实现"的估计，以此力图"促使"更加现实主义并避免过度低估。

通常微软把任务细化到4小时(半天)到3天之间。对于准确进度的安排，微软的经 理 是这样认识的："任何任务只要超过一星期，那人们就一定没有充分地全盘考虑它 。任 何任务某人估计只用少于半天就可完成，则他对它考虑得太多了。他应该用列多 的时 间去编程，更少的时间来考虑。"对于类似类于Windows NT之类的操作系统而言， 进 度安排更加困难，对其一般以几天或者半周为工作单位进行进度估计。

安排开发人员与小组进度时的心理学

当项目变大时，微软把员工分成小组。然后经理把进度的责任和所有权尽可能地 分发 下去，直到小组和个人；这使二者都产生了一种拥用工作的感觉。它还在小组中 ，个 人中，尤其是小组领导中造成强烈的跟上其它同事预计进度的压力，因为经理可 能再 平衡进度，从落后的小组或个人手中拿走工作。这样，同事间的压力使经理不需 要太 多的努力就可以对个人或单个小组的进程实施严格控制。

"固定的"出品日

为了把创造力约束在时间限制之中，微软现在在新产品或者产品新版本开始前争 取固 定出品日，至少是有出品日的内部目标。这给人们施加砍去特性和集中在一个项 目上 的压力，逼迫他们去苦苦思考应将那个新特性加入产品中。虽然最终产品的交付 目标 可能是由高级执行人员设定，但是开发人员与小组仍然设定他们自已的进度表。





附录：同步－稳定开发法

计划阶段

定义产品的想象性描述、说明与进度

＊想象性描述 产品和程序管理部门运用广泛的顾客意见来确定和优化产品的 特性。

＊ 说明文件 基于想象性描述，程序管理部门与开发组定义特性的功能寮殃，结 构问题， 以及各部分间的相关性。

＊ 制订进度表与构造特性小组　其于说明文件，程序管理部门协调进度表，安排 出特 性小组，每个小组包括大约1名程序经理，3 – 8个开发员，3 – 8个测试员(以1: 1比例 与开发员平行工作。)

开发阶段

用3 – 4个顺序的子项目，每个产生一个里程碑式的产品发送，来完成特性的 开发。

程序经理协调开发过程。

开发员设计、编码、调试。测试员与开发员配对，不断进行测试。　

＊子项目Ⅰ 前1/3的特性：最重要的特性与共享的构件。

＊子项目Ⅱ 中间1/3的特性。

＊子项目Ⅲ 最后1/3的特性：最不重要的特性。

稳定化阶段

全面的内外部测试，最后的产品稳定化以及发货。

程序经理协调OEM与ISV，监督从顾客得到的信息反馈。开发员进行最后的调试与

代码稳定化。测试员发现并清除错误。

＊内部测试 公司内部对整个产品做详尽的测试。

＊ 外部测试 公司外在的"β"测试点，象OEM，ISV以及最终用户处对整个产品做

详尽的测试。

＊发货准备 为批量生产准备发布最后的"金盘"与文档。

UML是一种建模语言而不是方法,这是因为UML中没有过程的概念,而过程正是方法的一个重要组成部分。UML本身独立于过程,这意味着用户在使用UML进行建模时,可以选用任何适合的过程。过程的选用与软件开发过程的不同因素有关,诸如所开发软件的种类(如实时系统、信息系统和桌面产品)、开发组织的规模(如单人开发、小组开发和团队开发)等。用户将根据不同的需要选用不同的过程。然而,使用UML建模仍然有着大致统一的过程框架,该框架包含了UML建模过程中的共同要素,同时又为用户选用与其所开发的工程相适合的建模技术提供了很大的自由度。

1. UML建模过程高层视图

图2是UML建模过程的一个高层视图。这是一个迭代递增的开发过程。使用此方法,不是在项目结束时一次性提交软件,而是分块逐次开发和提交。构造阶段由多次迭代组成,每一次迭代都包含编码、测试和集成,所得产品应满足项目需求的某一子集,或提交给用户,或纯粹是内部提交。每次迭代都包含了软件生命周期的所有阶段。同时,每次迭代都要增加一些新的功能,解决一些新的问题。

因此,首先要做的工作是:选择一些功能点,然后完成这些功能;之后再选择别的功能点,如此循环往复。前两个阶段是初始( Inception)和细化 ( Elaboration) 阶段。在初始阶段,需要考虑项目的效益,并确定项目的范围。这一阶段需要与项目出资方进行讨论。在细化阶段,需要收集更为详细的需求,进行高层分析和设计,并为构造阶段制定计划。运用这种迭代开发过程时,还有一些工作(如β测试、性能调试和用户培训等)要放到最后的移交阶段(Transition)中进行。

事实上,涉及实际建模工作的微过程存在于上述的每次迭代中。迭代式开发是项目成功的重要保证。

2. UML实际建模过程

每次迭代都分为以下几个阶段:
分析阶段　建模的目的是捕捉系统的功能需求,分析、提取所开发系统的”客观世界”领域的类以及描述它们的合作概貌。
设计阶段　建模的目的是通过考虑实现环境,将分析阶段的模型扩展和转化为可行的技术实现方案。
实现阶段　具体工作就是进行编码,同时对已构造的模型作相应的修正。
配置阶段　通过模型描述所开发系统的软硬件配置情况。
测试阶段　使用前几个阶段所构造的模型来指导和协助测试工作。

在系统开发的不同阶段,使用UML为系统建模,可以通过建立不同的模型,从不同的视角,以不同的详略程度对系统进行描述。下面以一个商业管理信息系统的开发过程为例,具体介绍UML建模的实际过程:
(1) 需求
最初版本商业MIS的正文需求规格说明应当由代表系统最终用户的人员提供,内容包括系统基本功能需求和对计算机系统的要求。大致描述如下:
· 它是一个商业支持系统;
· 采购员采购所需的商品;
· 保管员将采购的商品登记入库;
· 调拨员将库存商品调拨到相应的销售部门;
· 销售部门销售商品;
· 统计部门核算商场经营状况;
· 系统能运行于通用的技术环境(如Unix、Windows等)中,具有
良好的图形用户界面
· 系统容易维护,便于功能扩充 。
由于基于UML的系统开发采取增量和迭代方式,商业MIS的初始版本仅需要完成系统的最基本功能(基本业务),而其他功能的实现(如商品移管、电子订货、电子支付、网络销售等)则在以后的版本中完成。

(2) 分析
分析的任务是找出系统的所有需求并加以描述,同时建立模型,以定义系统中的关键领域类,应由系统用户和开发人员合作完成。这一阶段不要拘泥于设计细节和技术方案。

需求分析
分析的第一步是定义用例,以描述所开发系统的外部功能需求。用例分析包括阅读和分析需求说明,此时需要与系统的潜在用户进行讨论。用例模型的主要构件是用例、角色和系统边界。用例用于描述每个功能需求,系统边界用于界定系统功能范围,而角色用于描述与系统功能有关的外部实体,它可以是用户,也可以是外部系统。
在本实例中,通过分析,先确认商业MIS中的角色有销售人员、库存人员、采购人员、辅助人员和分析人员。在此基础上,确认用例。商业MIS的用例有订货采购、库存管理、商品销售、统计分析、系统维护(包括增加商品、取消商品、制作标签、价格变更、取消或更新标签)。如图3所示。

除了用用例图描述系统需求外,还可以用文字(或活动图)对每个用例进行需求说明,更具体地描述该用例与角色的交互。例如我们可以描述订货采购用例的需求说明如下:
· 如果是新商品:
a. 新商品登记;
b. 采购进货;
c. 登记入库 。
· 如果商品库存不足:
a. 采购进货;
b. 登记入库。
订货采购需求可以用活动图来描述,如图4所示。由于用例的需求说明直接影响到后续设计阶段对类的操作的定位,因此,用例的需求说明应当尽量全面、准确。

值得说明的是,绝大多数用例可以在系统需求分析阶段确定,但随着系统的进展,可能会发现更多的用例,甚至会发现前面定义的用例存在不够确切或错误的地方,需要重新修改。因此,在整个系统开发过程中,都应当时刻关注用例。

特定领域分析
分析阶段的另一项工作是特定领域分析,以列出系统中的特定领域类。我们可以通过阅读规格说明、用例以及寻找系统处理的”概念”来进行特定领域分析,也可以通过用户和领域专家的讨论,以识别出要处理的所有关键类及它们的相互关系。这里的特定领域是指具体的商业领域,而不是整个系统领域。
在本实例中,可以确定商业MIS中的特定领域类为商品、保质商品、非保质商品、物品、销售、订货、库存、厂商,并使用类图来描述系统领域类及其关系。
需要强调的是,这一阶段对特定领域类的描述具有一定的素描性质,也就是说特定领域类的操作和属性不一定与最终实现时的定义一致。因为此时还没有涉及到系统功能的具体实现,不可能准确、完整地定义它们。有一些操作需要在设计阶段细化时才能确定。
此外,为了描述领域类的动态行为,可以使用UML中的任何一种动态图(如顺序图、活动图、合作图、状态图)。本阶段的各动态图都具有素描性质,主要是为了协助对领域类及其相互关系的分析,为下一阶段的具体设计打下基础。
UML建模是很灵活的过程,使用者不必面面俱到地画出各种图。对于每一幅图,只有在必要时(比如能帮助分析、设计、指导编码、加深理解、促进交流等)才需要画出,这样的图对建模才有意义,否则会浪费精力而事倍功半
(3) 设计
设计阶段的任务是通过综合考虑所有的技术限制,以扩展和细化分析阶段的模型。设计的目的是指明一种易转化成代码的工作方案,是对分析工作的细化,即进一步细化分析阶段所提取的类(包括其操作和属性),并且增加新类以处理诸如数据库、用户接口、通信、设备等技术领域的问题。
设计阶段可以分为两个部分:结构设计是高层设计,其任务是定义包(子系统),包括包间的依赖性和主要通信机制。我们希望得到尽可能简单和清晰的结构,各部分之间的依赖尽可能的少,并尽可能的减少双向的依赖关系。
第二部分是详细设计,细化包的内容,使编程人员得到所有类的一个足够清晰的描述。同时使用UML中的动态模型,描述特定情况下这些类的实例之间的行为。
· 结构设计
一个设计良好的系统结构是系统可扩充和可变更的基础。包实际上是一些类的集合。类图中包括有助于用户从技术逻辑中分离出应用逻辑(领域类),从而减少它们之间的依赖性。这就是软件结构设计强调的模块间的高聚合、低偶合的原则。在商业MIS中,存在以下包(或子系统):
用户接口包:用户接口类允许用户访问系统数据和加入新数据。在商业对象中,用户接口包跟商业对象包合作,调用商业对象的操作,实施数据的检索和插入。
商业对象包:包括来自分析阶段的特定领域类。在设计阶段,详细设计这些类,以完整定义他们的操作,支持对数据库的存取。所以,所有商业对象类必须继承数据库包中的类。
数据库包:为商业对象包中的类提供服务,便于永久存储。
实用包:包含系统其他包要使用的服务。它们之间的内在关系如图1所示。

· 详细设计
详细设计的目的是通过创建新的类图、状态图和动态图,描述新的技术类,并扩展和细化分析阶段”素描”的商业对象类。这些图在分析阶段也曾用过,不过在详细设计阶段,它们是从技术层次上对系统进行更详尽的描述。如分析阶段的用例描述用来验证它们是否在设计阶段都得到处理,而顺序图用来展示系统中每个用例在技术上如何实现,等等。
数据库包:MIS的实现必须有永久存储对象即数据库的支持,因此系统中必须增加数据库层,提供这种服务。目前,市面上有许多商用数据库,有的是真正的面向对象数据库如工程数据库,有的是传统的关系数据库。由于我们只讨论设计方法,不涉及具体的环境,因此,可以抽象一个永久存储类来实现对数据库的通用操作,如存储、更新、删除、查询等。永久类类似于MFC中的基类。
商业对象包:设计阶段的商业对象包即是分析阶段的领域类,需要从实现角度对这些类进行细化,包括如何实现他们之间的关联和行为。所有这些对象类必须从数据库包的永久类中继承而来。分析阶段描述的类的操作,在设计模型中可能被分解成几个操作或者改变名称。因为分析是构造每个类的框架,而设计是对系统的详细说明,因此设计模型中所有类的操作必须定义符号和返回值。图2是经过细化后的商业类图(局部)

在设计阶段,也可细化分析阶段的状态图,更详细的显示状态的变换细节(如图3)。使用状态图可以揭示单个对象在整个系统中的变化细节,对了解和实现关键类有较大的帮助。
此外,还可以使用其他图在实现层上从不同侧面对分析阶段建立的模型进行细化。
用户接口包:用户接口包在其他包的”顶层”。在系统中,它为用户提供信息和支持。由于所有与用户的交互都是通过用户接口实现的,因此UML的动态模型非常适合对GUI包的描述。图4用顺序图描述系统增加新商品用例的动态模型。另一种表示顺序的图是合作图(如图5)。

建立用户接口是设计阶段的一项特殊活动。在商业MIS中,用户接口可以分为功能(系统中的主功能窗口,如采购、库存、销售、统计分析等)、信息(显示系统信息的窗口以及(维护系统的窗口)等三部分。
目前,由于可视化技术的迅速发展,用户界面的设计相对比较简单。一般情况下,应用系统的用户界面由带有菜单条和相应图形的主窗口组成。
(4) 实现
构造或实现阶段是对类进行编程的过程。可以选择某种面向对象对象编程语言(如Java)作为实现系统的软件环境。Java很容易实现从逻辑视图到代码部件的映射,因为类到Java代码文件之间是一一映射关系。图6是设计模型的部件图,显示逻辑视图到部件视图的一个简单映射。逻辑视图中的包也映射到相应的部件视图中。

在实现阶段中,可以选取下列图的说明来辅助编程:
· 类的规格说明:每个类的规格说明详细显示了必要的属性和操作。
· 类图:显示类的静态结构和类之间的关系。
· 状态图:显示类的对象可能的状态、所需处理的转移以及触发这些转移的操作。
· 包含某个类的对象的动态图(顺序图、合作图、活动图):显示该类的某个方法的实现或别的对象是如何使用该类的对象的。
· 用例图和规格说明:显示系统需求和结果。
编码期间也可能会发现设计模型的缺陷。这时需要开发者修改设计模型。修改设计模型时一定要保持设计模型与编码的一致性,以便将来易于维护。
(5) 测试和配置
完成系统编码后,需要对系统进行测试,它通常包括:单元测试、集成测试、系统测试和验收测试。在单元测试中使用类图和类的规格说明,对单独的类或一组类进行测试;在集成测试中,使用组件图和合作图,对各组件的合作情况进行测试;在系统测试中,使用用例图,以检验所开发的系统是否满足例图所描述的需求。
系统的配置是实际的交付系统,包括文档和组成模型等。对商业MIS而言,它是一个典型的客户/服务器系统。可以用配置图显示系统的物理结构,如图7所示。从表面上看,配置图能显示系统设备之间的关系以及显示节点跟可执行软件单元的对应关系。然而一旦某个节点内部的对象或可执行部件过多(超过5个),就很难完全用配置图清楚描述这种关系。

(6) 小结

本文所举的商业MIS系统的UML建模过程可以用图8来描述。其中首先要把握的是如何使用用例技术正确描述系统需求。UML中的类图描述的是系统中类的静态关系,对象图有助于对复杂类的理解。在系统开发过程中,类图可应用于分析、设计和实现阶段。类的包化有助于进行系统结构设计。商业MIS的包分为用户接口包、商业对象包、数据库包,他们之间的关系是前者依赖后者。

UML的动态模型包括状态图、顺序图、合作图以及活动图。在商业MIS中,顺序图对描述商业对象的交互非常有用,是商业MIS分析、设计和实现阶段最重要的支持手段之一。

总之,UML提供的九种视图从不同应用层次和不同角度为系统从系统分析、设计直到实现的提供有力支持。在不同的阶段建立不同的模型,建模的目的也各不相同。

UML为用户建模提供了强大的支持,并提供了很大的自由度。用户在遵循增量迭代开发的原则下,完全可以根据自己所开发系统的特点,在每次迭代的微过程(分析、设计、实现、测试和配置)中,灵活的选用UML所提供的各种图。
我们认为,未来的软件开发范式将具有以下三个特点:首先,软件开发自动化的程度将越来越高;其次,在所开发的软件中隐藏的差错将越来越少;第三,在新型软件工程环境的支持下,将有能力开发出自适应的软件系统。标准建模语言UML及其集成化支持环境,将为走向这个新范式铺平道路(全文完)。

1. 消息

在面向对象技术中,对象间的交互是通过对象间消息的传递来完成的。在UML的四个动态模型中均用到消息这个概念。通常,当一个对象调用另一个对象中的操作时,即完成了一次消息传递。当操作执行后,控制便返回到调用者。对象通过相互间的通信(消息传递)进行合作,并在其生命周期中根据通信的结果不断改变自身的状态。

在UML中,消息的图形表示是用带有箭头的线段将消息的发送者和接收者联系起来,箭头的类型表示消息的类型,如图2所示。

UML定义的消息类型有三种:

简单消息(Simple Message) 表示简单的控制流。用于描述控制如何在对象间进行传递,而不考虑通信的细节。
同步消息(Synchronous Message) 表示嵌套的控制流。操作的调用是一种典型的同步消息。调用者发出消息后必须等待消息返回,只有当处理消息的操作执行完毕后,调用者才可继续执行自己的操作。

异步消息(Asynchronous Message) 表示异步控制流。当调用者发出消息后不用等待消息的返回即可继续执行自己的操作。异步消息主要用于描述实时系统中的并发行为。

2. 状态图
状态图(State Diagram)用来描述一个特定对象的所有可能状态及其引起状态转移的事件。大多数面向对象技术都用状态图表示单个对象在其生命周期中的行为。一个状态图包括一系列的状态以及状态之间的转移。

(1) 状态　所有对象都具有状态,状态是对象执行了一系列活动的结果。当某个事件发生后,对象的状态将发生变化。状态图中定义的状态有:初态、终态、中间状态、复合状态。其中,初态是状态图的起始点,而终态则是状态图的终点。一个状态图只能有一个初态,而终态则可以有多个。

中间状态包括两个区域:名字域和内部转移域,如图3所示。图中内部转移域是可选的,其中所列的动作将在对象处于该状态时执行,且该动作的执行并不改变对象的状态。

一个状态可以进一步地细化为多个子状态,我们将可以进一步细化的状态称作复合状态。子状态之间有”或关系”和”与关系”两种关系。或关系(如图4)说明在某一时刻仅可到达一个子状态。例如,一个处于行驶状态的汽车,在”行驶”这个复合状态中有向前和向后两个不同的子状态,在某一时刻汽车要么向前,要么向后。与关系( 如图5)说明复合状态中在某一时刻可同时到达多个子状态(称为并发子状态)。具有并发子状态的状态图称为并发状态图。

(2) 转移　状态图中状态之间带箭头的连线被称为转移。状态的变迁通常是由事件触发的,此时应在转移上标出触发转移的事件表达式。如果转移上未标明事件,则表示在源状态的内部活动执行完毕后自动触发转移。

3. 顺序图

顺序图(Sequence Diagram)用来描述对象之间动态的交互关系,着重体现对象间消息传递的时间顺序。顺序图存在两个轴:水平轴表示不同的对象,垂直轴表示时间。顺序图中的对象用一个带有垂直虚线的矩形框表示,并标有对象名和类名。垂直虚线是对象的生命线,用于表示在某段时间内对象是存在的。对象间的通信通过在对象的生命线间画消息来表示。消息的箭头指明消息的类型。

顺序图中的消息可以是信号(Signal)、操作调用或类似于C++中的RPC(RemoteProce dure Calls)和Java中的RMI(Remote Method Invocation)。当收到消息时,接收对象立即开始执行活动,即对象被激活了。通过在对象生命线上显示一个细长矩形框来表示激活。

消息可以用消息名及参数来标识。消息也可带有顺序号,但较少使用。消息还可带有条件表达式,表示分支或决定是否发送消息。如果用于表示分支,则每个分支是相互排斥的,即在某一时刻仅可发送分支中的一个消息。

在顺序图的左边可以有说明信息,用于说明消息发送的时刻、描述动作的执行情况以及约束信息等。一个典型的例子就是用于说明一个消息是重复发送的。另外,可以定义两个消息间的时间限制。

一个对象可以通过发送消息来创建另一个对象,当一个对象被删除或自我删除时,该对象用”X”标识。

另外,在很多算法中,递归是一种很重要的技术。当一个操作直接或间接调用自身时,即发生了递归。产生递归的消息总是同步消息,返回消息应是一个简单消息。

4. 合作图

合作图(Collaboration Diagram)用于描述相互合作的对象间的交互关系和链接关系。虽然顺序图和合作图都用来描述对象间的交互关系,但侧重点不一样。顺序图着重体现交互的时间顺序,合作图则着重体现交互对象间的静态链接关系。

合作图中对象的外观与顺序图中的一样。如果一个对象在消息的交互中被创建,则可在对象名称之后标以{new}。类似地,如果一个对象在交互期间被删除,则可在对象名称之后标以{destroy}。对象间的链接关系类似于类图中的联系(但无多重性标志)。通过在对象间的链接上标志带有消息串的消息(简单、异步或同步消息)来表达对象间的消息传递。

(1) 链接　链接用于表示对象间的各种关系,包括组成关系的链接(Composition Li nk)、聚集关系的链接(Aggregation Link)、限定关系的链接(Qualified Link)以及导航链接(Navigation Link)。各种链接关系与类图中的定义相同,在链接的端点位置可以显示对象的角色名和模板信息。

(2) 消息流　在合作图的链接线上,可以用带有消息串的消息来描述对象间的交互。消息的箭头指明消息的流动方向。消息串说明要发送的消息、消息的参数、消息的返回值以及消息的序列号等信息
活动图(Activity Diagram)

活动图的应用非常广泛,它既可用来描述操作(类的方法)的行为,也可以描述用例和对象内部的工作过程。活动图是由状态图变化而来的,它们各自用于不同的目的。活动图依据对象状态的变化来捕获动作(将要执行的工作或活动)与动作的结果。活动图中一个活动结束后将立即进入下一个活动(在状态图中状态的变迁可能需要事件的触发)。图1给出了一个活动图的例子。

活动和转移

一项操作可以描述为一系列相关的活动。活动仅有一个起始点,但可以有多个结束点。活动间的转移允许带有guard-condition、send-clause和action-expression,其语法与状态图中定义的相同。一个活动可以顺序地跟在另一个活动之后,这是简单的顺序关系。如果在活动图中使用一个菱形的判断标志,则可以表达条件关系(见图1),判断标志可以有多个输入和输出转移,但在活动的运作中仅触发其中的一个输出转移。

活动图对表示并发行为也很有用。在活动图中,使用一个称为同步条的水平粗线可以将一条转移分为多个并发执行的分支,或将多个转移合为一条转移。此时,只有输入的转移全部有效,同步条才会触发转移,进而执行后面的活动,如图2所示。

泳道
活动图告诉你发生了什么,但没有告诉你该项活动由谁来完成。在程序设计中,这意味着活动图没有描述出各个活动由哪个类来完成。泳道解决了这一问题。它将活动图的逻辑描述与顺序图、合作图的责任描述结合起来。如图2所示,泳道用矩形框来表示,属于某个泳道的活动放在该矩形框内,将对象名放在矩形框的顶部,表示泳道中的活动由该对象负责。
对象
在活动图中可以出现对象。对象可以作为活动的输入或输出,对象与活动间的输入/输出关系由虚线箭头来表示。如果仅表示对象受到某一活动的影响,则可用不带箭头的虚线来连接对象与活动,如图2所示。
信号
如图3所示,在活动图中可以表示信号的发送与接收,分别用发送和接收标志来表示。发送和接收标志也可与对象相连,用于表示消息的发送者和接收者。

6. 四种图的运用
上面对UML中用于描述系统动态行为的四个图(状态图、顺序图、合作图和活动图)做了简单地介绍。这四个图均可用于系统的动态建模,但它们各自的侧重点不同,分别用于不同的目的。下面对如何正确使用这几个图做一简单的总结,在实际的建模过程中要根据具体情况灵活运用这些建议。

首先,不要对系统中的每个类都画状态图。尽管这样做很完美,但太浪费精力,其实你可能只关心某些类的行为。正确的做法是:为帮助理解类而画它的状态图。状态图描述跨越多个用例的单个对象的行为,而不适合描述多个对象间的行为合作。为此,常将状态图与其它技术(如顺序图、合作图和活动图)组合使用。

顺序图和合作图适合描述单个用例中几个对象的行为。其中顺序图突出对象间交互的顺序,而合作图的布局方法能更清楚地表示出对象之间静态的连接关系。当行为较为简单时,顺序图和合作图是最好的选择。但当行为比变复杂时,这两个图将失去其清晰度。因此,如果想显示跨越多用例或多线程的复杂行为,可考虑使用活动图。另外,顺序图和合作图仅适合描述对象之间的合作关系,而不适合对行为进行精确定义,如果想描述跨越多个用例的单个对象的行为,应当使用状态图。

标准建模语言UML的静态建模机制

任何建模语言都以静态建模机制为基础,标准建模语言UML也不例外。UML的静态建模机制包括用例图(Use case diagram)、类图(Class diagram)、对象图(Object diagram )、包(Package)、构件图(Component diagram)和配置图(Deployment diagram)。

1. 用例图

(1) 用例模型(Use case model)
长期以来,在面向对象开发和传统的软件开发中,人们根据典型的使用情景来了解需求。但是,这些使用情景是非正式的,虽然经常使用,却难以建立正式文挡。用例模型由Ivar Jacobson在开发AXE系统中首先使用,并加入由他所倡导的OOSE和Objectory方法中。用例方法引起了面向对象领域的极大关注。自1994年Ivar Jacobson的著作出版后,面向对象领域已广泛接纳了用例这一概念,并认为它是第二代面向对象技术的标志。
用例模型描述的是外部执行者(Actor)所理解的系统功能。用例模型用于需求分析阶段,它的建立是系统开发者和用户反复讨论的结果,表明了开发者和用户对需求规格达成的共识。首先,它描述了待开发系统的功能需求;其次,它将系统看作黑盒,从外部执行者的角度来理解系统;第三,它驱动了需求分析之后各阶段的开发工作,不仅在开发过程中保证了系统所有功能的实现,而且被用于验证和检测所开发的系统,从而影响到开发工作的各个阶段和 UML 的各个模型。在UML中,一个用例模型由若干个用例图描述,用例图主要元素是用例和执行者。

(2) 用例(use case)
从本质上讲,一个用例是用户与计算机之间的一次典型交互作用。以字处理软件为例,”将某些正文置为黑体”和”创建一个索引”便是两个典型的用例。在UML中,用例被定义成系统执行的一系列动作,动作执行的结果能被指定执行者察觉到。

图1 用例图

在UML中,用例表示为一个椭圆。图1显示了一个金融贸易系统的用例图。其中,”风险分析”,”交易估价”,”进行交易”,”设置边界”,”超越边界的交易”,”评价贸易”,”更新帐目”等都是用例的实例。概括地说,用例有以下特点:
·用例捕获某些用户可见的需求,实现一个具体的用户目标。
·用例由执行者激活,并提供确切的值给执行者。
·用例可大可小,但它必须是对一个具体的用户目标实现的完整描述。

(3) 执行者(Actor)
执行者是指用户在系统中所扮演的角色。其图形化的表示是一个小人。图1中有四个执行者:贸易经理、营销人员、售货员和记帐系统。在某些组织中很可能有许多营销人员,但就该系统而言,他们均起着同一种作用,扮演着相同的角色,所以用一个执行者表示。一个用户也可以扮演多种角色(执行者)。例如,一个高级营销人员既可以是贸易经理,也可以是普通的营销人员;一个营销人员也可以是售货员。在处理执行者时,应考虑其作用,而不是人或工作名称,这一点是很重要的。

图1中,不带箭头的线段将执行者与用例连接到一起,表示两者之间交换信息,称之为通信联系。执行者触发用例,并与用例进行信息交换。单个执行者可与多个用例联系;反过来,一个用例可与多个执行者联系。对同一个用例而言,不同执行者有着不同的作用:他们可以从用例中取值,也可以参与到用例中。

需要注意的是执行者在用例图中是用类似人的图形来表示,尽管执行的,但执行者未必是人。例如,执行者也可以是一个外界系统,该外界系统可能需要从当前系统中获取信息,与当前系统有进行交互。在图1中,我们可以看到,记帐系统是一个外界系统,它需要更新帐目。

通过实践,我们发现执行者对提供用例是非常有用的。面对一个大系统,要列出用例清单常常是十分困难。这时可先列出执行者清单,再对每个执行者列出它的用例,问题就会变得容易很多。

(4) 使用和扩展(Use and Extend)
图1中除了包含执行者与用例之间的连接外,还有另外两种类型的连接,用以表示用例之间的使用和扩展关系。使用和扩展是两种不同形式的继承关系。当一个用例与另一个用例相似,但所做的动作多一些,就可以用到扩展关系。例如图1中,基本的用例是”进行交易”。交易中可能一切都进行得很顺利,但也可能存在扰乱顺利进行交易的因素。其中之一便是超出某些边界值的情况。例如,贸易组织会对某个特定客户规定最大贸易量,这时不能执行给定用例提供的常规动作,而要做些改动。我们可在”进行交易”用例中做改动。但是,这将把该用例与一大堆特殊的判断和逻辑混杂在一起,使正常的流程晦涩不堪。图1中将常规的动作放在”进行交易”用例中,而将非常规的动作放置于”超越边界的交易” 用例中,这便是扩展关系的实质。当有一大块相似的动作存在于几个用例,又不想重复描述该动作时,就可以用到使用关系。例如,现实中风险分析和交易估价都需要评价贸易,为此可单独定义一个用例,即”评价贸易”,而”风险分析”和”交易估价”用例将使用它。
请注意扩展与使用之间的相似点和不同点。它们两个都意味着从几个用例中抽取那些公共的行为并放入一个单独用例中,而这个用例被其他几个用例使用或扩展。但使用和扩展的目的是不同的。

(5) 用例模型的获取
几乎在任何情况下都会使用用例。用例用来获取需求,规划和控制项目。用例的获取是需求分析阶段的主要任务之一,而且是首先要做的工作。大部分用例将在项目的需求分析阶段产生,并且随着工作的深入会发现更多的用例,这些都应及时增添到已有的用例集中。用例集中的每个用例都是一个潜在的需求。

a. 获取执行者
获取用例首先要找出系统的执行者。可以通过用户回答一些问题的答案来识别执行者。以下问题可供参考:
·谁使用系统的主要功能(主要使用者)。
·谁需要系统支持他们的日常工作。
·谁来维护、管理使系统正常工作(辅助使用者)。
·系统需要操纵哪些硬件。
·系统需要与哪些其它系统交互,包含其它计算机系统和其它应用程序。
·对系统产生的结果感兴趣的人或事物。

b. 获取用例
一旦获取了执行者,就可以对每个执行者提出问题以获取用例。
以下问题可供参考:
·执行者要求系统提供哪些功能(执行者需要做什么)?
·执行者需要读、产生、删除、修改或存储的信息有哪些类型。
·必须提醒执行者的系统事件有哪些?或者执行者必须提醒系统的事件有哪些?怎样把这些事件表示成用例中的功能?
·为了完整地描述用例,还需要知道执行者的某些典型功能能否被系统自动实现?
还有一些不针对具体执行者问题(即针对整个系统的问题):
·系统需要何种输入输出?输入从何处来?输出到何处?
·当前运行系统(也许是一些手工操作而不是计算机系统)的主要问题?
需要注意,最后两个问题并不是指没有执行者也可以有用例,只是获取用例时尚不知道执行者是什么。一个用例必须至少与一个执行者关联。还需要注意:不同的设计者对用例的利用程度也不同。例如,Ivar Jacobson说,对一个十人年的项目,他需要二十个用例。而在一个相同规模的项目中,Martin Fowler则用了一百多个用例。我们认为:任何合适的用例都可使用,确定用例的过程是对获取的用例进行提炼和归纳的过程,对一个十人年的项目来说,二十个用例似乎太少,一百多个用例则嫌太多,需要保持二者间的相对均衡。

2. 类图、对象图和包
数千年以前,人类就已经开始采用分类的方法有效地简化复杂问题,帮助人们了解客观世界。在面向对象建模技术中,我们使用同样的方法将客观世界的实体映射为对象,并归纳成一个个类。类(Class)、对象(Object)和它们之间的关联是面向对象技术中最基本的元素。对于一个想要描述的系统,其类模型和对象模型揭示了系统的结构。在UML中,类和对象模型分别由类图和对象图表示。类图技术是OO方法的核心。图1显示了一个金融保险系统的类图。

(1) 类图
类图(Class Diagram)描述类和类之间的静态关系。与数据模型不同,它不仅显示了信息的结构,同时还描述了系统的行为。类图是定义其它图的基础。在类图的基础上,状态图、合作图等进一步描述了系统其他方面的特性。
(2) 类和对象
对象(Object)与我们对客观世界的理解相关。我们通常用对象描述客观世界中某个具体的实体。所谓类(Class)是对一类具有相同特征的对象的描述。而对象是类的实例(Instance)。建立类模型时,我们应尽量与应用领域的概念保持一致,以使模型更符合客观事实,易修改、易理解和易交流。

类描述一类对象的属性(Attribute)和行为(Behavior)。在UML中,类的可视化表示为一个划分成三个格子的长方形(下面两个格子可省略)。图1中,”客户”就是一个典型的类。

类的获取和命名　最顶部的格子包含类的名字。类的命名应尽量用应用领域中的术语,应明确、无歧义,以利于开发人员与用户之间的相互理解和交流。类的获取是一个依赖于人的创造力的过程,必须与领域专家合作,对研究领域仔细地分析,抽象出领域中的概念,定义其含义及相互关系,分析出系统类,并用领域中的术语为类命名。一般而言,类的名字是名词。

类的属性　中间的格子包含类的属性,用以描述该类对象的共同特点。该项可省略。图1中”客户”类有”客户名”、”地址”等特性。属性的选取应考虑以下因素:
*原则上来说,类的属性应能描述并区分每个特定的对象;
*只有系统感兴趣的特征才包含在类的属性中;
*系统建模的目的也会影响到属性的选取。
根据图的详细程度,每条属性可以包括属性的可见性、属性名称、类型、缺省值和约束特性。UML规定类的属性的语法为:
可见性　属性名 :　类型 = 缺省值　{约束特性}
图1″客户”类中,”客户名”属性描述为”- 客户名 : 字符串 = 缺省客户名”。 可见性”-”表示它是私有数据成员,其属性名为”客户名”,类型为”字符串”类型,缺省值为”缺省客户名”,此处没有约束特性。
不同属性具有不同可见性。常用的可见性有Public、Private和Protected三种,在UML中分别表示为”+”、”-”和”#”。
类型表示该属性的种类。它可以是基本数据类型,例如整数、实数、布尔型等,也可以是用户自定义的类型。一般它由所涉及的程序设计语言确定。
约束特性则是用户对该属性性质一个约束的说明。例如”{只读}”说明该属性是只读属性。
类的操作(Operation)　该项可省略。操作用于修改、检索类的属性或执行某些动作。操作通常也被称为功能,但是它们被约束在类的内部,只能作用到该类的对象上。操作名、返回类型和参数表组成操作界面。UML规定操作的语法为:
可见性 操作名 (参数表) : 返回类型 {约束特性}
在图1中,”客户”类中有”取客户地址”操作,其中” +”表示该操作是公有操作,调用时需要参数”客户名”,参数类型为字符串,返回类型也为字符串。
类图描述了类和类之间的静态关系。定义了类之后,就可以定义类之间的各种关系了。

(3) 关联关系
关联(Association)表示两个类之间存在某种语义上的联系。例如,一个人为一家公司工作,一家公司有许多办公室。我们就认为人和公司、公司和办公室之间存在某种语义上的联系。在分析设计的类图模型中,则在对应人类和公司类、公司类和办公室类之间建立关联关系。
在图1中最上部存在一个”属于”/”签定”关联:每个”保险单”属于一个”客户”,而”客户”可以签定多个”保险单”。除了这个关联外,图1中还有另外两个关联,分别表示每个”保险单”包含若干个”保险单上的项目”,而每个”保险单上的项目”涉及单一的”保险类别”。

关联的方向　关联可以有方向,表示该关联单方向被使用。关联上加上箭头表示方向,在UML中称为导航(Navigability)。我们将只在一个方向上存在导航表示的关联,称作单向关联 ( Uni-directional Association ),在两个方向上都有导航表示的关联,称作双向关联 ( Bi-directional Association )。图1中,”保险单”到”保险单上的项目”是单向关联。UML规定,不带箭头的关联可以意味着未知、未确定或者该关联是双向关联三种选择,因此,在图中应明确使用其中的一种选择。

关联的命名　既然关联可以是双向的,最复杂的命名方法是每个方向上给出一个名字,这样的关联有两个名字,可以用小黑三角表示名字的方向(见图1中最上部的”属于”/”签定”关联)。为关联命名有几种方法,其原则是该命名是否有助于理解该模型。

角色　关联两头的类以某种角色参与关联。例如图2中,”公司”以”雇主”的角色,”人”以”雇员”的角色参与的”工作合同”关联。”雇主”和”雇员”称为角色名。如果在关联上没有标出角色名,则隐含地用类的名称作为角色名。角色还具有多重性(Multiplicity),表示可以有多少个对象参与该关联。在图2中,雇主(公司)可以雇佣(签工作合同)多个雇员,表示为”*”; 雇员只能与一家雇主签定工作合同,表示为”1″。多重性表示参与对象的数目的上下界限制。”*”代表0～∞,即一个客户可以没有保险单,也可以有任意多的保险单。”1″是1..1的简写,即任何一个保险单仅来自于一个客户,可以用一个单个数字表示,也可以用范围或者是数字和范围不连续的组合表示。

关联类　一个关联可能要记录一些信息,可以引入一个关联类来记录。图3是在图2的基础上引入了关联类。关联类通过一根虚线与关联连接。图4是实现上述目标的另外一种方法,就是使雇用关系成为一个正式的类。

聚集和组成　聚集(Aggregation)是一种特殊形式的关联。聚集表示类之间的关系是整体与部分的关系。一辆轿车包含四个车轮、一个方向盘、一个发动机和一个底盘,这是聚集的一个例子。在需求分析中,”包含”、”组成”、”分为……部分”等经常设计成聚集关系。聚集可以进一步划分成共享聚集(Shared Aggregation)和组成。例如,课题组包含许多成员,但是每个成员又可以是另一个课题组的成员,即部分可以参加多个整体,我们称之为共享聚集。另一种情况是整体拥有各部分,部分与整体共存,如整体不存在了,部分也会随之消失,这称为组成(Composition)。例如,我们打开一个视窗口,它就由标题、外框和显示区所组成。一旦消亡则各部分同时消失。在UML中,聚集表示为空心菱形,组成表示为实心菱形。需要注意的是,一些面向对象大师对聚集的定义并不一样。大家应注意其他面向对象方法与UML中所定义的聚集的差别。

(4) 继承关系
人们将具有共同特性的元素抽象成类别,并通过增加其内涵而进一步分类。例如,动物可分为飞鸟和走兽,人可分为男人和女人。在面向对象方法中将前者称为一般元素、基类元素或父元素,将后者称为特殊元素或子元素。继承(Generalization)定义了一般元素和特殊元素之间的分类关系。在UML中,继承表示为一头为空心三角形的连线。
如图1中,将客户进一步分类成个体客户和团体客户,使用的就是继承关系。
在UML定义中对继承有三个要求:
*特殊元素应与一般元素完全一致,一般元素所具有的关联、属性和操作,特殊元素也都隐含性地具有;

*特殊元素还应包含额外信息;
*允许使用一般元素实例的地方,也应能使用特殊元素。

(5) 依赖关系
有两个元素X、Y,如果修改元素X的定义可能会引起对另一个元素Y的定义的修改,则称元素Y依赖(Dependency)于元素X。在类中,依赖由各种原因引起,如:一个类向另一个类发消息;一个类是另一个类的数据成员;一个类是另一个类的某个操作参数。如果一个类的界面改变,它发出的任何消息可能不再合法。

(6) 类图的抽象层次和细化(Refinement)关系
需要注意的是,虽然在软件开发的不同阶段都使用类图,但这些类图表示了不同层次的抽象。在需求分析阶段,类图是研究领域的概念;在设计阶段,类图描述类与类之间的接口;而在实现阶段,类图描述软件系统中类的实现。按照Steve Cook和John Dianiels的观点,类图分为三个层次。需要说明的是,这个观点同样也适合于其他任何模型,只是在类图中显得更为突出。
概念层　概念层(Conceptual)类图描述应用领域中的概念。实现它们的类可以从这些概念中得出,但两者并没有直接的映射关系。事实上,一个概念模型应独立于实现它的软件和程序设计语言。
说明层　说明层(Specification)类图描述软件的接口部分,而不是软件的实现部分。面向对象开发方法非常重视区别接口与实现之间的差异,但在实际应用中却常常忽略这一差异。这主要是因为OO语言中类的概念将接口与实现合在了一起。大多数方法由于受到语言的影响,也仿效了这一做法。现在这种情况正在发生变化。可以用一个类型(Type )描述一个接口,这个接口可能因为实现环境、运行特性或者用户的不同而具有多种实现。
实现层　只有在实现层(Implementation)才真正有类的概念,并且揭示软件的实现部分。这可能是大多数人最常用的类图,但在很多时候,说明层的类图更易于开发者之间的相互理解和交流。

理解以上层次对于画类图和读懂类图都是至关重要的。但是由于各层次之间没有一个清晰的界限,所以大多数建模者在画图时没能对其加以区分。画图时,要从一个清晰的层次观念出发;而读图时,则要弄清它是根据哪种层次观念来绘制的。要正确地理解类图,首先应正确地理解上述三种层次。虽然将类图分成三个层次的观点并不是UML的组成部分,但是它们对于建模或者评价模型非常有用。尽管迄今为止人们似乎更强调实现层类图,但这三个层次都可应用于UML,而且实际上另外两个层次的类图更有用。

下面介绍细化概念。细化是UML中的术语,表示对事物更详细一层的描述。两个元素A、B描述同一件事物,它们的区别是抽象层次不同,若元素B是在元素A的基础上的更详细的描述,则称元素B细化了元素A,或称元素A细化成元素B。细化的图形表示为由元素B指向元素A的、一头为空心三角的虚线(千万不要把方向颠倒了!)。细化主要用于模型之间的合作,表示开发各阶段不同层次抽象模型的相关性,常用于跟踪模型的演变。

(7) 约束
在UML中,可以用约束(Constraint)表示规则。约束是放在括号”{}”中的一个表达式,表示一个永真的逻辑陈述。在程序设计语言中,约束可以由断言(Assertion)来实现。

(8) 对象图、对象和链
UML中对象图与类图具有相同的表示形式。对象图可以看作是类图的一个实例。对象是类的实例;对象之间的链(Link)是类之间的关联的实例。对象与类的图形表示相似,均为划分成两个格子的长方形(下面的格子可省略)。上面的格子是对象名,对象名下有下划线;下面的格子记录属性值。链的图形表示与关联相似。对象图常用于表示复杂的类图的一个实例。

(9) 包
一个最古老的软件方法问题是:怎样将大系统拆分成小系统。解决这个问题的一个思路是将许多类集合成一个更高层次的单位,形成一个高内聚、低耦合的类的集合。这个思路被松散地应用到许多对象技术中。UML中这种分组机制叫包(Package)(见图5)。

不仅是类,任何模型元素都运用包的机制。如果没有任何启发性原则来指导类的分组,分组方法就是任意的。在UML中,最有用的和强调最多的启发性原则就是依赖。包图主要显示类的包以及这些包之间的依赖关系。有时还显示包和包之间的继承关系和组成关系。
包的内容　在图5中,”系统内部”包由”保险单”包和”客户”包组成。这里称”保险单”包和”客户”包为”系统内部”包的内容。当不需要显示包的内容时,包的名字放入主方框内,否则包的名字放入左上角的小方框中,而将内容放入主方框内。包的内容可以是类的列表,也可以是另一个包图,还可以是一个类图。
包的依赖和继承　图5中”保险单填写界面”包依赖于”保险单”包;整个”系统内部”包依赖于”数据库界面”包。可以使用继承中通用和特例的概念来说明通用包和专用包之间的关系。例如,专用包必须符合通用包的界面,与类继承关系类似。通过”数据库界面”包,”系统内部”包既能够使用Oracle的界面也可使用Sybase的界面。通用包可标记为{abs tract},表示该包只是定义了一个界面,具体实现则由专用包来完成。

(10) 其他模型元素和表示机制
类图中用到的模型元素和表示机制较为丰富,由于篇幅的限制,这里不能一一介绍。主要还有以下模型符号和概念:类别模板(Stereotype)、界面(Interface)、参数化类(P arameterized Class)也称模板类(Template)、限定关联(Qualified Association)、多维关联(N-ary Association)、多维链(N-ary Link)、派生(Derived)、类型(Type)和注释(Note)等。

(11) 使用类图的几个建议
类图几乎是所有OO方法的支柱。采用标准建模语言UML进行建模时,必须对UML类图引入的各种要素有清晰的理解。以下对使用类图进行建模提出几点建议:
*不要试图使用所有的符号。从简单的开始,例如,类、关联、属性和继承等概念。在UML中,有些符号仅用于特殊的场合和方法中,只有当需要时才去使用。
*根据项目开发的不同阶段,用正确的观点来画类图。如果处于分析阶段,应画概念层类图;当开始着手软件设计时,应画说明层类图;当考察某个特定的实现技术时,则应画实现层类图。
*不要为每个事物都画一个模型,应该把精力放在关键的领域。最好只画几张较为关键的图,经常使用并不断更新修改。使用类图的最大危险是过早地陷入实现细节。为了避免这一危险,应该将重点放在概念层和说明层。如果已经遇到了一些麻烦,可以从以下几个方面来反思你的模型。
*模型是否真实地反映了研究领域的实际。
*模型和模型中的元素是否有清楚的目的和职责(在面向对象方法中,系统功能最终是分配到每个类的操作上实现的,这个机制叫职责分配)。
*模型和模型元素的大小是否适中。过于复杂的模型和模型元素是很难生存的,应将其分解成几个相互合作的部分。

3. 构件图和配置图
构件图(Component diagram)和配置图(Deployment diagram)显示系统实现时的一些特性,包括源代码的静态结构和运行时刻的实现结构。构件图显示代码本身的结构,配置图显示系统运行时刻的结构。

(1) 构件图构件图显示软件构件之间的依赖关系。一般来说,软件构件就是一个实际文件,可以是源代码文件、二进制代码文件和可执行文件等。可以用来显示编译、链接或执行时构件之间的依赖关系。
(2) 配置图配置图描述系统硬件的物理拓扑结构以及在此结构上执行的软件。配置图可以显示计算结点的拓扑结构和通信路径、结点上运行的软件构件、软件构件包含的逻辑单元(对象、类)等。配置图常常用于帮助理解分布式系统。
(3) 结点和连接　结点(Node)代表一个物理设备以及其上运行的软件系统,如一台Unix主机、一个PC终端、一台打印机、一个传感器等。如图1所示,”客户端PC”和”保险后台服务器”就是两个结点。结点表示为一个立方体,结点名放在左上角。
结点之间的连线表示系统之间进行交互的通信路径,在UML中被称为连接(Connectio n)。通信类型则放在连接旁边的”《》”之间,表示所用的通信协议或网络类型。
(4) 构件和界面　在配置图中,构件代表可执行的物理代码模块,如一个可执行程序。逻辑上它可以与类图中的包或类对应。因此,配置图中显示运行时各个包或类在结点中的分布情况。如在图1中,”保险后台服务器” 结点中包含”保险系统”、”保险对象数据库”和”保险系统配置”3个构件。在面向对象方法中,类和构件等元素并不是所有的属性和操作都对外可见。它们对外提供了可见操作和属性,称之为类和构件的界面。界面可以表示为一头是小园圈的直线。图1中,”保险系统”构件提供了一个”配置”界面。配置图中还显示了构件之间的依赖关系,”保险系统配置”构件依赖于这个”配置”界面。
(5) 对象(Object)　一个面向对象软件系统中可以运行很多对象。由于构件可以看作与包或类对应的物理代码模块,因此,构件中应包含一些运行的对象。配置图中的对象与对象图中的对象表示法一样。图1中,”保险系统配置”构件包含”配置保险政策”和”配置用户”两个对象。

标准建模语言UML的静态建模机制是采用UML进行建模的基础。我们认为,熟练掌握基本概念、区分不同抽象层次以及在实践中灵活运用,是三条最值得注意的基本原则。

UML是标准建模语言，它的定义包括两大类：UML语义、UML表示法。
(1) UML语义　描述基于UML的精确元模型定义。元模型为UML的所有元素在语法和语义上提供了简单、一致、通用的定义性说明,使开发者能在语义上取得一致,消除了因人而异的最佳表达方法所造成的影响。此外UML还支持对元模型的扩展定义。
(2) UML表示法　定义UML符号的表示法,为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。这些图形符号和文字所表达的是应用级的模型,在语义上它是UML元模型的实例。

表达的是应用级的模型,在语义上它是UML元模型的实例。
标准建模语言UML的重要内容可以由下列五类图(共9种图形)来定义:
·第一类是用例图,从用户角度描述系统功能,并指出各功能的操作者。
·第二类是静态图(Static diagram),包括类图、对象图和包图。其中类图描述系统中类的静态结构。不仅定义系统中的类,表示类之间的联系如关联、依赖、聚合等,也包括类的内部结构(类的属性和操作)。类图描述的是一种静态关系,在系统的整个生命周期都是有效的。对象图是类图的实例,几乎使用与类图完全相同的标识。他们的不同点在于对象图显示类的多个对象实例,而不是实际的类。一个对象图是类图的一个实例。由于对象存在生命周期,因此对象图只能在系统某一时间段存在。包由包或类组成,表示包与包之间的关系。包图用于描述系统的分层结构。
·第三类是行为图(Behavior diagram),描述系统的动态模型和组成对象间的交互关系。其中状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。通常,状态图是对类图的补充。在实用上并不需要为所有的类画状态图,仅为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图。而活动图描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并行活动。
·第四类是交互图(Interactive diagram),描述对象间的交互关系。其中顺序图显示对象之间的动态合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互;合作图描述对象间的协作关系,合作图跟顺序图相似,显示对象间的动态合作关系。除显示信息交换外,合作图还显示对象以及它们之间的关系。如果强调时间和顺序,则使用顺序图;如果强调上下级关系,则选择合作图。这两种图合称为交互图。
·第五类是实现图( Implementation diagram )。其中构件图描述代码部件的物理结构及各部件之间的依赖关系。一个部件可能是一个资源代码部件、一个二进制部件或一个可执行部件。它包含逻辑类或实现类的有关信息。部件图有助于分析和理解部件之间的相互影响程度。
配置图定义系统中软硬件的物理体系结构。它可以显示实际的计算机和设备(用节点表示)以及它们之间的连接关系,也可显示连接的类型及部件之间的依赖性。在节点内部,放置可执行部件和对象以显示节点跟可执行软件单元的对应关系。

从应用的角度看,当采用面向对象技术设计系统时,首先是描述需求;其次根据需求建立系统的静态模型,以构造系统的结构;第三步是描述系统的行为。其中在第一步与第二步中所建立的模型都是静态的,包括用例图、类图(包含包)、对象图、组件图和配置图等五个图形,是标准建模语言UML的静态建模机制。其中第三步中所建立的模型或者可以执行,或者表示执行时的时序状态或交互关系。它包括状态图、活动图、顺序图和合作图等四个图形,是标准建模语言UML的动态建模机制。因此,标准建模语言UML的主要内容也可以归纳为静态建模机制和动态建模机制两大类。