第三讲需求工程(requirementsengineering)资料课件

第三讲需求工程

（RequirementsEngineering）WelcometoSoftwareEngineeringLecture3ZhangJiannanjiannanz@163.com目标了解需求工程的主要活动及它们之间的关系；掌握有关需求的基本知识；掌握需求导出和分析的一些技术；了解结构化分析的基础知识和基本方法；重点掌握基于UML建模的面向对象分析方法了解需求有效性验证及如何进行需求评审；了解需求管理的必要性以及它如何支持其它需求工程活动。内容可行性研究需求分析基础需求导出与分析结构化分析基础UML与面向对象分析方法需求有效性验证需求文档需求管理恐怖的噩梦一个棘手的项目终于接近了尾声，作为项目经理的你坐在办公室舒展着紧张了几个月的身躯，头脑中盘算着如何让客户痛快的付清合同款。这时，客户走进你的办公室，坐下，直视着你的眼睛说道：“我知道你认为你理解了我说的是什么，但你恐怕不知道，我所说的其实不是我想要的。”需求工程过程需求工程过程并不具有唯一的模型，按照不同的应用领域、不同的客户与开发团队，需求工程的过程有很大的差异。然而，在所有的过程中都会涉及一些共同的活动，它们是：可行性研究(feasibilitystudy)；需求导出与分析(elicitationandanalysis)；需求描述(specification)；需求有效性验证(validation)；需求管理(management)。需求工程过程需求工程1.可行性研究可行性研究要决定被提议的系统是否值得去做。可行性研究过程较短，焦点集中在以下几个问题：系统的开发是否符合组织的总体目标？系统是否可能在现有的技术和预算限制内完成？系统能否与已存在的其它系统相兼容？进行可行性研究进行可行性研究包括信息评估、信息汇总和书写报告三部分工作。信息的评估与汇总需要分析人员与Stakeholders相沟通，通过提出问题汇总信息，可能提出的问题包括：如果系统没有实现，机构将如何应对？当前处理过程存在哪些问题？新系统将如何处理？系统将对业务目标有什么直接的贡献？系统需要和哪些系统相集成？需要使用新技术吗？使用那些技术？对待开发系统感兴趣和直接或间接从系统中获益的人2.需求分析基础2.1什么是需求？定义不一致需求具有双重功能：IanSommerville可以作为竞标、签约的基础一种开放的、易于交流的系统功能及约束的高层概要描述；签约之后，为了完成合同约定，开发者给出的对系统的详尽、准确的描述。两种描述都叫做需求文档，分别对应于用户需求和系统需求。2.2需求的类型用户需求从客户的角度，采用自然语言配合以图表对目标系统应提供的服务以及系统操作要受到的约束进行的声明。系统需求系统需求是一种结构化文档，要运用一些专业的模型详细的描述系统的功能及其约束。系统需求文档有时也称为功能描述，应该是精确的，它可以成为双方之间合同的重要内容，同时作为开发工作的依据。需求定义与描述用户需求定义1.LIBSYS应该能够管理全国及其他地区的版权代理商所要求的全部数据。系统需求描述1.1向LIBSYS申请建立一个档案的时候，系统应该用一个表格来记录申请者及他所提出的申请的详细情况；1.2LIBSYS申请表格应该从提交的日子开始在系统中保存5年；1.3LIBSYS申请表格必须能够由用户根据请求材料的名称和申请人来进行索引；1.4LIBSYS应该能够维护一个已经被系统处理的所有申请的日志；1.5对于作者提供出借权的材料，系统应该按月向已经在系统注册的版权代理商提供详细的出借信息。2.3功能需求与非功能需求功能需求对系统应提供的功能，系统在特定的输入下做出的反应及特定条件下的行为的描述。某些情况下还要包括系统不应做什么。非功能需求对系统提供服务或功能时收到的约束进行描述。如时间约束、开发过程约束和标准等。领域需求这种需求来自于系统的应用领域，反映领域特征。可能是功能需求也可能是非功能需求。2.3.1功能需求功能需求描述系统所应提供的功能或服务。取决于待开发软件的类型、未来的用户以及开发的系统类型。功能性的用户需求只需要对系统应提供的服务进行高层一般描述，对于系统需求，则应该详细的描述系统功能、输入输出及异常。功能需求描述例：图书馆系统（LIBSYS）

该图书馆系统要提供一个界面，使顾客能够访问多个图书馆不同的文献数据库中的资料。允许用户出于个人学习的目的对文献资料进行搜索、下载和打印。功能需求描述用户可以从总的数据库中进行查询，也可以从其中一个子集中查询；系统应提供一个适当的浏览器供用户阅读馆藏资料；每次借阅应该对应一个唯一标识符(ORDER_ID)。通过这个标识，可以允许用户把文献拷贝到常备存储区。不严密问题当需求被不严密的表述时，会产生很多问题。一些不明确、不准确的表述可能会使用户与开发者有不同的理解。思考上例中的短语“适当的浏览器”，如何理解？用户的理解

开发者的理解需求的全面性和一致性原则上，功能性需求描述应该具备全面性和一致性。全面性包括了所有用户要求的服务。一致性在系统服务的描述中没有冲突和矛盾Inpractice,itisimpossibletoproduceacompleteandconsistentrequirementsdocument.2.3.2非功能性需求非功能需求不直接和功能相关，但定义了实现系统功能受到的约束与系统特性。如可靠性、响应时间、存储空间、I/O设备能力等。非功能需求还常与系统的开发过程有关，表现为过程需求。如设计必须实用的特定CASE工具集、设计语言和开发方法。Whichoneismorecritical?俺当上白领儿了？也该买辆车了！先生，我们的汽车配置齐全，自动巡航、四气囊、真皮座椅、电动天窗、自动空调一应俱全，才八万多，性价比相当高！嗯，功能不错，价格也便宜，安全性怎麽样？……,呵呵，说实话，是有点小毛病，偶尔刹车会失灵，不过问题不大，多踩几下就行了！非功能需求分类产品需求Requirementswhichspecifythatthedeliveredproductmustbehaveinaparticularwaye.g.executionspeed,reliability,etc.机构需求Rcessstandardsused,implementationrequirements,etc.外部需求Reroperabilityrequirements,legislativerequirements,etc.非功能需求的类型非功能需求案例（仍以LIBSYS为例）产品需求

