新软件建模技术精.ppt

《新软件建模技术精.ppt》由会员分享，可在线阅读，更多相关《新软件建模技术精.ppt（75页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、新软件建模技术第1页，本讲稿共75页1.1UML和对象思想和对象思想UML是标准的图形化表示法，并不是OOA/D，没有掌握如何创建优秀的面向对象设计，或者如何评估和改进现有设计，那么学习UML或者UML CASE工具是毫无意义的。对象思想才是重点和难点。第2页，本讲稿共75页1.2OOD的原则和模式的原则和模式系统设计中的关键问题：应该如何为对象分配职责（Responsibility）？对象之间应该如何协作？什么样的类应该做什么样的事？模式：某些针对设计问题的，经过反复验证的解决方案可以（和已经）被表示为最佳时间的原则、起始或模式（pattern），即问题-解决方案公式，这些公式是系统化的、典

2、范的设计原则。第3页，本讲稿共75页1.3用例用例OOD（以及所有软件设计）与作为其先决活动的需求分析（requirements analysis）具有紧密联系，而在需求分析中通常包含用例的编写。第4页，本讲稿共75页1.4什么是分析和设计什么是分析和设计分析（analysis）强调的是对问题和需求的调查和研究，而不是解决方案。需求分析：对需求的调查研究。面向对象分析：对领域对象的调查研究。设计（design）：强调的是满足需求的概念（逻辑）上的解决方案（在软件和硬件方面），而不是实现。例如，对数据库方案和软件对象的描述。设计细想通常排斥底层或“显而易见”的细节。最终，设计可以实现，而实现（入

3、如代码）则表达了真实而完整的设计。第5页，本讲稿共75页1.5什么是面向对象分析和设计什么是面向对象分析和设计在面向对象分析过程中，强调的是在问题领域内发现和描述对象（或概念）。例如，在航班信息系统中包含飞机、航班、和飞行员在面向对象设计过程中，强调的是定义软件对象以及如何写作以实现需求。例如，软件对象Plane可以有tailNumber属性和getFlightHistory方法。最后，在实现或面向对象程序设计过程中，会实现设计出来的对象，入Java中的Plane类。第6页，本讲稿共75页第7页，本讲稿共75页1.5面向对象的分析与设计例子 一个简单的例子“掷骰子游戏”（dice game），

4、在这个游戏中游戏者掷出两个骰子。如果总点数为7就赢了，否则就输了。第8页，本讲稿共75页1.5.1定义用例定义用例需求分析可能包括人们如何使用应用的情节或场景，这些情节或场景可以被编写为用例（Use Case）。用例不是面向对象制品，而只是对情节的记录。但用例是需求分析中的一种常用工具。骰子游戏：第9页，本讲稿共75页1.5.2定义领域模型 面向对象分析关注从对象的角度创建领域描述，需要鉴别重要的概念、属性和关联。结果可以表示为领域模型（domain model）（展示重要的领域概念或对象）。领域模型不是对软件对象的描述，而是真是世界领域中的概念和想象的可视化。因此也被称为概念对象模型（con

5、ceptual object model）。第10页，本讲稿共75页第11页，本讲稿共75页1.5.3分配对象职责并绘制交互图 第12页，本讲稿共75页第13页，本讲稿共75页1.5.4定义设计类图定义设计类图第14页，本讲稿共75页2.迭代、进化和敏捷 迭代开发是OOA/D成为最佳实践的核心。敏捷实践是有效应用UML的关键。UP是相对流行的、示范性的迭代方法。相对于顺序或“瀑布”（waterfall）生命周期，迭代和进化式开发对部分系统及早地引入了编程和测试，并重复这一循环。这种方式通常会在还没有详细定义所有需求的情况下开始开发，同时使用反馈来明确和改进演化中的规格说明。依赖于短时快速的开发

