软件需求工程课件2013-06-11

需求模版框架产品限制条件------适用于项目与产品的限制与局限产品的目标客户、顾客和其他的风险承担者产品的用户需求限制条件命名标准和定义相关事实假定1需求模版框架功能需求------产品的功能产品的范围功能与数据需求2需求模版框架非功能需求------产品的品质观感需求易用性需求性能需求操作需求可维护性和可移植性需求安全性需求文化与政策需求法律需求3需求模版框架项目问题------适用于构建产品的项目开放式问题商业上架式软件解决方案新问题任务迁移风险费用用户文档后续版本需求4项目启动一、在这个阶段，我们要找出对项目我们真正知道些什么？

二、并开始对项目尽早进行度量。5项目启动阶段主要目的通过收集各种信息，确保项目可行，且资金充足。6项目启动阶段图示项目启动领域知识可重用的需求网罗知识客户客户的想法产品的战略计划主要风险和初始费用上下文范围图业务目标7项目启动阶段提交的产物1、产品的目的；2、客户；3、顾客；4、风险承担者；5、用户；6、限制条件；7、名称；8、相关事实和假定；9、工作的范围；10、估算的费用；11、风险；12、继续或终止的决定。8项目案例

IceBreaker项目运用各种数据来精确预测何时道路将结冰。然后它安排调度并派出卡车，在道路变得危险之前用除冰物质（一种盐类化合物）来处理道路。9IceBreaker气象站

该设备将气象和道路表面情况数据传送到产品的另一部份，在那里预测道路何时将结冰，然后派出卡车，用除冰物质处理路面。

10

IceBreaker气象站11产品目标应具备什么？大家一致同意的；清晰的；无歧义的；可度量的。12如何得到产品目标？需要从一份用户问题或项目背景的描述开始。推荐格式：1.产品的目标1a.该项工作的用户问题或背景内容：对引发任务的工作和情况的描述，同时也应描述用户希望用提交的软件来完成的工作。动机：这项说明为该项目提供了合法的理由。考虑：您应该考虑用户的问题是否严重，是否应该解决和为什么应该解决。13案例背景描述（IceBreaker项目）“道路在冬季结冰，这种结冰路面将引发道路交通事故，使人丧生。我们需要能够预测何时道路可能结冰，然后我们的车库可以及时调度除冰卡车来防止道路结冰。除了气象预报之外，可以使用地区的热象图和安装在道路上的气象仪发出的道路温度数据，我们希望新的系统能提供更精确的冰情预报。这将使我们能比现在更及时地进行除冰处理，从而减少道路交通事故。我们也希望能消除对道路不加选择的处理，因为那样会浪费除冰化合物，并破坏环境。”14目标来自于------问题的解决方案

当我们知道了问题是什么，并能够清晰地说明它，我们就可以开始规划一个解决方案。该解决方案就是产品要做的事，有助于解决问题或缓解问题。

但，产品的目标应该不仅仅是解决问题，还要提供业务上的优势。并且，如果存在这种优势，我们必须能够度量它。问题解决方案优势可度量的优势15案例项目目标的得出

根据IceBreaker项目的背景描述，我们发现：问题是：“因为道路结冰而引起的道路交通事故”，问题的解决方案是：“处理路面以防止结冰（如果道路已经结冰，理所当然是使冰融化）。”因此，我们可以说产品的目标是：“精确预报道路结冰时间并分派除冰卡车。”16案例项目目标的业务优势请看案例背景描述（红色部分）：“道路在冬季结冰，这种结冰路面将引发道路交通事故，使人丧生。我们需要能够预测何时道路可能结冰，然后我们的车库可以及时调度除冰卡车来防止道路结冰。除了气象预报之外，可以使用地区的热象图和安装在道路上的气象仪发出的道路温度数据，我们希望新的系统能提供更精确的冰情预报。这将使我们能比现在更及时地进行除冰处理，从而减少道路交通事故。我们也希望能消除对道路不加选择的处理，因为那样会浪费除冰化合物，并破坏环境。”因此，我们得出该产品的业务优势是：“通过预报道路结冰情况来减少道路事故。”这个优势是可度量的吗？17案例项目目标的得出