LIBSYS的用户界面应该能够正确处理错误操作，并给出提示和帮助信息。组织需求系统的开发过程和可交付文档应遵照XYZCo-SP-STAN-95中的相关定义。外部需求

系统不应对系统操作人员公开客户除名字与索引代码之外的任何个人信息。目标与验证非功能需求的常见问题是检验困难，可以通过设定目标来定义可检验的非功能需求。目标明确说明用户的意图，如可用性；可检验的非功能需求用可测试的度量标准来描述需求。可能的情况下，应量化非功能需求，从而使其检验更客观。案例：系统目标Thesystemshouldbeeasytouseeventoexperiencelesscontrollersandshouldbeorganisedinsuchawaythatusererrorsareminimised.可检验的非功能需求Experiencelesscontrollersshallbeabletouseallthesystemfunctionsafteratotaloftwohourstraining.Afterthistraining,theaveragenumberoferrorsmadebyexperiencelessusersshallnotexceedtwoperday.非功能需求的度量需求冲突一些复杂的系统中，功能需求与非功能需求常会出现冲突。例：SpacecraftsystemTominimiseweight,thenumberofseparatechipsinthesystemshouldbeminimised.Tominimisepowerconsumption,lowerpowerchipsshouldbeused.However,usinglowpowerchipsmaymeanthatmorechipshavetobeused.Whichisthemostcriticalrequirement?2.3.3领域需求领域需求来自于应用领域，描述的是反映领域特点的系统特性与特征。领域需求可能是新的功能需求，也可能是对现有需求的约束或定义一个特别的计算。领域需求非常重要，如果领域需求不能满足，可能会使整个系统无法运转。图书馆系统的领域需求ThereshallbeastandarduserinterfacetoalldatabaseswhichshallbebasedontheZ39.50standard.Becauseofcopyrightrestrictions,somedocumentsmustbedeletedimmediatelyonarrival.Dependingontheuser’srequirements,thesedocumentswilleitherbeprintedlocallyonthesystemserverformanuallyforwardingtotheuserorroutedtoanetworkprinter.领域需求表述的问题不易理解Requirementsareexpressedinthelanguageoftheapplicationdomain;Thisisoftennotunderstoodbysoftwareengineersdevelopingthesystem.表述模糊Domainspecialistsunderstandtheareasowellthattheydonotthinkofmakingthedomainrequirementsexplicit.2.4用户需求用户需求是从用户角度来描述的系统功能需求与非功能需求，这样的描述可以使不具备专业技术知识的用户能够看明白。用户需求使用任何人都看得懂的自然语言、图表和直观的图形来描述。自然语言的缺陷描述不够清楚

存在二义性，不易准确理解；需求混乱功能需求、非功能需求无法清晰区分；需求混合多个不同的需求可能被混合在一起表述；书写用户需求的准则设计一个标准格式，以帮助减少遗漏，避免不必要的细节描述；使用一致的语言，尤其强调区别强制性需求与希望性需求。如使用“必须

”定义强制性需求，使用“应该

”定义希望性需求；使用文本加亮来突出关键性需求；尽量避免使用计算机专用术语。2.5系统需求相对于用户需求，系统需求是对系统功能、服务及约束的更详尽的描述。系统需求是系统实现的基本依据，会被写入合同中。因此系统需求是一个完全的、一致的系统描述，是设计的起点。系统需求可以用系统模型来定义与说明。使用自然语言描述系统需求的问题不明确Thereadersandwritersoftherequirementmustinterpretthesamewordsinthesameway.NLisnaturallyambiguoussothisisverydifficult.描述随意性太大Thesamethingmaybesaidinanumberofdifferentwaysinthespecification.不能进行模块化描述NLstructuresareinadequatetostructuresystemrequirements.代替NL的描述方法结构化的自然语言这种方式保持了自然语言的表达能力和易懂等特点，同时用预先定义的模版限制了书写需求使得自由度：所有的需求都用一致的标准方法来书写；对使用的词汇进行了限制，并用模板来约束。基于标准格式的描述方法对功能或实体的定义；对输入及输入来源的描述；对输出及输出去向的描述；其它被引用实体的索引；前条件与后条件；对操作的副作用（如果有）的描绘。例：添加节点的格式化描绘应用表格进行描述这种方法常用做自然语言描述的补充。适用于对于多种不同条件有多种可选动作（结果）的情况。例：表格描述图形模型图形模型在需要描述系统的状态变化或动作序列时最为有用。有关图形模型的应用是这门课程的实践重点！例：ATM取款序列图3.需求导出与分析这个阶段在可行性研究之后进行。系统分析人员要和客户及最终用户一同调查应用领域，找出系统应提供的服务及其约束，即找出系统的功能需求与非功能需求。这个阶段通常与需求描述交叉进行。这个阶段的活动会涉及到机构中方方面面的人，如终端用户、工程人员、业务经理领域专家，甚至工会代表，他们都是对系统需求产生直接或间接影响的人，被称作