6、步骤、反馈和改写来不断明确需求和设计。第15页，本讲稿共75页2.1UP 软件开发过程：描述了构造、部署以及维护软件的方式。统一过程已经成为一中流行的构造面向对象系统的迭代软件开发过程。UP把普遍认可的最佳实践结合起来，成为联系紧密并具有良好文档的过程描述。第16页，本讲稿共75页2.2迭代和进化式开发 迭代开发（iterative development）是UP和大多数其他现代方法中的关键实践。在这种生命周期法中，开发被组织成一系列国定的短期小项目，称为迭代（iteration）；每次迭代都产生经过测试、集成并可执行的局部系统。每次迭代都具有各自的需求分析、设计、实现和测试活动。迭代生命周期

7、基于对经过多次迭代的系统进行持续扩展和精化，并以循环反馈和调整为核心驱动力，使之最终成为适当的系统。随着时间和一次又一次迭代的递进，系统增量式地发展完善，因此这一方法也被称为迭代增量式开发。因为反馈和调整使规格说明和设计不断进化，所以这种方法也被称为迭代和进化式开发。第17页，本讲稿共75页2.3为什么要使用迭代开发 减少项目失败的可能性，提高生产率，降低缺陷率。在早期缓解高风险早期可见的进展早期反馈、用户参与和调整，会产生更接近涉众真是需求的精化系统。可控复杂性：团队不会被“分析瘫痪”或长期且复杂的步骤所淹没。一次迭代中的经验可以被系统地用于改进开发过程本身，并如此反复进行下去。第18页，本

8、讲稿共75页2.4一次迭代持续的时间一次迭代持续的时间在每个开发周期中有一个实用的策略，那就是为这个开发周期加上一个“时间盒”即一段固定的时间。在这个开发周期中所有的工作都应在这个时间内完成。一般来说，两周到两个月是比较合适的时间盒值，如果时间再短一点，将很难完成任务；如果时间再长一些，一个开发周期中遇到的各种问题的复杂性将难以处理，并且得到反馈信息的时间将拖后。要成功实施“时间盒”调度，必须仔细选择所要处理的需求，并确保开发小组对所做出的选择负责。第19页，本讲稿共75页2.5瀑布生命周期瀑布生命周期在瀑布（或顺序）生命周期中，试图在编程之前（详细）定义所有或大部分需求。而通常于编程之前创建

9、出完整的设计（或模型集）。同样，试图在开始前定义“可控的”计划或时间表。但常常是“事与愿违”第20页，本讲稿共75页2.6如何进行迭代和进化式分析和设计如何进行迭代和进化式分析和设计在第1次迭代之前，召开第一个时间定量需求工作会议。在第1次迭代之前，召开迭代计划会议，（选择用例（或子集），在特定的时间内完成）。在3-4周内完成第1次迭代。在第1次迭代即将结束是，召开第2次需求工作会议，对上一次会议的所有材料进行复杂和精化。于周五上午，举行下一迭代计划会议。以相同步骤进行第2次迭代。反复进行4次迭代和5次需求工作会，这样在第4次迭代结束时，可能已经详细记录了约80-90%的需求，但只实现了系统的

10、10%。带该推进了整个项目的20%。在UP术语中，这是细化阶段（elaboration phase）的结束。此后，一般不需要再召开需求工作会议；需求已经稳定了，接下来是一系列为期3周的迭代，在最有一个周五召开的迭代计划会议上选择适宜的下一步工作，每次迭代都要反复询问：“就我么现在所知，下一个3周应该完成的、最关键的技术和业务特性是什么”第21页，本讲稿共75页2.7UP的其他关键实践的其他关键实践在早期的迭代中解决高风险和高价值的问题不断让用户参与评估、反馈和需求在早期迭代中建立内聚的核心架构不断验证质量：提早、经常和实际的测试进行一些可视化建模认真管理需求实行变更请求和配置管理第22页，本讲