“道路在冬季结冰，这种结冰路面将引发道路交通事故，使人丧生。我们需要能够预测何时道路可能结冰，然后我们的车路可以及时调度除冰卡车来防止道路结冰。除了气象预报之外，可以使用地区的热象图和安装在道路上的气象仪发出的道路温度数据，我们希望新的系统能提供更精确的冰情预报。这将使我们能比现在更及时地进行除冰处理，从而减少道路交通事故。我们也希望能消除对道路不加选择的处理，因为那样会浪费除冰化合物，并破坏环境。”是的。产品的成功可以通过事故数量的减少来度量，在这些事故中，道路结冰是一个因素。度量：“因结冰而发生的事故数将低于冬季发生的事故数的15%。”18目标的合理性至此，我们已经得到了一个可度量的目标，对一两个冬季进行事故监控也是可行的。事故统计数据和警察报告已经收集，对我们了解产品是否成功已经没有障碍。

但，这是一个合理的目标吗？为了消除大部分因为结冰导致的事故而花费成本和工作量来构建该产品，这值得吗？你想过下面的问题吗？“因结冰而发生的事故数将低于冬季发生的事故数的15%。”其中，“总数的15%”是从哪里来的？---启动会议或其替代方式19目标的可行性该目标可行吗？“及时地进行除冰处理”就会导致事故的减少吗？会降到低于总数的15%吗？让主要风险承担者参加会议的一个主要原因就是回答诸如此类的问题。20目标的可达成性该目标可达成吗？

本例中，代表产品设计者、构建者、硬件方的技术专家和气象学者的风险承担者让启动会议的参加者相信，技术是可获得的或可以建造的，类似的软件问题已经被团队事先解决。21有些产品的目标说明不止一个。请看背景描述：

“道路在冬季结冰，这种结冰路面将引发道路交通事故，使人丧生。我们需要能够预测何时道路可能结冰，然后我们的车路可以及时调度除冰卡车来防止道路结冰。除了气象预报之外，可以使用地区的热象图和安装在道路上的气象仪发出的道路温度数据，我们希望新的系统能提供更精确的冰情预报。这将使我们能比现在更及时地进行除冰处理，从而减少道路交通事故。我们也希望能消除对道路不加选择的处理，因为那样会浪费除冰化合物，并破坏环境。”目标：“在冬季道路养护支出上节省费用。”优势：“减少除冰和道路养护的费用。”度量：“除冰费用将在目前道路处理费用的基础上降低25%，并对道路造成的损伤将降低50%。”22小结：目标的以下方面

目标------关于产品要做什么的描述。优势------产品能提供怎样的业务优势？度量------如何对优势进行度量？合理性------构建产品的工作量超过了业务优势吗？可行性------产品能达到度量标准吗？可达成性------组织是否具备（或可获得）构建该产品的技能，在构建之后能够操作它吗？

目标陈述导致了优势和度量标准。一个简单的事实是：如果不能表达实现目标将取得的优势，或者该优势不可度量，那么该目标就不应该成为规格说明书的一部分。231.产品的目标1a.该项工作的用户问题或背景（已完成）1b.产品的目标内容：用一句话或很少的几句话来说明“我们希望该产品做什么？”换言之，即开发该产品的真正原因。动机：项目如果没有一个表述清晰、易于理解的目标，就会容易迷失在产品开发的沙漠中。产品必须提供某种业务优势。典型的优势是产品会增加组织在市场中的价值，减少运作的成本，或提供更好的顾客服务。不管是哪种优势，都应该是可度量的。开发该产品的优势或好处必须有某种客观的度量，首先它让您能确定该产品是否值得，其次让您能确定提交的产品是否达到目标。例子：“我们希望对顾客通过电话下订单订购我们的产品做出立即和完整的响应。”这个目标的度量将会表达为由于更好的响应带来的营业额的增长，或顾客满意度调查中分数值的上升。24请评价下面的这条业务目标

目标：改进我们进行业务的方式。25保持跟踪目标在建立起产品的目标后，需要保持项目朝着目标在前进。质量关让每项需求通过一系列的检查。有一项检查确保其相关性。产品的目标说明被作为评判相关性的准绳------如果需求不能以某种方式对目标做出贡献，那么它就是无关的。当需求分析师和用户对工作和建议的产品进行研究时，总是有可能忘记产品的目标。随着越来越多的需求被发现，越来越多的令人兴奋的功能被建议加入，有可能产品将不再能满足最初的目标了，因此最初期望的业务优势将不能实现。26谁为它付钱：客户IceBreaker产品的客户是MackAndrews先生，SaltworksSystems公司的首席执行官，MackAndrews先生已经同意为开发该产品投资，我们需要将这一点写入需求规格说明书中：“该产品的客户是MackAndrews先生，他是SaltworksSystems公司的首席执行官。最终客户会将该产品卖给其他国家的顾客。客户说他一个人对批准产品范围的变化负责。“27谁为它付钱：客户顾客：在产品开发完成后购买该产品。对IceBreaker来说，Northunmerland郡高速公路部门已经同意作为产品的第一个用户。说明书中如下：

