??xml version="1.0" encoding="utf-8" standalone="yes"?> 目标Q?》定义系l操?》ؓpȝ操作创徏契约 ?nbsp; 在UP中,用例和系l特性是用来描述pȝ行ؓ的主要方式,q且以满要求。有旉要对pȝ行ؓq行更ؓ详细和精的描述。操作契U用前|和后置条g的Ş式,描述领域模型里对象的详细变化Qƈ作ؓpȝ操作的结果。领域模型是最常用的OOA模型Q但是操作契U和状态模型也能够作ؓ有用的与OOA相关的制品?操作契约可以视ؓUP用例模型的一部分Q因为它对用例指出的pȝ操作的效用提供了更详l的分析。图11-1所C的UP制品的相互媄响强调了操作契约。该契约的主要输入时SSD中确定的pȝ操作、领域模型和领域专家的见解。该契约也可以作为对象设计的输入Q因Z们描q的变化很可能是软g对象或数据库所需要的? CZ 下面l出的是pȝ操作enterItem的操作契U。其中的关键元素是后|条Ӟ其他部分虽然有用但重要性稍低? 契约CO2:enterItem 操作Q?/font>enterItem(itemID:ItemID,quantity:integer) 交叉引用Q?/font>用例 : 处理销? 前置条gQ?/font>正在q行的销? 后置条gQ?/font>1》创ZSalesLineItem的实例sli(创徏实例)?》sli与当前Sale兌QŞ成关联)3》sli.quantity赋gؓquantityQ修改属性)4》基于itemID的匹配,sli兌到ProductDescriptionQŞ成关联) “Q创建实例)”q样的分cLZ帮助学习Qƈ不是契约的有效部分? 定义Q契U有哪些部分 下面对契U中的每个部分进行了描述Q? 操作Q?/font>操作的名U和参数 交叉引用Q?/font>会发生此操作的用? 前置条gQ?/font>执行操作之前Q对pȝ或领域模型对象状态的重要假设。这些假设比较重要,应该告诉读者? 后者条Ӟ最重要的部分。完成操作后Q领域模型对象的状态。后l章节将详细描述q个问题? 定义Q什么是pȝ操作 可以?font color="#cc0000">pȝ操作定义操作契约Q系l操作时作ؓ黑盒构g的系l在其公共接口中提供的操作。系l操作可以在l制SSD草图时确定,如图11-2。更_地讲QSSD展示?font color="#cc0000">pȝ事gQ即涉及pȝ的事件或I/O消息。输入的pȝ事g意味着pȝh用来处理事g的系l操作,正如OO消息Q一U事件或信号Q要由O(jin)OҎ(gu)Q一U操作)来处理那栗?涉及所有用例的pȝ操作的完整集合将pȝ视ؓ一个构件或c,定义了公qpȝ接口。在UML中,作ؓ整体的系l可以表C成名称为(例如QSystem的类的一个对象? 定义Q后|条?nbsp; 后置条gQpostconditionQ描qC领域模型内对象状态的变化。领域模型状态变化包括创建实例、Ş成或消除兌以及改变属性?nbsp; 后置条g不是在操作过E中执行的活?/font>Q相反,它们是对领域模型对象的观察结果,当操作完成后Q这些结果ؓ真,像烟散去后所能够清晰看到的事物?nbsp; 概括说来Q后|条件可以分Z下三U类型:Q?》创建或删除实例 2》属性值的变化 3》Ş成或消除兌Q精地Ԍ是UML链接Q?/font>Q。消除关联比较少见。删除实例的后置条g也十分少见,因ؓZ通常不会兛_明确强制销毁现实世界中的事物? 后置条g如何与领域模型相?/font> q些后置条g主要是在领域模型对象的语境中表示的。可以创Z么实例?Q来自于领域模型Q可以Ş成什么关联?Q来自于领域模型Q,{等? 动机Qؓ什么需要后|条?/font> 首先Q后|条件ƈ不L必要的。在大多数情况下Q系l操作的效果对开发者而言是相Ҏ(gu)晰的Q他们可以通过阅读用例、与专家交流或根据自q知识Ҏ(gu)q行理解。但有时需要更详细和精的描述。契U正提供了此cLq。注意,后置条g支持l粒度的l节和精性,以声明操作必d备的l果。在用例中也可以表示U详l别,但ƈ不适宜Q因于冗长和详细。契U是优秀的需求分析或OOA工具Q能够详l描q系l操作(领域模型对象而言Q所需的变化,而不需描述q些操作是如何完成的。换a之,设计可以被gq,我们可以重点分析必须发生的事物,而不是如何实现这些事物? 准则Q如何编写后|条?/font> 用过L态表辑|条Ӟ以强调它们是由操作引L状态变化的观察l果Q而不是发生的zd。这也是后置条g名称的由来!例如 Q较好)创徏了SalesLineItem 而不?font color="#cc0000"> Q较差)创徏SalesLineItem或SalesLineItem被创建? 准则Q后|条件因该完善到何种E度Q敏捷与重量U分? 契约有可能是无用的。这一问题在后箋章节中讨论。但是假讑֥U有用,则ؓ所有系l操作生成完整详l的后置条g集合是不可能的,或是没有必要的。就敏捷建模的本质而言Q只是将其视为初始最佳的猜测Q在q种理解下,详尽的后|条件是无法完成的,而所?#8220;完善”的规D明也是几乎不可能的或不可信的。但是要理解Q进行轻量的分析是现实和有效的,qƈ不是意味着要在~程前放弃Q何调查,q又是另一U极端的误解? CZQenterItem的后|条?nbsp; 以下内容剖析了enterItempȝ操作后置条g的动机? 创徏和删除实?nbsp; 输入itemID和商品项目的quantity后,会创建哪些新对象QSalesLineItem。因此: 注意对实例的命名。该名字化了在其他后|条件语句中对该新实例的引用? 属性修?nbsp; 在收银员输入商品目标识和对应的商品数量后,应该修改了哪些新对象或现有对象的属性?SalesLineItem的quantity应该变ؓ{于quantity参数。因? 准则Q是否应该更新领域模?/font> 通常在创建契U的q程中会发现Q需要在领域模型中记录新的概늱、属性或兌。不要局限于先前定义的领域模型,当你在思考操作契U过E中有新发现Ӟ要对领域模型q行改进?font color="#cc0000">在P代和q化式方法中Qƈ且反映了软g目的真是情况)Q所有分析和设计制品都不是完善的Q要Ҏ(gu)新发现对其改q?/font>? 准则Q契U在何时有效 在UP中,用例是项目需求的主要知识库。用例可以ؓ设计提供大部分或全部所需l节。这U情况下Q契U就没有什么作用。但有时对于用例而言Q所需状态变化的l节和复杂性难以处理或q于l节化。如果开发者在没有操作契约的情况下Q能够准地理解所需要完成的工作Q则可以不编写契U? 准则Q如何创建和~写契约 创徏契约时可以应用以下指|1》从SSD中确定系l操作?》如果系l操作复杂,其结果可能不明显Q或者在用例中不清楚Q则可以为其构造契U?》用以下几U类别来描述后置条gQ?》创建和删除实例?2》修改属?3》Ş成清除关联? ~写契约 最常见的错? 最常见的问题是遗漏了关联的形成。特别是当创Z新实例时Q通常需要徏立与若干对象的关联。不要遗忘这一点! 应用UMLQ操作、契U和OCL UML正式地定义了操作QoperationQ。引证如下:操作是可以调用对象执行的转换或查询的规格说明。例如,在UML中,接口元素是操作。操作是抽象而非实现。相比之下,Ҏ(gu)是操作的实现。引证如下:操作的实现。它规定了与操作兌的算法或q程。在UML元模型中Q操作具?font color="#990099">特征标记Q在q种语境中最为重要的是,与一lUMLU束对象兌Q这些对象被分类为指定操作语义的前置条g和后|条件。概括一下,UML通过U束定义操作的语义,q些U束可以用前|或后置的Ş式指定。要注意Q本章强调UML操作的规D明不能表C算法或解决Ҏ(gu)Q而只能是状态的变化或操作的效果。契U除了用于指定整个SystemQ也是_pȝ操作Q的公共操作外,q能够用于Q何粒度的操作Q子pȝ的公共操作(或接口)、构件、抽象类{。例如,可以为Stackq样的单个Y件类定义操作。本章讨论的_粒度操作属于将整个pȝ作ؓ黑盒构g的Systemc,但是UML操作可以属于McL接口Q它们都h前置和后|条件? 用OCL表示的操作契U? 本章中的前置后后|条件的格式是非正式的自然语a格式Q完全可以被UML接受Qƈ易于理解。但UMLq具有正式、严谨的语言Q成为对象约束语aQOCLQ,OCL可以用来表示UML操作的约束?font color="#cc0000">准则Q除非有不可避免的实际原因要求h们学习和使用OCLQ否则要保持单ƈ使用自然语言。尽我信存在真实Q且有效Q的应用Q但我从未见q用OCL的项目,即便我调查了大量客户和项?/font>? q程QUP的操作契U?nbsp; 前置和后|条件契U式UML指定操作的常用风根{在UML中,操作在许多别中存在Q从System到细_度的类。系l别的操作契约式用例模型的一部分Q尽原始的RUP或UP文中ƈ没有正式地强调这一炏VRUP作者证实了用例模型中包括操作契U? 阶段 初始--初始阶段不会引入契约Q因于详l? l化--如果使用契约的话Q大部分契约在l化阶段q行~写Q这时已l编写了大部分用例。只Ҏ(gu)复杂和微妙的pȝ操作~写契约? 目标Q?1》确定系l事?nbsp; 2》ؓ用例场景创徏pȝ序? ?/font> pȝ序图(SSDQ是为阐qC所讨论pȝ相关的输入和输出事g而快速、简单地创徏的制品。它们是操作契约和(最重要的)对象设计的输入。UML包含以顺序图为Ş式的表示法,用以阐述外部参与者到pȝ的事?font color="#cc0000">。图10-1中所C的是强调系l顺序图的UP制品的相互媄响。用例文本及其所C的pȝ事g是创建SSD的输入。SSD中的操作可以在操作契U中q行分析Q在词汇表中被详l描qͼq且Q最重要的是Q作计协作对象的L? CZQNextGen SSD 对于用例中一pd特定事gQSSD展示了直接与pȝ交互的外部参与者、系l(作ؓ黑盒Q以及由参与者发Lpȝ事gQ?font color="#cc0000">如图10-2所C)? 什么是pȝ序?nbsp; 用例描述外部参与者是如何与我们所希望创徏的系l进行交互的。在交互中,参与者对pȝ发vpȝ事g(system event)Q通常需要某些系l操?system operation)对这些事件加以处理?nbsp; UML包含了顺序图作ؓ表示法,以便能够阐述参与者的交互及参与者引发的操作?nbsp; pȝ序图表C的是,对于用例的一个特定场景,外部参与者生的事gQ其序和系l之内的事g。所有系l被视ؓ黑盒Q该囑ּ调的是从参与者到pȝ的跨系l边界的事g?font color="#0000cc">准则Q应为每个用例的L功场景,以及频繁发生的或者复杂的替代场景l制SSD?/font> 动机Qؓ什么绘制SSD 基本上,软gpȝ要对以下三种事gq行响应Q?Q来自于参与者(人或计算机)的外部事Ӟ2Q时间事Ӟ3Q错误或异常Q通常源于外部Q。因此,需要准地知道Q什么是外部输入的事Ӟ即系l事件。这些事件是pȝ行ؓ分析的重要部分? 在对软g应用如何工作进行详l设计之前,最好将其行Z?#8220;黑盒”来调查和定义pȝ行ؓ(system behavior)描述的是pȝ做什么,而无需解释如何做。这U描q的一部分是pȝ序图。其他部分包括用例和pȝ操作契约Q稍后进行讨论)? 应用UMLQ顺序图 UML没有定义所谓的“pȝ”序图,而只是定义了“序?#8221;。这一限定?yu)系l的应用视ؓ黑盒。之后,我们会在另一语境下用顺序图Q阐q完成工作的交互软g对象的设计?font color="#0000cc">序图中的@?/font> 注意?font color="#cc0000">?0-2中是如何使用交互?interaction frame)来表C顺序图中的循环的? SSD和用例之间的关系 SSD展示了用例中一个场景的pȝ事gQ因此它是从对用例的考察中生的Q?font color="#cc0000">参见?0-3Q?font color="#0000cc">应用UMLQ是否应该在SSD中显C用例文? 通常不这么做。如果你为SSD适当地命名,可以指明对应用的用例? 如何为系l事件和操作命名 pȝ事g应该在意囄抽象U别而非物理的输入设备别来表达?font color="#cc0000">如图10-4所C,pȝ事g的名UC动词开始(增加......Q输?.....Q结?.....Q?.....Q,可以提高清晰E度Q因样可以强调这些事件是命o或请求? 如何为涉及其他外部系l的SSD建模 SSD也同样可以用来阐q系l之间的协作Q但q个问题我们会在案例研究的猴戏P代中讨论Q因ơP代不包括q程pȝ协作? SSD的哪些信息要攑օ词汇表中 SSD中所C的元素Q操作名U、参数、返回的数据Q是z的。需要对q些元素加以适当的解释以便在设计时能够明地知道输入了什么,输出了什么。词汇表是详l描q这些元素的最佳选择? 准则Q对大多数制品来_一般在词汇表中描述其细节?/font> CZQMonopoly SSD 参见?0-5? q程QP代和q化式SSD 不用为所有场景创建SSDQ除非你在用需识别所有系l操作的预算技术(例如功能点计敎ͼ。相反,只需ZơP代所用的场景l制SSD。同Ӟ不应该花费太长时间来l制SSDQ用几分钟或半小时来l制卛_。当需要了解现有系l的接口和协作时Q或者将其架构记录在文ӞSSD也是十分有效的?font color="#0000cc"> UP中的SSD SSD是用例模型的一部分Q将用例场景隐含的交互可视化。尽UP的创们意识到ƈ理解q些囄用途,但最初的UP描述中ƈ没有直接提到SSD。有大量可能有用和广泛用的分析和设计制品或zdq没有在UP或RUP文中提及,SSD是其中之一。但是UP十分灉|Q提倡引入Q何能够增加h(hun)值的制品和实c?font color="#0000cc"> UP阶段 初始--通常不会在该阶段引入SSDQ除非你要对涉及的技术进行粗略的估算Q不要指望初始阶D늚估算是可靠的Q,q种估算的基是对pȝ操作的识别? l化--大部分SSD在细化阶D创建,q有利于识别pȝ事g的细节以便明系l必被设计和处理的操作Q有利于~写pȝ操作契约Qƈ且可能有利于对估的支持?nbsp; 目标 1》确定与当前q代相关的概늱 2》创建初始的领域模型 3》ؓ模型建立适当的属性和兌? ?nbsp; 领域模型是OO分析中最重要的和l典的模型。它阐述了领域中的重要概c领域模型可以作计某些Y件对象的灉|来源Q也作为在案例研究中所探讨的几个制品的输入。本章还展CUML表示法上OOA/D知识的h(hun)倹{基本表C法非常Ҏ(gu)Q但是对于有用模型的一些深奥的建模准则Q则需要数周或数月才能掌握? 和敏捷徏模和UP_中的所有事物一P领域模型也是可选制品。在?-1中所C的UP制品怺影响力中了领域模型。领域模型的范围限定于当前P代所开发的用例场景Q领域模型能够被不断地演q用以展C相关的重要概念。相关的用例概念和专家的观点作为创建领域模型的输入。反q来Q该模型又会影响操作契约、词汇表和设计模型,其是设计模型中领域?domain layer)的Y件对象? CZ ?-2展示了以UMLcd(class diagram)表示法绘制的部分领域模型。对领域模型应用UMLcd表示法会产生概念透视?conceptual perspective)模型?定一l概늱是OO分析的核心。如果能够通过熟练和快?是_每次早期q代不超q几个小?的调查来完成q项工作Q那么通常会在设计q程中得到回报,因ؓ领域模型能够支持更好的理解和沟通?font color="#3300ff">准则Q避免瀑布思维們Qؓ完成详尽?#8220;正确”的领域模型而进行大量徏模工作。这些方式都应避免,q且q种q量的徏模工作反而会D分析停滞Q这U调查几乎不会有什么回报?/font> 什么是领域模型 q一_N的面向对象分析步骤是从领域到重要概念或对象的分解?font color="#0000cc">领域模型(domain model)是对领域cL现实世界中对象的可视化表C。领域模型也UCؓ概念模型、领域对象模型和分析对象模型?font color="#0000cc">定义Q在UP中,术语"领域模型"指的是对现实世界概念cȝ表示Q而非软g对象的表C。该术语q不是指用来描述软gcRY件架构领域层或有职责软g对象的一l图。UP寚w域模型的定义是,可以在业务徏模科目中创徏的制品之一。更准确地讲QUP领域模型是UP业务对象模型(BOM)的特化,“专用于解释业务领域中重要?#8216;事物’和?#8221;也就是说Q领域模型专注于特定领域。更为广泛的BOM是扩展的、通常十分庞大和难以创建的多领域模型,BOM覆盖整个业务及其所有子域,本章q不늛q部分内容,q且也不提倡创建BOMQ因为需要在是实现前q行大量建模Q? 应用UML表示法,领域模型被描qCؓ一l没有定义操作(Ҏ(gu)的特征标讎ͼ的类?Qclass diagramQ。它提供了概念透视图。它可以展示Q? 定义Qؓ什么把领域模型UCؓ“可视化字?#8221; 请仔l观察图9-2.看看它是如何寚w域词汇或概念q行可视化和兌的。领域模型还昄了概늱的抽象。因U抽象可以表辑օ他大量事物,例如登陆、销售等? 领域模型Q用UML表示法)描述的信息也可以采用U文本方式(UP词汇表)表示。但是在可视化预a中更Ҏ(gu)理解q些术语Q特别是它们之间的关p,因ؓ我们的思维更擅长理解Ş象的元素和线条连接。因此,领域模型是可视化字典Q表C领域的重要抽象、领域词汇和领域的内容信息? 定义Q领域模型是软g业务对象囑 如图9-3所C,UP领域模型是对所x的现实世界领域中事物的可视化Q而不是诸如Java或C#cȝ软g对象Q或有职责Y件对象(参见?-4Q。因此以下元素不适用于领域模型: 定义Q?#8220;领域模型”的两个传l含? 在UP及本章中“领域模型”是现实世界中对象的概念透视图,而非软g透视图。但q一术语是多义的Q也用来表示“软g对象领的领域?#8221;也就是说Q在表示层或UI层之下的软g对象层是?font color="#3300ff">领域对象(domain object)l成?-领域对象是表C问题领域空间事物的软g对象Qƈ且与“业务逻辑”?#8220;领域逻辑”Ҏ(gu)相关。我通常会?font color="#3300ff">领域?domain layer)来表C领域模型针对Y件的W二个含义,因ؓ领域层也十分通用? 定义Q什么概늱 领域模型阐述领域中的概念cL词汇。概늱是思想、事物或对象。更正式的讲Q概늱可以从其W号、内涵和外g来考虑? 定义Q领域模型和数据模型是一回事?nbsp; 领域模型不是数据模型Q通过Ҏ(gu)据模型的定义来表C存储于某处的持久性数据)Q所以在领域模型里,q不会排除需求中没有明确要求记录其相关信息的c(q是对关pL据库q行数据建模的常见标准,但与领域建模无关Q,也不会排除没有属性的概念cR例如,没有属性的概念cL合法的,或者在领域内充当纯行ؓ角色而不是信息角色的概念cM是有效的? 动机Qؓ什么要创徏领域模型 领域模型和领域层使用怼的命名可以减Y件表CZ我们头脑中的领域模型之间的差异?nbsp; 动机Q降低与OO建模之间的表C差? q是OO的关键思想Q领域层软gcȝ名称要源于领域模型中的名Uͼ以对象h源于领域的信息和职责?font color="#cc0000">?-6阐述了这一思想。这样可?strong>减少我们的思维与Y件模型之间的表示差异。同事,qƈ非只是哲学上的考究--Ҏ(gu)间与金钱也会有实际的影响? 准则Q如何创建领域模? 1、寻找概늱 2、将其绘制ؓUMLcd中的c?3、添加关联和属? 准则Q如何找到概늱 既然领域模型表示的是概念c,那么关键问题是如何才能找到概늱?font color="#0000cc">扑ֈ概念cȝ三条{略 1、重用和修改现有的模型。这是首要、最佳且最单的Ҏ(gu)Q如果条件许可,通常从这一步开始。在许多常见领域中都存已发布的、绘制精l的领域模型和数据模型(可以修改为领域模型)Q这些领域包括库存、金融、卫生等{。我所参考的书籍包括Martin Fowler的《分析模式?Analysis Patterns)、David hay的Data Model Patterns和Len Silverston的Data Model Resource Book(?和卷2) 2、用分cd?nbsp; 3、确定名词短?nbsp; 重用现有的模型是最好的办法Q但出了本书的范围。第二个Ҏ(gu)Q用分cd表)也很有效?nbsp; Ҏ(gu)2Q用分cd? 我们可以通过制作概念cd选列表来开始创建领域模型?font color="#cc0000">参看?-1? Ҏ(gu)3Q通过识别名词短语L概念c? 在【Abbot83】中所的另一U有?因ؓ?技术是语言分析(linguistic analysis)Q即在对领域的文本性描qC识别名词和名词短语,其作ؓ候选的概念cL属性?nbsp; 准则Q用这U方法时必须心。不可能存在名词到类的映机Ӟq且自然语言中的词语h二义?/font>。领域模型是重要领域概念和词汇的可视化。那么从哪里扑ֈq些术语Q其中某些术语来源于用例。另外一些术语则源于其他文Q或是专家的x。无论如何,用例都是挖掘名词短语的重要来源之一? CZQ寻扑֒描绘概念c? 参见?-7 ?-8 准则Q敏捷徏?-l制cd的草? 注意?-8?/font>UMLcd的这U草N|让类框的底部和右侧呈开发状态。这样可以在发现新元素时对类方便地进行扩展? 准则Q敏捷徏?-是否要用工L护模?/strong> 敏捷模型在创建后通常很快p抛弃了(即ɘq样Q如果你使用白板的话Q我q是用数据相机拍下来Q。基于这U观点,则没有理由去l护或更新这些模型。但是这也不意味着更新模型是错的。通常Q进化的软g领域层对大部分重要术语会l予提示Q而且长生命期的OO分析领域模型不会增加价倹{? 准则Q报表对?-模型中是否要包括“据”
准则Q像地图l制者一h考;使用领域术语 地图l制者的{略既可用于地图Q也可以用于领域模型?font color="#cc0000">准则Q?以地囄制者的工作思维创徏领域模型Q?》用地域中现有的名U?2》排除无x出范围的特?3》不用凭I增加事?/font> 准则Q如何对非现实世界徏?/strong> 有些软gpȝ的领域与自然领域或业务领域几乎没有类g处,例如?sh)信软g。然而还是有可能些领域创建领域模型。此旉要高度的抽象Q对常见的非OO设计q行回归Qƈ且认真吸取领域专家所使用的核心词汇和概念? 准则Q属性与cȝ常见错误 在创建领域模型时最常见的错误是Q把应该是概늱的事物表CZؓ属性? 准则Q如果我们认为某概念cX不是现实世界中的数字或文本,那么X可能是概늱而不是属性?/font> 准则Q何时?#8220;描述”cd?/strong> 描述c(description classQ?/font>包含描述其他事物的信息。在[Coad92]中,q种c通常被命名ؓ目-描述W?/font>模式?font color="#cc0000">?-9 准则Q何旉要描q类 在以下情况下需要增加描q类Q例如,ProductDescriptionQ? ?-10 兌 扑ֈq表C出兌是有助的Q这些关联能够满_前所开发场景的信息需求,q且有助于理解领域?font color="#0000cc">兌QassociationQ是c(更精地_是这些类的实例)之间的关p,表示有意义和值得兌的连接(?-11Q?/font>在UML中,兌被定义ؓ“两个或多个类元之间的语义联系Q涉及这些类元实例之间的q接”? 准则Q何时表C关?/font> 兌表示了需要持l一D|间的关系Q根据语境,可能是几毫秒或数q。换a之,我们需要记录哪些对象之间的关系Q?׃领域模型是从概念角度出发的,所以是否需要记录关联,要基于现实世界的需要,而不是基于Y件的需要,管在实现过E中Q会有出现大量对兌的需要?font color="#cc0000">?-11兌? 准则Q在领域模型中要考虑如下兌Q?/font>1》如果存在需要保持一D|间的关系Q将q种语义表示为关联(“需要记?#8221;的关联)2》从常见兌列表中派生的兌? 准则Qؓ什么应该避免加入大量关?/font> 在具有n个节点的图中Q节炚w?n*(n-1))/2个关联,q可能是个非常大的数倹{连U太多会产生“视觉q扰”Q囑֏的乱,所以要谨慎地增加关联线。用本章准则所的标准,q且重点x“需要记?#8221;的关联? 观点Q关联是否会在Y件中实现 在领域徏模过E中Q关联不是关于数据流、数据库外键联系、实例变量或软gҎ(gu)中的对象q接语句Q关联声明的是针对现实领域从U概念角度看有意义的关系。也是_q些关系的大部分作为(设计模型和数据模型中的)D和可见性\径在软g中加以实现。但是,领域模型不是数据模型Q添加关联是ZH出我们寚w要关pȝ大致理解Q而非记录对象或数据的l构? 应用UMLQ关联表C法 兌被表CZؓcM间的q线Qƈ冠以首字母大写的兌名称?font color="#cc0033">见图9-12?font color="#cc0033">警告Q阅d向箭头对模型来说q不h特别意义Q只是对阅读囄人有所帮助? 准则Q在UML中如何对兌命名 ?#8220;cd-动词短语-cd”的格式ؓ兌命名Q其中的动词短语构成了可ȝ和有意义的顺序。诸?#8220;拥有”?#8220;使用”q样单关联名U通常是拙劣的Q因U名UC会增强我们对领域的理解。关联名U应该用首字母大写的Ş式,因ؓ兌表示的是实例之间链接的类元。在UML中,cd应该首字母大写。以下是复合性关联名U的两种常见q且{h(hun)的合法格式:1》Records-current 2》RecordsCurrent 应用UMLQ角?/font> 兌的每一端称?role)。角色具有如下可选项Q?1》多重性表辑ּ 2》名U?3》导?多重性将在后面讨论? 应用UMLQ多重? 多重?multiplicity)定义了类A有多个实例可以和类B的一个实例关联(见图9-13Q。在?-14中将l出一些多重性表辑ּ的例子。多重性的DC在特定时刻Q而不是某个时间跨度内Q有效关联的实例数量。多重性的值和建模者和软g开发者的x角度有关Q因为它表达了将要(或可能)在Y件中反映的领域约束?font color="#cc0000">见图9-15. 应用UMLQ两个类之间的多重关?nbsp; 在UMLcd中,两个cM间可能会有多重关联,qƈ不罕?font color="#cc0000">见图9-16? 准则Q如何在常见兌列表中找到关?nbsp; 通过使用?-2中的列表来开始添加关联。该列表中包含值得考虑的常见类别,对业务系l而言更是如此? CZQ领域模型中的关? 参见?-17和图9-18? 属?nbsp; 定概念cȝ属性是有助的,能够满当前所开发场景的信息需求。属?attribute)是对象的逻辑数据倹{? 准则Q何时展C属?/font> 当需求(例如Q用例)或暗C需要记住信息时Q引入属性? 应用UMLQ属性表C法 属性在cL囄W二g表示Q?font color="#cc0000">参见?-19Q。其cd和其他信息是可选的。在UML中,属性的完整语法是: visibility name:type multiplicity = default {property-string}Q对该表辑ּ译ؓ中文是: 可见?nbsp; 名称Q类?nbsp; 多重?默认?{Ҏ(gu)表} 参见?-20。依照惯例,大部分徏模者会假设属性的可见性ؓU有的(-Q,除非有另外表C,所以我通常不会昑ּ地标出可见性符受?nbsp; {readOnly}大概是属性的{property-string}部分最常用的倹{?nbsp; 多重性用来指C可能出现的|或者可以填充到Q集合)属性中的对象数量。例如,许多领域要求知道某h的名和姓Q但是中名是可选的。表辑ּmiddleName:[0..1]表示可选|该属性可以出??个倹{?font color="#0000cc">准则Q在哪里记录属性需?/font> 有些建模者认可只在领域模型中保留q种规格说明Q但是我发现q是一U错误們Qƈ且被扩散了,因ؓZ往往不去仔细查看领域模型或需求指对{h们也通常不会l护领域模型? 我徏议把所有这U属性需求置于UP词汇表(UP词汇表可充当数据字典Q。可能我已经p了一个小时和领域专家一L出领域模型的草图Q之后,我可以花?5分钟览q个草图q将其中表示的属性需求{Ud词汇表中。另一U方法是Q用工具将UML模型和数据字典统一hQ这h有属性会自动昄为数据字典的元素? 导出属?/font> Sale中的total属性可以从SalesLineItems中的信息计算或导出。当我们需要表达:q是重要属性,但是导出的,那么可以使用UML的约定:在属性名U前加以"/"W号?攉员输入的数量可以被记录ؓSalesLineItem的属性(参见?-21Q。但该数量可以从兌的多重性的实际D出来,所以被表示为导出属性,卛_以由其他信息导出的属性? 准则Q什么样的属性类型是适当?/font> x领域模型中的数据cd属?/font> 通俗的说Q大部分属性类型应该是“?#8221;数据cdQ例如数字和布尔。通常Q属性的cd不应该是复杂的领域概念,例如Sale或Airport?font color="#cc0000">?-22中CashiercȝcurrentRegister属性是不合适的Q因为其cd是RegisterQƈ不是单数据类型(例如Number或StringQ。表达Cashier使用Register的最有效的做法是使用兌Q而不是用属性? 准则 领域模型中属性的cd更应该是数据cd(data type)。十分常见的数据cd包括QBoolean,DateQ或DateTimeQ、Number、Character、String(Text)和Time。其他常见的cdq有Address、Color、Geometrics(Point、Rectangle)、Phone Number、Social Security、Number、Universal Product Code(UPC)、SKU、ZIP或者是邮政~码、枚丄?/font>? 准则Q通过兌而不是属性来表示概念cM间的关系?font color="#cc0000">参见?-23? 数据cd 领域模型中的属性通常应该是数据类?data type)。一般来_数据cd?#8220;基本”cdQ诸如数字、布?yu)、字W、字W串和枚?例如Q尺?{,打})。更准确地讲QUML术语中的数据cd指的是一l|而这l值的标识本n不具有Q何含义(在我们的模型或系l的语境下)。换a之,Ҏ(gu)据类型的{h(hun)性检验不是基于标识,而是Ҏ(gu)值来判断的? 数据cd值往往是恒定不变的Q例如,Integer的实?5"是不变的QDate的实?#8220;Nov.13,1990”可能也是不变的。而Person实例的lastName属性可能对不同人有不同的倹{? 从Y件角度出发,很少会对Integer或Date实例的存储地址Q标识)q行比较Q一般是对D行比较。另一斚wQ即使Person的不同实例具有相同的属性|但还是可以区分和比较其存储地址Q因为其唯一标识的重要性? 观点Q代码中的属? 在领域模型中属性主要ؓ数据cdQƈ不意味着C#或Java的属性只能是单的基础数据cd。领域模型是概念透视图,不是软g透视图。在设计模型中,属性可以是Mcd? 准则Q何时定义新的数据类型类 NextGen POSpȝ需要itemID属性,可以作ؓItem或ProductDescription的属性。注意,该属性看h只是数字或字W串Q例如,itemID:Integer或itemID:String?但实际上Q该属性ƈ不仅仅是字符串或数字Q商品项目标识符h子域Q,更有效的做法是在领域模型中加入类ItemIDQ或者ItemIdentifierQ,q且这个类作ؓitemID属性的cd。例如,itemID:ItemIdentifier?font color="#cc0000">?-3提供了一些准则,指明何时需要在模型中加入数据类型? 应用UMLQ在何处描述q些数据cdc?nbsp; 在领域模型里QItemIDcd该表CZؓ单独的类吗?q取决于你想要在图中的事物。既然ItemID是数据类型(实例的唯一标识不用于等h检验)Q那么可能只会表C在cL的属性分gQ?font color="#cc0000">如图9-24。采用哪U解x式取决于如何使用作ؓ沟通工L领域模型以及领域里概늚重要性? 准则QQ何属性都不表C外?nbsp; 领域模型里的属性不应该用于表示概念cȝ关系。违反这一原则的常见情冉|像在关系数据库设计中那样增加一U外键属性,用以兌两个cd?font color="#cc0000">参见?-25。可以用许多Ҏ(gu)来表C对象之间的关系Q外键就是其中一U方法,我们推q到设计时在军_如何实现对象关系Q以避免设计蠕变(design creep)? 准则Q对数量和单位徏?nbsp; 大部分用数字表示的数量不应该表示为纯数字。应该给q些数量加上单位Qƈ且通常q需要知道单位之间的转换关系。领域模型(和YӞ应该具备处理数量的技巧。一般情况下Q可以把数量表示为单独的Quantityc,q且兌到UnitcR通常可以对Quantity加以规格说明?font color="#cc0000">参见?-26? 实例Q领域模型中的属?/font> 参见?-27?9-28 l论Q领域模型是否正?/font> 没有所谓唯一正确的领域模型。所有模型都是对我们试图要理解的领域的近伹{领域模型主要是在特定群体中用于理解和沟通的工具。有效的领域模型捕获了当前需求语境下的本质抽象和理解领域所需要的信息Qƈ且可以帮助h们理解领域的概念、术语和关系? q程QP代和q化式领域徏? 在P代开发中Q我们会通过若干q代寚w域模型进行增量地演进。在每个q代中,领域模型都会限定于之前和当前要考虑的场景,而不是膨胀为瀑布风格?#8220;大爆?#8221;模型Q以q早试图捕获所有可能的概念cd联系。因此,只创建部分领域模型反映这一情ŞQ而不涉及其他? 准则Q避免瀑布思维們Qؓ完成详尽?#8220;正确”的领域模型而进行大量徏模工作,q些方式都应避免Q这U过量的建模工作反而会D分析停滞Q这U投入几乎不会有什么回报。每ơP代的领域模型建模旉不超q几个小?/font>? UP中的领域模型 如表9-4的徏议所C,UP中的领域模型通常开始和完成于细化阶Dc? UP业务对象模型与领域模? UP领域模型是较为少见的UP业务对象模型QBOMQ的正式变体。不要与其他对BOM的定义淆,UP BOM是一U描q整个业务的企业模型。BOM可以用来q行业务q程或再工程Q而不依赖于Q何Y件应用?/font>引证如下Q【UP BOM】作为抽象,描述的是业务人员和业务实体应该怎样兌Q以及它们如何协作以完成业务?/font> BOM使用不同的图Q类图、活动图和顺序图Q来阐述整个企业是如何运转的Q或应该如何q{Q。BOM通常有助于进行企业范围的业务q程工程Q而在创徏单个软g应用时ƈ不常见。因此,UP定义了领域模型,作ؓBOM的常用制品子集或特化?/font>引证如下Q你可以选择开?#8220;非完整的”业务对象模型Q重点解释领域中的重?#8220;事物”和品。?..】这些都成ؓ领域模型?/font> ?/strong> 本章概括案例研I在q代1的需求,然后要讨论初始和l化阶段的过E思想。ؓ理解后箋章节Ҏ(gu)ơP代的讨论Q阅读选择需求很重要?
q代1的需求和重点QOOA/D技术的核心
在这些案例中Q细化阶D|得P?的是基础范围和在构徏对象pȝ中所使用的常见OOA/D技术。当Ӟ构徏软gq需要其他许多技术,例如数据库设计、可用性工E、UI设计{,但是本书主要xOOA/D和UML应用Q其他技术不在本书涵盖范围之内?
在P代开发中Q我们ƈ非一ơ就实现所有需?/strong>
对P代生命周期方法(例如UP、XP、Scrum{)的关键理解就是:我们寚w求子集开始具有品品质的~程和测试,q且我们在完成所有需求分析之前开始这些开发,q与瀑布q程相反?
在多个P代里对同一用例q行增量式开?nbsp; 注意Qƈ不是在P?里要实现处理销售用例中的所有需求。通常是在若干q代内对同一用例的各U场景进行开发,q且逐渐地扩展系l直到最l完成所有需要的功能?font color="#ff0000">Q图8-1Q?/font>另一斚wQ简短的用例可以在一ơP代中完成? q程Q初始和l化 在初始阶D发生了什?
案例研究的初始阶D大概只持箋了一周。因不是目的需求阶D,所创徏的制品应该是明和不完整的Q该阶段用时很短Qƈ且只l过轻量U的调查?
初始阶段是迈向细化阶D늚一步。在该阶D决定基本的可行性、风险和范围Q对目是否值得q行更深入的调查q行决策。ƈ不是所有适合于初始阶D늚zd都要늛在其中,q一阶段面向需求的制品。初始阶D中可能的活动和制品包括Q?
l化之所?nbsp;
l化阶段是最初的一pdq代Q在q一阶段Q小l进行细致的调查、实玎ͼ~程和测试)核心架构、澄清大多数需求和应对高风险问题。在UP中,“风险”包含业务价倹{因此,早期工作可能包括实现那些被认为重要的场景Q而不是专门针Ҏ(gu)术风险?
l化阶段通常׃个或多个q代l成Q徏议每ơP代的旉?~6周? 在这一阶段Q不是要创徏可以丢弃的原型。与之相反,该阶D生的代码和设计是h产品品质的最l系l的一部分。在一些UP的描qCQ会误解"架构原型"(architectural
prototype)q一术语用来描述局部系l。该术语不是指可废弃的、实验性的原型Q在UP中,它表C最l系l的产品化子集。该术语更常见名U是可执行架?/font>(executable architecture)?font color="#cc0033">架构基线(architectural baseline)?nbsp; 用一句话来概括细化:构徏核心架构Q解决高风险元素Q定义大部分需求,以及预计Mq度和资?/font>? 在细化阶D可能出现的一些关键思想和最?jng)_践包?/font>Q? 在细化阶D会开始构建哪些制?nbsp; ?-1列出的是可能在细化阶D开始构建的制品样例Q同时指明这些制品要解决的问题? 何时知道自己q没有理解细化阶D?/font> 如果在项目中出现q些现象Q则表明你对l化阶段的理解是错误的,q且已经在UP之上强加了瀑布思想? q程Q计划下一个P?nbsp; 通过风险、覆盖范围和关键E度l织需求和q代? 在P?之前完成{划分Q但是在q代2之前要重新划分,依此cLQ因为新需求和新理解会对等U排列生媄响。也是_q代的计划是可适应的,q不是项目开始之时必d定下来的?
]]>
]]>
]]>
]]>
?/strong> 除用例之外,q有其他一些重要的UP需求制品,本章介l这些制品,q些内容与案例研I关pd切,q且提供了更为完整的需求示例?
其他需求制?nbsp; 用例不是要求的全部?
》补充性规D?nbsp; 捕获q确定了其他cd的需求,例如报表、文档、包装、可支持性说明、许可授权等
》词汇表 捕获术语和定义,它也可v到数据字典的作用
》设?nbsp;概括了对目?#8220;设想”Q即执行摘要。该制品?目主要思想提供z描q?
》业务规?/font>Q或领域规则Q捕获了凌驾于特定应用之上的长期规则或政{,例如E法
q些CZ的详程?nbsp; 本书首要目标是介lOOA/D基础知识Q而不是本章所的次要POS需求细节。因此本章只展示部分CZQƈ不展C完整详的需求示例?
某些节作为承上启下的q渡节Q突出重炚w题,提供对内容的感性认识,然后׃快速进入下面的内容?
准则Q初始阶D|否应该对此彻底地q行分析 非也。UP是一UP代和q化式方法,q意味着应该早在完整地分析和记录大多数需求之前,早q行h产品品质的编E和试。来自早期编E和试的反馈需求进化?
研究表明Q在开始阶D,高阶_粒度需求的“前十”列表是有帮助的。同P在早期花费一定时间去理解非功能性需求(例如性能或可靠性)也是有帮助的Q因Ҏ(gu)构选择h重要影响?
可靠性规D明:是否矛盾Q?nbsp; 接下来所~写的需求示例可能会造成以下错觉Q既然理解ƈ良好定义了真实的需求,那么也可以用它来寚w目进行可靠的预算和计划。这U错觉对非Y件开发者来说尤其强烈,E序员会从其惨痛教训中认识到q种计划和预是多么不可靠?
真正重要的是快速构建可以通过用户验收试的YӞ而且能够满用户真实的目标,但在用户对Y件进行评估或使用之前Q无法确定这些目标?
~写设想和补充性规D明是值得重视的,但是q些制品Q或者Q何需求)也ƈ不是完全可靠的规D明。只有编写代码、测试、获取反馈、进一步完成与用户和客L协作q且对Y件进行改写,才会真正辑ֈ目标?
qƈ不是要号召无序分析和思考就匆忙地去~码Q而是d地处理需求,快开始编E,q且不断引入用户和测试以得到反馈?
准则Q这些制品是否应该放在项目Web站点?/strong> 与普通的静态文?不同Q这些制品应该是链接的Q或者用不用于字处理器或电(sh)子表格的其他工具q行记录。例如,其中大多数可以记录在WiKi Web上?
NextGenCZQ(部分Q补充性规D?/strong> P78
注解Q补充性规D?nbsp; 补充性规D?/font>Qsupplementary specificationQ捕获了用例和词汇表难以描述的其他需求、信息和U束Q其中包括系l范围的"URPS+"Q可用性、可靠性、性能、可支持性和其他Q等质量属性或需求? 在思考用例的时候,某用例专有的非功能性需求可以首先简要地写入用例Q即用例?#8220;Ҏ(gu)需?#8221;节。但是,在这U非正式描述后,应该其归入补充性规D明,以便所有非功能性需求集中在一处,避免重复?
补充性规D明中的元素包括:
?#8220;FURPS+”需?-功能性、可用性、可靠性、性能和可支持?
》报?
》硬件和软gU束Q操作系l和|络pȝ{)
》开发约束(例如Q过E或开发工P
》其他设计和实现U束
》国际化问题Q货币单位、语aQ?
》文化Q用戗安装和理手册Q和帮助
》许可和其他法律问题
》包?
》标准(技术、安全和质量Q?
》物理环境问题(例如Q热度或振动Q?
》操作问题(例如Q如何处理错误,或者每隔多久进行备份)
》特定应用领域规?
》所x领域的信息(例如Q信用卡支付处理的整个过E)
质量属?nbsp; 有些需求可以称为系l的质量属?/font>Qquality attributeQ或qualities attributeQ,包括可用性、可靠性等{。需要注意的是,q些指的是系l的质量Q而非属性本w的质量Q属性本wƈ没有高质量之说?
当我们带?#8220;架构师的帽子”Ӟpȝ范围的质量属性(记录于补充性规则说明中Q将特别重要Q因为架构分析和设计极ؓ兛_在功能性需求语境下质量属性的定和选择Q第33章将Ҏ(gu)q行介绍?/strong>
补充性规D明中有功能性吗Q难道不应该在用例中吗? 某些功能或特性ƈ不适合采用用例的Ş式描qͼ可以采用Ҏ(gu)的方式来描q功能性?
UP当然也允怋用这U面向特性的Ҏ(gu)来描q需求,在这U情形下Q应在补充性规D明中描述Ҏ(gu)列表?
UP提倡但不是强求对功能性用用例。用例是一U优U的方法,可以通过产品使用的典型场景把一l相关特性集中v来思考。但是用例ƈ不是永远适用?
应用专用的领域(业务Q规?nbsp; 一般来_诸如E法{广泛应用的领域规则属于UP业务规则制品QUP其作ؓ核心的共享知识库。但是,对于更ؓ局限的特定于应用的规则Q例如如何计某商品折扣,可以记录在补充性规D明中?
所x领域的信?nbsp; q对于主题问题专家是h价值的Q他们可以编写(或提供URIQ一些与新Y件系l有关的领域解释Q销售和账务Q地下a/?气流量的地球物理学知识)Q以便ؓ开发小l提供背景信息和更ؓ深入的理解力
NextGenCZQ(部分Q设?/strong> P82
注解Q设?nbsp; ~写执行摘要寚w目运行进行简要的描述Q主要成员建立起对目的共同设惻I也是同样有帮助的?nbsp; 设想不应该占据很长的幅Q也不应该试图详l描q公司的需求。设惛_该概括用例模型和补充性规D明中的一些信息?
涉众的关键高阶目标及问题 该小节ȝ高阶Q通常高于特定用例Q目标和问题Qƈ且揭CZ重要的非功能和质量目标,q些目标可能属于某个用例或跨多个用例?
准则Q有哪些化的Ҏ(gu)Q?nbsp; 特别是在输入定义高阶问题和确定目标的zdq程中,会发生创造性、研I性的组工作。对于发现根源问题及目标、启发思\和定义优先Q存在一些有助于组工作的技术:
》思维导图Qmind mappingQ?
》品设惛_装制作(product vision box creationQ?
》鱼骨图Qfishbone diagramQ?
》排列图(pareto diagram)
》集体讨论(brainstormingQ?
》多ơ投表冻Imulti-votingQ?
》记Ҏ(gu)表冻Idot votingQ?
》提名小l过E(nominal group processQ?
》集体编写(brainwrittingQ?
》相x分l(affinity groupingQ?
可以在Web上找到这些方法的具体介绍。推荐在同一讨论会上采用其中几种Ҏ(gu)Q以便从不同角度发现共同的问题和需求?
pȝҎ(gu)概?/strong> 为掌握主要特性而在设想文中只列出用例名称是不够的Q原因如下:
1、太详细或层ơ太低。h们想要的是主要思想的概?
2、用例名U可能掩盖了涉众真正兛_的主要特?
3、有些值得注意的特性跨了多个用例或者与用例无关
因此Q?strong>Ҏ(gu)?/strong>作ؓ替代的、补充性的方式来表C系l的功能Q在q种语境下,更准地说法?strong>pȝҎ(gu)?/strong>Q即以高阶、简z的语句对系l功能加以概括。更为正式地Q在UP中,pȝҎ(gu)?/strong>?#8220;ql提供的外部可观察到的服务,可以直接实现涉众的需?#8221;
定义Q特性是pȝ能够实行的行Z的功能。特性应该通过如下语言上的试Q系l实?lt;Ҏ(gu)X>
功能上的系l特性与各种非功能性需求和U束q行Ҏ(gu)Q例?#8220;pȝ必须q行于Linux”Q显然不能通过上述语言上的试。例如,pȝ实现Linux?
准则Q如何编写功能列?nbsp; 通常可以使用两层次l构来组l系l特性。但是,如果设想文的层ơ多于两U,则显得过于详l。设x档的pȝҎ(gu)应该对功能性进行概括,非不应分解ؓl粒度元素的冗长列表?
准则Q在设想文档中包含的Ҏ(gu)最好少?0个,因ؓ更多的特性不能够被快速掌握。如果存在更多的Ҏ(gu),则需考虑对这些特性进行分l和概括?/font>
准则Q我们是否应该在设想文中重复其他需求? 准则Q对于其他需求,要避免在设想和补充性规D明(SSQ中重复或近于重复。最好只在SS中记录这些需求。在设想文中,可以指引读者到SS中阅读这些需?/font>
准则Q你应该先编写设惌是用例? 不需要严格定义这U先后顺序。在开发者合作创Z同需求制品时Q对一个制品的创徏工作会媄响ƈ有利于澄清另一个制品。尽如此,q是采用如下的顺序:
1、首先编写简要的设想草案
2、确定用L标和对应的用例名U?
3、详l编写一些用例,q且开始编写补充性规D?
4、精化设惻I对以上制品中的信息进行概括?
NextGenCZ:Q部分)词汇? P87
注解Q词汇表Q数据字典) 词汇?/strong>QglossaryQ的最形式是重要术语及其定义的列表。o人惊讶的一U常见情冉|Q不同涉众可以用略有不同的方式用同一Q通常是技术的或特定于领域的)术语。这一问题必须解决Q以减少沟通上的问题和需求的二义性? 准则Q及早开始编写词汇表。词汇表很快成为关于细_度元素l节信息的有效知识库?
词汇表作为数据字?nbsp; 在UP中,词汇表也充当数据字典Qdata dictionaryQ的角色Q即记录关于数据之数据,也就?strong>元数?/strong>QmetadataQ的文。在初始阶段Q词汇表应该是术语及其描q的单文档。在l化阶段Q词汇表可以扩展为数据字典?
术语的属性包括:
》别?
》描q?
》格式(cd、长度、单位)
》与其他元素的关p?
》值域
》验证规?
注意Q词汇表中的值域和验证规则是反映pȝ行ؓ的需求的l成部分?
准则Q我们是否可以在词汇表中记录l合术语 词汇表不仅用于记录原子术语,例如“产品h”Q它也能够ƈ且也应该包括诸如“销?#8221;Q其中包含其他元素,例如日期和地点)的组合元素和用来描述用例参与者之间所传递的一l数据的化名U。例如,在处理销售用例中Q考虑如下陈述Q?pȝ向外部支付授权服务发?u>支付授权hQƈh批准支付? “支付授权h”是一l数据的别名Q也需要在词汇表中加以解释?
NextGenCZQ业务规则(领域规则Q?/strong> P88
注解Q领域规? 领域规则指出领域或业务是如何q作的。尽应用需求通常都会受到领域规则的媄响,但是q些规则不是M一个应用的需求。公司政{、物理法则(例如油在C如何动Q和政府法律都是常见的领域规则?
领域规则通常UCؓ业务规则Qbusiness ruleQ,q也是其最常见的类型,但是q一术语q不是恰当的Q因为大量Y件应用不是面向业务问题的?
最好在单独的与应用无关的制品中定和记录领域规则,q在UP中称Z务规则制品,q样便能够分析在组l和目范围内进行共享和重用Q而不是只限定于特定项目的文档里?
规则了情节的q箋性而不是细节,有助于澄清用例中的歧义。例如,在NextGen POS中,如果有h问事否应该在处理销售用例中加入另一路径Q即不允怸记录{的信用卡支付Q业务规则给Z{案Q其表明M信用卡授权公叔R不允许这U情c?
q程QP代方法中的进化式需?/strong> PPT6概括了制品示例及其在UP中的旉。通常Q大多数需求制品始于初始阶D,q且主要在细化阶D开发?
初始阶段 涉众要决定项目是否值得深入调查。实质的调查zd在细化阶D发生,而不是初始阶D发生。在初始阶段Q设想以某种形式概括了项目思想Q以帮助决策者决定是否值得l箋Qƈ且从哪里着手?
因ؓ大多数需求分析发生在l化阶段Q所以在初始阶段应该只对补充性规D明稍作开发,只需要突出重要的质量属性用以揭CZ要风险和挑战。这些制品的输入可以在初始阶D늚需求讨Z上生?
l化阶段 通过l化阶段Q基于对部分pȝ增量构徏的反馈、调整以及在若干开发P代中举行的多个需求讨ZQ对“q景”和设x档加以精化。通过q一步的需求调查和q代开发,其他需求将更ؓ清晰q且可以记录在补充性规D明中?
在细化阶D늻束时Q完成ƈ提交用例、补充性规D明和设想是切实可行的Q因为在此时Q这些文能够合理地反映E_的主要特性和其他需求。尽如此,补充性规D明和设想不等同于ȝq?#8220;{v”了的规格说明Q改?-q僵化--是P代开发和UP的核心h(hun)倹{?
所谓的“ȝ{v”是在l化阶段l束Ӟ项目剩余时间里所要完成的事项与涉众达成一致意见,q且需求和q度l予承诺Q可能是以合同Ş式)Q这是完全切合实际的。在某一时刻Q在UP中是l化阶段的结束时刻)Q我们需要对“什么、多、何?#8221;有可靠的认识。从q种意义上说Q签|关于需求的合约时正常的Q也是有必要的。同时还需要具备变更控制过E(UP中明的最?jng)_践之一Q,以便正式地考虑和批准需求变_避免混ؕ和不受控的变更?
“ȝ{v”的事实还意味着如下几点Q?
?在P代开发和UP中,无论在需求规D明上付出多少努力Q还是不可避免地会存在一些变_q应该可以被接受。这些变更可能是能够为所有者带来竞争优势的、新q发生的对系l投机性的改进Q或者是׃加深了认识而引L改进?
?nbsp; 使涉众来q行评估、提供反馈以及掌握项目的方向以满_真实意图Q这是P代开发的核心价倹{?#8220;z手不干”Q不x于参与项目,而是在一l冻l的需求上{֭认可后就{待着目l束Q这样对涉众来说q没有好处,因ؓ他们几乎不会得到真正满光要的l果?
构造阶D?nbsp; 通过构造阶D,主要需求(包括功能性需求和其他需求)应该已经E_下来Q虽然还不是l结Q但是已l可以专注于ơ要的微C物了。因此,在此阶段Q补充性规D明和设想都不必进行大量改动?
?nbsp; 本章要介lP代和q化式需求,q且描述特定的UP需求制品,以此为后l的面向需求的章节做好铺垫?
定义Q需?nbsp; 需?requirement)是pȝQ更q义的说法是目Q必L供的能力和必遵从的条g?
UP提出了一pd的最?jng)_践,其中之一是需求管理(manage requirementQ?/font>。需求管理不d采用瀑布的观点,卛_~程之前目的第一个阶D就试图完全定义和固话需求。在变更不可避免Q涉众意愿不明朗的情况下QUP更推崇用“一U系l的Ҏ(gu)来寻找、记录、组l和跟踪pȝ不断变更的需?#8221;
而言之,是通过q代巧妙地进行需求分析、而非草率和随意地Z?需求分析的最大挑战是L、沟通和C什么是真正需要的Qƈ能够清楚地讲解给客户和开发团队的成员?
q化式需求与瀑布式需?/strong> 注意Q在UP的需求管理定义中使用?font color="#0000cc">“不断变更”一词。UP能够包容需求中的变_q将其作为项目的基本驱动力。这一Ҏ(gu)为重要,也是q代和进化式思想与瀑布思想的核心差异?
L需求可以采用的Ҏ(gu) ?#8220;不断变更”之外Q另一个重要的词是“L”。也是_UP提倡用一些有效的技巧以获得启示Q例如与客户一同编写用例、开发者和客户共同参加需求讨Z、请客户代理参加焦点组以及向客hC每ơP代的成果以求得反馈? UPƢ迎M能够带来价值ƈ提高用户参与度的需求启发方法?
需求的cd和种c?/strong> 在统一q程中,需求按?#8220;FURPS+”模型q行分类Q这是一U有效的记忆Ҏ(gu)Q其含义如下Q?
》功能性(FunctionalQ:Ҏ(gu)、功能、安全性?
》可用性(UsabilityQ:人性化因素、帮助、文?
》可靠性(ReliabilityQ:故障频率、可恢复性、可预测?
》性能QPerformanceQ:响应旉、吞吐量、准性、有效性、资源利用率?
》可支持性(SupportabilityQ:适应性、可l护性、国际化、可配置?
“FURPS+”?#8220;+”是指一些辅助性的和次要的因素Q比如:
》实玎ͼImplementationQ:资源限制、语a和工兗硬件等?
》接口(InterfaceQ:强加于外部系l接口之上的U束
》操作(OperationQ:对其操作讄的系l管?
》包装(PackagingQ:例如物理的包装盒
》授权(LegalQ:许可证或其他方式
其中某些需求可以统UCؓ质量属性(quality attributeQ?/strong>?strong>质量需?quality requirement)或系l的“某属?#8221;。这些需求包括:可用性、可靠性、性能和可支持性。在一般用中Q需求按?strong>功能?/strong>Q行为的Q和非功能?/strong>Q其他所有的行ؓQ来分类Q有些h不喜Ƣ这U宽泛的分类方式Q但q种方式已被q泛采用?
UP制品如何l织需?nbsp; UP提供了一些需求制品。同所有UP制品一P它们都是可选的。其中关键的制品包括Q?
》用例模型:一l用系l的典型场景。主要用于功能需?
》补充性规D明:基本上是用例之外的所有内宏V主要用于所有非功能需求,例如性能或许可发布。该制品也用来记录没有表CZؓ用例的功能特性,例如报表生成
》词汇表Q?/font>词汇表以最单的形式定义重要的术语。同时也包含?strong>数据字典Qdata dictionaryQ?/strong>的概念,其中记录了关于数据的需求,例如有效性规则,容许值等。词汇表可以详述M元素Q对象属性、操作调用的参数、报表布局{?
》设惻I概括了高阉求,q些需求在用例模型和补充性规D明中q行l化。设想也概括了项目的业务案例。设x短的执行概要文档Q用以快速了解项目的主要思想?
》业务规则:业务规则Q也UCؓ领域规则Q通常描述了凌驾于某一软g目的需求或政策Q这些规则是领域或业务所要求的,q且许多应用应该遵从q些规则。政府的E收法规是一个例子。领域规则的l节可以记录在补充性规D明中Q但是因些规则通常更ؓ持久Qƈ且对不止一个Y仉目适用Q所以应其攑օ集中的业务规则制品(供公司的所有分析员׃nQ,以便在这斚w做出的分析工作能够被更好的重用?
制品的正格?nbsp; 在UP中,所有制品都是信息的抽象Q它们可以存储在Web,板报Q或各种可以惌到的载体之上?/p>
?nbsp; 用例是文本Ş式的情节描述Q广泛应用于需求的发现和记录工作中。用例会影响目的众多方面(包括OOA/DQ,用例也将作ؓ本书案例研究中许多后l制品的输入?font color="#0000cc">?-1描述了UP制品的媄响力Q其中特别强调了文本形式的用例。将高阶目标和用例图作ؓ输入Q来创徏用例文本。反之,用例也能够媄响其分析、设计、实现、项目管理和试制品?
CZ ?-1中的用例不是囑ŞQ而是文本。用例初学者的常见错误是注重于次要的UML用例图,而非重要的用例文本?
用例通常比上qC子更l或l构化更强,但其本质仍然是通过~写使用pȝ实现用户目标的情节来来发现和记录功能性需求,也就是用的案例。用例不是什么复杂的概念Q尽发现需求,q当地编写通常有一定的困难?
定义Q参与者、场景和用例 参与者(actorQ?/font>是某些具有行为的事物Q可以是人(p色标识)、计机pȝ或组l?
场景QscenarioQ?/font>是参与者和pȝ之间的一pd特定的活动和交互Q也UCؓ用例实例Quse case instanceQ?/font>。场景是使用pȝ的一个特定的情节或用例的一条执行\径?
通俗地讲Q?font color="#0000cc">用例(use case)是一l相关的成功和失败场景集合,用来描述参与者如何用系l来实现其目标?
用例和用例模? UP在需求科目中定义了用例模型(Use-Case ModelQ。首先,q是所有书面用例的集合Q同Ӟ它是pȝ功能性和环境的模型?nbsp; 用例是文本文,而非囑ŞQ用例徏模主要是~写文本的活动,而非制图?
用例模型在UP中不是唯一的需求制品。其他制品还有补充性规D明、词汇表、设惛_业务规则。这些制品都有助于需求分析,但ƈ不是最主要的?
用例模型q可以包含UML用例图,以显C用例和参与者的名称及其关系。UML用例囑֏以ؓpȝ及其环境提供良好?font color="#000099">语境图(context diagramQ?/strong>Q也为按名称列出用例提供了快h式?
用例不是面向对象的,~写用例时也不会q行OO分析。但qƈ不妨其有效性,用例可以被广泛应用。也是_用例是经典OOA/D的关键需求输入?
动机Qؓ什么用用?/strong> 虽然q种Ҏ(gu)看v来像随意的注释,但是极ؓ重要。研Ih员设计了他们自己能够理解的复杂分析方法,但是会一般的业务人员qh不解。而在软g目中,~少用户参与是项目的主要原因之一Q所以Q何有利于用户参与的方法是l对值得的?
用例的另一个h(hun)值是了用L目标和观炏V?我们会提L问题Q?#8220;谁用系l?他们使用的典型场景是什么?他们的目的是什么?”与查询系l特性清单相比,以上问题更强调以客户Z心?
富有创造力的hl常会将单的思想变得晦ӆq且q于复杂。我们经怼发现Q用例徏模新手过于关心那些次要的问题Q比如用例图、用例关pR用例包{,而不是致力于单地~写文本情节的实际工作中?
用例的优性就在于Q能够根据需要对复杂E度和Ş式化E度q行增减调节?
定义Q用例是功能性需求吗 用例是需求,主要是说明系l如何工作的功能性或行ؓ性需求。按?#8220;FURPS+”需求类型,用例?#8220;F”Q功能性或行ؓ性)Q但也可以用于其它类型,特别是与用例紧密相关的那些类型。在l一q程和其他现代方法中Q用例被推荐作ؓ发现和定义需求的核心机制?
CQ用例是真正的需求(管不是所有的需求)?nbsp; 用例的主要思想Q通常Q是Qؓ功能性需求编写用例,从而降低详l的老式Ҏ(gu)列表的重要性或减少q种列表的用?
定义Q参与者的三种cd 参与者(actorQ?/font>是Q何具有行为的事物Q在所讨论pȝQSystem under Discussion ,SuDQ调用其他系l的服务Ӟq包括其自n。主要参与者和协助参与者会出现在用例文本的zd步骤中。参与者不仅是人所扮演的角Ԍ也可以是l织、Y件和计算机。相对于SuDQ有三种外部参与者:
》主要参与者(primary actorQ:h用户目标Qƈ通过使用SuD的服务完成。例如,攉?
》协助参与者(supporting actorQ:为SuD提供服务Q例如,信息服务Q。自动付Ҏ(gu)权服务即是一例。协助参与者通常是计机pȝQ但也可以是l织或h?
》幕后参与者(offstage actorQ:在用例行Zh影响或利益,但不是主要或协助参与者。例如,政府E收机构?
表示法: 用例的三U常用Ş?nbsp; 用例能够以不同Ş式化E度或格式进行编写:
?strong>摘要--z的一D式摘要Q通常用于L功场景,前例中的处理销售就是摘要Ş式的用例?
?strong>非正?-非正式的D落格式。用几个D落覆盖不同场景。前例中处理退货就是非正式形式的用例?
?strong>详述--详细~写所有步骤及各种变化Q同时具有补充部分,如前|条件和成功保证?
CZQ详q风格的处理销?nbsp; 详述用例Qfully dressed use caseQ?/font>是结构化的,它展CZ更多l节Qƈ且更为深入。(P50~P55Q?在P代和q化式UP需求分析中Q第一ơ需求讨Z应该以这UŞ式编?0%的关键用例。随后,对这10%中最h重要架构意义的用例或场景q行设计和编E?
对于详细的用例有各种格式的模ѝ自20世纪90q代早期以来Q用最为广泛的格式是alistair.cockburn.us上提供的模板Q该模板由Alistair Cockburn创徏Q他是用例徏模方法和畅销书的作者,PPT3阐述了这U风根{?
各小节的含义
l言元素
》范?/strong> 范围界定了所要设计的pȝ。通常Q用例描q的是对一个Y件系l(或硬件加软gQ的使用Q这U情况下UC?font color="#000000">pȝ用例Qsystem use caseQ?nbsp;。在更广义的范围上,用例也能够描q顾客和有关人员如何使用业务。这U企业的过E描q被UCؓ业务用例Qbusiness use caseQ?/strong>Q这也是q泛使用用例的极好示例,但这q不是本书所要介l的内容?
》? 在Cockburn的系l中Q用例主要分为用L标别或子功能别? 用户目标U别Quser-goal levelQ是通常所使用的别,描述了实C要参与者目标的场景Q该U别大致相当于业务流E工E中?strong>基本业务程QElementary Business ProcessQEBPQ?strong>子功能?/strong>Qsubfunction-levelQ用例描q支持用L标所需的子步骤Q当若干常规用例׃n重复的子步骤Ӟ则将其分d来,创徏为子功能U别用例Q以避免重复公共的文本);信用卡支付就是子功能用例的例子,该用例可以被许多常规用例所׃n?
》主要参与? 调用pȝ服务来完成目标的主要参与?
》涉众及其关注点列表--重要Q?nbsp; 该列表比看上去要重要和实用的多。它q界定了pȝ必须要做的工作。见以下引用Q?“[pȝ]实现了涉众之间的契约Q同时用例详l描qC该契U的行ؓ部分.......用例作ؓ行ؓ的契U,专门和完整地捕获与满x众关注点相关的行?#8221; q就回答了以下问题:用例应该包含什么? {案是:用例应该包含满所有涉众关注点的事?
》前|条件和成功保证Q后|条Ӟ 前置条gQpreconditionQ给出在用例中场景开始之前必Lqؓ真的条g。要注意的是Q有些条件也必须为真Q但是不值得~写出来。前|条件传辄是编写者认为应该引赯者警惕的那些值得注意的假设?strong>成功保证Q或后置条gQ给出用例成功结束后为真的事物,包括L功场景及其替代\径。该保证应该满 所有涉众的需求?
》主成功场景和步骤(或基本流E) 也被UCؓ“理想路径”场景Q或更朴实的“基本程”?#8220;典型程”。它描述了满x众关注点的典型成功\径。要注意的是Q它通常不包括Q何条件或分支。虽然包含条件或分支q不是错误,但是Q保持一定的q诏性,q且所有条件处理都推gx展部分,q种h争议的做法更易于理解和扩展?
场景记录以下三种步骤Q?
1、参与者之间的交互
2、确认过E(通常ql来完成Q?
3、系l完成的状态变?
》扩展(或替代流E) 扩展是重要的Qƈ且通常占据了文本的大部分篇q。扩展部分描qC其他所有场景或分支Q包括成功和p|路径?在整个用例编写当中,理想路径与扩展场景相l合应该满“几乎”所有涉众所x的问题?
扩展场景是主成功场景的分支,因此能够以对应的步骤1...N对其q行标识?
在扩展处理结束时Q默认情况下Q扩展场景将重新q入L功场景,除非扩展指出了其他方式(例如Q系l中断) ?nbsp; 有时候,某个扩展点将非常复杂Q例?#8220;信用卡支?#8221;扩展。在q种情况下可以用单独的用例来表达该扩展?
如果惌描述在Q何步骤(臛_大多数步骤)都可能发生的扩展条gQ那么可以?#8220;*a”?#8220;*b”q样的标记?
有时Q用例会产生分支以执行其他用例场景。在Cockburn表示法中Q用下划线表示所执行的第二个用例。假N常使用链接工L写用例,那么点击h下划U的用例名称会昄对应的文本?
》特D需?nbsp; 如果有用例相关的非功能性需求、质量属性或U束Q那么应该将其写入用例。其中包含需要考虑的和必须包含的质量属性(如性能、可靠性和可用性)和设计约束(通常对于I/O讑֤Q?
》技术和数据变元?/strong> 需求分析中通常会发C些技术变元,q些变元是关于必d何实现系l的Q而非实现pȝ哪些功能Q这U变元需要记录在用例中。常见的例子是,涉众制定了关于输入或输出技术的U束?
表示法:有其他格式吗Q?/strong>两栏变体 有时提倡用两栏或对话的格式,q种格式参与者和pȝ之间的交互。P60
准则Q以无用L面约束的本质风格~写用例 以本质风格编写用例;摒除用户界面q且x参与者的意图?q种Ҏ(gu)源目标的发现q程能够拓展视野Q以促成新的和改q的解决Ҏ(gu)?
准则Q编写简z的用例 删除“噪音”词汇Q因为即使一些细微之处也会篏UؓJ琐Q例如编写时应用“pȝ认证......”Q而不?#8220;q个pȝ认证......”
准则Q编写黑盒用?nbsp; 黑盒用例Qblack-box use caseQ?/font>是最常用和推荐用的cdQ它不对pȝ内部工作、构件或设计q行描述。反之,它以通过职责来描q系l,q是面向对象思想中普遍统一的隐M?-软g元素h职责Qƈ且与其他h职责的元素进行协作?
通过使用黑盒用例定义pȝ职责Qh们可以规定系l必d什么(行ؓ和功能需求)Q而不必决定系l如何去做(设计Q。实际上Q?#8220;分析”?#8220;设计”的区别就在于“什?#8221;?#8220;如何”的差异。这是在优秀软g开发中的重要主题:在需求分析中应该避免q行“如何”的决{,而是规定pȝ的外部行为,像黑盒一栗此后,在设计过E中创徏满该规D明的解决Ҏ(gu)?
准则Q采用参与者和参与者目标的视点 以下是RUP的用例定义,源于用例创立者Ivar JacobsonQ【一l用例实例,每个实例是系l所执行的一pdzdQ以此生对特定参与者具有h(hun)值的可观察结果?nbsp; 短语“对特定参与者具有h(hun)值的可观察结?#8221;是细微而又重要的概念,Jacobson认ؓq是关键Q因为它了需求分析的两个态度Q?
》关注系l的用户或参与者来~写需求,询问其目标和典型情况
》关注理解参与者所考虑的有价值的l果
准则Q如何发现用?nbsp; 为满主要参与者的目标而定义用例。因此,基本的过E如下:
1》选择pȝ边界 pȝ仅仅是Y件应用,q是硬件和应用作ؓ整体Q是一个h使用Q还是整个组l在使用Q?
2》确定主要参与?/font>--通过使用pȝ的服务实现其目标的那些h或事?
3》确定每个主要参与者目?/font>
4》定义满用L标的用例Q根据其目标对用例命名。通常Q用L标的用例和用户目标是一一对应的,但这里至有一个例外,后面对此进行讨论?
详细步骤1-4见P63~P65
准则Q什么样的测试有助于发现有用的用?nbsp; 一般来说不要提?#8220;什么是有效用例”q样的问题,更ؓ实际的问题是“对应用需求分析来_表示用例的有效别是什么?”下面l出一些经验方法:
老板试 EBP试 规模试
EBP试 EBP卛_本业务过E(Elementary Business ProcessQ,是源于业务过E领域的术语Q定义如下:【一个h于某一时刻在一个地Ҏ(gu)执行的Q务,用以响应业务事g。该d能够增加可量化的业务价|q且以持久状态留下数据,例如Q批准信用卡的信用额或者确定订购的h】ERP试与老板试cMQ尤其是对业务h(hun)值可量化q一限制而言。用例是在会话过E中完成的Q务。用例可能只需几分钟或一个小时就能完成。正如UP的定义,用例增强可观察或可量化的业务价|由此形成了这L解释Q系l和数据hE_和持久状态?
规模试 用例很少由单独的zd或步骤组成,相反Q用例通常包含多个步骤Q在详述形式的用例通常需?~10|本。用例徏模中的一个常见错误就是仅一pd相关步骤中的一个步骤定义ؓ用例?
试的合理违?nbsp; 管应用中主要用例的定义和分析可以满上q测试,但是常常会出C外。有Ӟ需要ؓ子Q务或常规EBPU别用例中的步骤~写单独的子功能U别用例。例如,诸如“信用卡支?#8221;{子d或扩展可能在多个基本用例中出现。如果有q种现象Q即使不能真正满EBP和规模测试,也需要考虑其分离为单独的用例Qƈ且将其连接到各个基本用例上,以避免文字上的重复?
认证用户q一用例可能无法通过老板试Q但是其步骤极ؓ复杂Q需要引起重视进行细致的分析Q例如需要考虑“单点d”Ҏ(gu)?
应用UMLQ用例图 UML提供了用例图表示法,用以描述用例名称和参与者及其之间的关系Q图6-3Q?【用例图和用例关pd~写用例工作中是ơ要的。用例是文本文档。编写用例意味着~写文本】Flower和Cockburn{世界的用例专安对用例图和用例关pM予重视,而是注重~写文本。借鉴大师l验的同Ӟ单的用例图还是能够ؓpȝ提供z可视的语境图,能够阐述外部参与者及其对pȝ的用。【准则:l制单的用例图,q与参与?目标列表兌。?
用例图是一U优U的系l?font color="#0000cc">语境?/font>(context diagram)Q也是_用例图能够展C系l边界、位于边界之外的事物以及pȝ如何被用。用例图可以作ؓ沟通工P用以概括pȝ及其参与者的行ؓ?
准则Q制?/strong> ?-4为制图提供了。ؓ了明v见,某些人徏议用其他表C法q出外部计机pȝ参与者,?-5所C?
准则Q不要倚重于制图,保持其简?/strong> 再次重申Q用例工作之重在于编写文本,而非囑Ş或用例关pR?
应用UMLQ活动图 UML包含一U有助于工作和业务q程可视化的图:zd图。因为用例涵盖过E和工作分析,所以活动图能够成ؓ~写用例文本的有用的辅助措施Q对于那些描q复杂工作流的业务用例来说更是如此,因ؓ其中涉及大量参与者和q发zd?
动机Q用例还有其他益处么Q语境中的需?nbsp; 用例的动机在于关注谁是关键参与者,其目标和一般的d是什么。除此之外,其本质而言Q用例是一U简单的、被q泛理解的Ş式(情节或场景Ş式)
正如Uses Case:Requirements in Context的书名所暗示的那P在用系l的典型场所的语境下Q用例组l了一l需求。这是g好事Q以面向用户的场景(例如用例Q作为公q索,考虑q组l需求,可以增强寚w求的理解Qƈ且能够提高需求分l的内聚性?
无论用例多么重要Q但它ƈ不是唯一必要的需求制品。最好将非功能性需求、报表布局、领域规则和其他不知所|的元素写入UP的补充性规D明中厅R?
CZQ?Monopoly游戏 见P70
q程Q在q代Ҏ(gu)中如何用用?nbsp; 用例是UP和其他众多P代方法的核心。UP提倡用例驱动开发(use-case driven developmentQ这意味着Q?
》功能需求首先记录在用例Q用例模型)中;无论如何使用Q其他需求技术(例如功能列表Q都是上ơ要?
》用例是q代计划的重要部分。P代的工作是通过选择一些用例场景或整个用例来(部分圎ͼ定义的。同Ӟ用例是预的关键输入?
?strong>用例实现Quse-case realizationQ驱动设计。也是_组设计协作对象和子pȝ是ؓ了执行或实现用例?
》用例通常会媄响用h册的l织
》功能或pȝ试应当W合用例的场?
》ؓ重要用例的最常用场景创徏UI "向导" 或快h式可以方便执行常用Q?
在P代中如何演化用例和其他规D?/strong> 本节重申了进化式q代开发的关键思想Q规D明的工作d在各q代中的旉量和U别。PPT4展示了一个样例(而非真正的解x案)Q表明了如何开发需求的UP{略?
在UP中,提倡在需求讨Z上编写用例?font color="#0000cc">?-7对完成此工作提Z旉和地Ҏ(gu)面的?
何时创徏各种UP制品Q含用例Q?/strong> PPT5描述了一些UP制品Q及其开始和净化的旉表示例?
【在初始阶段如何~写用例Q细化阶D如何编写用例?构造阶D如何编写用例? 研究PPT3Q参考P74?
什么是初始阶段 大多数项目需要一个简短的起始步骤Q在该步骤中要考虑以下几类问题Q?
1、项目的设想和业务案例是什么?
2、是否可行?
3、购买还是开发?
4、粗略估计一下成本:是一万还是十万美元,q是上百万美元?
5、项目应该l下去还是停止?
惌定义设想q大致得出所需的预,必ȝI求。但是,初始阶段的目标ƈ不是定义所有需?/strong>Q或产生可信的预或目计划?
对于是否存在q于化的风险Q其理念是,未来新pȝ的M目标和可行性而言Q只q行以形成合理判断的调查,q能够确定是否值得l箋深入研究卛_Q而深入研I室l化阶段的工作?
大多数需求分析是l化阶段q行的,q且伴以h产品品质的早期编E和试?
因此Q大多数目的初始阶D늚持箋旉相对较短Q例如耗时一周或几周。实际上Q在许多 目中,如果初始阶段的时间超q一周,那么“初始”失M它的意义Q因为初始阶D只需定q个目是否值得认真研究Q而不是真正去深入q行研究Q这工作应留待l化阶段q行Q?
用一句话来概括初始阶D:
预见目的范围、设惛_业务案例
用一句话来概括初始阶D要解决的问题:
涉众是否项目设惛_本达成一_目是否值得l箋q行认真研究
在P代开发和UP中,初始阶段的预和计划是不可靠的。它只不q提供了对工作量的粗略估计,帮助Z军_是否项目l下厅R?
初始阶段的持l时?/strong> 初始阶段主要是ؓ目目标建立一些初始的共同构想Q确定项目是否可行,q决定是否值得q入l化阶段加以认真研究。如果预先就军_目必须q行Qƈ且项目显然是可行的,那么初始阶段?strong>更加短暂。这时候,初始阶段可能只包含第一ơ需求研讨会Qƈ为第一ơP代制定计划,然后快速地q入l化阶段?
初始阶段会创建的制品 PPT2列D了一般在初始阶段Q或l化阶段早期Q会创徏的制品以及各个制品所解决的问题。后l几章将详细解释其中部分制品Q特别是“用例模型”?nbsp; q代开发的一个重要观Ҏ(gu)Q?/strong>在初始阶D只完成其中部分制品Q在后q代中对其进行精化。而且Q除非认定某制品很可能具有实用h(hun)|否则不应该创制品。因为是在初始阶D,所以相关的研究和制品内定w不多?
在初始阶D可能要q行一些编E工作,其目的是创徏“概念验证”原型Q(典型的)通过面向UI的原型来澄清一些需求,以及为关键的“昄d”技术问题做一些编E实验?
是否意味着大量的文? CQ这些制品都是可选的。要有选择地创建对目有价值的制品。因是P代开发,所以重要的不是在初始阶D创建完整的规格说明Q而是形成初始、概略的文。这些文在l化q代中精化,以便响应由早期编E和试得到的极有h(hun)值的反馈?
同样Q创建制品或模型的重点不在于文或图本nQ而是其中蕴含的思想、分析和前期准备。这也正是敏捷徏模的观点Q徏模的最大h(hun)值是增强理解Q而非记录可靠的规D明?
q要注意的是Q可以在以后的项目中部分重用以往目中的制品。一般在不同目中,风险、项目管理、测试和环境q些制品都可能存在大量相g处。所有UP目都应该用相同的名Uͼ以相同方式来l织制品Q例如风险列表、开发案例等Q。这样就可以方便C以往目中找够在新项目中重用的制品?
何时知道自己q不了解初始阶段
1、当认ؓ大部分项目的初始阶段会持l几周或更长?
2、在初始阶段试图定义大部分的需求时
3、期望初始阶D늚预算和计划是可靠?
4、定义架构(应该在细化阶D以q代方式来定义架构)
5、认为正的工作序应该是:1>定义需?nbsp; 2> 设计架构 3>实现
6、没有业务案例或设想制品
7、详l编写所有用?
8、没有详l编写Q何用例,与之相反Q应该编?0%~20%的用例以便获得对问题范围的真实认?
初始阶段中有多少UML初始阶段的目的是攉_的信息来建立共同设想Q决定项目是否l进行,以及目是否值得q入l化阶段来认真研I?nbsp; 初始阶段更关注对基本范围的理解以?0%的需求,q主要是以文字方式表辄。实际上Q本书就是如此,大多数UML囑ְ出现在下一个阶D?-l化阶段
案例研究中涵盖的内容 通常Q应用包括UI元素、核心应用逻辑、数据库讉K以及与外部Y构件的协作。尽OO技术可以用于所有层Q但是这里对OOA/D的介l首要集中于核心应用逻辑层,同时会对其它层进行一些讨论?
对其他层Q如UI层)设计的探讨只限于其与应用逻辑层的接口设计上?strong>Z么要重点探讨核心应用逻辑层的OOA/DQ?
1、其它层通常Ҏ(gu)?q_有极大的依赖性。例如,如果探讨ZJava的Web UI或胖客户UI层的OO设计Q我们还需要了解Struts或Swing{框架的l节。但是对?NET或PythonQ其选择和细节具有巨大差异?
2、相比之下,核心逻辑层的OO设计对各U技术来说是怼?
3、在应用逻辑层语境中学习到基本OO设计技巧适用于所有其他层或构件?
4、当新框架或技术出现时Q其它层的设计方法和模式呈现出快速变化的势?
案例研究{略QP代开?q代学习 本书的组l展Cq代开发的{略。案例研I在多次q代中应用OOA/D。第一ơP代用于一些核心功能,后箋q代扩展q些功能Q图3-2Q?
Z与P代开发协同v来,本书以P代和循环渐进的方式介l分析和设计主题、UML表示法和模式。在W一ơP代里Q介l一l核心的分析设计主题和表C法。第二次q代展开介绍信理cUML表示法和模式。第三个q代亦是如此?
案例一QNextGen POSpȝ
案例二:Monopoly游戏pȝ
?/strong> q代开发是OOA/D成ؓ最?jng)_늚核心Q也是本书所介绍的OOA/D的核心?敏捷实践Q如敏捷建模Q是有效地应用UML的关键。UP是相Ҏ(gu)行的、示范性的q代Ҏ(gu)。本章将对这些主题进行介l?
相对于顺序或“瀑布”QwaterfallQ?/font>生命周期Q?font color="#0000ff">q代和进化式开发(interative and evolutionary developmentQ?/font>寚w分系l及早地引入了编E和试Qƈ重复q一循环。这U方式通常会在q没有详l定义所有需求的情况下假讑ּ发开始,同时使用反馈来明和改进演化中的规格说明?
在P代开发中Q我们依赖于短时快速的开发步骤、反馈和改写来不断明需求和设计。相比之下,瀑布模型提倡在~程之前预先完成需求和设计步骤。一直以来,成功/p|的研I表明,瀑布模型和Y仉目高p|率具有极大关p,对它的推q源于信念和风闻Q而不是具有统计意义的证据。研I证实,q代Ҏ(gu)与较高的成功率、生产率和低~陷率具有关pR?/font>
什么事UPQ?其他Ҏ(gu)能否对其q行补充 软g开发工E描qC构造、部|以及维护Y件的方式?l一q程已经成ؓ一U流行的构造面向对象系l的q代软g开发过E。特别是QRationall一q程QRational Unified Process ,RUPQ是对统一q程的详l精化,q且已经被广泛采U?
UP是十分灵zd开攄Qƈ且鼓励引q其他P代方法中的有用的实践Q诸?font color="#0000ff">极限~程QExtreme Programming,XPQ?/font>、Scrum{等?例如Q在UP目中可以引入XP?font color="#0000ff">试驱动开发(test-driven developmentQ、重构(refactoringQ?/font>?font color="#0000ff">持箋集成Qcontinuous integrationQ?/font>{实c同P也可以引入Scrum的公共项目室Q?#8220;作战?#8221;Q和Scrum日常会议{实c?
概括而言Q本章介lUP源于下述三个理由Q?
1、UP是P代过E。P代开发对本书介绍OOA/D的方式,以及OOA/D的最?jng)_践具有媄响?
2、UP实践提供了如何实施OOA/D的示范结构。这也Ş成了本书的结构?
3、UPh灉|性,可以应用于轻量和敏h法,q些Ҏ(gu)包括其他敏捷Ҏ(gu)Q诸如XP或ScrumQ的实现Q稍后将Ҏ(gu)作更多介l?/font>
什么是q代和进化式开?/strong> q代开?interative development)是UP和大多数其他CҎ(gu)中的关键实践。在q种生命周期Ҏ(gu)中,开发被l织成一pd固定的短期(如三个星期)项目,UCؓq代(iterative)Q每ơP代都产生l过试、集成ƈ可执行的局部系l。每ơP代都h各自的需求分析、设计、实现和试zd?
q代生命周期Z对经q多ơP代的pȝq行持箋扩展和精化,q以循环反馈和调整ؓ核心驱动力,使之最l成为适当的系l。随着旉和一ơ又一ơP代的递进Q系l增量式地发展完善,因此q一Ҏ(gu)也被UCؓq代和增量式开?interative and incremental development)(参见?-1)。因为反馈和调整使规D明和设计不断q化Q所以这U方法也UCؓq代和进化式开?interative and evolutionary development)?
每次q代都生可执行的但不完整的pȝQ它不是已经准备好可以交付的产品。直到多ơP代之后,pȝ才能够合格的用于产品部v?
q代的输Z是实验性的或将丢弃的原型,q代开发也不是构造原型。与之相反,其输出是最l系l的产品子集?
如何在P代项目中处理变更
每次q代选择一组需求,q快速设计、实现和试。在早期q代中,寚w求和设计的选择对于最l期望来说可能ƈ不准。但是,在最l确定所有需求或l过深思熟虑而定义完整设计之前,快速地实施一步的方式可以得到快速反?-来自用户、开发h员和试的反馈?
q种反馈h极高的h(hun)倹{与“推测”完整、正的需求或设计相反Q团队可以从实际构造和试的反馈中Q挖掘出臛_重要和实际的观点Qƈ修改和调整对需求或设计的理解?早期频繁地在“不错。。。但?#8221;中@环,正是改进软g和发C么对涉众有真正h(hun)值的实用方式。然而这q对开发者不断变换方向的无序和反应式开发的认可Q作Z条中间\U是可行的?
除了明确需求之外,负蝲试验证局部设计和实现是否正确Q或者是否需要在下次q代中改变核心架构。最好及早解军_验证h风险的、关键的设计决策Q而P代开发提供了完成q项工作的机制?
因此Q工作是通过一pd有序的构?-反馈--调整循环向前q展的。早期P代中pȝ偏离“正确轨迹”的程度会大于后q代。随着旉的发展,pȝ沿着q一轨迹收敛。如?-2
q代开发的优点
q代开发的优点包括Q?
1、减项目失败可能性,提高生率,降低~陷率。对q代和进化式的研I表明了q一炏V?
2、在早期Q而不是晚期)~解高风险(技术、需求、目标、可用性等{)
3、早期可见的q展
4、早期反馈、用户参与和调整Q会产生更接q涉众真实需求的_pȝ?
5、可控复杂性:团队不会?#8220;分析瘫痪”或长期且复杂的步骤所Ҏ(gu)
6、一ơP代中的经验可以被pȝ地用于改q开发过E本w,q如此反复进行下厅R?
一ơP代的持箋旉和时间定?/strong>
大部分P代方法徏议P代时间在2~6周之间。小步骤、快速反馈和调整时P代开发的主要思想QP代时间过长会破坏q代开发的核心动机q增加项目风险?q代的一个关键思想是时间定?timeboxed)Q或旉固定?
什么是瀑布生命周期 在瀑布生命周期q程中,试图在编E之前(详细定义所有或大部分需求)。而且在通常与编E之前创建出完整的设计。同P会试囑֜开始前定义“可靠?#8221;计划或时间表Q但常常事与愿违?
反馈和改写的必要?/strong>
在复杂、变更系l中Q如大多数Y仉目)Q反馈和调整是成功的关键要素?
1、来自早期开发中的反馈,有助于程序设计h员理解规D明,客户演示也有助于_需求?
2、来自测试中的反馈,有助于开发者精化设计或模型?
3、来自团队处理早期特性过E中的反馈,有助于精化时间表和估?
4、来自客户和市场的反馈,有助于重新定义下一ơP代实现特性的优先U?
-如何q行q化和P代式分析和设?nbsp; q里的介l可能会lh留下q样的印象,即编E前的分析和设计毫无价|但这是与瀑布思维同样偏激的误解。P代和q化式分析设计师中庸之道。这里有个简短的例子Q用以说明在q{良好的UP目中,q代Ҏ(gu)是如何被q用的。这里假讑֜目交付前,最l将?0ơP代?
在第一ơP代之前,召开W一个时间定量的需求工作会议,例如切的定义ؓ两天旉。业务和开发h员(包括首席架构师)需要出席?
1> 在第一天上午,q行高阶需求分析,例如仅仅定用例和特性的名称Q以及关键的非功能性需求。这U分析不可能是完的?
2> 通过咨询首席架构师和业务人员Q从高阶列表中选择10%列表(例如Q?0个用例中?0%Q,q些目要具备以下三U性质QA、具有重要的架构意义Q如果要实现Q我们必设计、构造和试的核心架构) B、具有高业务价|业务真正兛_的特性) C、具有高风险Q例?#8220;能够处理500个ƈ发交?#8221;{)。所选的三个用例可能被标识ؓ:UC2、UC11和UC14?
3>在剩下的一天半内,对这三个用例的功能和非功能性需求进行详l的分析。完成这一q程后,?0%q行了深入分析,90%q行了高阶分析?
在第一ơP代之前,召开q代计划会议Q选择UC2、UC11和UC14的子集,在特定时间内Q例如,四周的时间定量P代)q行设计、构造和试。要注意的是Q因为其中包含大量工作,所以ƈ不是在第1ơP代中p构造出全部三个用例。在选择了特定子集目标后Q在开发团队的帮助下,其分解Zpd更ؓ详细的P代Q务?
在三到四周内完成W?ơP代(选择旉定量Qƈ严格遵守旉Q?
1> 在开始的两天内,开发者和其他成员分组q行建模和设计工作,在首席架构师的带领和指导 下,?#8220;公共作战?#8221;的众多白板上Q画出UML的草图(及其他的模型Q?
2> 然后Q开发者摘掉其"建模帽子"q带?~程帽子"Q开始编E、测试和集成工作q且剩余的时间均用于完成q项工作。开发者将建模草图作ؓ其灵感的LQ但要清楚这些模型只是局部的Qƈ且通常是含p的?
3> q行大量的测试,包括单元试、验收测试、负载测试和可用性测试等?
4> 在结束前的一周,查是否能够完成初始的q代目标Q如果不能,则羃?yu)P代的范围Q将ơ要目标|回d列表中?
5> 在最后一周的星期二,ȝ代码Q必L入、集成和试所有代码,以徏立P代的基线?
6> ?星期三的上午Q向外部涉众演示此局部系l,展示早期可视q展Q同时要求反馈?nbsp;
在第一ơP代即结束时Q如最后一周的星期三和星期四)Q召开W二ơ需求工作会Q对上一ơ会议的所有材料进行复查和_。然后选择h重要架构意义和高业务价值的另外10%?5%的用例,用一C天对其进行详l分析。这工作完成后Q会详细记录下大?5%的用例和非功能性需求。当Ӟq也不是完美的?
于周五上午,举行下一ơ的q代计划会议?
以相同步骤进行第二次q代
反复q行四次q代和五ơ需求工作会Q这样在W四ơP代结束时Q可能已l详l记录了U?0%~90%的需求但只实Cpȝ?0% Q注意,q些大量、详l的需求集是基于反馈和q化的,因此其质量远高于Ua依靠推测而得出的瀑布式规D明)
我们大概推进了整个项目过E的20%。在UP的术语里Q这?font color="#0000cc">l化阶段(elaboration phase)的结束。此Ӟ可以估计q些_的、高质量的需求所需工作量和旉。因为具有依据现实得出的调查、反馈结论ƈq行了早期编E和试Q因此估计能够做什么和需要多长时间的l果会更为可靠?
此后Q一般不需要再召开需求工作会Q需求已l稳定了Q尽需求永q不会被ȝQ。接下来是一pd为期三周的P代,在最后一个周五召开的P代计划会议上选择适宜的下一步工作,每次q代都要反复询问Q?#8220;我们现在所知,下一个三周应该完成的、最关键的技术和业务Ҏ(gu)是什么?”
PPT2-5 中描qCl过20ơP代的目?
利用q种方式、经q早期探索式开发的几次q代之后Q团队将能够更准地回答“什么、多、何?#8221;?
什么是风险驱动和客户驱动的q代计划 UPQ及大多数新Ҏ(gu)Q提?font color="#0000cc">风险驱动Qrisk-drivenQ?/strong>?font color="#0000cc">客户驱动(client-driven)相结合的q代计划。这意味着早期的P代目标要能够识别和降低最高风险,q且能构造客h兛_的可视化Ҏ(gu)?
风险驱动q代开发更为明地包含了以架构Z心(architecture-centricQ?/strong>q代开发的实践Q意味着早期q代要致力于核心架构的构造、测试和E_。ؓ什么?因ؓ没有E_的架构就会带来高风险?
什么是敏捷Ҏ(gu)及其观点 敏捷开?agile development)Ҏ(gu)通常应用旉定量的P代和q化式开发、用自适应计划、提倡增量交付ƈ包含其他提倡敏h(快速和灉|的响应变_的h(hun)值和实践。除此之外,他们q提倡反映简易、轻量、沟通、自l织团队{更多敏h的实践和原则?
Scrum敏捷Ҏ(gu)中的实践范例包括公共目工作室和自组l团队,q些实践通过每日例行会议来协调工作,在例会上要求每位成员回答四个特定的问题? 极限~程QXPQ方法中的实践范例包括结对编E和试驱动开发(test-driven developmentQ?
包括UP在内的Q何P代方法都可以施加以敏L?
什么是敏捷建模 有经验的分析员和建模者了解以下这条徏模的U诀Q?建模Q构建UML草图Q的目的主要是ؓ了理解,而非文档?nbsp; 也就是说Q徏模的真正行ؓ能够q且是应该能够对理解问题或解x案空间提供更好的方式?nbsp;
?Agile Modeling" 一书中Q将q种观点及与之一致的敏捷Ҏ(gu)UCؓ敏捷建模(agile modeling)?q其中包含了以下许多实践和h(hun)|
1?/font>采用敏捷Ҏ(gu)q不意味着不进行Q何徏模,q是个错误理解。Feature-Driven Development、DSDM和Scrum{许多敏h法、一般都包含重要的徏模期。正如Ambler(XP Ҏ(gu)和敏捷徏模的专家)所aQ即便是XPQ可能是最强调徏模的最为知名的敏捷Ҏ(gu)Q的奠基Z认可敏捷建模Qƈ且多q来有大量徏模者都在实践中采用了敏捷徏模?
2?/font>建模和模型的目的主要用于理解和沟通,而不是构建文档?
3?/font>不要Ҏ(gu)有或大多数Y件设计徏模或应用UML。可以将单的设计问题推g到编E阶D,在编E和试q程中解册些问题。只需对设计空间中不常见、困隑֒手的一部分问题徏模和应用UML
4?/font>可能用最单的工具。徏议用支持快速输入和改变?#8220;低能?#8221;创造力增强型的易工兗同Ӟ选择支持大可视空间的工具。例如,最好在白板上草图UMLQ用数码相机捕获图形。(q里 q不是说UML CASE工具或字处理软g不可取或毫无价|但是对于创造性工作来_在白板上画草图更为流畅ƈ便于修改。关键的规则是简单和敏捷Q而不Z用何U技术)
5?/font>不要单独建模Q而是l对在白板上建模Q同时要C建模的目的是发现、理解和׃n大家的理解。小l成员要轮流画草图,以每个人都参与其中?
6?/font>q行的创建模型。例如,在一块白板上勑UML动态视囄交互图,同时在另一白板上勾d补充性的UML静态视囄cd。同时开发这两种模型Q视图)Qƈ不断交替?
7?/font>在白板上用笔画草图时Q应使用“_?#8221;的简单表C法。UMLl节是否_ևq不重要Q关键是建模者能够互相理解,坚持使用单、常用的UML元素?
8?/font>要知道所有模型都可能是不准确的,最l代码或设计会与模型有差异,甚至h极大的差异。只有测试过的代码才能证实真正的设计Q先前绘制的模型N是不完整的,最好只是将其视Zơ探索?
9?/font>开发者应该ؓ自己q行OO设计建模Q而不是创建模型图后交l其他编E者去实现--q是非敏L面向瀑布的方法?
本书中的敏捷建模Qؓ什么用UML草图的快?/strong> 因ؓq些图是Z提高可读性而用工L心绘制的。ؓ了让大家感受真实情况Q本书有时会使用在白板绘制的UML草图的数码快照。这栯然易L差一些,但是可以提醒读者敏捷徏模是很有用的Qƈ且这U方式是案例研究所使用的实际工作方式?
什么是敏捷UP UP的创始hq没有ؓ其赋予重量或非敏捷的含义,管其庞大的可选活动集和制品集会给人留下这U印象。实际上QUP可以采纳和应用可适应性和轻量U的_--敏捷UP。以下是应用的一些示例:
1?/strong>推荐使用UPzd和制品的集。虽然某些项目得益于使用较多的UMLzd和制品,但一般来说应该保持简z。要CQ所有UP制品都是可选的Q除非它们能增加价|否则避免创徏q些制品。应该致力于早期的编E,而非构徏文档?
2?/font>UP是P代和不断q化的,所以在实现前的需求和设计师不完整的。它们是在一pdq代中,Z反馈而生的?
3?/font>以敏捷徏模实践应用UML
4?/font>对于整个目不应有详l的计划。应该制定估计结束日期和主要里程的高阶计划Q称?/font>阶段计划Q,但是不要对这些里E碑详细定义l粒度的步骤。只能预先对一个P代制定更l的计划Q称?strong>q代计划Q。详l计划是׃ơ次q代的调整而完成的?
UP的其他关键实?/strong> UP所倡导的核心思想是:短时间定量P代、进化和可适应性开发。其他一些UP的最?jng)_践和关键概念包括Q?
1、在早期q代中解决高风险和高价值的问题
2、不断地让用户参与评估、反馈和需?
3、在早期q代中徏立内聚的核心架构
4、不断的验证质量Q提早、经常和实际地测?
5、在适当的地方用用?
6、进行一些可视化建模Q用UMLQ?
7、认真管理需?
8、实时变更请求和配置理
什么是UP的阶D?nbsp; UP目其工作和P代组lؓ四个主要阶段Q?
1、初始(InceptionQ?/font>Q大体上的构惟뀁业务案例、范围和模糊评估
2、细化(ElaborationQ?/font>Q已_的构惟뀁核心架构的q代实现、高风险的解冟뀁确定大多数需求和范围以及q行更ؓ实际的评?
3、构造(ConstructionQ?/font>Q对遗留下来的风险较低和比较单的元素q行q代实现Q准备部|?
4、移交(TransitionQ?/font>Q进行beta试和部|?
?-6说明了UP中常用的面向q度表的术语。注意,一个开发周期(以系l发布ؓ产品作ؓl束标志Q由多个q代l成
什么是UPU目 UP描述?strong>U目(discipline)中的工作zdQ例如编写用例。科目是在一个主题域中的一l活动(及相兛_品)Q例如需求分析中的活动。在UP中,制品QartifactQ?/font>是对所有工作品的l称Q如代码、Web囑Ş、数据库模式、文本文、图、模型等?
UP中有几个U目Q本书中只关注以下三个科目中的制品:
1?strong>业务建模Q?/font> 领域模型制品Q应用领域中的重要概念的可视化?
2?strong>需?/font>Q?/font>用以捕获功能需求和非功能需求的用例模型及其补充性的规格说明制品?
3?strong>设计Q?/font>设计模型制品Q用于对软g对象q行设计?
?-7列出了更多的UPU目?nbsp; 在图中,实现表示~程和构建系l,而不是部|Ӏ?strong>环境U目是指建立工具qؓ目定制q程Q也是_讄工具和过E环境?
U目和阶D之间的关系 如图2-7所C,一ơP代的工作会遍历大部分或全部科目。然而,跨越q些U目的相对工作量会随着旉发生变化。自然而然Q早期P代們于更多的需求和设计Q后期P代则较少q行q方面的工作Q因为通过反馈和改写过E,需求和核心已经向于稳定?
UP阶段Q初始、细化等Q的q一主题Q?strong>?-8阐述了对应于各阶D늚相对工作量的变化。请注意Q这只是性意见,而非强制?
UP阶段和科目对本书l构的媄?/strong> 案例研究初始和细化阶Dc其重点是业务徏模、需求和设计U目中的一些制品,因ؓq些都是需求分析、OOA/D、模式和UML的主要应用之处?
下面的列表和?-9描述了本书关于UP阶段的组l?
1、初始阶D对应的章介l需求分析的基本内容
2、P?介绍OOA/D基础和如何ؓ对象分配职责
3、P?的重Ҏ(gu)对象设计Q特别介l一些经怋用的“设计模式”
4、P?介绍各种主题Q例如架构分析和框架设计?
如何定制q程和UP开发案?/strong>
UP中有可选制品或实践?/strong> 当然Q?几乎所有的制品和实践都是可选的。也是_某些UP实践和原则是一成不变的Q例如P代和风险驱动开发以及质量的持箋验证?然而,UP的一个关键内涉|Q所有活动和制品Q模型、图、文。。。)都是可选的--或许除了代码Q?
UP中描q的一l可能的制品可以看作药房里的一l药剂。就像不会有Z加选择地随便吃药,而是要对症下药一P对于UP目Q开发团队应该选择一l能够解军_特定问题和需要的制品。一般来_要关注一l具有较高实践h(hun)值的制品?
定义Q什么是开发案?nbsp; 为项目选择实践和UP制品可以~写为简短文,q称为开发案例(环境U目中的制品Q(PPT01Q可以作为本书所探讨?NextGen目"案例研究中的开发案?
判断你是否理解P代开发或UP 若出C下迹象,表明你ƈ没有理解以敏L采用P代开发和UP的真正含义?
1?/strong>在开始设计或实现之前试图定义大多数需求。同P在开始实C前试囑֮义大多数设计Q试囑֜q代~程和测试之前定义和提交完整的架?
2?/strong>在编E之前花Ҏ(gu)日或数周q行UML建模Q或者认为在l制UML囑֒q行设计时要准确完整地定义及其详l的设计和模型。ƈ且,认ؓ~程只是单机械地其转换Z码的q程
3?/strong>认ؓ初始阶段=需求阶D,l化阶段=设计阶段Q构造阶D?实现阶段Q也是说将瀑布模型叠加于UP之上Q?
4?/strong>认ؓl化的目的是完整仔细地定义模型,以能够在构造阶D将其{换ؓ代码
5?/strong>坚信合适的q代旉长度Z个月之久Q而不是三?
6?/strong>认ؓ采用UP意味着要完成大量可能的zd和创建大量的文档Qƈ且认为UP是需要遵循大量步骤的、正规和J琐的过E?
7?/strong>试图寚w目从开始到l束制定详细计划Q试N所有P代,以及每个q代中可能发生的事情?
20世纪80q代中期以来QCraig帮助了数以千计的开发者,使他们能够应用OOA/D、熟l用UML建模技术、采用P代开发实c?
在结束其街头浪音乐家生涯后QCraig?0世纪70q代开始用APL、PL/I和CICS建立pȝ。从20世纪80q代初期开始,他开始对人工产生兴趣、ƈ用Lisp机器、Lisp、Prolog和Smalltalk建立q知识系l。他也ؓ使用Java?NET、C++和Smalltalk建立pȝ的公司工作过。他在大部分业余旉里担任过Changing Requirement乐队的主韛_他手?
他在加拿大温哥华Simon Fraser大学获得计算机科学学士和士学位?
本书的主要内?/strong> “拥有一把锤子未必能成ؓ架构?#8221;Q这句谚语在对象技术领域同样适用。对创徏对象pȝ来说Q了解面向对象语aQ例如JavaQ是必要的,但不是首先要做的。了?#8220;对象思想”才是关键所在!
本书是对应用了统一建模语言QUMLQ和模式的OOA/D的介l。同Ӟ对于q代开发,本书使用l一q程QUnified ProcessQ的敏捷Ҏ(gu)作ؓCZq代q程?
UML和对象思想 UMLq不是OOA/DQ也不是Ҏ(gu)Q它只是囑Ş表示法?font color="#0000ff">如果没有真正掌握如何创徏优秀的面向对象设计,或者如何评估和改进现有设计Q那么学习UML或者UML CASE工具是毫无意义的。对象思想才是重点和难炏V?/font>因此本书重点阐述对象设计?而且Q我们需要一U用于OOA/D?#8220;软g蓝图”的语aQ这既是一U思考的工具Q也是一U沟通的形式。因此,本书也将探讨如何在OOA/D中应用UMLQƈ늛l常使用的UML表示法?
OOD的原则和模式 应该如何为对象分?font color="#0000cc">职责QresponsibilityQ?/strong>?对象之间应该如何协作Q什么样的类应该做什么样的事情?q些都是pȝ设计中的关键问题Q而本书将会讲授作为经典OO设计之象?font color="#0000cc">?strong>职责驱动设计Qresponsibility-driven designQ?/strong>。同Ӟ某些针对设计问题的,l过反复验证的解x案可以被表示成ؓ最?jng)_늚原则、启C或模式QpatternQ?/strong>Q即问题-解决Ҏ(gu)公式Q这些公式是pȝ化的、典型的设计原则。本书将会通过讲授如何应用模式或原则,使读者更快地学习和熟l用这些基本的对象设计习惯用法?
案例研究 本书对OOA/D的介l是通过一?font color="#0000cc">贯穿全书的案例研IӞongoing case studyQ?/font>来阐q的Qƈ且充分深入到分析和设计中Q考虑和解决了现实问题中o人生畏但必须被考虑和解决的l节?
用例 OOD(以及所有Y件设?与作为其先决zd的需求分?requirement analysis)h紧密联系Q而在需求分析中通常包含用例Quse caseQ的~写。因此,管q些主题q是特定与面向对象的,但也会在案例研究的开始对其进行介l?
q代开发、敏捷徏模和敏捷UP 需求分析和OOA/D需要在某种开发过E的语境中进行描q和实践。在q种情况下,使用著名?font color="#0000cc">l一q程 QUnified ProcessQ的敏捷Q轻量的、灵zȝQ方法作P代开发过E(iterative development processQ的样例Qƈ在这一q程中介l需求需求分析和OOA/D的主题。然而,q里所늛的分析和设计主题对于许多开发过E是通用的,在敏捷UP的语境中学习它们q不影响q些技术对于其他方法的适用性,q些Ҏ(gu)包括Srucm、Feature-Driven Development(FDD)、lean Development、Crystal Methods{等?
重要的学习目?/strong> 在OO开发中Q至关重要的能力是熟l地Y件对象分配职?/font>。ؓ什么? 因ؓ分配职责是必要执行的一Ҏ(gu)动(无论是画UML图时q是q行E序设计Q都要ؓ软g对象分配职责Q,q且它对软g构g的健壮性、可l护性和可重用性具有重要媄响?
什么是分析和设?/strong> 分析QanalysisQ?/font>的是寚w题和需求的调查研究Q而不是解x案?#8220;分析”一ơ含义广泛,最好加以限Ӟ如需求分析(寚w求的调查研究Q或面向对象分析Q对领域对象的调查研IӞ?
设计 QdesignQ?/font>的是满需求的概念上的解决Ҏ(gu)Q在软g斚w和硬件方面)Q而不是其实现。与“分析”相同Q对“设计”一词最好也加以限制Q如面向对象设计或数据库设计?
什么是面向对象分析和设?/strong> 在面向对象分析(object-oriented analysisQ?/font>q程中,的是在问题领域内发现和描q对象(或概念)?
在面向对象设?object-oriented designQ简U对象设?q程中,的是定义软g对象以及它们如何协作以实现需求?
1、定义用?需求分析可能包括h们如何用应用的情节或场景,q些情节或场景可以被~写成用例(use caseQ?/font>。用例不是面向对象制品,而只是对情节的记录。但用例是需求分析中的一U常用工兗?
2、定义领域模?/strong> 面向对象分析x从对象的角度创徏领域描述?/font>面向对象分析需要鉴别重要的概念、属性和兌?nbsp; 面向对象分析的结果可以表CZؓ领域模型Q在领域模型中展C重要的领域概念或对象。需要注意的是,领域模型模型q不是对软g对象的描qͼ它真实世界领域中的概念和想象可视化。因此,它也被称为概念对象模型(conceptual object modelQ?
3、分配对象职责ƈl制交互?font color="#0000cc"> 面向对象设计x软g对象的定?-它们的职责和协作。顺序图(sequence diagram,UML的一U交互图)是描q协作的常见表示法。它展示Y件对象之间的消息,和由消息引v的方法调用?
4、定义设计类?除了在交互图中显C对象协作的动态视囑֤?font color="#0000cc">q可以用设计cdQdesign class diagramQ来有效地表C类定义的静态视图。这样可以描q类的属性和Ҏ(gu)?/font>
什么是UML l一建模语言QUMLQ是描述、构造和文档化系l制品的可视化语a?/font>
在上面的UML定义中,关键Ҏ(gu)可视化这个词QUML是图形化表示法的事实标准Q用来绘制和展示与Y件有关的囑ŞQ以及文字)。本书重点关注UML的常用图、这些常用图中的常用Ҏ(gu)和在未来版本中不太可能变化的核心表C法?
UML定义了各UUML(UML profileQ,q些专用于某些常用主题领域的表C法子集Q例如对EJB使用UML EJB?
在更深入的层ơ上QUML表示法的基础是UML元模?meta-model)Q它描述建模元素的语义,UML元模型主要对模型驱动架构QModel Driven ArchitectureQMDAQCASE工具供应商具有媄响。开发者ƈ不需要对其进行学习?
+ - 1、应用UML的三U方?
UML作ؓ草图 非正式的、不完整的图Q通常是在白板上手l草图)Q借助可视化语a的功能,用于探讨问题或解x案空间的复杂部分?
UML作ؓ蓝图 相对详细的设计图Q用于:1Q逆向工程Q即以UML囄方式对现有代码进行可视化Q其易于理解?Q代码生成(前项工程Q?
对于逆向工程QUML工具d源文件或二进制文Ӟq生成UML包图、类囑֒序图(一般情况下Q。这?#8220;蓝图”能够帮助读者从整体上理解元素、结构和协作?
无论是h工还是用自动工L成代?/font>Q在此之间绘制一些详l的N能够为生成代码的工作提供指导。一般情况下Q代码生成工具用图生成一些代码,然后由开发者编写ƈ填充其他代码?
UML作ؓ~程语言 用UML完成软gpȝ可执行规D明。可执行代码能够被自动生成,但ƈ不像通常一样ؓ开发者所见或修改Qh们仅使用UML“~程语言”q行工作。如此应用UML需要有所有行为或逻辑q行囑Ş化表C的实用Ҏ(gu)Q但是目前在理论、工L健壮性和可用性方面仍然处于发展阶Dc?
UML和银Ҏ(gu)想 旉验真理。UML仅仅是标准的囑Ş化表C法Q用常用符L可视化徏模能够带来极大的帮助Q但它不可能与设计和对象思想同等重要。设计知识是极不d的且更ؓ重要的技能,它ƈ不是通过学习UML表示法或者CASE或MDA工具可以掌握的?font color="#0000cc">如果不具备良好的OO设计和编E技能那么即使用UMLQ也只能d挫劣的设?/font>。如果要深入了解q一主题Q徏议阅?#8220;Death by UML Fever”(UML的发明者Grady Booch亦ؓ认可)?What UML Is and Isn't?" 因此Q本书是对OOA/D和应用UMLq行熟练OO设计的介l?/font>
敏捷建模Qagile modelingQ?/strong>了UML作ؓ草图的方式,q也是用UML的普通方式,而且通常Ҏ(gu)间投入具有高回报Q一般费时较短)。虽然UML工具能够提供帮助Q但是徏议也考虑使用UML的敏捷徏模方法?
2、应用UML的三U透视?UML描述的是原始囄型,如类囑֒序图。它q没有在q些图上叠加建模的透视图。例如,同样的UMLcd表示法既能够描绘现实世界的概念,又能够描lJava中的软gcR?
Systropy面向对象Ҏ(gu)了这一观点。其L是,同一U表C法可以用来描述模型的三U透视囑֒cd
概念透视?/strong> 用图来描q现实世界或x领域中的事物?
规格说明QYӞ透视?/strong> 用图Q用与概念透视图中相同的表C法Q?来描qY件的抽象物或h规格说明和接口的构gQ但是ƈ不约定特定实玎ͼ例如Q非特定为C#或Java中的c)?
实现QYӞ透视?/strong> 用图来描q特定技术中的Y件实现?
在实际设计过E中Q很会使用规格说明透视图(推迟了目标技术的选择Q例如用Javaq是使用.NetQ;大多数面向Y件的UMLN会采用实现透视图?
不同透视图中“c?#8221;的含?/strong> 在原始的UML中,?-6中的矩Ş被称为类QclassQ,但这个术语包含各U现象,如物理事务、抽象概cY件事物、事件等{?
一个方法在原始UML之上d了另一个术语。例如,在UP中,领域模型中的UML框被UCؓ领域模型(domain concept)?font color="#0000cc">概念c(conceptual classQ?/font>。领域模型表C的是概念透视图。设计模型中的UML框被UCؓ设计c(design classQ,设计模型依据建模者的需要,表示的是规格说明透视图或实现透视图?
为清晰v见,本书中与cȝ关的术语与UML和UP保持一_q些术语如下Q?
1、概늱Qconceptual classQ?/strong>--现实世界中的概念或事物。在概念或本质透视图中使用。UP领域模型中包含概늱?
2、Y件类Qsoftware classQ?/strong>--无论在过E还是方法中Q都表示软g构g在规D明或实现透视图中的类?
3、实现类Qimplement classQ?/strong>--特定OO语言中的cR?
Z在某些章中没有大量用UML 本书的主题ƈ不是UML表示法,而是在OOA/D和相关需求分析的语境下,对UML应用、模式和q代q程的全景揭C。需求分析通常先于OOA/DQ因此,本书在开始几章先介绍关于用例和需求分析的重要主题Q然后再后各章中详l介lOOA/D和UML?
可视化徏模的优点 用符h表示说明问题所冒的风险是显而易见的Q绘制或阅读UML意味着我们要以更加可视化的方式工作Q开发我们的脑力Q以便更快地掌握Q主)二维?U表C法中的W号、单元及关系?
q个古老而朴素的道理常常会遗失在大量的UMLl节和工具中。这是不应该的!囑֏以帮助我们更Z利地观察全景Q发现Y件元素或分析之间的联p,同时允许我们忽略或隐藏旁支末节。这是UML或其他图形化语言的本质h(hun)倹{?/strong>