11、稿共75页2.8UP阶段阶段初始（Inception）：大体上的构想、业务案例、范围和模糊评估。细化（Elaboration）：已精化的构想、核心架构的迭代实现、高风险的解决、确定大多数的需求以及进行更为实际的评估。构造（Construction）：对遗留下来的风险较低和比较简单的元素进行迭代实现，准备部署。移交（Transition）：进行beta测试和部署。第23页，本讲稿共75页第二部分 第24页，本讲稿共75页1.初始阶段初始阶段初始阶段是建立项目共同设想和基本范围的比较简短的起始步骤。为了在随后的细化阶段哪能够开始编程，它将包括对10%的用例进行分析、关键的非功能需求的分析、业务案例

12、创建和开发环境的准备。在该阶段考虑以下几类问题：项目的设想和业务案例是什么？是否可行？购买还是开发？初略估算一下成本项目应该继续下去还是停止？第25页，本讲稿共75页2.进化式需求进化式需求第26页，本讲稿共75页2.1定义需求定义需求需求（requirement）就是系统（更广义的说法是项目）必须提供的能力和必须遵从的条件。在变更不可避免，涉众意愿不明朗的情况下，UP更推崇“一种系统的方法来寻找、记录、组织和跟踪系统不断变更的需求”。通过迭代巧妙地进行需求分析，而非草率和随意为之。需求分析最大的挑战是寻找、沟通和记住什么是真正的需求，并能够清楚地讲解给客户和开发团队。第27页，本讲稿共75页

13、2.2进化式需求与瀑布式需求进化式需求与瀑布式需求第28页，本讲稿共75页2.3寻找需求可以采用的方法 与客户一同编写用例开发者与客户共同参加需求讨论会请客户代理参加焦点小组向客户演示每次迭代的成果以及求得反馈。第29页，本讲稿共75页2.4需求的类型和种类 需求按照“FURPS+”模型进行分类：功能性（Functional）：特性、功能、安全性可用性（Usability）：人性化因素、帮助、文档性能（Performance）：响应时间、吞吐量、准确性、有效性、资源利用率。可支持性（Supportability）：适应性、可维护性、国际化、可配置性。第30页，本讲稿共75页2.4需求的类型和种

14、类(续)“+”是指一些辅助性的和次要的因素：实现（Implementation）：资源限制、语言和工具、硬件等。接口（Interface）：强加于外部系统接口之上的约束。操作（Operation）：对其操作设置的系统管理。包装（Packaging）：授权（Legal）：许可证或其他方式。在进行架构分析的时候，质量属性对系统架构具有极大影响。功能性需求和非功能性需求第31页，本讲稿共75页2.5UP制品如何组织需求 用例模型：一组使用系统的典型场景。主要用于功能（行为）需求补充性规格说明：用例之外的所有内容。词汇表：重要的术语。设想：概括了高阶需求，这些需求在用例模型和补充性规格说明中进行细化。

15、也概括了项目的业务案例。帮助快速了解项目的主要思想。业务规则：描述凌驾于某一软件项目的需求或政策。第32页，本讲稿共75页3用例 用例是文本形式的情节描述，用以说明某参与者使用系统以实现某些目标。广泛应用于需求的发现和记录中。不是图形，而是文本。通过编写使用系统实现用户目标的情节来发现和记录功能性需求，也就是使用的案例。第33页，本讲稿共75页3.1定义：参与者、场景和用例 参与者（actor）是某些具有行为的事物，可以是人（由角色标识）、计算机系统或组织。场景（scenario）是参与者和系统之间的一系列特定的活动和交互，也称用例实例（Use case instance）。是使用系统的一个特

16、定情节或用例的一条执行路径。用例（Use case）就是一组相关的成功和失败场景的集合，用来描述参与者如何使用系统来实现其目标。第34页，本讲稿共75页3.2用例和用例模型用例和用例模型用例模型是所有书面用例的集合，是系统功能性和环境的模型。用例是文本文档，而非图形；用例建模主要是编写文本的活动，而非制图。用例模型可以包含UML的用例图，以显示用例和参与者的名称及其关系。UML用例图可以为系统及其环境提供良好的语境图（context diagram：显示了领域内的广义应用（或者是目标系统）和与之通信的其他实体或抽象物之间的数据流。），也为按名称列出用例提供了快捷方式。不是面向对象所特有的。第3

