软件工程教案范本

教师备课教案本

教师授课计划*课程名称软件工程学分3课程类型1、普通教育必修课（）；2、学科基础必修课（）；3、专业方向课（√）；4、学科基础选修课（）；5、素质教育选修课（）；6、专业选修课（）。学时分配总学时：48；课堂讲授：32学时；实践（验）课16学时授课起止周1-16授课班级软件工程班级人数56,69,50授课总次数*16教材名称《软件工程案例教程：软件项目开发实践第2版》作者韩万江姜立新出版时间2011年10月13日章节基本内容计划学时1软件工程总揽（软件工程知识体系，软件工程的三段论，方法、过程和工具的概述）62软件开发模型及可行性研究2软件需求（需求定义，需求层次，需求建模，需求规格说明，需求验证和变更控制）43分析建模（领域建模，架构设计）44软件设计（设计模式的应用,子系统设计）86软件编码（编码方法，编码过程）47软件测试、发布与维护（测试方法，测试级别）4考核要求（根据课程实际情况，不做要求的项目可不写）：1、平时成绩的构成比例和考核方式；20%考勤和读书笔记2、期中成绩的构成比例和考核方式；3、期末成绩的构成比例和考核方式；50%综合课程设计4、实验成绩的构成比例和考核方式。30%上机实验。填表日期：2015年3月1日章节名称第一章总揽（4次课）教学目的讲解软件工程三个基本要素，通过比较各种软件工程方法的优缺点来给出面向对象软件工程方法论。同时讲解各种软件过程模型，以及uml建模语言的相关知识。教学重点与难点软件工程的三个基本要素面向对象软件工程思想，学会以对象的方式来思考问题UML表示法教学内容与过程设计教学内容与过程设计软件工程的成果是为软件设计和开发人员提供思想方法和工具，而软件开发是一项需要良好组织、严密管理且各方面人员配合协作的复杂工作。软件工程正是指导这项工程的一门科学。一、软件工程知识体系（1）需求定义为解决真实世界问题而必须展示的特性。（2）设计既是“定义一个系统或组件的体系结构、组件、接口和其它特征的过程”，又是“这个过程的结果”。（3）软件构造指通过编码、验证、单元测试、集成测试和排错的组合，详细创建一个可以工作的、有意义的软件。（4）软件测试由在有限测试用例集合上，根据期望的行为，对程序的行为进行的动态验证组成，测试用例是从实际上是无限的执行域中适当的选择出来的。（5）软件一旦投入运行，就可能出现异常，运行环境可能发生改变，用户会提出新的需求。生命周期的维护阶段从软件交付时开始，但维护活动出现得还要早。（6）软件配置管理（SoftwareConfigurationManagement，SCM）是为了系统地控制配置的变更和维护配置在整个系统的生命周期中的完整性和可追踪性，而标识软件在时间上不同点的配置的学科。（7）软件工程管理知识域处理软件工程的管理与度量，虽然度量是所有知识域的一个重要方面，但在这里涉及的是度量程序的主题。（8）软件工程过程的知识域涉及软件工程过程本身的定义、实现、评定、度量、管理、变更和改进。（9）软件工程工具和方法知识域包括软件工程工具、软件工程方法。（10）软件质量知识域处理跨越软件生命周期过程的软件质量的考虑，由于软件质量在软件工程中无处不在，其它知识域也涉及质量问题，读者可以注意到本知识域到其它知识域的指示器。考核方式：组队，通过在整个项目的实施过程中不断贯彻软件工程的思想，达到培养团队开发的目的。讨论：小组人数最好多于3人，这是基于以下事实：给延期的项目增加人手会使项目进一步延期。因为向项目中增加人手，就必须花时间来进行培训。因此最终结果变成了：新增人员贡献非常慢，即使他们的效率确实很高时，那也只是耗尽了原有程序员的时间和精力。而且，项目中的程序员越多，程序员之间的相互交流就越复杂。该事实诠释了一部软件工程经典著作的书名，《TheMythicalMan-Month》即人月神话。该书指出：虽然我们采用人月（peoplepermonth）为单位来安排人手，但是每个人对软件的贡献各不相同，所以这些人月也不尽相同。在项目后期加入的人员更是如此，这些人的贡献几乎可以忽略不计。二、软件工程概述瓦茨·S·汉弗莱在IBM工作了27年，负责管理IBM全球产品研发。离任后，受美国国防部委托，加入卡内基·梅隆大学软件工程研究所（SEI），领导SEI过程研究计划，并提出了能力成熟模型（CMM）思想。在CMM浪潮席卷软件工业界之时，他又力推个人软件过程（PersonalSoftwareProcess，PSP）和团队软件过程（TeamSoftwareProcess，TSP），成为软件开发人员和开发团队的自修宝典。强调：这里需要注意“复杂”两个字，过于简单的应用没有必要是结构复杂化，高级的体系结构、框架、设计模式都是为复杂系统准备的。软件的复杂性：软件是一个庞大的逻辑系统，此外，软件主要依靠人脑的“智力”构造出来，多种人为因素使得软件难以统一化，更增加了其复杂性。软件的复杂性使得软件产品难以理解，难以生产，难以维护，更难以对生产过程进行管理。许多软件项目在某些方面非常复杂。例如，软件所涉足的应用领域往往包含复杂的专业知识，而懂得应用领域专业知识的人很可能不是实际编写软件的人。所以，这些领域的专家必须和负责软件开发的技术人员交流自己的需求。交流的过程是复杂的，软件开发人员只有在理解了用户面临的问题和需求后，才能动手开发软件。最后，许多进行中的软件项目规模非常大，不可能由一个人独立完成，因而开发技术小组必须将开发任务分成易于管理的模块，当各个部分全部完成后，将它们组装成可以协同工作的整体。将一个大项目分割成几个小部分，每个小部分由不同的人来开发，并且保证这些部分可以在一起工作，这个工程成为软件开发过程另一个复杂的来源。软件发展过程强调软件工程学科的发展没有停止，而且这里面没有教条，只有实践。举例：1、伦敦股票交易系统当初预算4.5亿英镑，后来追加到7.5亿英镑，历时五年，但最终还是失败，导致伦敦股票市场声誉下跌。2、2007年北京机场信息系统瘫痪。2007年10月10日13时28分，设在北京首都国际机场的中国民航信息网络股份公司离港系统突然发生故障，短短50分钟内，北京、广州、深圳、长沙机场至少84个离港航班发生延误。该系统是由美国某家公司研发，此事件引发信息系统安全的担忧。3、2008年北京奥运会售票系统于2007年10月30日上午11时瘫痪：北京奥运会的指定独家票务供应商——北京歌华特玛捷票务公司成立于2006年9月，由美国特玛捷公司、中体产业股份有限公司及北京歌华文化发展集团三家出资构建而成。售票系统瘫痪事件发生后，公众普遍质疑该公司是否具备承担08年北京奥运会的票务销售能力。三、软件工程三个要素——方法、工具、过程。软件工程是一门建立在以质量焦点为基础，分过程、方法和工具三个研究层次的综合技术。软件工程的基层是过程层，软件过程层是将方法和技术结合在一起的凝聚层，使得软件能够合理地、及时地开发出来。软件方法：在软件开发过程中所采用的技术，例如结构化的方法、面向对象的方法。软件过程：在软件产品生产过程中，软件人员所进行的一系列的软件工程活动。软件工具：在软件开发过程中为了实现某些方法而采用的手段，例如CASE工具，UML以及Rose等。讨论：一个有争议的观点：在软件开发中，最重要的因素不是程序员采用的工具、技术和语言，也不是过程，而是程序员自身的质量。这一观点来源于《peopleware》人件。其中说道“我们工作中最重要的问题与其说是技术问题，还不如说它本质上是社会问题。”并提出了“人员的作用远远大于其他任何因素”。这本书还有一些独到的见解，比如“工作环境对工作效率和产品质量也有影响”。例如，“最好团队的工作空间是最差团队的1.7倍（测量可用地板空间），而最好团队的表现是最差团队的2.6倍。软件工程的基本原理用分阶段的生命周期计划严格管理2.坚持进行阶段评审3.实行严格的产品控制4.采用现代程序设计技术5.结果应能清楚地审查6.开发小组的人员应该少而精7.承认不断改进软件工程实践的必要性四、软件方法论软件描述的就是现实业务在计算机中的映射，说起来简单，做起来很难。因为现实业务越来越复杂，而用户希望对软件的操作是越直接越好。软件分析设计方法的演变：1、没有方法。即意大利面条：SpaghettiCode，意指包含复杂庞大控制结构，杂乱无章的代码，特别是大量使用goto语句的代码等等。2、功能分解法功能分解＝功能＋子功能＋功能接口以系统需要提供的功能为中心来组织系统。适用于功能稳定的应用领域，如科学计算等。缺点：开头容易，结束难。对众多领域而言，功能易变。如企业管理和商业管理。对需求变化的适应能力很差。局部错误和局部修改很容易产生全局性的影响。重视功能，忽略数据。【举例】工资支付系统：更新工资信息；发放工资。更新工资信息：检查员工信息；提交工作记录；计算应发工资。发放工资：检查员工信息；计算应发工资；打印工资单；登记领取。3、数据流法：又称作结构化分析。基本策略是跟踪数据流，即研究问题域中数据如何流动以及在各个环节上进行何种处理，从而发现数据流和加工。4、信息建模法：信息建模＝实体（对象）＋属性＋关系＋父类型/子类型＋关联对象由实体－关系法发展而来。与数据库设计有很深的渊源。核心概念是实体和关系，实体描述问题域的事物，包含属性。关系描述事物之间在数据方面的联系，也可以带有属性。重视实体，而忽略功能。5、面向对象方法：面向对象方法的出发点和基本原则，是尽可能模拟人类习惯的思维方式，使开发软件的方法与过程尽可能接近人类认识世界解决问题的方法与过程，也就是使描述问题的问题空间(也称为问题域)与实现解法的解空间(也称为求解域)在结构上尽可能一致。五、面向对象的基本概念（1）对象在应用领域中有意义的、与所要解决的问题有关系的任何事物都可以作为对象，它既可以是具体的物理实体的抽象，也可以是人为的概念，或者是任何有明确边界和意义的东西。例如，一名职工、一家公司、一个窗口、一座图书馆、一本图书、贷款和借款等，都可以作为一个对象。总之，对象是对问题域中某个实体的抽象，设立某个对象就反映了软件系统保存有关它的信息，并具有与它进行交互的能力。对象的定义对象是封装了数据结构及可以施加在这些数据结构上的操作的封装体，这个封装体有可以唯一标识它的名字，而且向外界提供一组服务。属性表示对象的性质，属性值规定了对象所有可能的状态。对象的操作是指该对象可以展现的外部服务。例如，大型客机可视为对象，它具有位置、速度、颜色、容量等属性，对于该对象可施行起飞、降落、加速、维修等操作，这些操作将或多或少地改变飞机的属性值(状态)。（2）类是具有相同数据结构和相同操作的一组相似对象的抽象。即表示某些对象在属性和操作方面的共同特征。例如：直升飞机、大型客机、轰炸机可归为飞行器类。共同属性有：位置、速度和颜色等共同操作有：起飞、降落、加速和维修等类是在对象之上的抽象，有了类以后，对象则是类的具体化，是类的实例。把一组对象的共同特性加以抽象并存贮在一个类中的能力，是面向对象技术最重要的一点！（3）消息对象之间进行通讯的一种构造叫做消息。当一个消息发送给某个对象时，包含要求接收对象去执行某些活动的信息。接收到消息的对象经过解释，然后予以响应。这种通讯机制叫做消息传递。发送消息的对象不需要知道接收消息的对象如何对请求予以响应。访问一个方法的过程称为向这个对象发送一个消息。例如：MyCircle.Show(Green)，MyCircle是接收消息的对象的名字，Show是消息名，Green是消息的变元。消息的理解A）如何要求对象完成一定的处理动作？对象间如何进行联系？所有这一切都只能通过消息传递来实现。B）传递消息的对象称为发送者，接受消息的对象称为接受者。C）消息中只包含传递者的要求，它告诉接受者需要哪些处理，但并不指示接受者应该怎样完成这些处理。D）消息完全由接受者解释，接受者独立决定采用什么方式完成所需的处理，发送者对接受者不起任何控制作用。（4）封装封装帮助你管理复杂度的方法是不让你看到那些复杂度。在面向对象的程序中，把数据和实现操作的代码集中起来放在对象内部。一个对象好像是一个不透明的黑盒子，表示对象状态的数据和实现操作的代码与局部数据都被封装在黑盒子里面，从外面是看不见的，更不能从外面直接访问和修改这些数据和代码。使用对象的时候只需要知道他向外界提供的接口的形式，无须知道它的数据结构细节和实现操作的算法。信息隐藏的一个例子：假设你有一个程序，其中的每个对象都是通过一个名为id的成员变量来保存一种唯一的ID。这种设计方法是用一个整数来表示ID，同时用一个名为g_maxId的全局变量来保存目前已分配的ID的最大值。每当创建新的对象时，你只要在该对象的构造函数中简单地使用id=++g_maxId，就肯定能获得一个唯一的ID值，这样设计有没有问题？问题：1、如果你想把某些范围的ID留做它用该怎么办？2、如果你想使用非连续的ID来提高安全性？3、如果你想重新使用已销毁对象的ID？4、如果你的程序是多线程的，这种方法也不是线程安全的。创建新ID的方法就是一种你应该隐藏起来的设计决策。如果你在程序中到处使用++g_maxId，你就暴露了创建新ID的方法。相反，如果你在程序中都使用id=NewId()，那么就把创建新ID的方法隐藏起来了。再假设你发现需要把ID的类型由整型改为字符串。此时你会想到应该隐藏ID的类型。在C++里面，你可以简单地使用typedef把ID定义为IdType，或者定义一个IdType的类。（5）继承广义地说，继承是指能够直接获得已有的性质和特征，而不必重复定义它们。在面向对象技术中，继承是子类自动地共享基类中定义的数据和方法的机制。（6）多态“Thisabilitytomanipulatemorethanonetypewithapointerorareferencetoabaseclassisspokenofaspolymorphism”(《C++Primer》第838页)。即用基类的指针/引用来操作多种类(基类和其派生类)的对象的能力称之为多态。它是从语言实现的角度来考虑的。“polymorphismprovidesanotherdimensionofseparationofinterfacefromimplementation,todecouplewhatfromhow”(《ThinkinJava》3rdedtion)，即多态提供了另外一种分离接口和实现的尺度，即把“做什么”与“怎么做”分开。它是从设计的角度考虑的。“TheabilitytousethesameexpressiontodenotedifferentoperationsisreferedtoasPolymorphism”，(《Object-OrientedMethodsPrinciples&Practice》3rdEdition，第16页)。简单的说，多态就是“相同的表达式，不同的操作”，也可以说成“相同的命令，不同的操作”。这是从面向对象的语义的角度来看的。三种说法分别从不同的角度来阐述了多态的实质。其中第三种说法尤为确切：相同的表达式—函数调用，不同的操作——根据不同的对象就有不同的操作比如在公司中有各种职责不同的员工(程序员，业务员，文管等)，他们“上班”时，做不同的事情(也可以看作是一种业务逻辑)，我们把他们各自的工作都抽象为"上班"，关系如下：不恰当的比喻：OO的精髓是继承、封装和多态。继承就是说：你的爱人会继承做你女朋友时的相当多的优点，因为这些优点对你都是public的，但同时她也会继承以前的更多的缺点，因为其中很多缺点对你是protected，继承后才让你能访问。封装就是说：许多不想让你知道的东西她会封装起来，你只能通过她提供的有限的接口来访问到被接口函数做了手脚的东西。多态就是说：在她心情不同时，你去访问以她为参数的一个函数得到的结果是不同的。比如对她说“我爱你”。六、软件过程过程模型的思想只有两种：顺序和迭代。顺序：一年的时间，分成4个阶段，每个阶段完成一项任务。迭代：一年的时间，分成4个阶段，每个阶段作为一次迭代周期，每个迭代周期完成一系列任务。选择顺序方法的理由：1、需求相当稳定2、设计直截了当，而且理解透彻。3、开发团队对于这一应用领域非常熟悉。4、项目的风险很小。5、后期改变需求，设计和编码的代价很可能较昂贵。选择迭代方法的理由：1、需求并没有被理解透彻，或者出于其他理由你认为它是不稳定的。2、设计很复杂，或者有挑战性。3、开发团队对于这一应用领域不熟悉。4、项目包含许多风险。5、后期改变需求，设计和编码的代价很可能较低。1、瀑布模型瀑布模型的特点：阶段间具有顺序性和依赖性；尽可能推迟程序的物理实现；基于文档驱动的模型。瀑布模型的缺点：传统的瀑布模型过于理想化，实际的瀑布模型是带“反馈环”的。需求具有变更性，无法在最初就准确无误的确定下来。最终开发出的软件产品可能并不是用户真正需要的。所以瀑布模型的采用，一定要保证需求必须是准确定义和相对稳定的。2、快速原型模型快速原型模型是不带反馈环的，软件产品的开发基本上是线性顺序进行的。因为原型系统已经通过与用户交互而得到验证，据此产生的规格说明文档正确地描述了用户需求。快速原型模型的本质就是“快速”，一旦需求确定了，原型将被抛弃。制作原型：制作原型是指开发出系统中关键功能的实际模型。例如开发出一部分用户界面的原型可以判断系统的可用性，开发出关键算法的原型可以确定功能的执行时间，开发出典型数据集的原型能知道程序的内存需求。3、增量模型把软件产品作为一系列的增量构件来设计、编码、集成和测试。通常，第一个增量构件往往实现软件的基本需求，提供最核心的功能。交付产品时采用分批逐步向用户提交产品，而不是一次性交付产品。使用增量模型的困难是，在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发的产品。因此必须把软件的体系结构设计得具有开放性和扩充性。增量模型具有可在软件开发的早期阶段使投资获得明显回报和较易维护的优点。在进行增量开发时，我们先做出软件系统的一个尽可能简单、但能运行的版本。它不必接受真实的输入，也无需对数据进行真正的处理，更不用产生真实的输出——它仅仅需要构成一个足够强壮的骨架，支撑起未来将要开发的真实系统。在骨架形成之后，你要一点点地在其上附着肌肉和皮肤：把每个虚假的类替换为真正的类；不再假装接受输入，而是把接收真实输入的代码替换进去；不再假装产生输出，而是把产生真实输出的代码替换进去。你一次增加一小部分代码，直到得到一个完全可以工作的系统。【举例】采用增量模型开发的字处理软件，在第1个增量中提供基本的文件管理、编辑和文档生成功能；在第2个增量中提供复杂的编辑和文档生成功能；在第3个增量中提供拼写和语法检查功能；在第4个增量中提供高级页面排版功能。4、螺旋模型螺旋模型可以理解为带有风险分析过程的快速原型模型。构建原型是一种能使某些类型的风险降至最低的方法，但原型不能“包治百病”，对于某些类型的风险（例如，聘请不到需要的专业人员，或关键的技术人员在项目完成前“跳槽”），原型方法是无能为力的。螺旋模型的基本思想是：使用原型及其他方法来尽量降低风险。即每个阶段之前都增加了风险分析过程和快速原型模型。5、喷泉模型“喷泉”体现了面向对象软件开发过程迭代和无缝的特性。因为用面向对象方法开发软件时，在分析、设计和编码等项开发活动之间并不存在明显的边界。举例：如何进行迭代和进化式分析和设计。假设在项目交付前，最终将有20次迭代。1）在第1次迭代之前，召开第一个时间定量的需求工作会议，例如确切的定义为两天时间。业务和开发人员（包括首席架构师）需要出席。 在第一天上午，进行高阶需求分析，例如仅仅确定用例和特性的名称，以及关键的非功能性需求。这种分析不可能是完美的。 通过咨询首席架构师和业务人员，从高阶列表中选择10％列表项，假设为3个用例，这些项目需要具备以下三种性质：1、具有重要的架构意义，2、具有高业务价值。3、具有高风险。 在剩下的一天半内，对这3个用例的功能和非功能性需求进行详细的分析。完成这一过程后，对10％进行了深入分析，90％进行了高阶分析。2）在第一次迭代之前，召开迭代计划会议，选择3个用例的子集，在特定时间内进行设计、构造和测试。3）在三到四周内完成第一次迭代（选择时间定量，并严格遵守时间）。 在开始两天内，开发者和其他成员分组进行建模和设计工作，画出UML草图。 然后，开发者摘掉其“建模帽子”并带上“编程帽子”，开始编程、测试和集成工作并且剩余的时间均用于完成这项工作。 进行大量的测试，包括单元测试、验收测试、负载测试和可用性测试。 在结束前的一周，检查是否能够完成初始的迭代目标；如果不能，则缩小迭代范围，将次要目标置回任务列表中。 在最后一周的星期二，冻结代码，必须检入、集成和测试所有代码，以建立迭代的基线。4）在第一次迭代即将结束时，召开第二次需求工作会，对上一次会议的所有材料进行复查和精化。然后选择具有重要架构意义和高业务价值的另外10％到15％的用例，用一到两天对其进行详细分析。这项工作完成后，会详细记录大概25％的用例和非功能性需求。当然，这也不是完美的。5）与周五上午，举行下一次迭代的迭代计划会议。6）以相同的步骤进行第2次迭代。7）反复进行四次迭代和五次需求工作会，这样在第4次迭代结束时，可能已经详细记录了约80％～90％的需求，但是只实现了系统的10％。8）我们大概推进了整个项目过程的20％。在UP的术语里，这是细化阶段的结束。9）此后，一般不需要再召开需求工作会；需求已经稳定了。接下来是一系列为期三周的迭代，在最后一个周五召开的迭代计划会上选择适宜的下一步工作。总结：最重要的UP思想——迭代开发在这种方法中，开发被组织成一系列固定的短期小项目，称为迭代；每次迭代都产生经过测试的、经过集成的和可执行的系统。每次迭代都有自己的需求分析、设计、实现和测试活动。迭代的输出不是实验性或将丢弃的原型，迭代开发也不是原型开发。与之相反，其输出是最终系统的产品的子集。迭代开发不是要通过在实现前试图完整和正确地描述、冻结和“终止”一个已冻结的需求集和设计来应对软件开发中出现的不可避免的变更，而是要基于拥抱变更和适应调整的态度将变更和调整作为迭代开发中不能避免且真正必要的驱动力。每次迭代选择一小组需求，并快速设计、实现和测试，可以得到快速的反馈——来自用户、开发人员和测试（例如负载测试和可用性测试）的反馈。迭代开发的优点：在早期而不是晚期缓解高风险（技术、需求、目标、可用性等方面的风险）。早期可见的发展。早期反馈、用户参与和调整，会得到一个更接近项目相关人员真实需求的经过精化的系统。可控复杂性；开发组不会被“分析瘫痪”或长期复杂过程所淹没。在一次迭代中学到的知识可以被有系统地用于改进开发过程本身，下一次迭代也是如此，依次类推，进行下去。UP阶段和流程初始阶段：大体上的构想，业务案例，范围，模糊评估。细化阶段：已精化的构想，核心架构的迭代实现，高风险的解决，大多数需求和范围的识别，更为现实的评估。构造阶段：迭代实现遗留下来的风险较低和比较容易的元素，准备部署。移交阶段：beta测试，部署。细化阶段的一些关键思想和最佳实践包括：做短时间分区的、风险驱动的迭代。尽早开始编程。适应性地设计、实现并测试架构的核心和风险部分。尽早、经常、实际地测试。基于来自测试、用户、开发人员的反馈信息进行调整。通过一系列的研讨会，每个细化迭代一次，详细编写大部分用例和需求。细化阶段中在架构方面重要的是什么：1、早期的迭代建立和证明核心架构。（1）采用“宽且浅”的设计和实现方案。即识别单独的过程、层、软件包和子系统以及它们高层的职责和接口，为了连接它们以及阐明接口而部分实现它们。（2）细化模块间的本地和远程接口。（3）集成已有的组件。2、为了得到反馈信息，调整并证明核心架构是健壮的，细化阶段测试是重要的。七、软件工具：UMLUML也称为统一建模语言。它提供了一个可视化的建模语言，所谓可视化即通过一些很直观，容易理解的图形化来描述系统。因此用uml实现的文档形式为：“图形化＋文本描述＝相应文档”UML语言很全面，庞大，可以表示各种复杂的问题。这样一个丰富的语言，我们只需要用其20%部分，描述80％的问题，因此学习中，我们只需要掌握常用的基本组成部分，关键是要对这些组成部分了解之后，能够应用他所提供的表示方法，进行分析和设计。实际上在真正应用里面，活用UML是非常关键的，虽然它是一个语言，但是应用这个语言要根据分析设计里面需要描述设计模型的需要来应用。而不是说死记一些条目，很死板的去应用。只有活用，才能感受到UML语言的威力。一个比喻：uml中所提供的标准的图符，相当于音乐五线谱里的乐符，学会看乐符才能看得懂乐谱，才能进一步创造音乐。同样，懂得uml中的图符，才能进行系统分析和设计。应用UML的三种方式（1）UML作为草图——非正式的、不完整的图（通常是在白板上手绘草图），借助可视化语言的功能，用于探讨问题或解决方案空间的复杂部分。（2）UML作为蓝图——相对详细的设计图，用于：1）逆向工程，即以UML图的方式对现有代码进行可视化，使其易于理解。2）代码生成（前向工程），一般情况下，代码生成工具使用图生成一些代码，然后由开发者编写并填充其他代码。（3）UML作为编程语言——用UML完成软件系统可执行规格说明。可执行代码能够被自动生成，但并不像通常一样为开发者所见或修改，但是目前在理论、工具的健壮性和可用性方面仍然处于发展阶段。说明：UML和银弹思想，即相信软件中存在某种特殊的工具或技术，可以在生产率、缺陷减少、可靠性和简易性等方面带来极大的变化。工具无法弥补设计上的疏漏。UML的应用对象建模是用例驱动（即建立用例模型，从分析到设计都是以用例为核心来设计）：优势于功能列表（不是站在用户的角度考虑问题）以体系结构为中心（整个系统中强调体系结构的设计）迭代开发过程（由于开发过程不是一下子能够全部完成的，强调迭代化的开发，可以在用例的设计过程中不断的设计和补充）4＋1视图在用uml语言建立相应系统模型时，具体对于软件系统是用什么样的视图描述，通常uml建议采用4＋1＝5个视图的描述。用例视图：整个系统核心，它是从用户角度对系统的参与和要求的交互过程。描述整个系统具有什么样的功能。它也是后续设计、实现、实施、测试等等所有阶段的核心和基础，所有后续阶段或其他视图都以它为根本。逻辑视图：描述该系统，即用例中的所有功能，其内部结构是什么，组成关系是什么。主要应用于分析设计人员，建立相应结构。象静态结构方面：类，对象，及其关系；动态行为方面：并发，消息等相互联系。建立了逻辑视图之后，还要对系统进程、并发等机制进行描述。进程视图：处理并发和同步的线程和进程。实现视图：具体开发时，怎样把大的复杂系统分解成若干小的不同系统，进行搭建，或不同组件进行组合。一般大系统可能有不同组件，到底有哪些组件，哪些文件，这些组件，这些文件怎样连接，构成所要实现的系统。分布视图：系统开发完成后，系统可能是在分布式环境、网络环境下运行，系统不同部分在网络环境下怎样分布、布置，在部署视图中提供。总结：由这样5个视图从不同方面完整的表示了系统的所有功能和需要提供各个方面的要求。UML的组成：UML的词汇表包括3种构造模块：元素、关系、图。（1）元素：模型中重要的抽象。结构元素：UML模型中的名词。是模型中主要的静态部分，代表了概念的或物理的元素。1、用例与协作：前面讲过的用例是表示系统要实现的一个具体功能，要完成这个功能，实际需要一组对象类，及其对象类之间的互相关联来实现的，因此协作是对具体用例的实现进行建模，表示方法为虚椭圆。区别：用例只是描述对外呈献的行为，不关心这些具体功能是怎样实现的，而协作描述要实现这个用例的功能，具体需要哪些类，类与类之间的关系怎样。因此用例和协作之间是实现的关系。2、主动类：在类里面有一种类和一般类有一定区别，这种类具有主动的行为，一般来讲它可以主动的启动一些控制的活动，对实现来说它通常拥有一个进程或线程。它的表示方式是在外边框加粗。例如：事件管理器，它对事件队列有挂起，刷新功能，该类有一个进程对应，有主动控制的行为，称为主动类。3、构件：在大的系统开发过程中，往往把复杂的系统分成不同的构件，所以系统里面真正可以替代的构件在UML里面也有相应的描述，构件往往和接口一起使用的，因为任何构件的对外服务都是通过接口来描述的。行为元素：UML模型中的动态部分，它是模型中的动词，代表了跨越时间和空间的行为。UML中有两种主要的行为元素：交互作用（Interaction）和状态机（StateMachine）。交互作用：由在特定上下文中为完成特定目的而在对象间交换的消息集组成的行为。交互作用包括许多其他元素：消息、动作序列（由消息激活的行为）、连接（对象间的连接）。2、状态机：对象真正在创建到消亡的过程中，即实际生命周期里，是通过响应一定的事件，经历了不同的状态，所以状态机来描述对象所经历的状态的序列，及触发状态变化的事件。例如：命令处理的状态转换。开始系统一启动，进入初始状态，在初始状态进行初始化，准备工作；初始化完成后，进入空闲状态，循环等待输入的状态。如果接收了键盘输入，就使得系统从空闲状态进入命令处理状态，可能一个命令是由多个字符组成，所以它在接收相应按键之后把相应字符存入命令队列中，然后返回空闲状态，当下一次再有按键进入时，又继续进行处理，如果完整的命令输入完之后，可能要调用相应的命令处理程序执行，如果命令是一个结束的命令，则整个状态机就结束了。所以状态机有一个开始状态，多个结束状态，中间还有不同的中间状态，每个状态转换都有相应的事件触发。分组元素：是UML模型中用来组织元素的元素。在基本的事物组成中，经常把大量事物通过分包的方式进行组合。包：把一类基本元素分类，按照分包的原则可以各种各样。（2）关系：事物之间的连接。真正要构成一个系统，事物之间是有一些关系的。例如：课表和课程之间，课程可以加到课表里，或从课表里删除。课程变化时，课表相应发生变化。课程和课表之间是依赖关系。关联关系：属性可见性。通常需要保持长期，稳定存在的关系。依赖关系：非属性可见性（局部、本地、全局可见性），通常只需要保持短期的，局部的关系。实现关系：把具体形式化的描述与具体实现分离的方法。好处：把对外的形式化描述和具体实现分离，分离后如果内部实现改变，只要对外形式化描述不变，跟外部交互连接的部分不受到影响。（3）图：把事物通过关系连接起来形成图。真正描述模型是用一个个图来描述的。UML的9种图：用例图：定义了系统的功能需求，它完全是从系统的外部观看系统功能，并不描述系统内部对功能的具体实现。类图：描述系统的静态结构，表示系统中的类以及类与类之间的关系。对象图：描述了一组对象以及它们之间的关系，表示类的对象实例。组件图：描述组件以及它们之间的关系，表示系统的静态实现视图。具体系统可能划分成不同组件和模块，有哪些模块，组件之间的关系怎样由组件图描述。例子：在课程注册管理系统中，有两个子系统：收费系统，注册系统。注册系统分为：课程组件，人员管理组件。注册系统在课程注册完后，通过接口调用收费系统，将学生相应注册信息传递给收费系统，形成对学生的收费单，通知学生交费。课程系统又通过接口管理相应课程信息，即课程模块。对于学生教师人员进行管理。通过这两个模块，实现存取相应人员和课程信息，最后实现相应功能。部署图：反映系统中软件和硬件的物理架构，表示系统运行时的处理节点，以及节点中组件的配置。时序图和协作图：都表示一组对象之间的动态协作关系。其中时序图反映对象之间发送消息的时间顺序，协作图反映收发消息的对象的结构组织。时序图和协作图是同构的，即两者之间可以相互转换。状态图：强调同一个类里对象状态变化过程，和相应事件触发过程。所谓状态，是对对象属性值的一种抽象。各对象之间相互触发（即作用）就形成了一系列的状态变化。我们把一个触发行为称作一个事件。对象对事件的响应，取决于接受该触发的对象当时所处的状态，响应包括改变自己的状态或者又形成一个新的触发行为。状态有持续性，它占用一段时间间隔。状态与事件密不可分，一个事件分开两个状态，一个状态隔开两个事件。事件表示时刻，状态代表时间间隔。活动图：反映系统中从一个活动到另一个活动的流程，强调对象间的控制流程。八、敏捷宣言AgileSoftware敏捷过程作为对惯例性过程的挑战，由17位方法学家于2001年2月提出。在该方法论中，他们提出了4项价值以鼓励更好的开发软件：1、个人和交互高于过程和工具。开发过程中，最重要的因素是必须考虑到开发者是如何在一起工作的，因为如果他们不能摆正态度的话，最好的工具和过程也将会失去作用。2、可工作软件高于详尽的文档。3、与客户合作高于合同谈判。只有客户才能告诉开发者他们想要什么。与客户建立合同是重要的，但合同不能代替相互之间的沟通。4、对变化及时做出响应高于遵循计划。变化是软件开发的现实。