stakeholders。需求分析可能遇到的问题Stakeholdersdon’tknowwhattheyreallywant.Stakeholdersexpressrequirementsintheirownterms.Differentstakeholdersmayhaveconflictingrequirements.Organisationalandpoliticalfactorsmayinfluencethesystemrequirements.Therequirementschangeduringtheanalysisprocess.Newstakeholdersmayemergeandthebusinessenvironmentchange.需求螺旋过程活动需求发现Interactingwithstakeholderstodiscovertheirrequirements.Domainrequirementsarealsodiscoveredatthisstage.需求的分类与组织Groupsrelatedrequirementsandorganisesthemintocoherentclusters.优先排序和冲突解决Prioritisingrequirementsandresolvingrequirementsconflicts.需求文档Requirementsaredocumentedandinputintothenextroundofthespiral.需求的发现与识别这是整个过程中最为关键的活动，负责收集目标系统级现存系统的相关信息并从这些信息中提炼出用户需求和系统需求。信息的来源包括已有的文件，系统的信息持有者（stakeholders）以及相近系统的规约描述。ATMstakeholdersBankcustomersRepresentativesofotherbanksBankmanagersCounterstaffDatabaseadministratorsSecuritymanagersMarketingdepartmentHardwareandsoftwaremaintenanceengineersBankingregulators3.1多视点（viewpoint）需求定义视点用来表述不同角度的需求来源（信息持有者、其它相关系统及领域）。每一个视点代表系统需求的一个子集。从多视点对系统进行分析是十分重要的，因为没有那一种单一的途径能够诠释整个系统需求。视点的类型交互者视点Peopleorothersystemsthatinteractdirectlywiththesystem.InanATM,thecustomer’sandtheaccountdatabaseareinteractorVPs.间接视点Stakeholderswhodonotusethesystemthemselvesbutwhoinfluencetherequirements.InanATM,managementandsecuritystaffareindirectviewpoints.领域视点Domaincharacteristicsandconstraintsthatinfluencetherequirements.InanATM,anexamplewouldbestandardsforinter-bankcommunications.视点的识别以下的几个方面可以帮助识别视点：Providersandreceiversofsystemservices;Systemsthatinteractdirectlywiththesystembeingspecified;Regulationsandstandards;Sourcesofbusinessandnon-functionalrequirements.Engineerswhohavetodevelopandmaintainthesystem;Marketingandotherbusinessviewpoints.LIBSYS的视点3.2访谈对stakeholders进行正式的和非正式的访谈对于需求工程是非常重要的工作。有两种类型的访谈：封闭式访谈，预先定义所要提问的问题，又叫做限定式访谈；开放式访谈，不预先设定访谈内容，给定一个范围，与stakeholders自由交流以更好的把握他们的要求。访谈实践通常是采用两种方式相混合，以封闭式访谈开始，以开放式结束。访谈对于全面了解系统需求是一种很好的方法，在访谈中可以了解stakeholders的要求，他们是如何与系统交互的，对当前系统面临的问题等。访谈方式对于获取领域需求并不是很奏效Requirementsengineerscannotunderstandspecificdomainterminology;Somedomainknowledgeissofamiliarthatpeoplefindithardtoarticulateorthinkthatitisn’twortharticulating.对访谈者的要求有能力的访谈者应该是思维开阔的，愿意聆听他人的想法，并且不会对问题有先入为主的看法。他们善于用问题和建议去启发访问者的思维，或使用原型与被访问者讨论，而不是仅用‘whatdoyouwant’进行简单的提问。

3.3场景场景描述法是采用把系统交互放到一个真实的生活片段中，这样比采用抽象的形式描述要容易理解，容易导出目标系统的使用细节。场景的描述方式很多，一般包括：场景开始时系统初始状态的描述；一个标准事件流的描述；对可能出现的错误及解决方法的描述；其它并行事件流的描述；场景结束状态的描述。常用的方法，自然语言和用例。例：酒店预定场景描述开始：

MedocaSansumi,是theSantaCruzB&B的酒店前台，一边看着theHotelAppMain的银幕一边等着电话。电话从Ms.JaneGoogol打来，一个来自纽约的客户。Ms.Googol拿起电话说“你好，我是JaneGoogol，我想要为新年的前夜预定一间房间”。Medoca在HotelApp的主银幕上选择了“创建预定”。屏幕上显示出一个空预定。中间过程：

Medoca问到“你什么时候到达这里？”。Jane回答到“12月31日到，我想要住到1月5日。”Medoca输入了开始日期，并且问到“你想要预定什么类型的房子呢？”，“我将和我的丈夫一起到那，所以需要一个单独的并且有足够空间的，那个Blue房子有空的吗？”Jane问到。Medoca选择“single”在预定的表格中，完成了查找。系统给予了三种空房间的回应：Victoria,Blue和Queen。“是的，有空的”Medoca回答。Medoca选择了Bule房间，系统把它填入预定的表格中，然后做出“held”的预约记号。例：酒店预定场景描述更多的中间过程：

Medoca向系统中输入Jane的全名。Ms.Googol是一个现有的客户，所以系统通过客户表单的数据在预约的表格中给出回应。“你想要今天就把这个预定确定下来吗？”Medoca问道。“是的”Jane说，“用我的VISA卡，卡号是：1111-2222-3333-4444。”Jane在Medoca把卡号输入进去以后暂停了。“截至日期是2007年7月。”Medoca输入这些信息，并且在系统上选择了“VerifyPayment（确认付款）”。五分钟后，系统给出了银行存款验证的回应。系统把预定的状态改成了“confirmed.”例：酒店预定场景描述例：酒店预定场景描述结束：

Medoca告诉Jane预约号（系统产生的），并且问道“我还能为您做什么？”，Jane回答没什么了，Medoca向Jane道谢并且再见。Medoca关闭了预约表格的窗口，系统返回到MainHotelApp的主屏幕上。用例（UseCase）用例是一种基于UML的场景描述技术，用来识别在一个系统交互中的参与者并描述这个交互过程。用例的集合应该可以描述系统中的所有的交互。UML中的序列图可以用来配合用例图描述系统的交互细节。例1：文献打印用例图例2：

LIBSYS用例模型例3：文献打印序列图3.4

导出工作产品对于大多数系统而言，工作产品包括：Astatementofneedandfeasibility.Aboundedstatementofscopeforthesystemorproduct.Alistofcustomers,users,andotherstakeholderswhoparticipatedinrequirementselicitationAdescriptionofthesystem’stechnicalenvironment.Alistofrequirements(preferablyorganizedbyfunction)andthedomainconstraintsthatapplytoeach.Asetofusagescenariosthatprovideinsightintotheuseofthesystemorproductunderdifferentoperatingconditions.Anyprototypes

developedtobetterdefinerequirements.4结构化分析（SA）建模结构化分析方法是一种面向数据流的系统建模技术；SA帮助分析者理解系统的功能，并采用模型与用户进行交流；不同的模型从不同的角度对系统进行描述。结构化分析建模结构化分析方法建立的分析模型结构如下图：实体—关系图

数据词典状态—迁移图数据流图数据对象描述控制规格说明加工规格说明结构化分析模型的核心是数据词典，它描述了所有的在目标系统中使用的和生成的数据对象。围绕着这个核心的有三种图：实体—关系图(ERD)描述数据对象及数据对象之间的关系；数据流图(DFD)描述数据在系统中如何被传送或变换，以及描述如何对数据流进行变换的功能（子功能）；状态—迁移图(STD)描述系统对外部事件如何响应，如何动作。因此，ERD用于数据建模，DFD用于功能建模，STD用于行为建模。