“该产品的顾客是Northunmerland郡高速公路部门，主管JaneTorville是顾客代表。”28谁为它付钱：客户SaltworksSystems公司对IceBreaker项目抱有更大的期望。他们预计，一个成功的除冰预报系统将可以卖给其他郡议会，如果在开发产品时抱有这种想法，那么需求规格说明书应该包括一个附加的顾客。表述如下：

“该产品的潜在顾客包括英国所有的郡议会，需求规格说明书的一份小结将提供所有郡议会的高速公路部门管理者，目的是发现附加的需求。”29谁为它付钱：客户

“该产品的潜在顾客包括英国所有的郡议会，需求规格说明书的一份小结将提供所有郡议会的高速公路部门管理者，目的是发现附加的需求。”30顾客顾客应该由一个风险承担者代表，积极参与项目开发。尽管可能存在很多用户，但是需要有一个顾客代表。这可能是市场部门、来自用户小组的一个代表、来自关键顾客一个高级用户，或者是来自于我们组织内部的领域专家和易用性专家，或者是其他一些人。产品的实质、组织结构、顾客基础和其他一些可能因素将决定谁将成为团队里的顾客代表。“参考资料：最初的Vaisala除冰系统是在1996年为Cheshire郡议会开发的，产品的设计者是ThermalMappingInternational公司和计算机部门，该产品目前已在英国所有郡实施，并拥有超过100个海外顾客。”31用户：理解他们用户是最终操纵您的产品的人。确定用户的目的是让您能理解他们所做的工作。对他们越了解，就越能开发出合适的产品。不同的用户对产品将提出不同的需求。总是会存在很多的潜在用户，还有很多可能会被遗忘或没有被注意到。简易的方法是：对可能使用产品的人列一份清单------一份分类清单。作为一个起点，列出人们将扮演的角色，这些角色与产品的关系。32风险承担者和顾问风险承担者是在产品中有既得利益的人------他们构建产品、管理产品、使用产品或以某种方式受到产品用途的影响。风险承担者是对产品有一些要求的人，因此在需求收集活动中必须向他们咨询。顾问是那些知道产品的一些需求的人，虽然产品不会影响到他们。首要的风险承担者是？