17、5页，本讲稿共75页3.3为什么使用用例为什么使用用例缺少用户参与用户参与是项目失败的主要原因之一，所以任何有利于用户参与的方法是绝度值得的。用例是一中优秀的方法，使领域专家或需求提供者自己编写（或参与编写）用例称为可能，并使这项工作难度降低。用例的另一个价值是强调了用户的目标和观点。“谁使用系统，他们使用的典型场景是什么？他们的目的是什么？”（以客户为中心）。用例被推荐作为发现和定义需求的核心机制。第36页，本讲稿共75页3.4参与者的三种类型 主要参与者（primary actor）：具有用户目标，并通过使用系统的服务实现。（发现驱动用例的用户目标）协助参与者（supporting act

18、or）：为系统提供服务。（为了明确外部接口和协议）幕后参与者（offstage actor）：在用例行为中具有影响或利益。（）为了确保满足所有的重要事物第37页，本讲稿共75页3.5表示法：用例的三种常用形式表示法：用例的三种常用形式摘要：简洁的一段式概要，常用于主成功场景。使用时机：在早期需求分析中，为快速了解主题和范围。非正式：非正式的段落式。用几个段落覆盖不同场景。使用时机：在早期需求分析中，为快速稍微详细了解主题和范围。详述：详细描述所有步骤及各种变化，同时具有补充部分，如前置条件和成功保证。使用时机：确定并以摘要形式编写了大量用例后，在第一次需求讨论会中，详细编写其中少量具有重要架构

19、意义和高价值的用例。（教材P49-55）第38页，本讲稿共75页3.6发现用例发现用例1）选择系统边界。2）确定主要参与者；3）确定每个主要参与者的目标；4）定义满足用户目标的用例，根据其目标对用例命名。通常，用户目标级的用例和用户目标是一一对应的。第39页，本讲稿共75页3.7测试有用的用例测试有用的用例老板测试：EBP（基本业务过程）测试：一个人于某个时刻在一个地点所执行的任务，用以响应业务事件。该任务能增加可量化的业务价值，并以持久状态留下数据。用例不是单独的一小步；如：删除一条记录用例主成功场景应该是5-10步骤；用例不能持续数日或多个会话过程；第40页，本讲稿共75页3.8活动图活动

20、图活动图：U ML包含一种有助于使工作流和业务过程可视化的图用例涵盖过程和工作流分析，所以活动图能够称为编写用例文本的有用的辅助措施。第41页，本讲稿共75页第42页，本讲稿共75页3.9在迭代过程中如何使用用例在迭代过程中如何使用用例用例驱动开发:功能需求首先记录在用例；用例是迭代计划的重要部分。迭代工作是通过选择一些用例场景或整个用例来定义的。用例实现驱动设计：设计协作对象和子系统是为了执行或实现用例；用例通常会影响用户手册的组织；为重要用例的最常用场景创建UI“向导”或快捷方式可以方便执行常用任务。第43页，本讲稿共75页4迭代1领域模型 领域模型是OO分析中最重要的和经典的模型。确定一

21、组概念类是OO分析的核心。阐述了领域中的重要概念；可以作为设计某些软件对象的灵感来源；领域模型的范围限定于当前迭代所开发的用例场景；能够不断演进用以展示相关的重要概念。第44页，本讲稿共75页4.1什么是领域模型 对领域内的概念类或现实世界中的对象可视化表示。也称概念模型、领域对象模型和分析对象模型。UML表示法，领域模型被描述为一组没有定义操作（方法的特征标记）的类图，它可以展示：领域对象或概念类概念类之间的关联概念类的属性。第45页，本讲稿共75页4.1什么是领域模型（续）领域模型是可是化字典，表示领域的重要概念、领域词汇和领域的内容信息。领域模型不是软件对象。领域模型不是数据模型：不会排