结构化分析建模4.1数据建模与实体—关系图(ERD)数据模型包括三种互相关联的信息：数据对象描述对象的属性描述对象间相互连接的关系（具体绘制方法同数据库原理ER模型画法）4.2功能建模和数据流图

功能建模的思想就是用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止。数据流图可以表示任何一个系统（人工的、自动的、或混合的）中的数据流程；每个表示加工的圆圈可能需要进一步分解以求得对问题的全面理解；着重强调的是数据流程而不是控制流程。4.2.1数据流图的画法数据流图中的常用图元有以下四种：表示外部实体，代表数据源和数据池（终点）。表示加工，代表接收输入，经过变换，继而产生输出的处理过程。表示数据流，代表数据的流向和路径。表示数据存储，代表系统加工的数据所存储的地方。

例：教材采购与销售管理系统数据流图

F1教材存量表

1

销售

2采购

书库保管员

学

生领书单购书通知进书通知

购书单

缺书单

F2缺书登记表

缺书汇总表多个数据流与加工之间关系的符号

4.2.2分层数据流图复杂的实际问题，在数据流图上常常出现十几个甚至几十个加工。画数据流图的基本步骤概括地说，就是自外向内，自顶向下，逐层细化，完善求精。按照系统的层次结构进行逐步分解，并以分层的数据流图反映复杂的结构关系，能清楚地表达和容易理解整个系统。4.2.2分层数据流图画分层数据流图的注意事项数据流图要具有可读性、一致性、正确性。①数据流图上所有图形符号只限于前述四种基本图形元素。②顶层数据流图上的数据流必须封闭在外部实体之间。③数据应通过加工流动，避免从一个数据存储直接流向另一个数据存储。④每个加工至少有一个输入数据流和一个输出数据流，且输入与输出数据流要平衡。有输入，无使用及输出为“黑洞”，无输入和产生而有输出为“奇迹”。⑤在数据流图中，需按层给加工框编号。编号表明该加工处在哪一层，以及上下层的父图与子图的对应关系。⑥规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡。画分层数据流图的注意事项⑦图上每个元素都必须有名字。数据流和数据文件的名字应当是“名词”或“名词性短语”，表明流动的数据是什么。加工的名字应当是“动词＋宾语”，表明做什么事情。⑧可以在数据流图中加入物质流，帮助用户理解数据流图。⑨数据流图中不可夹带控制流。⑩初画时可以忽略琐碎的细节，以集中精力于主要数据流。例：教材采购与销售管理系统零层数据流图L0教材购销系统领书单

进书通知

学生书库保管员

购书单缺书单

教材采购与销售管理系统一层数据流图L1F1教材存量表

1

销售

2采购

书库保管员

学

生领书单购书通知进书通知

购书单

缺书单

F2缺书登记表

缺书汇总表教材采购与销售管理系统二层数据流图L2.11.1查库存1.2售书1.3申请采购

学生

购书单领书单缺书列表F1教材存量表F2缺书登记表到货书单进书通知缺书汇总表教材采购与销售管理系统二层数据流图L2.22.3进货进书通知F1教材库存量表2.1询价2.2订货订货价格F2缺书登记表缺书单

书库管理员进书通知进货单缺书汇总表4.2.3数据词典数据词典用于精确、严格地定义每一个与系统相关的数据元素（包括数据流、数据存储和数据项），并以字典式顺序将它们组织起来，使得用户和分析员有共同的理解。在数据词典的每一个词条中应包含以下信息：①名称：数据对象或控制项、数据存储或外部实体的名字。②别名或编号。③分类：数据对象？加工？数据流？数据文件？外部实体？控制项（事件∕状态）？④描述：描述内容或数据结构等。⑤何处使用：使用该词条（数据或控制项）的加工。⑥注释：数据量，峰值，限制，组织方式等

数据词典中的符号

符号含义解释

＝＋[...,...][...|...]{...}m{...}n(...)“...”..被定义为与或或重复重复可选基本数据元素连结符例如，x=a＋b，表示x由a和b组成。例如，x=[a,b]，x=[a|b]，表示x由a或由b组成。例如，x={a}，表示x由0个或多个a组成。例如，x=3{a}8，表示x中a出现3到8次。例如，x=(a)，表示a可在x中出现,也可不出现。例如，x=“a”，表示x为取值为a的数据元素。例如，x=1..9，表示x可取1到9之中的任一值。例如：类型：数据流条目名字：购书列表别名：购书单列表描述：对学生提供的购书单通过查库存将有库存的购书信息汇总形成的列表定义：购书列表={需书单位+书名+（刊号）+数量+（时限）+[学生用书|教师用书|图书馆用书]}类型：数据项条目名字：需书单位别名：购书单位描述：提供购书单的单位名称定义：20个汉字例如：类型：数据存储条目编号：F1名字：教材库存量表别名：描述：记录每种库存教材的库存数量定义：教材库存量表={书名+（刊号）+（版本）+数量}数据组织方式：按书名拼音顺序排列例如：4.2.4加工规格说明

加工规格说明用来说明DFD中的数据加工的加工细节，数据加工的输入，实现加工的算法以及产生的输出。另外，加工规格说明指明了加工（功能）的约束和限制，与加工相关的性能要求，以及影响加工的实现方式的设计约束。目前用于写加工规格说明的工具有结构化语言、判定表和判定树。结构化语言：类型：加工说明条目编号：2.1名字：询价别名：加工逻辑：首先根据购书通知逐个进行多方询价然后比较各种报价比较其他情况（有无现货，付款方式，是否送货等）综合评定供应商，确定订货价格输入数据：购书通知输出数据：订货价格触发条件：每当书库管理员发出购书通知执行发生频度：一般每周一次，最多每天一次判定树和判定表

判定树和判定表适于描述多个逻辑条件的组合描述。判定树根据判定条件的关系构造，内部节点为判定条件，叶子节点为判定结果。判定表的基本结构为：基本条件条件项基本动作动作项判定树和判定表

判定树和判定表