用户、客户和顾客33其他风险承担者管理者、业务主题相关者、开发者、检查人员、市场力量、法律方面、反对者、专业团体、公众意见、政府、特殊利益团体、技术专家、文化利益、相邻系统342.客户、顾客和其他风险承担者2a.客户是为开发付费的人，并将成为所提交产品的拥有者内容：这一项必须给出客户的姓名。有多个姓名是允许的，但是如果姓名超过三个，本项就会失去意义。动机：客户最终将接受该产品，因此必须对提交的产品满意。如果产品是作为内部使用来开发的，客户和顾客的角色由相同的人来担当。如果您无法找到一个客户的姓名，那么也许您就不应该构建该产品。考虑：当为外部用户构建一个软件包或产品时，有时客户是市场部门。在这种情况下，来自于市场部门的一个人必须作为客户，并记下姓名。352.客户、顾客和其他风险承担者2b.顾客是将花钱购买该产品的人内容：对内部使用的开发来说，顾客就是最终将决定是否接受该产品的人，这通常是将部署该产品的部门经理。给出此人的姓名。注意这可能与客户相同。对于大量上市销售的产品，顾客是那些将从货架上购买产品的人。在这种情况下，应该以足够详细的方式定义目标顾客的特征，这样需求分析师可以想象顾客并据此形成需求。请注意，对于某些大量上市销售产品的开发工作来说，市场部门可能作为代理顾客，在这种情况下，应该确保市场人员尽可能地像最终顾客一样给出详细的描述。动机：顾客的角色将决定是否购买该产品，或是否部署它。构建的产品必须满足顾客的目标，同时也要满足客户的限制条件。即使您的顾客是工作在客户组织中其他部门的人，他们还是有权决定用还是不用新产品。362.客户、顾客和其他风险承担者2c.其他风险承担者内容：其他一些人或组织的名称，他们或者受到产品的影响，或者需要他们提供输入信息以便构建产品。例如：风险承担者可能包括：经理或项目；业务主题方面的专家；技术人员；系统开发者；市场人员；产品经理；测试和质量保证人员；审查员，诸如安全审查人员或审计人员；律师；易用性专家；您所处行业的专业人员。同时也请检查上下文范围图中每个相邻系统。在您收集需求的活动中，可能需要有人对相邻系统做一些讲解。动机：风险承担者对产品有要求。不能找齐所有的风险承担者会导致遗漏需求。373.产品的用户3a.产品的用户内容：产品的潜在用户或操作员的列表。针对每种类型的用户提供以下信息：用户分类——如学校里的儿童、公路工程师，项目经理等；用户工作的任务——总结用户的职责；主题相关的经验——用户在业务方面的知识。按照新手、熟练工或专家来评定；技术经验——描述用户在相关技术方面的经验，按照新手、熟练工或专家来评定。其他用户特征——描述任何可能对产品需求和最终设计产生影响的其他特征。描述诸如以下问题：身体能力/障碍；智利能力/障碍；对工作的态度；对技术的态度；教育程度；语言技能；年龄段；性别等。383.产品的用户3a.产品的用户动机：用户是为了完成工作而与产品交互的人。您越了解用户，就越可能提交适合用户工作方式的产品，符合用户的隐喻和偏好。当您在确定产品的易用性需求时，应该考虑这些对用户的描述。例子：用户的来源可能很广，有时甚至想象不到。考虑您的用户可能是办公室职员、商店店员、经理、接受过专门训练的操作员；普通公众；随意的用户；过路人；文盲；手工艺人；学生；测试工程师；外国人；儿童；律师；远程用户；用过电话线或因特网使用该产品的人，救险工作人员等，几乎任何人都可以成为用户。393.产品的用户3b.对用户设的优先级内容：在每类用户后面附上一个优先级，这区别了用户的重要性和优先地位。按以下优先级划分用户：关键用户——这些用户是对产品的后续成功至关重要的。给由这类用户提出的需求更高的优先级；次要用户——他们将使用该产品，但他们的意见对产品的长期成功并无影响。如果次要用户的需求和关键用户的需求发生冲突，应该优先考虑关键用户的需求。不重要用户——这类用户的优先级是最低的。这包括不常用的、未授权的和没有技能的用户，以及误用了该产品的用户。（这种类型的用户所占的百分比，目的是评估对这类用户要考虑多少）403.产品的用户3b.对用户设的优先级动机：如果认为某些用户对产品或组织更重要，那么应该写明，因为这会影响您设计该产品的方式。例如：您需要知道，是否有一个很大的顾客曾经特别询问过该产品，并且如果他们得不到想要的东西，结果会造成严重的业务损失。某些用户可能被列为对产品没有重要影响，这表示这些用户会使用该产品，但在产品中的没有被赋予利益。换言之，这些用户不会抱怨，也不会对产品作出什么贡献。来自于这些用户的任何特殊需求都只有较低的设计优先级。41需求限制条件解决方案限制条件项目限制条件424.需求限制条件4a.解决方案的限制条件内容：此处明确了限制条件，它们规定了解决问题必须采取的方式。您可以认为它们的指令性的解决方案。仔细描述该解决方案，以及测试是否符合的度量标准。如果可能，您应该解释使用该解决方案的原因。动机：动机是确定必须成为最终产品一部分的限制条件。出于某些原因，您的客户、顾客或用户可能有一些设计偏好。如果不满足这些偏好，您的解决方案将不会被接受。例子：“产品必须使用目前的双向无线电系统与卡车中的驾驶员通信。”、”产品必须使用WindowsNT操作系统”、”产品必须是一个手持设备。”434.需求限制条件4a.解决方案的限制条件考虑：我们希望定义一个边界，在此边界范围内我们可以解决问题。请注意，任何人如果有在某项技术方面的经验，都会倾向于以该项技术的角度看需求。这种倾向性导致人们出于错误的原因强加一些解决方案限制条件，假定限制条件很容易就潜入到需求规格说明书中。如果您强加了一些限制条件，带来的危险性就是您将失去得到问题的最佳解决方案的自由。解决方案限制条件应该只限于那些绝对不可能商榷的解决方案。444.需求限制条件4b.实现环境。此处描述产品将被实施的技术环境和物理环境，包括自动的、机械的、组织的和其他设备。这包括了非人力相邻系统。4c.伙伴应用。此处描述那些不属于产品的一部分的应用程序，但产品必须与这些应用程序协作。4d.商业上架销售软件。此处描述实现产品需求必需使用的COTS。4e.预期的工作场地环境。此处描述用户工作和使用该产品的工作场地。此处描述任何可能对产品设计产生影响的工作场地特征。4f.开发者构建该产品需要多长时间。最后期限或商业机会的时限。4g.该产品的财务预算是多少。以金钱的形式或可得资源的形式说明。45词汇表------数据字典的基础名称很重要。在启动会议上开始收集并记录项目将用到的一些名称。每个项目或产品都有一些特别的名称。这些是我们需要捕获的术语，同时也要得到它们公认的含义。当没有一个集中的词汇表时，我们总是会吃惊地发现将导致多少错误。我们也发现好的名称对交流思想是很有效的。这方面花一些功夫是值得的，这将保证今后在项目中能顺利地进行沟通。将来的详细系统分析将用这些词汇作为基础来形成完整的数据字典。46词汇表请对IceBreaker项目中的“气象站”一词进行定义。47词汇表“气象站”：一组硬件，能够收集并传递道路温度、空气温度、湿度和降水量数据。气象站在Northumberland郡安装了八处。485.命名标准和定义定义项目中使用到的所有术语，包括同义词。内容：一个字典，包括在需求规格说明书中使用的所有名称的含义。这个字典应该使用您的组织或行业使用的标准名称。这些名称也应该反映出在工作领域中当前使用的术语。该字典包括项目中用到的所有重要名称。请仔细地选择名称，以避免传达不同的、不期望的含义。为每个名字写下简明扼要的定义，这些定义必须经过相应的风险承担者同意。动机：名称十分重要，它们能反映含义。如果定义得好，可以省掉数小时的解释。在项目的这个阶段注意名称将有助于尽早澄清误解。在需求阶段得到的字典将在整个项目中使用并不断补充。例子：除冰卡车——在冬季，将除冰物质散布到道路上的运输工具49ATM案例的数据词典（供参考）：账户：某银行的单个账户，交易要依靠账户来进行。账户可以有许多不同的种类，例如经常账户和储蓄账户。一个客户可以持有多个账户。ATM：允许客户使用现金卡作为身份证明来进行交易的柜台。ATM与客户进行交互，收集交易信息，给中心计算机发送交易信息进行校验和处理，给用户支付现金。我们假定ATM不需要独立于网络运转。银行：拥有客户账户的金融机构，发放现金卡，通过ATM网络授权访问帐户。50设定范围我们设定范围的方法是把一块工作（我们要研究的工作）与另一些工作（围绕我们的工作）分开。记住，你碰到的任何一项工作都或多或少与其他的工作有联系。51设定范围为了确定何处是一项工作的结束，另一项工作开始的地方，请考虑工作职责。也就是说，我的这部分工作要负责得到什么，相邻的工作要负责接收什么。我的工作需要从相邻的工作得到什么才能开始自己的职责？（如下页图示）52影响范围设定的因素：产品目标和其他限制条件设定工作的范围意味着决定在确定产品的需求之前有多少工作要研究。当考虑哪部分是本产品的工作，哪部分是其他工作时，请牢记产品的目标。它限制了哪些应该是我们的工作范围之内的，哪些放在工作范围之外是安全的。但必须确保在工作范围之内的工作足够满足产品的目标。可得到的预算和允许的开发时间也会影响项目的范围。53影响范围设定的因素：感兴趣的领域感兴趣的领域是与主题相关的领域。我们要研究的工作来自于一个主题或多个主题。根据本项目的背景描述，请找出该项目涉及的领域。54背景描述“道路在冬季结冰，这种结冰路面将引发道路交通事故，使人丧生。我们需要能够预测何时道路可能结冰，然后我们的车路可以及时调度除冰卡车来防止道路结冰。除了气象预报之外，可以使用地区的热象图和安装在道路上的气象仪发出的道路温度数据，我们希望新的系统能提供更精确的冰情预报。这将使我们能比现在更及时地进行除冰处理，从而减少道路交通事故。我们也希望能消除对道路不加选择的处理，因为那样会浪费除冰化合物，并破坏环境。”55设定工作上下文范围工作上下文范围定义了我们要研究的工作，以及工作周围的其他系统。可以把它想象成“您的工作职责是什么？其他人的工作职责是什么？”我们通过创建上下文范围的模型来展示这种指责上的划分，上下文范围模型表现了工作和与之相连的工作56设定工作上下文范围让我们从相邻系统看起，它们是围绕在我们的工作周围的一些工作。它们可以从产品的目的、背景信息和感兴趣的领域推导出来。针对每个领域，问以下问题：是否存在一个物理实体代表这个领域？这个领域提供数据或政策，还是都提供？我将从何处得到关于该领域的信息？578.产品的范围内容：上下文范围图确定了为了构建该产品您需要调查的工作。请注意这包括的范围超出了目标产品。如果我们不了解产品将支持的工作，就很少有机会构建能与它的环境无缝集成的产品。上下文范围图说明了需要理解的其他主题相关的领域（系统、人和组织）。相邻系统与工作上下文范围之间的接口说明了为什么我们对相邻系统有兴趣。动机：动机是清楚地定义我们打算研究的工作的边界。工作活动与相邻系统之间的信息流精确地定义了工作系统的职责和相邻系统的职责。58卡车车库预测和调度道路除冰的工作气象站气象预报局道路工程热像图提供者59该产品的成本会是多少？在这个阶段上下文范围内已经提供了相当多的可度量的方面，因此没有理由不进行度量。度量的要点是理解工作的大小。尽管这个阶段还不知道精确的产品边界，但是度量工作可以让你对任务大小有个了解，以决定是否要进行该项目。如果连基本的度量工作都不做，那么任何预测必定是建立在猜测的基础之上。60风险您知道问题有可能会发生，那么为什么不注意它们？一些破坏性最大的风险：不准确的度量标准；测量工作做得不够；过重的时间进度压力；管理层玩忽职守；不准确的费用估计；银弹综合症；蔓延的用户需求；低质量；低生产效率；61风险可能与本阶段最有关系的是需求相关的风险。例如：产品没有清晰和可度量的目标；缺少客户参与；缺少风险承担者参与；在需求上很少或不能达成一致；需求蔓延；镀金需求；没有需求对应的度量方式；快速变化的需求；需求变更控制不够；新进入未知的业务，需求不确定。62继续还是终止？在启动会议阶段得到的提交产物为评估项目的可行性提供了基础。考虑以下问题，决定是否终止。产品的目标清楚吗？目标是可度量的，可行的吗？有可能达到项目的目标吗？能就工作的上下文范围取得一致同意的意见吗？高可能性、后果严重的风险是否让项目变得不可行？考虑产品带来的好处，它的费用是否合理？风险承担者愿意参与吗？是否有足够的理由投资该项目？是否有足够的理由不投资该项目？在按下项目的启动的按钮之前，还需要进行进一步的调查吗？63启动会议替代方案您不必一定要举行一个会议，但您需要知道会议要提交的那些事实。64小结项目启动阶段是一个了解认知的过程。了解项目的限制条件。启动阶段提供了知识。启动阶段提交的产物作为后续活动的输入信息，它们非常有价值。65用例------需求获取的有效方法66建模公式67整个软件过程就是用例驱动的。用例驱动软件生产过程是非常有道理的。要解决问题领域就要归纳出所有必要的抽象角度（用例），为这些用例描述可能的特定场景，并找到实现这些场景的事物、规则、行为。再换个说法，如果我们找到的那些事物、规则、行为实现了所有必要的用例，那么问题领域就解决了。总之，实现用例是必须做的工作，一旦用例实现了，问题领域就解决了。这就是用例驱动方法的原理。用例驱动68只见树木不见森林。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。UML。。。。。。。。。。。。。。。。。。。。。。。。(建模)。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。69。。。。。。。。。。。。。。。。。。。UML。。。。。。。。。。。。。。。。。。。系统软件过程站在软件过程的角度70为什么需要UML?提到UML我们必须先搞清楚一个问题……71你赞同以下哪几种说法？面向对象是现代科学发展到一定程度才出现的研究成果；面向过程和面向对象都是一种软件技术；面向过程和面向对象是一个古已有之的认识论的问题；世界的本质是由对象组成的，平时看上去相互无关的独立对象在不同的驱动力下和规则下体现出不同的运动过程；世界的一切都不是孤立的，它们相互紧密联系在一起，缺一不可，相互影响，相互作用，并形成一个个具有严格因果律的小系统，而更小的系统组成了更大的系统，所有小系统之间的联系也是紧密不可分割的。面向对象方法具有更强大的抽象能力。UML是面向对象方法的具体化和符号。学习UML的过程就是掌握面向对象思想和方法的过程。相对学习UML符号而言掌握它们背后的方法和思想是更为重要的；面向过程和面向对象都是人们认识世界的方法。面向对象就是指使用一系列面向对象程序设计语言的软件开发方法。72。。。。。。。。。。。。。。。。。。。UML。。。。。。。。。。。。。。。。。。。系统面向对象还是面向过程？软件过程73什么是面向对象?（ObjectOriented,简称OO）