22、除需求中没有明确要求记录其相关信息的类；不会排除没有属性的类；（充当纯行为角色的概念类）第46页，本讲稿共75页4.2概念类概念类概念类（conceptual class）是思想、事物或对象，可以从符号、内涵和外延来考虑。符号：表示概念类的词语或图形；内涵：概念类的定义；外延：概念类所适用的一组示例；第47页，本讲稿共75页4.3为什么要创建领域模型 降低与OO建模之间的表示差异：领域层软件类的名称要源于领域模型中的名称，以使对象具有源于领域的信息和职责。第48页，本讲稿共75页4.4如何创建领域模型 以当前迭代中所要设计的需求为界：寻找概念类将其绘制为UML类图中的类；添加关联和属性。第49

23、页，本讲稿共75页4.5如何找到概念类 重用或修改现有模型；使用分类列表；（P104-105）确定名词短语。（P105-106）第50页，本讲稿共75页4.6准则：报表对象准则：报表对象模型中是否要包模型中是否要包括括“票据票据”票据是POS领域的重要术语，但也许它只是销售和支付数据的报表，因此是一种信息的重复。是否应该将票据包含在（当前迭代周期）领域模型中？第51页，本讲稿共75页4.7使用领域术语 第52页，本讲稿共75页4.8属性与类 在创建领域模型常犯的错误：把应该是概念类的事物表示为属性。准则：任务某概念类X不是现实世界中的数字或文本，那么X可能是概念类而不是属性。比如：Store（

24、商店是否作为Sale的一个属性）？Destination（目的机场）是否应作为Flight（航班）的一个属性？第53页，本讲稿共75页4.9“描述”概念类 描述类：包含描述其他事物的信息。为什么要使用描述类？在以下情况下需要增加描述类：需要有关商品或服务的描述独立于任何商品或服务的实例。删除其所描述事物的实例后，导致信息丢失，而这些信息是需要维护的，但是被错误地与所删除的事物关联起来。减少冗余或重复信息。第54页，本讲稿共75页4.10销售点终端问题域中的后选概念 POSTITEMStoreSalePaymentProductCatalogProductSpecificationSalesLi

25、neItemCashierCustomerManager 第55页，本讲稿共75页4.10关联关联关联（association）是类（类的实例）之间的联系，表示有意义和值得关注的连接。关联能够满足当前所开发场景的信息需求，并且有助于理解领域。UML中，关联被定义为“两个或多个类元之间的语义联系，涉及这些类元实例之间的连接”。第56页，本讲稿共75页4.11何时需要关联 由于领域模型是从概念角度出发的，所以是否需要记录关联，要基于现实世界的需要，而不是基于软件的需要（尽管在实现过程中，会有出现大量对关联的需要）。准则：在领域模型中要考虑如下关联：如存在需要保持一段时间的关系，将这种语义表示为关联

26、（“需要记住”的关联）；从常见关联类表中派生出的关联。准则：应该避免加入大量关联。关联不是关于数据流、数据库外键联系、实例变量或软件中的对象连接语句；关联声明的是针对现实领域从纯概念的角度看有意义的关系。这些关系大部分将作为（设计模型和数据模型中的）导航和可见性路径在软件中加以实现。领域模型不是数据模型；添加关联是为了突出对重要关系的理解，而非记录对象或数据结构。第57页，本讲稿共75页4.12关联表示法关联表示法关联被表示为类之间的连线。多重性：表示在特定时刻（而不是在一段时间之内）有效关系的实例数量。关联的末端可以包含多重性表达式：指明类实例之间的数量关系。命名：“类名-动词短语-类名”角