章节名称需求工程（4次课）教学目的需求的定义和需求的层次。什么是用例，如何编写用例。如何构建需求模型，如何编写需求规格说明书。教学重点与难点1、需求捕获的方法。2、用例。3、需求模型的构建。4、需求规格说明书的编写。教学内容与过程设计教学内容与过程设计启动软件项目是由于软件需求的存在，资料表明，软件项目中40％～60％的问题都是在需求分析阶段埋下的隐患。软件开发中返工开销占开发总费用的40％，而其中70％～80％的返工是由需求方面的错误所导致。因此一个项目成功的关键因素之一就是对需求分析的把握程度。而项目的整体风险往往表现在需求分析不明确，业务流程不合理，所以，需求分析是软件开发的重要一环。软件的需求具有模糊性、不确定性、变化性和主观性的特点，相比硬件的需求，是有形的、客观的、可描述的、可检测的。一、需求的定义需求，是指对用户需要解决的问题的整体描述。需求是软件实现之源，没有了需求，软件也就无从谈起。在IEEE软件工程标准词汇表中定义需求为：（1）用户解决问题或达到目标所需要的条件或能力（2）系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力（3）一种反映上面（1）或（2）所描述条件或能力的文档说明二、需求的层次软件需求是指用户对软件的功能和性能的要求。软件人员要准确理解用户的要求，进行细致的调查分析，将用户非形式化的需求陈述转化为完整的需求定义，再由需求定义转化到相应形式的需求规格说明。有时也可以将软件需求按照层次来说明（如上图）。业务需求：反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中说明。用户需求：用户使用产品必须要完成的任务，它们通常使用用例文档（usecase）进行说明。功能需求：开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。非功能需求：描述系统展现给用户的行为和执行的操作等。包括：产品必须遵循的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件；质量属性。通常也可以总结为FURPS+：Functional（功能性）：特性、功能、安全性。Usability（可用性）：人性化因素、帮助、文档。Reliability（可靠性）：故障频率、可恢复性、可预测性。Performance（性能）：响应时间、吞吐量、准确性、有效性、资源利用率。Supportability（可支持性）：适应性、可维护性、国际化、可配置性。＋：表示一些辅助性的和次要的因素，比如：实现（Implementation）：资源限制、语言和工具、硬件等。接口（Interface）：强加于外部系统接口之上的约束。操作（Operation）：对其操作设置的系统管理。包装（Packaging）：例如物理的包装盒。授权（Legal）：许可证或其他方式。软件需求规格：软件需求规格充分描述了软件系统应具有的外部行为，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；非功能性需求（例如性能要求等）；设计或实现的约束条件及质量属性。软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起到重要的作用。为了强调非功能需求，举例说明：2月27日，中央电视台“第一时间”报道了北京市二中院开庭审理程稚瀚涉嫌盗取北京移动通信公司充值卡密码一案，程稚瀚曾是UT斯达康深圳分公司工程师，被指控利用网络技术手段侵入北京移动通信公司充值中心数据库，修改充值卡原始数据并窃取了充值卡密码，并通过淘宝网和QQ向他人出售，致使北京移动通信公司损失近380万元。该栏目主持人认为：1.2亿元网络安全投入，居然不堪一击，中国移动也该好好总结一下了。事实上，程稚瀚在作案过程中使用的大多都是些没有技术含量的攻击手段，但是偏偏没有技术含量的攻击事件，在电信、银行、证券、保险业却屡屡得逞另一个案例：两大学生利用网通ADSL用户升级时系统的漏洞，在一个月内盗取了价值70余万元的网易一卡通虚拟游戏点卡。不能不令我们深思。三分技术，七分管理”的网络安全体系建立原则几乎被每个电信和银行业的企业所强调，并成为指导其安全管理体系建设的基本原则。三、需求工程20世纪80年代中期，形成了软件工程的子领域——需求工程。需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。四、需求问题的代价在早期阶段，软件是无形的，除了一些文档性的规格说明以外没有什么具体有形的东西，而且比较容易修改。但随着时间的推移，软件产品越来越详细（在设计阶段），越来越具体（在编码阶段），越来越固定（当代码逐渐接近最终的方案时）。在早期可以轻易改变的东西，越到后期就越难得多。很多人不理解这些前期准备的重要性，其实我们可以把软件过程比作食物链。其中程序员是软件食物链的最后一环。架构师吃掉需求，设计师吃掉架构，而程序员则消化设计。在健康的生态环境中，海鸥吃新鲜的鲑鱼。这对海鸥是营养丰富的大餐，因为鲑鱼吃的是新鲜的青鱼，而青鱼吃的是新鲜的水蝽。这是一条健康的食物链。在软件开发中如果食物链的每一级都是健康的食物，那么最终由程序员编写出的代码也是健康的。而在受污染的环境中，水蝽在核废料中游泳，青鱼被聚氯联二苯污染，而吃青鱼的鲑鱼又在泄漏的原油中游荡。海鸥，就成为最不幸的了，因此它吃下去的不仅仅是不健康的鲑鱼体内的原油，还有青鱼体内的聚氯联二苯和水蝽体内的核废料。在软件开发中，如果需求污染了，它就会污染架构，而架构就会污染编码。这样会导致程序员脾气暴躁、营养失调；开发出的软件具有放射性污染，而且周身都是缺陷。五、需求面临的困难“石头”问题：说客户常常会交给她一些项目，她称之为“给我一块石头”。可是当你把石头交给客户时，他会看一会“石头”，然后说：“是的，但是……，实际上我想要的是一块小一点的蓝色石头。”而当你交出一块小一点的蓝色石头时，又会引发“一块圆的小一点的蓝色石头”的要求。最终的结果可能是，客户一直都在想要一块小一点的蓝色大理石—或者他也许根本不能确定他到底要什么，而不是一块小小的蓝色大理石—甚至是猫眼大小的蓝色大理石就已经足够了。而他会在你交出第一块（大的）石头和第三块（蓝色的小）石子之间不断改变对需求的想法。开发人员在与客户会谈时总会提这样的问题：“你想要它做什么？”当开发人员按照客户预先的需求经过艰苦努力终于交出一块石头却得不到客户的肯定时，总是感到非常沮丧；而客户也同样沮丧，因为即使他可能也发现很难说清自己真正的要求，他还是觉得自己已经讲得很明白，只是开发人员没理解罢了！解决需求问题的手段和方法：A、分离稳定和不稳定B、先定架构再进行子系统的开发六、什么是用例用例：一种被广泛使用的用于发现和记录需求的机制。用例就是如何使用系统来达到目标的一组情节。用例不应该被设计得过于复杂，写到够用的详细程度即可。一个用例就是描述参与者使用系统来达成目标的时候一组相关的成功场景和失败场景的集合。用例是文本文档而不是图表，用例建模的主要工作是写文本而不是画图。用例的层次性使得用例对需求变更的适应性很强。再次强调：用例是文本形式的情节描述，用以说明某参与者使用系统以实现某些目标。初学者的常见错误就是注重于次要的UML用例图，而非重要的用例文本。七、需求调研需求获取的主要任务是和用户方的领导层、业务层人员的访谈式沟通，目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等具体情况和客观的信息，以建立起良好的沟通渠道和方式。需求调研的方式(1)访谈和会议：需要注意，每一次交流一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。例如，可以将需求细分为功能需求、非功能需求、环境限制、设计约束等类型。(2)市场调查(3)访问用户和用户领域的专家(4)考察现场，跟踪现场业务流程(5)开发人员和用户共同组成联合小组“老太太哲学”来源于李瑞环在天津当市长时候的一个故事，说是，人大代表、政协委员和各界群众座谈，有一次，一个老太太问：她家的煤气灶为什么总是点不着火？主管领导通过讲道理、摆数字的方式，给老太太解释，此时李瑞环说，你不用讲太多道理，老太太只要求煤气能一点就着。