面向对象软件开发方法描述和理解问题域的基本思想是，对问题域进行自然分割，以更接近人类思维的方式建立问题域模型，从而使生产出的软件尽可能直接地描述现实世界，具有更好的可维护性，能适应用户需求的变化。74什么是面向对象?（ObjectOriented,简称OO）面向对象建模与设计是使用真实世界的概念模型来思考问题的一种方法。其基本元素是“对象”。

对象既包含数据结构，又包含行为。对于理解问题、与应用领域专家交流、建模企业级应用、编写文档、设计程序和数据库来说，面向对象模型都非常有用。75什么是面向对象?（ObjectOriented,简称OO）对于软件来说，面向对象这个术语的意思是，把软件组织成一系列离散的、合并了数据结构和行为的对象。

76OO方法的几个特征

1.标识：意指数据被量化成称为对象（object）的离散的、可辨识的实体。

在真实世界中，对象只是一种简单的存在，但在编程语言中，每个对象都有一个唯一的句柄，借助这个句柄就可以引用对象。

77OO方法的几个特征

2.分类：指的是有着相同的数据结构（属性）和行为（操作）的对象被分组为一个类。

类（class）是什么？答:A)是一种抽象；B)是单个对象组成的无限集合；

78每个对象都是该类的一个实例（instance）