5UML与面向对象分析方法较早的软件开发，用结构程序设计方法。这种方法中程序的定律是：程序=（算法）+（数据结构）即过程（函数）是一个独立的整体，数据结构（包含数据类型与数据）也是一个独立的整体。两者分开设计，以算法（函数或过程）为主。voidmain(){

inta=1,b=2,c;c=max(a,b);}5.1结构化与面向对象结构化程序设计是一种面向过程的自顶向下的程序设计方法。BuildACarBuildChassisBuildEngineBuildDriveSystemAssemble…………结构化与面向对象结构化设计中模块和模块之间的关系，被紧紧局限于信息流，试图通过信息流及其转换来认识系统，这限制了对模块之间众多关系的表达和体现，如继承、依赖。main()buildD()buildE()buildC()assemble()…………结构化与面向对象流水线式的过程处理与人们日常处理问题的方式不一致。随着时间流逝，软件工程师越来越注重系统整体关系的表示和数据模型技术（把数据结构与过程看作一个独立功能模块）。程序定律被重新认识：

程序=（过程+数据结构）这样的思想符合现实世界中的事物特征，我们区分事务主要依靠就是事物各式各样的特征，包括事物不同的属性和特定的行为。集成化的软件开发方法--面向对象方法产生。结构化与面向对象在面向对象中，过程与数据结构被捆绑成一个对象，这样就不用为如何实现通盘的程序功能而费尽心机了。这时侯，程序定义变为：

对象=（过程+数据结构）程序=（对象+对象+...）也就是说，程序就是许多对象在计算机中相继表现自己。而对象又是一个个程序实体。结构化与面向对象

思考：请描述你到饭店就餐的情景！

结构化与面向对象5.2.1UML是什么统一建模语言UnifiedModelingLanguageUML是一个通用的可视化建模语言UnifiedModelingLanguage（统一建模语言）是对象管理组织（OMG）制定的一个通用的、可视化的建模语言标准，可以用来可视化（visualize）、描述（specify）、构造（construct）和文档化（document）软件密集型系统的各种工件（artifacts，又译制品）

5.2UML基础UML的历史BoochmethodOMTUnifiedMethod0.8OOSEOthermethodsUML0.9UML1.01989-1994期间，OO方法从不足10种增加到50多种UML1.1OOPSLA´95Web-June´96UMLpartnerspublicfeedback

2004FinalsubmissiontoOMG,Nov‘97FirstsubmissiontoOMG,Jan´97OMGAcceptance,Nov1997

Fall1998UML1.3UML2.0UML的创始人UML是由世界著名的面向对象技术专家G.Booch、J.Rumbaugh和I.Jacobson发起，在Booch方法、OMT方法和OOSE方法的基础上，广泛征求意见，集众家之长，几经修改而完成的。ThreeamigosBoochRumbaughJacobsonUML的特点统一了面向对象方法的表示表示能力强大，可用于各种软件系统建模，以及其它系统建模，如商业系统与开发过程无关允许扩展本身不设计特点语言的语法及规则，但可对应到各种OOP语言框架UML和OOA、OODUML既不是方法论，也不是一种开发过程，而是面向对象系统分析与设计的建模语言，是一种语言工具。如同英语充当国际交流的工具一样OOA&OOD是方法论，该方法论的实践过程中需要使用UML的图符，使用时还必须遵循一定的原则及步骤。5.2.2

UML结构UMLStructure构造块buildingblocks公共机制commonmechanisms构架architecture基本UML建模元素、关系和图达到特定目标的公共UML方法系统架构的UML视图UML模型元素模型元素是构成图片的最基本单位，一种模型元素通常有它主要出现的图类型，但同时可以用在不同的图中，但不论出现在哪里，一般表示相同的含义。通用机制一般用来表示注释、语义、约束等含义，不隶属于任何一种图，是所有图中通用的一些特殊模型元素。