许多媒体用“老百姓哲学”来对这个故事进行解读，说是政府要替老百姓办实事。我这里从软件工程的角度解读一下。

老太太提问题的目的，显然不是为了学习煤气灶点火的机理，实际上传递了一个信息，天津的煤气有问题，点不着。政府官员，假定不是推卸责任的话，显然没有理解老太太的真实意图。官员的回答，也没有用老太太能理解的方式进行，他应该直接告诉老太太怎么做，即便要推卸责任，用哪些情况做不到来代替说理也要好些。

软件工程中，需求获取是项目的重要步骤，用户的问题域是项目执行者要解决的目标域，不过，这两个域却存在不同的表达方式，用户总是从使用的角度来理解问题和提出问题，项目人员总是从设计的角度来理解问题和解决问题。

客户的问题并不能直接变成项目执行的目标，因为客户的问题使用业务术语来描述，项目却需要软件术语来执行。举例子说，数学工作者的问题是用数学公式来描述的，他并不知道软件怎样设计才能完成他的任务，如果软件设计者只熟悉软件领域，数学公式他也无法看懂，就谈不上完成任务。

需求问题实际上还要复杂，客户受限于知识水平和经验，常常无法准确地表达要求，作为问题提出者，他们的描述是零散的、模糊的、错误的甚至是自相矛盾的，而这样的目标无法完成，因此，需求获取者从有干扰的信息中挖掘、过滤、还原用户的真实需求，是重要的任务。