自行车对象

抽象成-自行车类Mike的自行车属性Brian的自行车车架尺寸Mary的自行车车轮尺寸……齿轮数材料操作变速移动修理79再一个例子

多边形对象

抽象成-多边形类属性顶点边界颜色填充颜色

操作绘制擦除移动80OO方法的几个特征

3.继承：指的是多个类基于一种分层关系，共享类间属性和操作（合称特征）。父类（super-class）拥有子类（subclass）要精炼和详细指定的通用信息。子类不需要重复其父类的特征。

81OO方法的几个特征

4.多态：是指对于不同的类来说，相同的操作会有不同的动作。操作是对象执行或被执行的一个过程或转换。

82OO主题

有几个主题在OO方法中无处不在。尽管这几个主题并不是OO系统所特有的，但OO系统对他们的支持却极为出色。83OO主题---1.抽象抽象（abstraction）使我们可以专注于应用程序最本质的那些方面，同时忽略细节。这意味着在确定如何实现功能之前，要先关注对象是什么，做了什么。使用抽象机制，可以避免不成熟的细节承诺。对于OO开发来说，抽象的能力是最重要的一项技能。84OO主题---2.封装封装（encapsulation）将对象的外部因素（可以被其他对象访问）与内部实现细节（其他对象不可见）分离开来。封装阻止程序的组成部分过于依赖，如果那样的话，很小的变化也会引起巨大的涟漪效应。

