基于RUP软件开发规范.doc

基于rup软件开发规范部门批准人批准日期公司批准人批准日期目录1概述62角色与活动62.1项目经理62.2构架设计师72.3系统分析员72.4用户界面设计员82.5数据库设计员82.6系统设计员82.7实施员92.8测试员92.9部署经理93 需求调研分析规范103.1需求调研规范103.1.1需求调研人员103.1.2需求调研方法103.1.3需求调研工件113.2需求分析规范113.2.1 业务建模规范113.2.1.1业务建模目的113.2.1.2业务建模活动概述113.2.1.3 业务建模工件173.2.2 需求分析规范173.2.2.1 需求分析目的173.2.2.2 需求分析活动概述17目的：17步骤：17目的：18步骤：18目的：19步骤：20目的：22步骤：223.2.2.3 需求分析工件244分析设计规范244.1分析设计目的244.2分析设计活动概述254.2.1构架分析25目的：25步骤：254.2.2确定设计机制27目的：27步骤：274.2.3确定设计元素28目的：28步骤：284.2.4合并现有设计元素30目的：30步骤：304.2.5说明运行时构架31目的：31步骤：324.2.6说明分布33目的：33步骤：334.2.7用例分析34目的：34步骤：344.2.8用例设计36目的：36步骤：364.2.9子系统设计38目的：38步骤：384.2.10类设计39目的：39步骤：394.2.11数据库设计42目的：42步骤：424.3分析设计工件445实施规范445.1实施目的445.2实施活动概述445.2.1建立实施模型44目的：44步骤：445.2.3实施构件46目的：46步骤：465.2.4修复缺陷47目的：47步骤：475.2.5执行单元测试48目的：48步骤：485.2.6集成子系统48目的：48步骤：485.2.7集成系统49目的：49步骤：495.3实施工件496测试规范506.1测试目的506.2测试活动概述506.2.1制定测试计划50目的：50步骤：506.2.2设计测试51目的：51步骤：516.2.3设计测试包和测试类52目的：52步骤：526.2.4实施测试52目的：52步骤：536.2.5执行测试53目的：53步骤：536.3测试工件547部署规范547.1部署目的547.2部署活动概述547.2.1制定部署计划54目的：54步骤：557.2.2管理验收测试56目的：56步骤：567.2.3检验已生产的产品56目的：56步骤：567.2.4编写发布说明57目的：57步骤：577.2.5开发安装工件57目的：57步骤：577.2.6编写培训材料58目的：58步骤：587.3部署工件588配置与变更管理588.1配置与变更管理目的588.2配置与变更管理活动概述598.2.1编写cm计划59目的：59步骤：598.2.2创建部署单元59目的：59步骤：598.2.3报告配置状态60目的：60步骤：608.2.4执行配置审核60目的：60步骤：608.2.5建立变更控制流程60目的：60步骤：608.3配置与变更管理工件61附件62调研记录表62用户视图清单631概述该软件规范基于rup 2000制定的。制定过程中考虑了xx事业部目前设计水平和能力，其中抽取了rup中较为核心的活动，并结合了公司和部门以前的设计与开发经验。该规范是作为xx事业部软件开发工作中必须依据的文件，详细的设计流程、活动和工件描述，参见rup2000文件。2角色与活动2.1项目经理l 定义：项目经理负责分配资源，确定优先级，协调与客户和用户之间的沟通。总而言之，就是尽量使项目团队一直集中于正确的目标。项目经理还要建立一套工作方法，以确保项目工件的完整性和质量。l 活动：序号活动名称1.确定监测与控制流程2.计划阶段和迭代3.制定评测计划4.定义项目组织和人员配备5.制定软件开发计划6.制定产品验收计划7.制定风险管理计划8.制定问题解决计划9.制定迭代计划10.人员配备11.启动迭代12.评估迭代13.为阶段收尾做准备14.为项目收尾做准备15.监测项目状态16.安排和分配工作17.报告状态18.处理异常事件和问题19.制定qa计划2.2构架设计师l 定义：构架设计师负责在整个项目中对技术活动和工件进行领导和协调。构架设计师要确立每个构架视图的整体结构：视图的详细组织结构、元素的分组以及这些主要分组之间的接口。因此，与其他角色相比，构架设计师的见解重在广度，而不是深度。l 活动：序号活动名称1.确定用例的优先级2.构架分析3.确定设计机制4.确定设计元素5.合并现有设计元素6.说明分布7.说明运行时构架8.建立实施模型9.制定设计指南10.制定编程指南2.3系统分析员l 定义：系统分析员通过概括系统的功能和界定系统来领导和协调需求获取及用例建模。例如，确定存在哪些主角和用例，以及他们之间如何交互。l 活动：序号活动名称1.制定需求管理计划2.制定用例建模指南3.获取常用词汇4.获取涉众请求5.确定前景6.查找主角和用例7.建立用例模型结构8.管理依赖关系2.4用户界面设计员l 定义：用户界面设计员通过以下方法领导和协调用户界面的原型设计和正式设计： 1、 分析对用户界面的需求，包括可用性需求； 2、 构建用户界面原型； 3、 邀请用户界面的其他涉众（如最终用户）参与可用性复审和使用测试会议； 4、 对用户界面的最终实施方案（由设计员和实施员等其他开发人员创建）进行复审并提供相应的反馈。l 活动：序号活动名称1.用户界面建模2.设计用户界面原型3.制定用户界面指南2.5数据库设计员l 定义：数据库设计员定义表、索引、视图、约束条件、触发器、存储过程、表空间或存储参数，以及其他在存储、检索和删除永久性对象时所需的数据库专用结构。l 活动：序号活动名称1.数据库设计2.6系统设计员l 定义：系统设计员定义一个或几个类的职责、操作、属性及关系，并确定应如何根据实施环境对它们加以调整。此外，设计员可能要负责一个或多个设计包或设计子系统，其中包括设计包或子系统所拥有的所有类。l 活动：序号活动名称1.类的设计2.子系统设计3.用例分析4.用例设计5.设计测试包和测试类2.7实施员l 定义：实施员负责按照项目所采用的标准来进行构件开发与测试，以便将构件集成到更大的子系统中。如果必须创建驱动程序或桩模块等测试构件来支持测试，那么实施员还要负责开发和测试这些测试构件及相应的子系统。l 活动：序号活动名称1.实施构件2.修复缺陷3.执行单元测试4.实施测试构件和子系统5.开发安装工件2.8测试员l 定义：测试员负责对测试进行计划、设计、实施和评估，包括：生成测试计划和测试模型；执行测试过程；评估测试范围和测试结果，以及测试的有效性；生成测试评估摘要l 活动：序号活动名称1.制定测试计划2.设计测试3.实施测试4.评估测试5.制定测试指南2.9部署经理l 定义：部署经理负责制定向用户群体发布产品的计划，并将其纳入布署计划中。l 活动：序号活动名称1.制定部署计划2.定义材料清单3.管理验收测试4.管理beta测试5.编写发布说明6.提供下载站点7.发布以进行生产8.检验已生产的产品3 需求调研分析规范3.1需求调研规范3.1.1需求调研人员参加需求调研的人员，一般由开发方需求调研人员和相关配合人员组成。需求调研人员：应该善于简化工作，并且具有良好的沟通技巧。担任该角色的人应该具有相关业务领域的知识并具有丰富开发经验。相关配合人员：是被开发方配合开发的人员，具有一定的计算机应用水平，并且能够熟悉相关的一些具体业务。3.1.2需求调研方法需求调研一般采用座谈方式，参加人员是需求调研人员、相关配合人员和业务部门领导或业务代表。步骤一、了解用户需求，主要从以下几方面1、 了解业务部门的组织机构和岗位分布情况2、 了解业务部门主要业务内容3、 了解业务部门的主要业务流程和业务特点4、 了解业务部门和其他业务部门相关联业务5、 了解业务部门现有机器、网络和软件应用现状6、 了解业务部门对新系统的要求和期望步骤二、收集用户视图1、 收集业务部门内部使用的台帐、单据和报表2、 收集流向该业务部门的单据、报表3、 收集流向其他业务部门的单据、报表步骤三、需求调研确认1、 需求调研人员填写用例模型确认子表2、 由相关业务部门进行用例模型确认3.1.3需求调研工件需求调研阶段产生的工件如下：1、 调研记录表2、 用户视图清单3.2需求分析规范需求分析方法主要采用面向对象的方法，在具体实施时采用rup（rational unified process）方法。在rup中需求分析具体包括两部分，一是业务建模，另一是需求分析。3.2.1 业务建模规范3.2.1.1业务建模目的业务建模的目的在于： l 了解目标组织（将要在其中部署系统的组织）的结构及机制。 l 了解目标组织中当前存在的问题并确定改进的可能性。 l 确保客户、最终用户和开发人员就目标组织达成共识。 l 导出支持目标组织所需的系统需求3.2.1.2业务建模活动概述3.2.1.2.1评估目标组织目的：l 从当前流程、工具、人员能力、人们的态度、客户、竞争对手、技术趋势、问题以及有待改进之处等方面入手，来描述要部署应用程序的组织的当前状态。 l 确立必须对目标组织进行设计的动机。 l 确定业务建模工作的涉众。步骤：l 启动评估 建议在研讨班中启动评估，以便在研讨班中召集关键人员（启动时已知的关键人员）。这一启动研讨班主要用于业务分析员召集业务建模工作的涉众，收集来自项目涉众的问题，以便创建一个全面的列表。l 确定涉众 确定业务建模工作的涉众。确定目标组织以外的涉众，例如：顾客、竞争对手和其他涉众等l 说明目标组织的结构 简要说明组织结构及其当前的角色和团队。此外，还要考虑目标组织中不同部分之间的关系。例如，销售和维护之间的关系，以及产品开发和销售之间的关系l 确定关键人员 确定目标组织中的所有关键人员。 l 评估经营理念和经营策略 大多数组织都详尽地记录了其经营理念和策略。如果已经记录了“虚拟”组织（即进行业务建模是为了理解目标客户的业务流程，以便生产更好的产品），则可以不执行此步骤。l 基准 确定下列内容：参照的基准是谁；用于基准比较的指标；如何执行基准比较l 评测目标组织 评测组织是指理解组织的业务流程，并对其加以评测l 确定变更的起因 询问涉众希望变更业务流程和业务工具的原因。l 评估应变能力 分析目标组织的应变能力。组织就象个人一样，只能适应一定范围之内的变化。某些组织对变更的准备可能会比其他组织更加充分。要了解组织的应变能力，我们建议您同组织中的人员进行访谈，了解他们对变更的态度和意愿。l 确定问题 确定问题的最佳途径是召集关键人员通过开会来发现问题。l 作出结论 分析收集到的信息，编辑应该关注的方面和问题的列表。 l 提出建议 您需要将有关未来的建议作为评估的一部分。这些建议应该说明进行业务建模所采用的方法。3.2.1.2.2设定和调整目标目的：l 确定业务建模工作的范围。 l 确定未来目标组织的前景。 l 就目标组织可能要做的改进和新的目标达成一致。 l 说明目标组织的首要目标。步骤：l 确定目标组织的范围 讨论应在建模工作中选择包括的内容范围，从而确定目标组织的构成。通过使用业务主角和业务用例符号能够有效（但并不必然）地完成该讨论工作。l 确定涉众 在目标组织评估中，您应该已经确定了业务的涉众。在业务前景中，您需要指明这些涉众中的哪些在目前项目的范围内仍被认为是涉众。l 就目标组织的目标达成一致 标组织的目的表示了利用业务建模工作要实现的目标。l 确定对工作施加的约束 需要考虑多种多样的约束来源。l 明确阐述问题说明 在目标组织评估中，您可能确定在目标组织中已经存在一系列问题，这些问题是您和涉众共同确定的。在业务前景文档中，您需要将列表中的问题限制在业务建模工作范围之内准备集中解决的问题。l 确定哪些区域需要划分优先级 需要就业务建模工作应该区分目标组织中哪些区域的优先级问题加以讨论并达成一致。3.2.1.2.3制定业务规则目的：l 确定要在项目中考虑哪些业务规则。 l 对业务规则做出详细的定义。 步骤：l 收集规则源 确定您有哪些规则源。有些业务规则来自法律和法规，而其他业务规则可能是公司标准。还有一些业务规则表达了业务建模工作要实现的目标。l 表述规则 用严格和正式的语言来表述业务规则，同时要考虑规则阅读者的具体情况，以确保他们能够有效地理解这些规则。有关业务规则的类别和风格的详细信息。3.2.1.2.4获取常用业务词汇目的：l 定义可用于业务的所有文本说明，尤其是可用于业务用例说明的常用词汇。 步骤：l 查找常用术语 在业务建模中，必须使用问题领域中最常用的术语和表达方法来定义常用词汇。此后您还应该在业务的所有文本说明中始终如一地使用常用词汇。这样可以保持文本说明的一致性，从而避免项目成员对术语的使用及其含义产生误解。您应该将词汇记录在一个词汇表中。3.2.1.2.5查找业务主角和业务用例目的：l 概述业务中的各个流程。 l 为待建模的业务定义边界。 l 定义将与业务交互的对象（人或事物）。 l 制作业务用例模型图。 步骤：l 查找业务主角 业务主角备选者可以是与业务进行交互的任何个人、小组、组织、公司或计算机。l 查找业务用例 为了找到主要的业务用例，请考虑各业务主角可以从业务中获取的价值。请从主要且最重要的业务主角（即客户）开始l 确定业务用例的优先级 业务主角与业务用例一旦确定，就必须确定业务用例的优先级，看哪些业务用例值得进行详细说明。l 编写业务用例工作流程的概述 为了解业务用例的目的，您通常都需要使用工作流程的概述。这种概述可采用分步说明的形式。当相关人员（即使是同一个人）在以后具体说明业务用例时，将会需要使用该分步说明。l 描述业务主角与用例交互的方式 要确定哪些业务主角与业务用例进行交互，可通过定义它们之间的通信关联关系来进行。如果必须要表示通信的发起方，则应向该关联关系中添加导向性。l 将业务用例与主角打包 如果您拥有很多业务用例，就可以将它们划分成用例包，使文档更易于理解。l 在用例图中表示业务用例模型 用例图用于综合说明业务主角、业务用例以及它们之间的关系。 3.2.1.2.6建立业务用例模型目的：l 从需要作为抽象业务用例考虑的业务用例中提取行为。这类行为的示例包括公用行为、可选行为以及将在以后的迭代过程中开发的行为。 l 查找新的抽象业务主角, 它们定义了与其他几个业务主角共享的角色。 步骤：l 建立业务用例间的包含关系 如果发现工作流程中有很大部分能够析出某种包含关系，达到简化原有业务用例的目的，那么这些部分就可以组成一个新的业务用例，包含在原有业务用例中。例： 个人登记 (individual check-in) 和团体登记 (group check-in) 两个业务用例都包含行李处理 (baggage-handling) 业务用例。 l 建立业务用例间的扩展关系 如果发现工作流程的主要部分能够组成正常工作流程的一个选项，则可将该部分析出形成一个新的业务用例，将它作为原有业务用例的扩展。例： 利用扩展关系将“特殊行李处理”用例的工作流程插入到“个人登记”用例中。l 建立业务用例间的泛化关系 如果您发现工作流程具有结构、目的和行为，您可通过用例泛化关系将它显示在业务用例模型中。例：具体参见用例模型中的泛化关系l 建立业务主角间的泛化关系 如果两个业务主角以完全相同的方式与同一个业务用例相互作用，则它们对于该业务用例所扮演的角色是完全一样的。为了区分这种情况，您可以为它们之间的共同角色创建一个新的业务主角。原有的业务主角继承这个新的业务主角。例：差旅人员 (business traveler) 和普通旅行者 (tourist) 这两个主角继承了乘客的所有属性。所以，这两个主角都能担任乘客 (passenger) 这一角色。3.2.1.3 业务建模工件业务建模阶段产生的工件如下：1、 业务词汇表2、 业务规则3、 业务用例模型3.2.2 需求分析规范3.2.2.1 需求分析目的l 与客户和其他涉众在系统的工作内容方面达成并保持一致。l 使系统开发人员能够更清楚地了解系统需求。 l 定义系统边界（限定）。 l 为计划迭代的技术内容提供基础。 l 为估算开发系统所需成本和时间提供基础。 l 定义系统的用户界面，重点是用户的需要和目标。 3.2.2.2 需求分析活动概述3.2.2.2.1获取常用词汇目的：l 定义可用于系统的所有文本说明，尤其是可用于用例说明的常用词汇。步骤：l 查找常用术语 在需求工作流程中，必须使用问题领域中最普通的术语来定义常用词汇。此后您还应该在系统的所有文本说明中始终如一地使用常用词汇，尤其是在用例说明中。这样可以保持文本说明的一致性，从而避免项目成员对术语的使用及其含义产生误解。您应该将词汇记录在一个词汇表中。要发现问题领域中的常用术语，不仅可以考虑在需求中使用的术语，还可以考虑开发团队对于要构建的系统的常识中涉及的术语。侧重描述下列概念的术语： a: 代表那些在组织的日常工作中或系统预期的操作环境中所用概念的业务对象的概念。在多数情况下，已经存在类似的概念列表。 b: 系统需要涉及的存在于真实生活中的对象。这些对象是自然存在的，例如：汽车、宠物狗、瓶子、飞机、乘客、保护区或票据。 3.2.2.2.2查找主角和用例目的：l 概述系统的功能。 l 定义在系统内处理的内容和在系统外处理的内容。 l 定义与系统进行交互的对象（人或事物）。 l 将模型分为主角包和用例包。 l 制作用例模型图。 步骤：l 查找主角 定义系统用途的最初步骤包括查找主角。系统必须与之交互的每种外部现象都由一个主角来代表。为了查找主角，需考虑以下问题： a：哪些用户组需要该系统来帮助他们执行任务？ b：需要哪些用户组来执行该系统最明显的主要功能？ c：需要哪些用户组来执行该系统的辅助功能（如系统维护与系统管理）？ d：该系统是否将会与外部的硬件或软件系统进行交互？ 主角的名称应明确表示主角的角色。确保在以后不会对主角的名称产生混淆。撰写包括主角的职责范围及主角对系统的要求在内的简要说明，以提供各个主角的定义。由于主角代表的是系统外的事物，所以无需对其作详细说明。l 查找用例 当完成了对主角的初步概述之后，下一步就是查找系统的用例。第一批用例都是非常初步的用例，您必定会对其进行几次修改，直至他们稳定为止。如果系统的版本或需求不完善，或者系统分析含混不清，那么系统的功能也将会含混不清。因此，您必须不断地问自己，是否找到了恰当的用例。此外，在得到最终的版本之前，您还应准备添加、删除、组合和分割用例。详细说明用例之后，就可以更好地理解用例。查找用例的最佳方法是考虑各个主角对系统的需求。不要忘记，系统仅为其用户而存在，所以系统应以用户的需要为基础。通过对系统提出的功能性需求，您可以考虑到主角的更多需要。对于各个（人或非人）主角，需考虑以下问题： a：此主角希望系统执行的主要任务是什么？ b：此主角是否将在系统中创建、存储、更改、删除或读取数据？ c：此主角是否需要将突发变更或外部变更通知给系统？ d：是否需要将系统中发生的某些特定事件通知给此主角？ e：此主角是否将执行系统启动或关闭操作？ l 描述主角与用例交互的方式 由于表示主角与用例之间的关系十分重要，所以每当找到一个用例，就应确定哪些主角将与之进行交互。为此，必须定义一个通信关联关系，其导航方向应该与主角和用例之间的信号传输方向相同。通信关联关系示例： 用例和主角之间的一条线或一个箭头表示它们通过相互发送信号进行交互。l 将用例和主角打包 如果主角或用例的数目过多，就应该将它们分成用例包，以简化用例模型的维护。这也使用例模型更易于掌握。另外，通过让开发人员负责用例包或主角包，可简化用例模型中职责的分配。l 在用例图中表示用例模型 在用例模型图中，您可以详细说明用例与主角的关系以及相关用例之间的关系。这些图中可能包括： a：属于同一个用例包的主角。 b：主角及与之交互的所有用例。 c：处理相同信息的用例。 d：同一组主角所使用的用例。 e：通常按一种顺序执行的用例。 f：属于同一个用例包的用例。 g：最重要的用例。这种用例图可作为模型的概要，并可能会包括在用例视图中。 h：一同开发的用例（在相同的递增阶段中）。 每个图都应该由用例模型中的相应包所拥有。用例图示例： 3.2.2.2.3建立用例模型目的：l 有些业务用例需要作为抽象业务用例考虑，并从中提取行为。这类行为的示例包括公用行为、可选行为、异常行为以及将在以后的迭代过程中开发的行为。 l 查找新的抽象主角, 它们定义了与其他几个主角共享的角色。 步骤：l 建立用例间的包含关系 如果用例包括一个行为段，该段对于此用例其他部分的重要性完全在于它产生的结果，而不在于得到结果的方法，则可以将此行为分离出来作为新的包含用例。而初始的用例则成为与此包含用例有包含关系的基本用例。 两个用例间的包含关系是指用例实例为保持其完整性，不仅要符合基本用例的说明，同时还应当遵循包含用例的说明。包含关系可以通过以下方式帮助阐明用例： a：隔离和封装复杂的细节，使之不会模糊用例的实际含义。 b：包含涉及到几个基本用例的行为，提高用例的一致性。 通常，有不止一个用例必须包含某个包含用例，这样维护一个额外用例和包含关系才有价值。包含关系示例： 用例 place call 和 start system 都包含有抽象用例 manage virtual circuit 的行为。l 建立用例间的扩展关系如果用例包括几个行为段，这些段具有可选特性或者异常特性，并且它们不会增加对用例主要目的理解程度，则可以将这些行为分离出来作为新的扩展用例。而原始的用例则成为基本用例，扩展用例与之就形成了扩展关系。 在基本用例中您需要声明扩展点，这些扩展点定义在基本用例中可能进行扩展的位置。 对于复杂分支流和可选行为，最好将它们划分出来，形成扩展用例。通常此行为相当复杂，并且难以描述：将其包含在事件流中将更加难以看到“正常”行为。提取该行为将有助于提高对用例模型的理解。 只有扩展用例知道它和基本用例之间的关系。基本用例只知道它具有扩展点，而并不清楚什么样的扩展用例在使用这些扩展点。扩展用例示例： 用例“召开电话会议”和“显示呼叫方身份”是基本用例“打电话”的两个扩展用例。l 建立用例间的泛化关系如果两个或以上的用例在结构和行为上有相似之处，您可以将这些共同行为分离出来创建新的父用例。而初始的用例则成为与此父用例有泛化关系的子用例。子用例继承父用例中描述的所有行为。两个用例间的泛化关系指的是遵守子用例说明的用例实例还应当遵守父用例说明，这样才认为它是完整的。一般而言，应当至少有两个子用例继承同一个父用例，这样维护父用例以及其与子用例之间的泛化关系才有意义。有一种例外情况，即有两个用例，其中一个用例是另一个用例的特例，但它们都需要具有独立的可实例化性质。泛化关系示例 “拨打本地电话”用例和“拨打长途电话”用例都继承了“拨打电话”抽象用例的公有行为。l 建立主角间的泛化关系 主角具有某些共同的特征，您可以使用主角泛化关系来建立这些特性的模型。这部分工作最好在您完成了用例模型的首次尝试后进行。 编写主角间泛化关系的简短说明，并用例图对它们作进一步的解释。主角间泛化关系示例： 出纳员 (teller) 和会计员 (accountant) 这两个主角继承了余额监管员 (balance supervisor) 的所有特征。所以，这两个主角都能担任余额监管员的角色。3.2.2.2.4设计用户界面原型目的：l 创建用户界面原型。步骤：l 设计用户界面原型 下面列出了设计用户界面原型的工作的不同方面： a：确定主窗口每一个边界类聚合关系都可以产生备选的用户界面主窗口。然而，请回忆一下，构建对象模型的目标之一是确定层次尽可能少的聚合关系分层结构；其根本目的是最大限度减少主窗口的数目，因而也最大限度减少它们之间的导航路径。导航路径太长不仅增加不必要的交互开销，而且使得用户更容易在系统中“迷路”。理想状况是，所有窗口都应当从一个主要主窗口打开，这样窗口导航长度最大为 2。设法避免窗口导航长度大于 3。主要主窗口应当是用户启动应用程序时打开的窗口。正常情况下，只要应用程序在运行时，它就始终处于打开状态，而且它还是让用户花费大量“使用时间”的地方。由于它始终处于打开状态，并且构成用户与系统的第一接触，因而它是加强用户系统思维模型的最重要载体。b：设计可视化主窗口主窗口可视化，尤其是主要主窗口的可视化，对系统的可用性有非常重要的影响。显示窗口的设计在一定程度上意味着您必须考虑所包含对象的哪些部分（属性）应当显示；使用事件流（示意板说明）无疑将有助于确定显示属性的优先顺序，尤其是在使用所需指导说明对其进行扩展时更有帮助。如果用户需要查看对象许多不同的属性，您可以实现在一个主窗口中包含几个视图，每一个视图显示一组不同的属性。设计此可视化窗口也意味着您必须考虑应当如何使用所有的可视化元素实现所包含对象的组成部分（属性）可视化。如果一个主窗口包含几个不同类的对象，则找到这些类的“公有基”很重要，比如在所有或大部分类中都包含的属性类型。通过某种维度显示公有基，这样用户就能把不同类的对象互相联系起来，并可以查看主窗口的样式。这大大地增加了用户界面的“带宽”。 c：设计主窗口操作边界类的职责指定了它们对应的窗口所需的操作。主窗口和所包含对象的操作也常作为快捷菜单和工具栏中的替代选项和补充选项显示出来。如果某个主窗口包含几个类的对象，并且它们具有不同的操作，您可以给每一个类，或者给每一组紧凑的操作分配一个菜单。d：设计特征窗口需要为所有边界类的设计特征窗口，这样用户就可以得到这些类的所有属性。注意，某些对象在主窗口中可能只是部分显示出来（请参见上面的“设计可视化主窗口”一节）；另一方面，它们的特征窗口将显示它们所有的属性。注意，所有属性平均值都是此步骤的重要输入，因为它们可以帮助确定某个特定属性的最佳可视化方式。e：设计涉及多个对象的操作如果某个边界类定义了许多将在用户界面中显示的对象，则设计包含这些对象的操作通常会比较棘手。以下是这类操作的不同变形：1、提供在多个对象中进行搜索的机制的操作，2、提供对多个对象进行排序的机制的操作。3、提供多个对象间用户控制继承的机制的操作，4、提供对浏览多个对象的分层结构进行管理的机制的操作，5、提供选择多个对象的机制的操作。f：设计其他功能给用户界面添加需要的动态行为。大多数动态行为由目标平台产生，如选择操作范式、双击打开、右击鼠标弹出菜单等。l 实施用户界面原型 实施用户界面原型有三种基本方法： 1、制图：使用铅笔和纸绘制。 2、位图：在位图编辑器中绘制。 3、可执行文件：可以“运行”并能和最终用户交互的模拟应用程序。 l 获得有关用户界面原型的反馈 将用户界面原型展示给其他人是极其重要。但是，为获得有价值的反馈，您不必非得进行完全的使用测试，即实际用户使用原型执行实际任务。在使用测试中发现的大多是一些“视而不见”的缺陷。这些缺陷是任何未参与用户界面设计的人本来可以提醒您注意的问题。随着原型设计和实施的不断深入，需要将设计展示给越来越多的复审员，其中包括： 1、其他项目成员 2、外部可用性专家 3、用户3.2.2.3 需求分析工件需求分析阶段产生的工件如下：1、 词汇表2、 用例模型3、 用例规约4、 用户界5面原型4分析设计规范4.1分析设计目的分析设计的目的在于： 1、 将需求转换为未来系统的设计。2、 逐步开发强壮的系统构架。3、 使设计适合于实施环境，为提高性能而进行设计。4.2分析设计活动概述4.2.1构架分析目的：l 根据从相似系统或相似问题领域中获取的经验，定义备选构架。 l 定义系统构架模式、核心机制和建模约定。 l 定义有关复用的策略。 l 为计划流程提供输入。 步骤：l 编写构架概述构架概述是在项目生命周期的初期、甚至是在项目的提议阶段编写的。它反映有关实施前景的初期决策和可行的假设，以及与系统的物理构架、逻辑构架以及非功能性需求有关的决策。并通常由构架设计师在项目资助人的协助之下编写。构架概述采取了使用大量图片、示意板或图标化图形的非正规形式。就概念而言，它使用图形解释有关解决方案的提案的本质特征，并阐述主要构想和涉及的主要构建模块。构架概述的正式程度视具体项目而定。例如，在非常正式的大型项目中，有必要在软件构架文档中的适当部分记录构架概述，以便用于正式复审。此时的构架概述只是暂时完成而已。只有在开发并确认高级部署模型和实施模型之后，构架概述图才可以成为作出承诺的依据。l 调查可用资产理解正在为其考虑资产配置的环境需求。理解必需的系统规模和一般功能。查阅组织的资产基础和业界文献，确定资产或相似的项目。需要考虑的资产有多种类型，例如业界模型、框架、类和经验，但是可考虑的资产并非局限于此。评估可用资产是否有助于解决当前项目所面临的关键挑战，以及是否符合项目的约束条件。分析资产和客户需求之间的一致程度。考虑现有需求中是否存在需要再作进一步探讨的地方（以便使用资产）。评估是否可以修改或扩展资产来满足需求。从采用资产的角度，评估在成本、风险和功能方面的折衷方案。在原则上决定是否使用一项或多项资产，并记录作出相应决策的理由。l 定义子系统的高层组织设计模型通常是分层组织的 - 一个用于大、中型系统的通用构架模式。层次的数量不是固定的，而是随情况的变化而变化的。在构架分析中通常侧重于两个高层层次，即应用程序层和业务专用层；即“子系统的高层组织”。其他低级层次在活动：合并现有设计元素中考虑。如果采用其他构架模式，将围绕构架模板来定义子系统。l 确定分析机制分析机制可通过两种模式确定：“自顶向下”（根据先验知识确定）和“自底向上”（随进行过程逐步确定）。在“自顶向下”模式下，构架设计师可根据其过去的经验估计出领域内会有哪些问题，以及如何解决这些问题。在分析过程中，常见的构架问题（可称之为机制）如：永久性、事务管理、故障管理、消息传递和推理机。所有这些构架问题的共同之处在于它们是大多数系统的一般性功能，分别实现与基本应用功能的交互或支持基本应用功能。分析机制提供的是如何实现系统要求的基本功能，而不必考虑部署平台或实施语言。通常，可以采用多种不同的方式设计和实现分析机制；对应于每种分析机制可以有多种设计机制，而每种设计机制可以有多种实现方法。采用“自底向上”的方法，分析机制是最后生成的：即构架设计师见到分析机制时，它们已经创建好了。也许这些机制最初比较模糊，随着各种问题的解决方案确定（如何同步不同线程中各个元素的时钟，寻找分配资源的通用方式），逐渐产生一个通用的框架。从这些方案中即生成了有助于简化语言分析的分析机制。l 确定核心的抽象概念通过采取确定系统必须处理的核心抽象概念（即在业务建模和需求活动中确定的概念）的措施来进行分析。需求和业务建模活动通常会揭示系统必须能够处理的核心概念，与此同时，这些概念也证实了其自身是核心的设计抽象概念。因为已经确认，所以没有必要在活动：用例分析中重复确认工作。为了利用现有知识，我们初步确定使用实体分析类，来代表这些以系统常识（诸如需求、词汇表、特别是领域模型或业务对象模型）为基础的核心抽象概念。定义核心抽象概念时，还要定义实体类之间存在的所有关系。在一个或多个类图中展示核心抽象概念，并为其编写简要的说明。取决于领域和系统的新颖程度，可能已有现存的分析模式，它记录了系统建模所需的众多核心抽象概念。采用这种模式（它应该已经在领域中成功应用），将会明显降低确定必须要表示的重要概念的工作量。l 创建用例实现用例是大部分初期分析设计工作的重心。为了实现从以需求为中心的活动到以设计为中心的活动的转移，工件：用例实现充当了两者之间的桥梁。它提供了一种用于将设计模型中的行为追踪到用例模型的方法，并围绕用例概念在设计模型中组织协作。为用例模型中的每个用例，在设计模型中创建用例实现。用例实现的名称应该和与其关联关系的用例名称相同，且应该在用例实现和它所关联关系的用例之间建立追踪依赖关系。l 开发高层部署模型采用以前编写的构架概述，现在就可以开发高层部署模型。部署模型的主要业务驱动因素如下：1 （多个地点），在用户简档（在前景中）、用例以及用例模型中定义2 业务数据（在业务对象模型和设计模型中）3 服务级别需求（在补充规约中）4 约束条件（在补充规约中）部署模型在满足非功能性需求和约束条件的同时，还必须能够支持依赖于需要访问数据的构建的用例。构件暂时放置在节点上。确认节点数和连接数足以支持不同节点上的构件之间、以及构件与其存储的数据之间的交互。l 复审结果在构架分析完成之后，复审已经确定的构架机制、子系统、包和类，以确保它们的完整性和一致性。由于构架分析的结果是初步的，相对非正式的，因此复审也应该是非正式的。应该采用重要用例的场景，对在不同（从业务角度到发生特定交互）的层次上所作出的构架选择进行确认。4.2.2确定设计机制目的：根据实施环境强加的约束条件，完成由分析机制到设计机制的改进步骤：l 对分析机制的使用对象进行分类 分析机制提供了概念化的服务集，这些服务由分析对象使用。分析机制为较为复杂的行为提供了一种简便形式，这些行为虽不必在分析过程中考虑，但最终总要予以处理。分析机制的主要目的是便于我们获取那些待设计的系统服务的需求，而不必担心服务提供程序自身的细节。现在，我们应开始精炼分析机制收集的信息。步骤如下：确定各分析机制的使用对象。浏览给定分析机制的所有使用对象，查看使用对象要求该分析机制应具备的特征。例如，可能很多分析对象都要利用永久性机制，但它们在这方面的要求却相去甚远：某个拥有一千个永久实例的类，其永久性需求相对于拥有四百万个永久实例的类显然是不同的。类似地，如果某个类的实例对实例数据的响应时间必须短于一毫秒，则它所需的永久性方法也必然有别于那些实例数据仅能通过特定查询与批量报告应用程序进行访问的类。确定各分析机制的特征简档。可能存在差别很大的特征简档，提供不同程度的性能、占用空间、安全性、经济成本等。由于分析机制各不相同，因此要赋予不同的特征。很多机制都要求估计要管理的实例数，还要估计实例的预期大小（以预期字节数表示）。在任何系统内传递大量数据都会极大地影响性能，而且这些问题是必须处理的。根据使用对象所用的特征简档将使用对象分组。将对某分析机制（具有相似的特征简档）有共同需要的使用对象分成一组；基于每种这样的需要确定一种设计机制。设计机制就是从这种方式的分组入手的。举例来说：分析机制“进程间通信”可映射到“对象请求代理程序”设计机制。不同的特征简档将带来不同的设计机制，但这些设计机制却可来自同一分析机制。分析过程中很简单的永久性机制会在设计过程中带来若干个永久性机制：如内存永久性、基于文件、基于数据库、分布式等机制。设计机制是根据不同的特征简档对分析机制的改进。l 为实施机制开列清单 自下而上地制定实施机制清单，这些机制可任由您处理： 中间件产品提供的机制。操作系统提供的机制。构件提供的机制。类库提供的机制。遗留代码（另请参见活动：合并现有设计元素）。专用包：gui 生成器、地理信息系统、dbms 等。l 将设计机制映射到实施机制设计机制是对实施机制的抽象表示，分析机制与实施机制之间的联系就是通过设计机制建立的。通过在设计中使用抽象的构架机制，我们可以考虑如何提供构架机制，而不致混淆面临的问题与特殊机制的细节。它还允许我们尝试用某一具体实施机制替换另一种机制，而这不会对设计产生负面影响。确定特征的范围。根据已为设计机制确定的特征来决定设计机制特征值的范围，这样对应用备选实施机制而言是合理的、经济的或可行的。考虑构件的购置成本。对于备选实施机制，除了纯粹的技术标准外，还应考虑购置或获得许可的成本、产品成熟度、与厂商的关系、支持等等。寻找合适的构件或自行构建。您会常常发现：对于某些设计机制没有显然适用的实施机制；此时则需要寻找合适的产品，或确定是否需要内部开发。您还可能发现有些实施机制自始至终都未曾使用。l 记录构架机制 在此活动中，构架设计师这一角色需要通过构建或集成机制并且核实其作用来确定并验证这些机制，经验证后，再对系统设计的其余部分贯彻执行这些机制。机制及有关机制使用的详细信息应记录在项目专用的工件：设计指南中。从分析机制到设计机制，再到实施机制的关系（或映射），以及相关的进行如此选择的理由，都应记录在软件构架文档中。4.2.3确定设计元素目的： 对分析类的交互进行分析，以确定设计模型元素。步骤：l 确定事件与信号事件是发生在系统外部但却引发系统内部操作的事情；事件的发生具有随机性，且相互之间具有潜在独立性。对事件及时响应的需要是系统中并行需求的主要驱动因素。信号与事件相似，但信号产生于内部来源；信号用于在系统中的不同并行元素之间进行异步通信。如果确定了系统必须响应的事件，并确定了用于在系统的不同并行部分之间进行通信的信号，将有助于确定系统构架的基本部分。要确定系统必须响应的事件，可借助于用例及其相关的实现。对于主角发送给系统的各个激励，考虑系统以何种方式检测到该激励：是系统对等待响应的用户进行轮询，还是由检测事件的设备或传感器来触发接收操作？信号用于在系统内的各个部分进行通信，且往往用于传达故障或异常事件，但信号也可用于任何需要异步通信的环境。信号通常用中断来实施，但也可以使用轮询技术。确定构架中的信号之所以重要，是因为这样就可制定信号使用方式与时间的通用规则，并确定哪些信号将使用哪些信令机制（如使用哪些特定的中断或轮询消息）。如果不能在这些方面达成一致，将会造成相当严重的损失，并将导致完全无法预测的系统行为。l 确定类、封装体和子系统确定类。如果一个分析类很简单，并已代表单一的逻辑抽象，就可按照一一对应的关系将其直接映射到设计类。通常，实体类会相对完整地持续到设计阶段。由于实体类往往也具有永久性，所以应确定设计类是否应具有永久性，并在类说明中作出相应的记录。确定封装体。在已确定的分析对象的环境中，考虑系统的并行需求：是否需要系统对外部生成事件作出响应？如果需要，当这些事件发生时，哪些分析类处于“活动”状态？用例模型中的外部事件由正在与用例进行交互的主角所发出的激励来表示。要了解事件发生时哪些对象在进行交互，请参见相应的用例实现。首先，将这些对象分组为若干独立的协作对象集，这种分组是对封装体的初步分组。确定子系统。如果分析类相当复杂，以致它所包括的行为无法由单个类来独自负责执行，就应将该分析类映射到设计子系统。使用设计子系统来封装这些协作，其封装方式具