要准确获取需求，需要贴近客户，用他们能够理解的方式沟通，说他们能够听得懂的话，而不是鸡对鸭讲，各说各话。对于技术人员之间，则要用技术人员的语言，便于意思的精确表达，减少交流误差。表现在软件工程中，就是对不同的人建立不同的模型。不同的模型分别以不同的侧面来展现问题本身。

如果你是技术人员，你不能很好的和客户沟通，或者你的老板总是不理解你每天的辛苦，老太太哲学应该能给你一些提示。调研中存在的问题小型项目：投入几万到三四十万的项目，忽略合同或协议的签署，而仅仅只有一个表面的意向。最终导致在开发过程中，用户不断提出各种各样的问题和要求，以至于需求工作无法正常进行。大型项目：几百万或者几千万的项目。软件开发商急切的想得到这个项目，于是就逼迫开发人员尽快投入开发，必须不惜一切代价去拿下它。这样也就直接造成在还没有签订合同和正式协议之前，开发人员就不得不进入用户的工作区进行需求调研。此时，如果商务最终没有能谈下来，就使得开发人员的工作付之东流。用户日渐成熟：用户会要求软件厂商先拿出相应的产品或者软件，然后才会考虑和软件厂商签订进一步合同。用户甚至希望，先试用软件（其实是使用软件），然后签合同。合同一旦签完，软件就可全部交付！而国内软件企业很难做到（产品化的软件太少，造成经常发生用户现场定制开发工作的情况存在。）用户过于繁忙：用户有很多借口说忙。当然，在需求调研人员以诸如请客吃饭为借口搞好关系的时候，他们大多数还是愿意来的。因此需求调研人员就需要考虑如何协调这其中的关系，来保证需求调研的顺利完成。这时需要掌握好一个原则是：不能逼迫用户（如催促等行为），不要以与项目相关的任何理由来逼迫用户配合需求调研工作。不同的软件不同的结果：对于可以让客户直接见到利益的软件系统，用户愿意购买，也比较愿意付款，而且也比较愿意配合您的工作。但是这样的项目大部分都隶属于增值业务范围之内。还有相当数量的软件是不可能让客户直接体会到收益的；此时应该注意将隐藏在软件产品后面的收益尽量呈献出来，让客户充分体会到。高层的关注：高层领导非常关注的大型项目，一般比较容易推进。例如电信行业的计费、网管系统，税务的税收、缴费系统、电力的生产、调度、计费、电检系统等。但是，也要注意，不要因为引起了高层的关注就对下面的人不再关注，更不能因此而引起具体办事人员的反感，否则将使项目的进展面临异乎寻常的压力。和用户交流的技巧交流中的心态定位：首先，开发人员一定要让用户意识到：开发人员是为他们工作的！开发人员的工作不会造成他们被裁掉，只是用来简化他们的工作，减轻他们的工作负担，让他们可以更舒服、更轻松地工作——即使，最终的结果可能完全相反，也要如此做。我们要为用户考虑：应该站在用户的立场上进行考虑。采用适当的交流语言：尽量采用用户行业内的语言或者用户可以理解的语言和方式。使用流程图最常用的方式是：用户边描述，需求人员边绘图，然后给用户看图，让用户根据图来指出问题，然后，再修改，再看，如此反复，直到用户满意为止。表格：流程图可以描述工作流程，而表格可以描述工作的结果，或者阶段性成果。图形：如设备部署图、网络结构图、资源分布图等。文字：使用文字是必须的，但是文字越少越好！描述性文字一定要精练、短小，切忌长篇大论。八、需求建模问题的提出：在系统尚未存在时，怎样描述用户需要一个什么样的系统？如何规范的定义用户需求？考虑问题的思路：把系统看作一个黑箱，看它对外部的客观世界发挥什么作用，描述它外部可见的行为。注意：需求是技术无关的。在需求阶段讨论技术是没有任何意义的。那只会让你的注意力分散。需求分析的基本策略是采用脑力风暴、专家评审、焦点会议组等方式进行具体的流程细化、数据项的确认，必要时可以提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。用户方可以通过审查业务流程报告、数据项表以及操作开发方提供的原型系统，来提出反馈意见，并对可接受的报告、文档签字确认。需求建模的步骤：1、识别执行者2、识别用例3、详述业务用例4、对用例进行排序和分包第一步：识别执行者执行者：在系统之外，透过系统边界与系统进行有意义交互的任何人或外部系统。三类参与者：1、主要参与者：具有用户目标，并通过使用该系统的服务完成。为何确定主要参与者？发现驱动用例的用户目标。2、协助参与者：为系统提供服务（例如，信息服务）。自动付费授权服务即是一例。协助参与者通常是计算机系统，但也可以是组织和人。为何确定协助参与者？为了明确外部接口和协议。3、幕后参与者：在用例行为中具有影响或利益，但不是主要或协助参与者。例如，政府税收机构。为何确定幕后参与者？这是为了确保确定并满足所有必要的重要事物。如果不明确地对幕后参与者进行命名，则有时很容易忽略其影响或利益。执行者要点：系统外—必须和它交互系统边界--责任边界，非物理边界系统边界--直接与系统交互有意义交互--属于目标系统的责任任何事物--人、外系统、外部因素、时间与外部系统交互的几种情况：1、一直与系统进行交互的其他系统或设备。2、发起交互的其他系统或设备。3、从交互中取值的其他系统或设备。注意：用例图的执行者描述了可以由某些实体扮演的一种角色，不表示一个特定个体。一个执行者和一个用例之间存在通信关系并不意味着扮演这个角色的实体必须执行某个任务，它仅表示可能执行这个任务，这取决于具体情况。第二步：识别用例用例实例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。一个用例定义一组用例实例。用例的三种常用形式：1、摘要——简洁的一段式概要，通常用于主成功场景。何时使用？在早期需求分析过程中，为快速了解主题和范围。可能只需要几分钟进行编写。2、非正式——非正式的段落格式。用几个段落覆盖不同场景。何时使用？同上。3、详述——详细编写所有步骤及各种变化，同时具有补充部分，如前置条件和成功保证。何时使用？确定并以摘要形式编写了大量用例后，在第一次需求讨论会中，详细地编写其中少量（10％）的具有重要架构意义和高价值的用例。识别用例的要点：价值结果à有意义的目标执行者可见à业务语言执行者可见à用户观点一组用例实例à用例的粒度用例的粒度讨论：警惕CRUD泛滥！Create,Read,update,delete用有色眼镜看，所有业务最终都会成为CRUD多问：为什么要CRUD？光CRUD能为actor提供价值吗？如果CRUD不涉及复杂的交互，一个用例“管理××”即可不管是C、R、U、D，都是为了完成“管理”的目标甚至很多种基本数据的管理都可以用一个用例表示讨论：登陆怎么处理方案二：“登陆”用例仅描述登陆的信息，会员执行其他功能时都要先登陆，其缺点为，对会员要进行多次验证。方案三：注意在“购物”和“修改会员资料”用例的前置条件中写明登陆成功条件。用例的关系：扩展关系：寻找用例中的特殊场景：用例中的特殊场景点，（例如，购物，包括支付卡，现金，优惠卷等），（例如，定价，包括打折的业务规则）。包含关系:某些步骤在多个用例重复出现，且单独形成价值，即用例之间的公共功能。已经有现成的公共用例存在，只需拿来使用即可。用例的步骤较多时，可以用Include简化（慎用）。泛化关系：用例之间的泛化：一个任务与该任务的一个特殊版本之间的关系。例子：在买票系统中，个人购买和团体购买都是买票的特例。采用关系不同，文档结构不同（如果改成extend，则表示识别用户用例中的另外一条路径）讨论：泛化与扩展的区别如果打算描述一个根据“运行时”条件有可能在某一时刻增加的附加行为，则可以使用扩展。如果希望标记整个任务的一个特定版本，就应该用泛化。第三步：编写用例文档用例文档模板：前置条件和后置条件：开始用例之前必须满足的条件。注意：必须是系统能检测的。用例成功结束后系统应该具备的状态。例如，前提条件可能是另一个用例已经执行，或者用户具有运行当前用例的权限。用例图并不显示用例执行的顺序，但前提条件可以将这一方面的信息建档。前置条件传达的是编写者认为应该引起读者警惕的那些值得注意的假设。涉众利益：回答了用例应该包含什么？即用例应该包含满足了所有项目相关人员兴趣的内容。另外，在编写用例其余部分之前就确定涉众及其关注点，能够让我们更加清楚地了解详细的系统职责。基本路径：核心的核心：客户最想看到、最关心的路径各种补充约束的描述方法：非功能性需求：正确性：correctness，指系统规范、设计和实现方面的错误的稀少程度。可用性：指用户学习和使用一个系统的容易程度。集群是一种廉价且实用的高可用性解决方案。所谓集群指的是一系列节点的集合，这些节点具有相同的目的，并且互相连接。集群的优点在于可以赋予服务容错和负载均衡的能力。集群通过多个节点间的相互补充，可以在其中某个节点失效时持续的提供服务，从而提高服务的可用性；通过集群中各节点对负载的动态分担，可以将负载比较均匀的分布到多个节点中，从而提高整体性能。可靠性：Reliability，指在指定的必需条件下，一个系统完成所需功能的能力——应该有很长的平均无故障时间。数据库服务器＋备份服务器各种设计约束：界面样式：系统显示订单明细，应采用附件××所示的屏幕格式报表：系统打印工资单，工资单的格式如附件××所示平台：一般针对整个系统：由于公司目前大约有200台PC在使用，还需要使用若干年，所以系统应能在这些PC上运行（Pentium166，128MRAM）由于×公司的IT人员有Oracle专长，而且目前已有的其他应用系统也使用Oracle数据库，所以系统应使用Oracle数据库。接口：通过RS-232接口读取。总结：用例编写准则1、以无用户界面约束的本质风格编写用例。2、编写简洁的用例。3、编写黑盒用例。（黑盒用例不对系统内部工作、构件或设计进行描述。反之，它以通过职责来描述系统）4、采用参与者和参与者目标的视点。第四步：对用例进行排序和分包排序原则：以下情况的用例优先级别最高a)对类图有重要影响b)包含丰富的业务过程信息和线索c)有开发风险、时间紧迫或功能复杂d)涉及到重要核心技术或新技术e)能直接产生经济效益或降低成本f)代表本系统的核心流程分包原则：按执行者分包按主题分包按开发团队分包按发布情况分包补充、活动图利用文本描述事件流是很有用的，但如果事件流的逻辑复杂且有许多其他事件流，则文本形式可能较难阅读和理解。这时可以使用活动图来描述事件流，它是事件流的另一种建模方式。在用例模型中，活动图用来捕捉用例的活动，它着重描述操作以及用例实例或对象中的活动。活动图是一种描述工作流的方式，它用来描述采取何种动作、做什么（对象状态改变）、何时发生（动作序列）以及在何处发生（泳道）。活动图用于描述系统的工作流程和并发行为，活动图可以看作状态图的特殊形式，活动图中一个活动结束后将立即进入下一个活动。总结：用例实践方法最理想：客户写用例－－理想即不现实最糟糕：客户不参与，开发人员杜撰折衷：客户提供素材，开发人员写用例九、需求管理由于需求是正在构建的系统必须符合的事务，而且符合某些需求决定了项目的成功或失败，因此找出需求是什么，将它们记下来，进行组织，并在发生变化时对它们进行追踪，这些活动都是有意义的。需求管理就是：一种获取、组织并记录系统需求的系统化方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。需求管理的主要活动：需求确认：开发方和客户共同对需求文档进行评审，双方对需求达成共识后做出书面承诺，使需求文档具有商业合同效果。在设计开始之前验证需求的正确性及其质量，就能大大减少项目后期的返工现象。需求验证务必确保需求符合完整性、正确性、灵活性、必要性、无二义性、一致性、可跟踪性及可验证性等。需求跟踪：将系统设计、编程、测试等阶段的工作成果与需求文档进行比较，建立与维护“需求文档－设计文档－代码－测试用例”之间的一致性，确保产品依据需求文档进行开发。需求变更控制：依据“变更申请——审批——更改——重新确认”的流程处理需求的变更，确保需求的变更不会失去控制而导致项目发生混乱。这是一句老话了：唯一不变的只有变化。你应该将所有系统将可能发生的变化以及潜在需求记录下来,以便将来能够实现通过在建模期间考虑这些假设的情况，你就有可能开发出足够强壮且容易维护的软件。设计强壮的软件是你最基本的目标。案例分析：某公司的需求变更控制流程