封装不是OO语言所特有的，但将数据结构和行为组织在一个实体中，这样的封装比以前的语言---例如Fortran、Cobol和C更干净、更有力。85OO主题---3.共享

OO方法有利于不同层次上的共享。继承数据结构和行为使得子类可以共享通用代码。通过继承完成共享是OO语言的一个主要的优点。比节省代码量更重要的是概念的清晰性，认识到不同的操作实行的实际上都是相同的事。这样就减少了必须理解和分析的不同情形的数量。86OO主题---4.强调对象的本质

OO方法强调对象是什么，而不是如何使用它。对象的用法依赖于应用程序的细节，经常会在开发过程中发生变化。随着需求的演化，对象提供的特征会比使用它的方法来得更加稳定，因此，构建在对象结构上的软件系统最终也会比较稳定。与功能分解方法学相比，OO开发在数据结构上投入了较大精力，而较少关注过程结构。87OO主题---5.协同（synergy）标识、分类、多态和继承都是OO语言的特色。这些概念中的每一个都可以分开使用，但结合在一起，它们就会互相促进，互为补充。强调对象的基本特性会迫使开发者更加仔细和深入地思考对象是什么，做了些什么。这与关注重心只在数据和操作上的用法相比，前者所生成的最终系统会更加干净、更加通用和更加健壮。88关于OO开发有效性的证据