UML模型元素依赖实现UML图形图diagrams类图classdiagrams对象图objectdiagrams构件图componentdiagrams部署图deploymentdiagrams用例图usecasediagrams顺序图sequence`diagrams协作图collaborationdiagrams状态图statechartdiagrams活动图activitydiagrams静态模型

(系统结构)动态模型

(系统行为)UML图形对整个系统而言：功能由用例图描述。静态结构由类图和对象图描述。动态行为由状态图、顺序图、协作图和活动图描述。物理架构则是由构件图和部署图描述。用例图UseCaseDiagram用例图定义了系统的功能需求，它完全是从系统的外部观看系统功能，并不描述系统内部对功能的具体实现。是从外部执行者的角度来描述系统提供的功能。购买货品归还货品出租货品报废货品店员类图ClassDiagram类图描述系统的静态结构，表示系统中的类以及类与类之间的关系。对象图ObjectDiagram对象图描述了一组对象以及它们之间的关系，表示类的对象实例。对象图是对类图一种实例化。是系统某个时期可能存在的具体对象实例。aLoan2：借书记录借书日期=2006-04-16应还日期=2006-06-16还书日期=2006-06-10aItem3：图书序号=003状态=租出aReader：读者编号=042440101姓名=张三……aLoan1：借书记录借书日期=2006-04-16应还日期=2006-06-16还书日期=2006-05-8aItem2：图书序号=001状态=在库aItem1：图书流水号=001状态=租出aTitle：图书品种索书号=TP21108馆藏数量=3可借数量=2…状态图StateChartDiagram状态图表示一个状态机，强调对象行为的事件顺序。是对类的补充，展示此类对象可能的状态和发生某些事件时其状态的转移情况。在馆内状态=在馆借出归还淘汰图书购买图书正常状态=借出超过期限借出超期通知读者顺序图SequenceDiagram&

协作图CollaborationDiagram顺序图和协作图均表示一组对象之间的动态协作关系，其中顺序图反映对象之间发送消息的时间顺序，协作图反映收发消息的对象的结构组织。顺序图和协作图是同构的，即两者之间可以相互转换。构件图ComponentDiagram构件图描述程序代码的组织结构。构件以及它们之间的依赖关系，表示系统的静态实现视图。CourseCourseOfferingStudentProfessorCourse.dllPeople.dllCourseUserRegister.exeBilling.exeBillingSystemUML2.0中的构件图部署图DeploymentDiagram部署图反映了系统中软件和硬件的物理架构，表示系统运行时的处理节点以及节点中构件的配置。瘦客户端Web服务器(HP6000)应用服务器(HP6000)数据库服务器(IBM7100)HTTPTCP/IPTCP/IP管理员客户端TCP/IP架构与视图软件架构（softwarearchiecture）也称之为软件体系结构，它是一组有关如下要素的重要决策：软件系统的组织，构成系统的结构化元素，接口和它们相互协作的行为的选择，结构化元素和行为元素组合成粒度更大的子系统的方式的选择，以及指导这一组织（元素及其接口、协作和组合方式）的架构风格的选择。IEEE：：架构是在组件及其彼此间和与环境间的关系引导设计发展原则中体现的系统的基本结构。4+1视图ProcessViewDeploymentViewLogicalViewUse-CaseViewImplementationViewEnd-userFunctionalityProgrammers

Softwaremanagement

PerformanceScalabilityThroughput

SystemintegratorsSystemtopology

Delivery,installationcommunicationSystemengineeringAnalysts/DesignersStructure

4+1视图UseCaseViewEnd-user:Functionality这些视图由用例视图所统一，它描述项目干系人（stakeholder）的需求；所有其他视图都是从用例视图派生而来，该视图把系统的基本需求捕获为用例并提供构造其他视图的基础LogicalViewAnalysts/Designers:Structure系统功能和关键抽象；描述问题域的关键抽象，作为类和对象的集合。重点是展示对象和类是如何组成系统、实现所需系统行为的。4+1视图ProcessViewSystemintegrators:Performance,Scalability,Throughput系统性能、可伸缩性和吞吐量；建模在我们系统中的可执行线程和进程作为活动类。其实，它是逻辑视图面向进程的变体，包含所有相同的制品。ImplementationViewProgrammers:SoftwareManagement系统组装和配置管理；对组成基于系统的物理代码的文件和构件进行建模。它同样展示出构件之间的依赖，展示一组构件的配置管理以定义系统的版本。DeploymentViewSystemengineering:SystemTopology,Delivery,Installation,Communication系统的拓扑结构、分布、移交和安装；建模把构件物理地部署到一组物理的、可计算节点上，如计算机和外设上。5.3面向对象的分析（OOA）面向对象的分析、设计和编程是彼此相联系又相区分的。面向对象的分析是相对于结构化分析方法而言，关注的是应用领域的对象建模。面向对象的分析也同样包括需求的导出、分析和确认等几个基本活动，但所用的分析方法与模型和传统的结构化方法不同。5.3.1需求导出工作流程目标描述需求导出确定系统做什么确定：系统与谁（参与者）互相作用系统必须支持什么行为（叫作用例）每个用例的详细的功能性需求非功能性需求需求导出工作流程访谈业务所属人获取高层的功能性需求

访谈项目干系人获得所有的功能性和非功能性需求

通过SRS文档确定项目约束和风险

通过SRS文档中的功能性需求创建项目词典

通过SRS文档创建初始用例图

业务所属者脑海中的模型项目干系人脑海中的模型愿景文档SRS访谈业务所属人获取高层的功能性需求

访谈项目干系人获得所有的功能性和非功能性需求

通过SRS文档确定项目约束和风险

通过SRS文档中的功能性需求创建项目词典

通过SRS文档创建初始用例图

业务所属者脑海中的模型项目干系人脑海中的模型愿景文档SRS

确定项目愿景

确定项目愿景如果要决定项目的愿景，则必须与项目的业务所属者访谈后决定高级别的功能需求。业务所属者指拥有项目的任何人。功能性需求是系统必须为某个角色所执行的操作。愿景访谈焦点愿景访谈需要注意以下方面：用于项目的商业案例。用于项目的功能需求。风险。约束。项目干系人。

捕获需求访谈业务所属人获取高层的功能性需求

访谈项目干系人获得所有的功能性和非功能性需求

通过SRS文档确定项目约束和风险

通过SRS文档中的功能性需求创建项目词典

通过SRS文档创建初始用例图

业务所属者脑海中的模型项目干系人脑海中的模型愿景文档SRS制定需求收集的计划需要：确定所有必须的需求的来源确定所有要访谈的项目干系人确定捕获需求的来源可以从多种来源获取系统需求，以下是主要的几种：访谈项目干系人观察用户的工作

分析和记录政策和过程分析现有的系统分析和记录输入输出创建SRS文档SRS文档记录软件系统的一系列需求SRS文档包括六部分：项目简介约束与假定风险功能性需求非功能性需求项目术语SRS文档应该详细，避免不清晰与缺乏焦点功能性需求功能性需求部分包括以下几部分：主要特性参与者用例应用用例详细需求用例部分用例部分提供了一个包括所有用例的优先级，唯一编号，以及描述的表格。例如：用例名称优先级编号描述管理预约E1这个用例使得BookingAgent可以创建、找回、更新或和删除预约和用户信息录入用户E2这个用例使得Receptionist可以录入一个顾客信息促销管理H7这个用例使得经理和建立促销和折扣信息事件管理H8这个用例使得事件调解人员可以创建、查询、更新和删除协商事件信息发送调查F12这个用例使得编程人员可以设置系统发送用户调查的时间应用部分应用部分提供了一个包括所有组成系统的独立应用表格。例如：应用名称描述/用例HotelApp这个可独立的应用实现了旅店管理或小事件处理的主要功能。

支持用例：E1，E2，E3，E6，H7，H8，F9，F10，F11，以及F12WebPresenceApp这个网络应用使得消费者可以自己查看旅店信息进行预约

支持用例：E4和E5KioskApp在每个酒店大厅里的小亭子里面都有这样一个应用系统

支持用例：F13详细需求部分详细需求部分是构成每一个用例的完整的详尽的功能性需求列表。每个功能性需求有一个基于用例编码的标识符。这个用例编码是优先级编号加上用例编号每一个功能性需求有一个描述例如：FR需求描述E1-1系统允许BookingAgent创建、查询、更新和删除一个预约。E1-2预约是指在一定时间内对一间或多间房间的预定。写一个详细的需求一个功能性的需求描述的一个重要要素是用单词“将会”，例如，“旅店预定系统将会允许一个预定代理新建，检索更新，但是不能删除一个用户。”为了更加详细。可以在下面范围内考虑：描绘一个用例的数据集或者需要；描绘系统中对象之间，活动之间的关联性；描绘能完成一个活动的所有策略。可追溯性的重要性详尽的功能性需求定义了系统必须执行的行为，贯穿其它的工作流（分析，设计，实现，测试）对于验证系统是否满足需求是非常重要的。用UML注释中的功能性需求编号标记满足需求的组件用源代码注释中的功能需求编号表示满足需求的代码块用测试计划中的功能需求编号表示是哪个测试验证了需求被满足写非功能性需求部分非功能性需求部分是按照系统质量分类的一个完整列表。每一个非功能性需求在一个用例的基础上给定一个标识每一个非功能性需求包含一个描述，例如：NFR需求描述E1-101根据历史信息表明，在B&B的property中大约每个月都有150个定单，而在比较繁忙的property中大约每个月都有1000个定单。因此，系统必须支持每个月至少1300个定单。E1-102HotelApp的图形用户界面必须在5秒内响应用户输入。可以在应用服务器上实现以消除网络的不稳定带来的影响。E1-103HotelApp必须支持每个property至少5个用户同时进行操作。写项目术语表SRS中的术语表应该包括：特定领域内的术语同义词技术术语软件开发术语

创建初始用例图访谈业务所属人获取高层的功能性需求

访谈项目干系人获得所有的功能性和非功能性需求

通过SRS文档确定项目约束和风险

通过SRS文档中的功能性需求创建项目词典

通过SRS文档创建初始用例图

业务所属者脑海中的模型项目干系人脑海中的模型愿景文档SRS用例图的必要性SRS是由一系列详细的需求组成的，是基于文本形式的。客户方干系人需要系统的一份整体视图。系统的用例组成了所有开发的基础。确定用例图的元素用例图是“表示了系统内的参与者与用例之间关系的一个图”（UMLv1.4specpageB-21）参与者（Actors）参与者就是代表与系统进行交互的角色这个图标代表了系统的human类型的参与者这个图标能代表参与者是一个外部系统这个图标代表激活用例的时间触发器用例（UseCases）一个用例封装了为达到某个成果的系统的主要行为用例是用椭圆形表达的，它内部的文字就是用例的标题用例编码能够被用在标题的前面，用来建立与SRS的对应关系一个用例描述了为实现某个有价值的成果，在参与者与系统之间进行的交互。系统边界“用例可选择附在一个长方形里表示系统内部的边界(UMLv1.4spec.page354)”系统的边界是随意的这个等价的用例图表示了一个透明的系统边界用例关联用例关联描述了“在用例中一个用户的参与。”一个参与者必须关联一个或者多个用例一个用例必须关联一个或者多个参与者它们之间的关联是用一条没有箭头的实线来表示的创建一个用例图创建和命名系统的边界长方形。确定所有从SRS中得到的系统的参与者。为每个参与者：用例为系统描述了所有高级的行为和有哪些参与者参与了这些行为中。创建一个用例图，主要有以下几个步骤：

在图中增加一个参与者的图标在每个参与者参与的图中增加用例画出参与者的用例关联例：HotelReservationSystem1）创建系统边界2）增加用户这个参与者和用例3）增加预约代理这个参与者4）增加了接待员这个参与者保存用例图用例图提供了SRS功能性需求部分的可视化表示法。保持SRS中的用例图能够促进保持两个成果物的同步。用例图的主要目的是为用户提供系统行为的简单视图。用例图能够放置在SRS中。用例场景尽可能详细的从来不包含有条件的陈述以相同的方法开始但拥有不同的结果不指明过多用户界面方面的细节显示成功的也显示不成功的结果（在不同的场景中）一个用例场景是一个用例的混合实例一个用例场景应该：用例场景驱动着几个其他的OOAD工作流程选择用例场景用例包括与参与者的复杂的交互作用。用例有几个潜在的失败点，例如系统或者数据库的外部的交互作用。为所有用例创建多个场景，将花费很多的时间。因此，可以通过下面的标准，选择合适的场景：下面是场景的两种类型：主要的场景用来记录成功的结果次要的场景用来记录失败的事件书写一个用例场景一个用例场景是一个故事：描述了一个参与者怎么使用系统和系统对参与者的动作给于了怎么样回应。拥有一个开始，一个过程和一个结果。用例场景举例开始：

MedocaSansumi,是theSantaCruzB&B的酒店前台，一边看着theHotelAppMain的银幕一边等着电话。电话从Ms.JaneGoogol打来，一个来自纽约的客户。Ms.Googol拿起电话说“你好，我是JaneGoogol，我想要为新年的前夜预定一间房间”。Medoca在HotelApp的主银幕上选择了“创建预定”。屏幕上显示出一个空预定。中间过程：

Medoca问到“你什么时候到达这里？”。Jane回答到“12月31日到，我想要住到1月5日。”Medoca输入了开始日期，并且问到“你想要预定什么类型的房子呢？”，“我将和我的丈夫一起到那，所以需要一个单独的并且有足够空间的，那个Blue房子有空的吗？”Jane问到。Medoca选择“single”在预定的表格中，完成了查找。系统给予了三种空房间的回应：Victoria,Blue和Queen。“是的，有空的”Medoca回答。Medoca选择了Bule房间，系统把它填入预定的表格中，然后做出“held”的预约记号。用例场景举例更多的中间过程：

Medoca向系统中输入Jane的全名。Ms.Googol是一个现有的客户，所以系统通过客户表单的数据在预约的表格中给出回应。“你想要今天就把这个预定确定下来吗？”Medoca问道。“是的”Jane说，“用我的VISA卡，卡号是：1111-2222-3333-4444。”Jane在Medoca把卡号输入进去以后暂停了。“截至日期是2007年7月。”Medoca输入这些信息，并且在系统上选择了“VerifyPayment（确认付款）”。五分钟后，系统给出了银行存款验证的回应。系统把预定的状态改成了“confirmed.”用例场景举例结束：

Medoca告诉Jane预约号（系统产生的），并且问道“我还能为您做什么？”，Jane回答没什么了，Medoca向Jane道谢并且再见。Medoca关闭了预约表格的窗口，系统返回到MainHotelApp的主屏幕上。用例场景举例保存用例场景用例场景比较长，通常是保存在从SRS中分离出来的文档中SRS应该建立对这些用例场景的文档的引用5.3.2需求分析（精化）工作流程目标描述需求导出确定系统做什么需求分析（精化）建立现有的业务流程模型确定：一个精化的用例图从存在的系统中抽取关键抽象，建立域模型（分析类）需求分析工作流程分析用例场景发现更多细节在分析的基础上精化用例图用活动图验证用例用CRC分析法确定关键抽象表述域模型中关键抽象之间的关系使用从用例场景中得到的对象图来验证域模型SRSUseCaseformCRC

精化用例分析用例场景发现更多细节在分析的基础上精化用例图用活动图验证用例用CRC分析法确定关键抽象表述域模型中关键抽象之间的关系使用从用例场景中得到的对象图来验证域模型SRSUseCaseformCRC分析用例创建一个用例表格。识别继承模式。识别用例依赖。用例表格用例表格用于记录单用例详细分析和用例场景表格要素描述用例标识和名称需求规约中定义的用例编号和名称描述一到两行关于用例目的的描述参与者列出可以使用此用例的所有相关的参与者优先级需求规约中定义的用例的优先级别（Essential,High-value,orFollow-on）风险用例的风险因素（按高、中、低分类）表格要素描述前置条件和假设用例被调用时的（系统）状态触发条件通知参与者用例应该被调用的条件主事件流组成此用例的用户动作的执行序列可选事件流任何可能发生的次要的操作和事件后置条件用例完成时系统应该所处的状态非功能性需求与用例相关的非功能性需求列表。可以是非功能性需求的概述，也可以是需求规约中的非功能性需求的编码列表用例表格创建用例表按照下面的步骤确定用例表中应填写的信息：1、依照SRS文档来填写数据。2、依据用例场景决定前置条件；3、依据用例场景决定触发条件；4、依据用例主要用例场景决定主事件流；5、依据用例次要用例场景决定可选事件流6、决定后置条件第一步—根据需求规约文档填写相关信息根据需求规约文档填写下列元素：用例标识和名称E1：预定房间描述此用例用于在房间出租中创建一个新的预约参与者主要：酒店前台次要：招待员、管理人员优先级基本的（Essential）非功能性需求E1-102(性能)E1-105(可扩展性)E1-108(可靠性)

第二步—根据用例场景确定前置条件一个好的用例场景应该在第一段就描述用例开始时系统的状态。它们就是前置条件：

SantaCruz的负责预约的酒店前台MedocaSansumi正耐心地等着电话，此刻旅店管理系统的主页面已经被打开。前置条件酒店前台正在等电话旅店管理系统的主页面已被打开第三步—根据用例场景确定触发条件用例场景还应该陈述参与者如何才能知道应该去启动一个特定的用例。

这时候，来自纽约的Ms.JaneGoogol打来了电话，Ms.JaneGoogol说“你好，我是Ms.JaneGoogol。我想为新年前夕预约房间”。触发条件消费者打来电话要求预定第四步—根据主要用例场景确定主事件流根据主要用例场景确定主事件流。

Medoca：“你什么时候入住？”。Jane：“12月31日，我会一直住到1月5日”。Medoca在表格中输入日期。Medoca：“你想要什么类型的房间？”。Jane：“我和我丈夫住一块，所以一间单人房就足够了。还有没有雅间？”Medoca在定单表中选择“单人房间”并做查询。主事件流……接待员输入查询条件接待员查询房间安排表以确定可用房间系统显示在指定范围内的可用房间接待员选择一个房间……第五步—根据次要用例场景确定可选事件流根据次要用例场景确定可选事件流。在主要场景和每一个次要场景之间按顺序做差异分析。可选事件流就是主要场景和次要场景中不同的那些步骤。可选事件流在第5步中，如果没有房间可用，预约代理会提示消费者选择不同类型或者不同日期的房间，返回到第3步第六步—决定后置条件一个好的用例场景应该在最后一段描述用例结束时系统的状态。它们就是后置条件。

Medoca把系统提供的预约编号告诉Jane：“你还需要什么帮助吗？” Jane：“没有了。”

Medoca向她表示感谢并挂断电话。 Medoca关闭预约窗口，返回旅店管理系统MainHotelApp主页面。后置条件预约被存入数据库，预约单窗口被关闭，系统回到主界面展开高级用例一些在需求捕获阶段获取的用例太高级。这种情况下就要引入新的用例来分解工作流。一般情况下，管理实体意味着可以创建、（重获）、更新、和删除一个实体（所以称为，CRUD操作）。还有其他一些关键词：维护处理此外，也可能存在其他类型的高级用例。可以通过分析用例场景以及寻找其他有意义的分支流程来确定。同样地，如果几个场景有不同的起点，这些场景可能代表着不同的用例。展开高级用例展开高级用例优化前的用例图：展开高级用例展开版本产生了更多的联系：分析继承模式

用例图中，参与者之间以及用例之间都可能存在继承关系。一个参与者可以继承父参与者的所有用例关系。一个用例可以派生出多个特殊化的用例。参与者继承一个参与者可以继承父参与者的所有用例关系：用例的特殊化一个用例可以派生出多个特殊化的用例：用例特殊化通常由用例场景的多样性来决定。分析用例依赖用例可以以两种方式依赖于其他用例：一个用例（a）包含（include）另外一个用例（b）。 用例a需要用例b的功能并且总是执行这个内含的用例。一个用例（a）扩展（extend）另外一个用例（b）。

用例a可能（可选择的）用到用例b的功能，于是去扩展用例b。<<include>>依赖包含依赖可以使你能够把多个用例共同的行为识别出来。确定和记录系统的通用行为。回顾用例场景找到通用行为。给这个通用的行为取一个名字并在用例图中绘制出包含关系。<<include>>依赖<<include>>依赖确定和记录与外部系统交互的行为。回顾用例场景找出与外部系统有关的行为序列。给这个行为取一个名字并在用例图中绘制出包含关系。<<extend>>依赖<<extend>>依赖使你找出那些不属于主事件流，而是可选场景中的系统行为。<<extend>>依赖识别和记录与用例可选事件流有关的行为。回顾用例场景找出重要的行为序列。给这个行为取一个名字并在用例图中绘制出扩展关系一个旅店预约系统的组合实例如何使用活动图？在活动图中描绘用例的主事件流。通过项目干系人对活动图的评论来验证用例。活