章节名称面向对象分析教学目的掌握分析阶段的主要活动掌握领域建模、系统顺序图、操作契约等的编写方法教学重点与难点静态模型的建模方法动态模型的建模方法教学内容与过程设计教学内容与过程设计一、概述OOA：概念层。帮助软件工程人员和用户组织目标系统的知识。不考虑与实现有关的因素。是一种以从问题域词汇中发现的类和对象的概念来考察需求的分析方法。OOD：OOD把注意的焦点从问题空间转移到了解空间。针对系统的具体实现，对OOA阶段建立的模型进行调整与增补，并对人机界面、数据存储和控制接口建模。OOP：实现层，把OOD模型变为程序。即用面向对象语言(如C++，Java等)实现设计。分析和设计可以概括为：做正确的事（分析）和正确地做事（设计）。面向对象分析和设计：在OOA过程中，强调的是在问题领域内发现和描述对象或概念。在OOD过程中，强调的是定义软件对象和这些软件对象如何协作来满足需求。UP过程的描述：初始和细化初始阶段是迈向细化阶段的一小步。在该阶段决定基本的可行性、风险和范围，对项目是否值得深入调查进行决策。初始阶段可能的活动和制品包括：（1）简短的需求讨论会。（2）大多数参与者、目标和用例名称。（3）大多数以摘要形式编写的用例。以详述形式编写10％～20％的用例，以加深对范围和复杂性的理解。（4）确定大多数具有影响和风险的质量需求。（5）编写设想和补充性规格说明的第一个版本。（6）风险列表。（7）技术上的概念验证原型和其他调查，用以揭示特殊需求的技术可行性。（8）面向用户界面的原型，用于确定对功能需求的设想。（9）对购买/构建/复用构件的建议，在细化阶段进行精化。（10）对候选的高层架构和构件给出建议。（11）第一次迭代的计划。（12）候选的工具列表。细化：构建核心架构，解决高风险元素，定义大部分需求，预计总体进度和资源。在细化阶段可能出现的一些关键思想和最佳实践包括：（1）实行短时间定量、风险驱动的迭代。（2）及早开始编程。（3）对架构的核心和风险部分进行适应性的设计、实现和测试。（4）尽早、频繁、实际地测试。（5）基于来自测试、用户、开发者的反馈进行调整。（6）通过一系列讨论会，详细编写大部分用例和其他需求，每个细化迭代举行一次。面向对象分析和设计的实质是一种系统建模的技术，它不是从功能或算法上考虑整个系统，而是从系统的组成上进行分解，利用类及对象作为软件的基本构造单元，以更接近人类思维的方式建立模型，从而使设计出的系统尽可能直接的描述现实世界，构造出模块化、可重用、易维护的软件。动态模型：有助于设计逻辑、代码行为或方法体。例如UML交互图。动态模型倾向于创建更为有益、困难和重要的图形。静态模型：有助于设计包、类名、属性和方法特征标记（但不是方法体）的定义，例如UML类图。敏捷建模采取了并行创建这两种模型的方式。二、对象模型领域模型是概念类或者感兴趣领域的现实对象的可视化表示。UML表示法中，用一组不定义操作的一组类图来说明。领域模型是现实世界概念类的一种表示，不是软件组件的一种表示。它不是描述软件类的图集，也不是有着职责的软件对象。2.1创建领域模型的步骤：用概念类分类列表和名词短语识别的方法找出当前需求中的候选概念类。在领域模型中描述这些概念类。在概念类之间添加必要的关联来记录那些需要保存记忆的关系。添加用来实现需求的必要属性。注意：概念类和属性命名时使用问题域中的词汇。一个领域模型可以将那些与当前需求无关的概念类排除在问题域之外。领域模型应当排除不包含在当前考虑下的问题域中的事物。2.2识别类及其属性对象是对问题域中有意义的事物的抽象，它们既可能是物理实体，也可能是抽象概念。具体地说，大多数客观事物可分为下述5类：(1)可感知的物理实体，例如，飞机、汽车、书、房屋等等。(2)人或组织的角色，例如，医生、教师、雇主、雇员、计算机系、财务处等等。(3)应该记忆的事件，例如，飞行、演出、访问、交通事故等等。(4)两个或多个对象的相互作用，通常具有交易或接触的性质，例如，购买、纳税、结婚等等。(5)需要说明的概念，例如，政策、保险政策、版权法等等。在分析所面临的问题时，可以参照上列5类常见事物，找出在当前问题域中的候选类与对象。另一种更简单的分析方法，是所谓的非正式分析。这种分析方法以用自然语言书写的需求陈述为依据，把陈述中的名词作为类与对象的候选者，用形容词作为确定属性的线索，把动词作为服务(操作)的候选者。当然，用这种简单方法确定的候选者是非常不准确的，其中往往包含大量不正确的或不必要的事物，还必须经过更进一步的严格筛选。通常，非正式分析是更详细、更精确的正式的面向对象分析的一个很好的开端。2.3审查类（1）冗余相同的类使用多于一个的名字。注意：近似的对象不一定完全相同，应该确定是否值得建立不同的类。（2）系统边界之外现实世界中存在许多对象，不能把它们都纳入到系统中去，仅需要把与本问题密切相关的类与对象放进目标系统中。有些类在其他问题中可能很重要，但与当前要解决的问题无关，同样也应该把它们删掉。（3）操作指被系统或者在系统内部完成的事件的名词。应该慎重考虑它们在本问题中的含义，以便正确地决定把它们作为类还是作为类中定义的操作。通过判断一个事件或者操作的实例是否包含状态、行为或者特征，如果没有，则不应该是类。（4）属性一个名词明显表示一些不具有感兴趣行为的简单事情，它是另一个类的属性。当然，如果某个性质具有很强的独立性，则应把它作为类而不是作为属性。判断是概念类或属性的原则:如果我们不将概念类X看成是现实世界中的数字或者文本，X就可能是概念类而非属性。（5）实现在分析阶段不应该过早地考虑怎样实现目标系统。因此，应该去掉仅和实现有关的候选的类与对象。在设计和实现阶段，这些类与对象可能是重要的，但在分析阶段过早地考虑它们反而会分散我们的注意力。（6）描述概念类在下列情况下，添加概念类的规格说明或描述：当需要商品或者服务的信息描述，独立于那些商品或者服务当前已存在的任何示例。由于与被删除的事物之间存在不正确的关联信息，删除它们所描述的事物实例会导致仍需维护信息的丢失。能够减少冗余或者重复的信息。2.4属性审查属性对问题域的基本结构影响很小。随着时间的推移，问题域中的类始终保持稳定，属性却可能改变了，相应地，类中方法的复杂程度也将改变。（1）是否在系统责任之内属性不是越详细越好，关键看是否是当前系统感兴趣的属性。（2）属性是否描述类对象的特征（3）属性是否存在冗余：常见冗余如：出生年月－－年龄（4）是否有1对多的复杂属性1:1－－可以在原类内展开1:N－－独立出去形成关联如果一个会员只有一个联系地址，可以在原类内展开，如果包含多个联系地址，则将联系地址独立出去形成关联。（5）属性是否对类的所有对象都有意义2.5识别类之间的泛化泛化：子类通过继承拥有超类的特征关联：对象通过组装拥有其他对象的特征类A具有类B的全部属性和操作，而且具有自己特有的某些属性和操作。A称为B的子类，B称为A的超类。泛化举例两种方式建立泛化关系：自底向上：抽象出现有类的共同性质泛化出父类，这个过程实质上模拟了人类归纳思维过程。自顶向下：把现有类细化成更具体的子类，这模拟了人类的演绎思维过程。2.6审查泛化关系（1）问题域是否需要这样的分类？（例：书——善本书）（2）系统责任是否需要这样的分类?（例：职员——本市职员）（3）是否符合分类学的常识?（用“isa”去套）（4）是否构成了继承关系?（确实继承了一些属性或服务，如航标船与一般的船）2.7识别类之间的关联类A与类B关联，如果类A在物理上或逻辑上是B的一部分；类A的对象向类B的对象发送一个消息；类A的对象建立类B的对象；类A的对象包含一个属性，属性的取值是类B的对象或者类B的对象集合；对象之间的静态联系是指，最终可通过对象属性来表示的一个对象对另一个对象的依赖关系。对象之间的动态联系是指，对象之间在行为（服务）上的依赖关系。在一个领域模型中需要考虑下面的关联：（1）那些需要将概念之间的关系信息保持一段时间的关联（“需要知道”型关联）。（2）从通用关联列表中派生出的关联。通用关联列表A在物理上是B的一部分A在逻辑上是B的一部分A在物理上包含在B中/依赖于BA在逻辑上包含在B中A是对B的描述A是交易或报表B中的一项A为B所知/为B所记录/录入B中/为B所捕获A是B的一个组织子单元A使用或管理BA与B通信A与一个交易B有关A是一个与另一个交易B有关的事务A与B相邻A为B所拥有A是一个与B有关的事件关联的指导原则：（1）将注意力集中在那些需要将概念之间的关系信息保持一段时间的关联。（2）识别概念类比识别关联更重要（3）太多的关联不仅不能有效地表示领域模型，反而会使领域模型变得混乱。有时，（4）发现某些关联很费时，但带来的好处并不大。（5）避免显示冗余或导出的关联。聚合vs.组合识别聚合（组合）结构的意义：在动态建模时帮助进行职责分配。举例：发给订单的修改订单项消息，在内部是通过调用订单项的修改消息完成的。比较：关联的几种表现形式2.8识别聚合（组合）思路（1）物理上的整体事物和它的组成部分（2）组织机构和它的下级组织（3）团队（组织）和成员（4）空间上的包容（5）抽象事物的整体和部分2.9识别连接（1）将注意力集中在那些需要将概念之间的关系信息保持一段时间的关联。（2）识别实体类比识别关联更重要。（3）太多的关联不仅不能有效地表示对象模型，反而会使对象模型变得混乱。（4）避免显示冗余或导出的关联。课堂作业：根据前面的类图，识别类之间的关联（聚合、组合、连接），要说明多重性，如果关联的形式是“连接”，还要注明关联名。三、动态模型几乎解决任何一个问题，都需要从客观世界实体间的相互关系中抽象出有价值的对象模型；当问题涉及交互作用和时序（如用户界面或过程控制等），动态模型