OO开发工作开始于GE研发中心的内部应用程序。开发者用OO来开发编译器、图形、用户界面、数据库、oo语言、CAD系统、元模型、控制系统以及其他一些应用。OO模型还被用于评述结构不良、难以理解的程序。

自从20世纪90年代中期以来，OO从GE扩展到了全世界。现在，OO不能被认为是一种时髦的或是一种纯理论的方法了，它已经是计算机科学和软件工程的主流。89抽象层次是面向对象方法中极其重要且非常难以把握的技巧；要想建立好模型，就需学会站在不同的抽象层次考虑问题。抽象层次越高，被屏蔽（或者说封装）的信息也就越多，信息量越少也就越容易理解和处理。抽象层次90统一过程一般抽象层次91什么时候选择什么样的层次以及总共抽象多少层？------用例粒度抽象层次与边界的选择总是相生相伴------边界抽象层次相关的问题92视图是UML建模中另一个非常重要的概念；视图用于组织UML元素，表达出模型某一方面的含义，视图的准确应用是建立好模型的一个重要组成部分；目标对象的每一个属性都是它的一个视图。例如：汽车的大小、重量、外观、性能、安全等。只有将必要的方面都用视图展现出来，观察者才会真正理解这个事物。UML里定义了用例图、类图、对象图、包图、活动图等不同的视图。何谓视图？93观察者会抱怨视图给出的信息不是很清晰；希望从更多的角度来查看事物的信息。这就引出了视图中另一个被很多人忽视的概念------

视角给出事物所有属性的视图就足够了吗？94不同的人或者同一个人出于不同的目的会对同一个信息从不同的角度来审视和评估；不同的角度展示了同样信息的不同认知角度以便于理解。例如：汽车的外观视图。视角：是人们观察事物的角度95适当的视角给适当的人。软件干系人很多，有客户、系统分析员、架构师、设计师、开发人员、测试人员、项目经理等，他们对同样信息的审视角度是不同的。错误的选择视角常常导致需求改来改去难以确定。恰当的视角96为特定的信息选择正确的视图；为特定的干系人展示正确的视角。也就是要经常思考下面两个问题：应该为哪些软件信息绘制哪些视图？应该为哪些干系人展示哪些视角？视图和视角对建立一个好的模型很重要97一切都是对象；对象都是独立的；对象都具有原子性；对象都是可抽象的；对象都有层次性。对象分析方法98对象的独立性99对象分析方法总结100构造类型（stereotype）参与者用例边界业务实体包分析类设计类关系组件节点UML核心元素101构造类型（stereotype）:也称为版型、类型。概念：是对一个UML元素基础定义的扩展，在同一个元素基础定义的基础上赋予特别的含义，使得这个元素适用于特定的场合。例如：用例的构造类型有“业务用例”、“业务用例实现”等；“类”有“边界类”、“实体类”、“控制类”等。意义：构造类型只是UML的一种扩展手段，是在建模的不同阶段区分视图的不同点。例如：“业务用例”就是专门应用在业务建模场合的。构造类型也可以自己定义。UML核心元素1022.参与者（actor）:定义：actor是在系统之外与系统交互的某人或某事物。如图所示：UML核心元素参与者位于边界之外；参与者可以非人。103发现参与者：参与者的一个重要来源是涉众，从涉众中找出那些直接对系统发出动作，或直接从系统中接收反馈的涉众。在查找参与者的过程中，可以询问以下问题以帮助确定参与者：谁负责提供、使用或删除信息？谁将使用此功能？谁对某个特定功能感兴趣？在