27、色：关联的每一端称为角色第58页，本讲稿共75页第59页，本讲稿共75页4.13属性 属性是对象的逻辑数据值。确定概念类的属性能够满足当前所开发场景的信息需求。当需求建议或暗示需要记住信息时，引入属性。第60页，本讲稿共75页4.14属性类型 领域模型中的属性通常应该是简单数据类型。简单数据类型指的是一组值，而这组值的标识本身不具有任何意义。第61页，本讲稿共75页4.15何时定义新的数据类型何时定义新的数据类型在领域模型里，把最初被认为是数字或字符串的数据类型表示为新的数据类型：由不同的小节组成；具有与之相关的操作；具有其他属性；单位数量；具有以上性质的一个或多个类型的抽象。第62页，本讲稿

28、共75页4.16任何属性都不表示为外部键 领域模型里的属性不应该用于表示概念类的关系。应使用关联而不是属性来表示类型关联。第63页，本讲稿共75页4.17对数量和单位建模 大部分用数字表示的数量不应该表示为纯数字。一般做法：把数量表示为一个单独的Quantity（数量类），并且将该类关联到Unit（单位类）。第64页，本讲稿共75页5系统顺序图系统顺序图是系统调查过程的一部分，这个调查过程主要是查明要建立的系统是一个什么样的系统，因此，系统顺序图是分析模型的一部分。展示了参与者向系统发起的事件。系统顺序图（system sequence diagram）展示了在一个特殊的用例场景（用例执行过程

29、的一个特定实例或实现路径用例生效的一个真实例子）中系统外部参与者发起的事件、事件的顺序以及各个系统之间的交互时间等。在顺序图中，所有的系统都被当作黑盒子看待，顺序图的重点是参与者发起的跨越系统边界的事件第65页，本讲稿共75页第66页，本讲稿共75页5.1系统行为系统行为在进行逻辑设计之前软件应用系统将如何工作，必须对系统行为进行调查，并且要将系统行为定义为一个“黑盒子”。系统行为（system behavior）描述了系统做什么，而不解释系统怎么做。系统顺序图是对系统行为所做的描述的一部分。第67页，本讲稿共75页5.2系统事件和系统操作系统事件（system event）是有某个参与者发起

30、的指向某个系统的输入事件。一个事件的发生能够触发一个响应操作的执行。系统操作（system operation）是系统为响应一个事件而执行的一个操作。第68页，本讲稿共75页5.3如何建立一个系统顺序图 1）将系统表示为一个黑盒子，在盒子下划一条线2）识别出所有直接对系统进行操作的参与者。在每个参与者下划一条线3）根据用例的典型事件发生过程的描述，找出每个参与者所发起的（外部）事件。将他们标在图中。第69页，本讲稿共75页5.4契约 契约是一个描述某个操作应该得到什么结果的文档。经常采用叙述体，强调发生了什么，而不是如何发生。通常契约是用前置和后置条件中描述的状态变化表达。契约可以用来描述一个

31、单独的软件类方法，也可以用来描述规模更大的系统操作。第70页，本讲稿共75页5.5系统操作契约 描述了当一个系统操作被调用时整个系统的状态变化。（后置条件）第71页，本讲稿共75页5.6契约举例-enterItem如果是一次新的销售交易，一个Sale实例被创建如果是一次新的销售交易，新生成的Sale实例与POST发生关联一个SalesLineItem实例被创建SalesLineItem实例与Sale实例形成关联该SalesLineItem实例的quantity属性被设置SalesLineItem实例与一个ProductSpecification实例发生关联，这个关联建立在2者UPC匹配的基础上

32、第72页，本讲稿共75页5.7后置条件与概念模型后置条件的表达要符合概念模型语境：什么实例可以被创建？什么关联可以被形成？实例的创建与撤消属性的修改关联的形成与破裂第73页，本讲稿共75页5.8StartUp的契约一个Store、一个POST、一个ProductCatlog和一个ProductSpecification的实例被创建ProdcutCatalog与ProductSpecification之间形成关联Store与ProductCatlog之间形成关联Store与POST之间形成关联POST与ProductCatlog之间形成关联第74页，本讲稿共75页5.9前置条件前置条件定义了操作开始时对系统状态所做的假设。第75页，本讲稿共75页