软件工程教案(理论课程)

1、教师备课教案本(理论课程)系 别：计算机工程系课程名称：软件工程教师姓名：段琢华授课时间：20132014学年第 2 学期电子科技大学中山学院教师授课计划*课程名称软件工程学分3课程类型1、普通教育必修课（ ）； 2、学科基础必修课（ ）； 3、专业方向课（ ）；4、学科基础选修课（ ）； 5、素质教育选修课（ ）； 6、专业选修课（ ）。学时分配总学时：48 ；课堂讲授： 32学时； 实践（验）课 16学时授课起止周1-16授课班级游戏11，嵌入式11,网络11班级人数56,69,50授课总次数*16教材名称软件工程案例教程：软件项目开发实践 第2版作者韩万江 姜立新出版时间2011年10月

2、13日章节基 本 内 容计划学时1软件工程总揽（软件工程知识体系，软件工程的三段论，方法、过程和工具的概述）62软件开发模型及可行性研究2软件需求（需求定义，需求层次，需求建模，需求规格说明，需求验证和变更控制）43分析建模（领域建模，架构设计）44软件设计（设计模式的应用, 子系统设计）86软件编码（编码方法，编码过程）47软件测试、发布与维护（测试方法，测试级别）4考核要求（根据课程实际情况，不做要求的项目可不写）：1、平时成绩的构成比例和考核方式；20% 考勤和读书笔记2、期中成绩的构成比例和考核方式；3、期末成绩的构成比例和考核方式；50% 综合课程设计4、实验成绩的构成比例和考核方式

3、。30% 上机实验。 填表日期： 2014年 02月 25日 教案时间安排第 周 ，总第 次课 章节名称第一章 总揽（4次课）教学目的讲解软件工程三个基本要素，通过比较各种软件工程方法的优缺点来给出面向对象软件工程方法论。同时讲解各种软件过程模型，以及uml建模语言的相关知识。教学重点与难点软件工程的三个基本要素面向对象软件工程思想，学会以对象的方式来思考问题uml表示法教学内容与过程设计教学内容与过程设计软件工程的成果是为软件设计和开发人员提供思想方法和工具，而软件开发是一项需要良好组织、严密管理且各方面人员配合协作的复杂工作。软件工程正是指导这项工程的一门科学。一、软件工程知识体系（1）需

4、求定义为解决真实世界问题而必须展示的特性。（2）设计既是“定义一个系统或组件的体系结构、组件、接口和其它特征的过程”，又是“这个过程的结果”。（3）软件构造指通过编码、验证、单元测试、集成测试和排错的组合，详细创建一个可以工作的、有意义的软件。（4）软件测试由在有限测试用例集合上，根据期望的行为，对程序的行为进行的动态验证组成，测试用例是从实际上是无限的执行域中适当的选择出来的。（5）软件一旦投入运行，就可能出现异常，运行环境可能发生改变，用户会提出新的需求。生命周期的维护阶段从软件交付时开始，但维护活动出现得还要早。（6）软件配置管理（software configuration manag

5、ement，scm）是为了系统地控制配置的变更和维护配置在整个系统的生命周期中的完整性和可追踪性，而标识软件在时间上不同点的配置的学科。（7）软件工程管理知识域处理软件工程的管理与度量，虽然度量是所有知识域的一个重要方面，但在这里涉及的是度量程序的主题。（8）软件工程过程的知识域涉及软件工程过程本身的定义、实现、评定、度量、管理、变更和改进。（9）软件工程工具和方法知识域包括软件工程工具、软件工程方法。（10）软件质量知识域处理跨越软件生命周期过程的软件质量的考虑，由于软件质量在软件工程中无处不在，其它知识域也涉及质量问题，读者可以注意到本知识域到其它知识域的指示器。考核方式：组队，通过在整个

6、项目的实施过程中不断贯彻软件工程的思想，达到培养团队开发的目的。讨论：小组人数最好多于3人，这是基于以下事实：给延期的项目增加人手会使项目进一步延期。因为向项目中增加人手，就必须花时间来进行培训。因此最终结果变成了：新增人员贡献非常慢，即使他们的效率确实很高时，那也只是耗尽了原有程序员的时间和精力。而且，项目中的程序员越多，程序员之间的相互交流就越复杂。该事实诠释了一部软件工程经典著作的书名，the mythical man-month即人月神话。该书指出：虽然我们采用人月（people per month）为单位来安排人手，但是每个人对软件的贡献各不相同，所以这些人月也不尽相同。在项目后期加

7、入的人员更是如此，这些人的贡献几乎可以忽略不计。二、软件工程概述人物简介：watts s.humphrey瓦茨·s·汉弗莱在软件工程领域享有盛誉，被美国国防软件工程杂志crosstalk评为近几百年来影响软件发展的十位大师之一。瓦茨·s·汉弗莱在ibm工作了27年，负责管理ibm全球产品研发。离任后，受美国国防部委托，加入卡内基·梅隆大学软件工程研究所（sei），领导sei过程研究计划，并提出了能力成熟模型（cmm）思想。在cmm浪潮席卷软件工业界之时，他又力推个人软件过程（personal software process，psp）和团队软件

8、过程（team software process，tsp），成为软件开发人员和开发团队的自修宝典。强调：这里需要注意“复杂”两个字，过于简单的应用没有必要是结构复杂化，高级的体系结构、框架、设计模式都是为复杂系统准备的。软件的复杂性：软件是一个庞大的逻辑系统，此外，软件主要依靠人脑的“智力”构造出来，多种人为因素使得软件难以统一化，更增加了其复杂性。软件的复杂性使得软件产品难以理解，难以生产，难以维护，更难以对生产过程进行管理。许多软件项目在某些方面非常复杂。例如，软件所涉足的应用领域往往包含复杂的专业知识，而懂得应用领域专业知识的人很可能不是实际编写软件的人。所以，这些领域的专家必须和负责软

9、件开发的技术人员交流自己的需求。交流的过程是复杂的，软件开发人员只有在理解了用户面临的问题和需求后，才能动手开发软件。最后，许多进行中的软件项目规模非常大，不可能由一个人独立完成，因而开发技术小组必须将开发任务分成易于管理的模块，当各个部分全部完成后，将它们组装成可以协同工作的整体。将一个大项目分割成几个小部分，每个小部分由不同的人来开发，并且保证这些部分可以在一起工作，这个工程成为软件开发过程另一个复杂的来源。软件发展过程强调软件工程学科的发展没有停止，而且这里面没有教条，只有实践。举例：1、伦敦股票交易系统当初预算4.5亿英镑，后来追加到7.5亿英镑，历时五年，但最终还是失败，导致伦敦股票

10、市场声誉下跌。2、2007年北京机场信息系统瘫痪。2007年10月10日13时28分，设在北京首都国际机场的中国民航信息网络股份公司离港系统突然发生故障，短短50分钟内，北京、广州、深圳、长沙机场至少84个离港航班发生延误。该系统是由美国某家公司研发，此事件引发信息系统安全的担忧。3、2008年北京奥运会售票系统于2007年10月30日上午11时瘫痪：北京奥运会的指定独家票务供应商北京歌华特玛捷票务公司成立于2006年9月，由美国特玛捷公司、中体产业股份有限公司及北京歌华文化发展集团三家出资构建而成。售票系统瘫痪事件发生后，公众普遍质疑该公司是否具备承担08年北京奥运会的票务销售能力。三、软件

11、工程三个要素方法、工具、过程。软件工程是一门建立在以质量焦点为基础，分过程、方法和工具三个研究层次的综合技术。软件工程的基层是过程层，软件过程层是将方法和技术结合在一起的凝聚层，使得软件能够合理地、及时地开发出来。软件方法：在软件开发过程中所采用的技术，例如结构化的方法、面向对象的方法。软件过程：在软件产品生产过程中，软件人员所进行的一系列的软件工程活动。软件工具：在软件开发过程中为了实现某些方法而采用的手段，例如case工具，uml以及rose等。讨论：一个有争议的观点：在软件开发中，最重要的因素不是程序员采用的工具、技术和语言，也不是过程，而是程序员自身的质量。这一观点来源于peoplew

12、are人件。其中说道“我们工作中最重要的问题与其说是技术问题，还不如说它本质上是社会问题。”并提出了“人员的作用远远大于其他任何因素”。这本书还有一些独到的见解，比如“工作环境对工作效率和产品质量也有影响”。例如，“最好团队的工作空间是最差团队的1.7倍（测量可用地板空间），而最好团队的表现是最差团队的2.6倍。软件工程的基本原理1. 用分阶段的生命周期计划严格管理2. 坚持进行阶段评审3. 实行严格的产品控制4. 采用现代程序设计技术5. 结果应能清楚地审查6. 开发小组的人员应该少而精7. 承认不断改进软件工程实践的必要性四、软件方法论软件描述的就是现实业务在计算机中的映射，说起来简单，做

13、起来很难。因为现实业务越来越复杂，而用户希望对软件的操作是越直接越好。软件分析设计方法的演变：1、没有方法。即意大利面条：spaghetti code，意指包含复杂庞大控制结构，杂乱无章的代码，特别是大量使用goto语句的代码等等。2、功能分解法功能分解功能子功能功能接口以系统需要提供的功能为中心来组织系统。适用于功能稳定的应用领域，如科学计算等。缺点：开头容易，结束难。对众多领域而言，功能易变。如企业管理和商业管理。对需求变化的适应能力很差。局部错误和局部修改很容易产生全局性的影响。重视功能，忽略数据。【举例】工资支付系统：更新工资信息；发放工资。更新工资信息：检查员工信息；提交工作记录；计

14、算应发工资。发放工资：检查员工信息；计算应发工资；打印工资单；登记领取。3、数据流法：又称作结构化分析。基本策略是跟踪数据流，即研究问题域中数据如何流动以及在各个环节上进行何种处理，从而发现数据流和加工。4、信息建模法：信息建模实体（对象）属性关系父类型/子类型关联对象由实体关系法发展而来。与数据库设计有很深的渊源。核心概念是实体和关系，实体描述问题域的事物，包含属性。关系描述事物之间在数据方面的联系，也可以带有属性。重视实体，而忽略功能。5、面向对象方法：面向对象方法的出发点和基本原则，是尽可能模拟人类习惯的思维方式，使开发软件的方法与过程尽可能接近人类认识世界解决问题的方法与过程，也就是使

15、描述问题的问题空间(也称为问题域)与实现解法的解空间(也称为求解域)在结构上尽可能一致。五、面向对象的基本概念（1）对象在应用领域中有意义的、与所要解决的问题有关系的任何事物都可以作为对象，它既可以是具体的物理实体的抽象，也可以是人为的概念，或者是任何有明确边界和意义的东西。例如，一名职工、一家公司、一个窗口、一座图书馆、一本图书、贷款和借款等，都可以作为一个对象。总之，对象是对问题域中某个实体的抽象，设立某个对象就反映了软件系统保存有关它的信息，并具有与它进行交互的能力。对象的定义对象是封装了数据结构及可以施加在这些数据结构上的操作的封装体，这个封装体有可以唯一标识它的名字，而且向外界提供一

16、组服务。属性表示对象的性质，属性值规定了对象所有可能的状态。对象的操作是指该对象可以展现的外部服务。例如，大型客机可视为对象，它具有位置、速度、颜色、容量等属性，对于该对象可施行起飞、降落、加速、维修等操作，这些操作将或多或少地改变飞机的属性值(状态)。（2）类是具有相同数据结构和相同操作的一组相似对象的抽象。即表示某些对象在属性和操作方面的共同特征。例如：直升飞机、大型客机、轰炸机可归为飞行器类。共同属性有：位置、速度和颜色等共同操作有：起飞、降落、加速和维修等类是在对象之上的抽象，有了类以后，对象则是类的具体化，是类的实例。把一组对象的共同特性加以抽象并存贮在一个类中的能力，是面向对象技术

17、最重要的一点！（3）消息对象之间进行通讯的一种构造叫做消息。 当一个消息发送给某个对象时，包含要求接收对象去执行某些活动的信息。接收到消息的对象经过解释，然后予以响应。这种通讯机制叫做消息传递。发送消息的对象不需要知道接收消息的对象如何对请求予以响应。访问一个方法的过程称为向这个对象发送一个消息。例如：mycircle.show(green)，mycircle是接收消息的对象的名字，show是消息名，green是消息的变元。消息的理解a）如何要求对象完成一定的处理动作？对象间如何进行联系？所有这一切都只能通过消息传递来实现。b）传递消息的对象称为发送者，接受消息的对象称为接受者。c）消息中只包

18、含传递者的要求，它告诉接受者需要哪些处理，但并不指示接受者应该怎样完成这些处理。d）消息完全由接受者解释，接受者独立决定采用什么方式完成所需的处理，发送者对接受者不起任何控制作用。（4）封装封装帮助你管理复杂度的方法是不让你看到那些复杂度。在面向对象的程序中，把数据和实现操作的代码集中起来放在对象内部。一个对象好像是一个不透明的黑盒子，表示对象状态的数据和实现操作的代码与局部数据都被封装在黑盒子里面，从外面是看不见的，更不能从外面直接访问和修改这些数据和代码。使用对象的时候只需要知道他向外界提供的接口的形式，无须知道它的数据结构细节和实现操作的算法。信息隐藏的一个例子：假设你有一个程序，其中的

19、每个对象都是通过一个名为id的成员变量来保存一种唯一的id。这种设计方法是用一个整数来表示id，同时用一个名为g_maxid的全局变量来保存目前已分配的id的最大值。每当创建新的对象时，你只要在该对象的构造函数中简单地使用id=+ g_maxid，就肯定能获得一个唯一的id值，这样设计有没有问题？问题：1、如果你想把某些范围的id留做它用该怎么办？2、如果你想使用非连续的id来提高安全性？3、如果你想重新使用已销毁对象的id？4、如果你的程序是多线程的，这种方法也不是线程安全的。创建新id的方法就是一种你应该隐藏起来的设计决策。如果你在程序中到处使用+ g_maxid，你就暴露了创建新id的方

20、法。相反，如果你在程序中都使用id=newid()，那么就把创建新id的方法隐藏起来了。再假设你发现需要把id的类型由整型改为字符串。此时你会想到应该隐藏id的类型。在c+里面，你可以简单地使用typedef把id定义为idtype，或者定义一个idtype的类。（5）继承广义地说，继承是指能够直接获得已有的性质和特征，而不必重复定义它们。在面向对象技术中，继承是子类自动地共享基类中定义的数据和方法的机制。（6）多态“this ability to manipulate more than one type with a pointer or a reference to a base cla

21、ssis spoken of as polymorphism” (c+ primer第838页)。即用基类的指针/引用来操作多种类(基类和其派生类)的对象的能力称之为多态。它是从语言实现的角度来考虑的。“polymorphism provides another dimension of separation of interface from implementation, to decouple what from how”(think in java3rd edtion)，即多态提供了另外一种分离接口和实现的尺度，即把“做什么”与“怎么做”分开 。它是从设计的角度考虑的。 “the ab

22、ility to use the same expression to denote different operations is refered to as polymorphism”，(object-oriented methods principles & practice3rd edition，第16页)。简单的说，多态就是“相同的表达式，不同的操作”，也可以说成“相同的命令，不同的操作”。这是从面向对象的语义的角度来看的。三种说法分别从不同的角度来阐述了多态的实质。其中第三种说法尤为确切：相同的表达式函数调用不同的操作根据不同的对象就有不同的操作比如在公司中有各种职责不同的

23、员工(程序员，业务员，文管等)，他们“上班”时，做不同的事情(也可以看作是一种业务逻辑)，我们把他们各自的工作都抽象为"上班"，关系如下： 不恰当的比喻：oo的精髓是继承、封装和多态。继承就是说：你的爱人会继承做你女朋友时的相当多的优点，因为这些优点对你都是public的，但同时她也会继承以前的更多的缺点，因为其中很多缺点对你是protected，继承后才让你能访问。 封装就是说：许多不想让你知道的东西她会封装起来，你只能通过她提供的有限的接口来访问到被接口函数做了手脚的东西。多态就是说：在她心情不同时，你去访问以她为参数的一个函数得到的结果是不同的。比如对她说“我爱你”。

24、六、软件过程过程模型的思想只有两种：顺序和迭代。顺序：一年的时间，分成4个阶段，每个阶段完成一项任务。迭代：一年的时间，分成4个阶段，每个阶段作为一次迭代周期，每个迭代周期完成一系列任务。选择顺序方法的理由：1、需求相当稳定2、设计直截了当，而且理解透彻。3、开发团队对于这一应用领域非常熟悉。4、项目的风险很小。5、后期改变需求，设计和编码的代价很可能较昂贵。选择迭代方法的理由：1、需求并没有被理解透彻，或者出于其他理由你认为它是不稳定的。2、设计很复杂，或者有挑战性。3、开发团队对于这一应用领域不熟悉。4、项目包含许多风险。5、后期改变需求，设计和编码的代价很可能较低。1、瀑布模型瀑布模型的

25、特点：阶段间具有顺序性和依赖性；尽可能推迟程序的物理实现；基于文档驱动的模型。瀑布模型的缺点：传统的瀑布模型过于理想化，实际的瀑布模型是带“反馈环”的。需求具有变更性，无法在最初就准确无误的确定下来。最终开发出的软件产品可能并不是用户真正需要的。所以瀑布模型的采用，一定要保证需求必须是准确定义和相对稳定的。2、快速原型模型快速原型模型是不带反馈环的，软件产品的开发基本上是线性顺序进行的。因为原型系统已经通过与用户交互而得到验证，据此产生的规格说明文档正确地描述了用户需求。快速原型模型的本质就是“快速”，一旦需求确定了，原型将被抛弃。制作原型：制作原型是指开发出系统中关键功能的实际模型。例如开发

26、出一部分用户界面的原型可以判断系统的可用性，开发出关键算法的原型可以确定功能的执行时间，开发出典型数据集的原型能知道程序的内存需求。3、增量模型把软件产品作为一系列的增量构件来设计、编码、集成和测试。通常，第一个增量构件往往实现软件的基本需求，提供最核心的功能。交付产品时采用分批逐步向用户提交产品，而不是一次性交付产品。使用增量模型的困难是，在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发的产品。因此必须把软件的体系结构设计得具有开放性和扩充性。增量模型具有可在软件开发的早期阶段使投资获得明显回报和较易维护的优点。在进行增量开发时，我们先做出软件系统的一个尽可能简单、但能

27、运行的版本。它不必接受真实的输入，也无需对数据进行真正的处理，更不用产生真实的输出它仅仅需要构成一个足够强壮的骨架，支撑起未来将要开发的真实系统。在骨架形成之后，你要一点点地在其上附着肌肉和皮肤：把每个虚假的类替换为真正的类；不再假装接受输入，而是把接收真实输入的代码替换进去；不再假装产生输出，而是把产生真实输出的代码替换进去。你一次增加一小部分代码，直到得到一个完全可以工作的系统。【举例】采用增量模型开发的字处理软件，在第1个增量中提供基本的文件管理、编辑和文档生成功能；在第2个增量中提供复杂的编辑和文档生成功能；在第3个增量中提供拼写和语法检查功能；在第4个增量中提供高级页面排版功能。4、

28、螺旋模型螺旋模型可以理解为带有风险分析过程的快速原型模型。构建原型是一种能使某些类型的风险降至最低的方法，但原型不能“包治百病”，对于某些类型的风险（例如，聘请不到需要的专业人员，或关键的技术人员在项目完成前“跳槽”），原型方法是无能为力的。螺旋模型的基本思想是：使用原型及其他方法来尽量降低风险。即每个阶段之前都增加了风险分析过程和快速原型模型。5、喷泉模型“喷泉”体现了面向对象软件开发过程迭代和无缝的特性。因为用面向对象方法开发软件时，在分析、设计和编码等项开发活动之间并不存在明显的边界。举例：如何进行迭代和进化式分析和设计。假设在项目交付前，最终将有20次迭代。1）在第1次迭代之前，召开第

29、一个时间定量的需求工作会议，例如确切的定义为两天时间。业务和开发人员（包括首席架构师）需要出席。在第一天上午，进行高阶需求分析，例如仅仅确定用例和特性的名称，以及关键的非功能性需求。这种分析不可能是完美的。通过咨询首席架构师和业务人员，从高阶列表中选择10列表项，假设为3个用例，这些项目需要具备以下三种性质：1、具有重要的架构意义，2、具有高业务价值。3、具有高风险。在剩下的一天半内，对这3个用例的功能和非功能性需求进行详细的分析。完成这一过程后，对10进行了深入分析，90进行了高阶分析。2）在第一次迭代之前，召开迭代计划会议，选择3个用例的子集，在特定时间内进行设计、构造和测试。3）在三到四

30、周内完成第一次迭代（选择时间定量，并严格遵守时间）。在开始两天内，开发者和其他成员分组进行建模和设计工作，画出uml草图。然后，开发者摘掉其“建模帽子”并带上“编程帽子”，开始编程、测试和集成工作并且剩余的时间均用于完成这项工作。进行大量的测试，包括单元测试、验收测试、负载测试和可用性测试。在结束前的一周，检查是否能够完成初始的迭代目标；如果不能，则缩小迭代范围，将次要目标置回任务列表中。在最后一周的星期二，冻结代码，必须检入、集成和测试所有代码，以建立迭代的基线。4）在第一次迭代即将结束时，召开第二次需求工作会，对上一次会议的所有材料进行复查和精化。然后选择具有重要架构意义和高业务价值的另外

31、10到15的用例，用一到两天对其进行详细分析。这项工作完成后，会详细记录大概25的用例和非功能性需求。当然，这也不是完美的。5）与周五上午，举行下一次迭代的迭代计划会议。6）以相同的步骤进行第2次迭代。7）反复进行四次迭代和五次需求工作会，这样在第4次迭代结束时，可能已经详细记录了约8090的需求，但是只实现了系统的10。8）我们大概推进了整个项目过程的20。在up的术语里，这是细化阶段的结束。9）此后，一般不需要再召开需求工作会；需求已经稳定了。接下来是一系列为期三周的迭代，在最后一个周五召开的迭代计划会上选择适宜的下一步工作。总结：最重要的up思想迭代开发在这种方法中，开发被组织成一系列固

32、定的短期小项目，称为迭代；每次迭代都产生经过测试的、经过集成的和可执行的系统。每次迭代都有自己的需求分析、设计、实现和测试活动。迭代的输出不是实验性或将丢弃的原型，迭代开发也不是原型开发。与之相反，其输出是最终系统的产品的子集。迭代开发不是要通过在实现前试图完整和正确地描述、冻结和“终止”一个已冻结的需求集和设计来应对软件开发中出现的不可避免的变更，而是要基于拥抱变更和适应调整的态度将变更和调整作为迭代开发中不能避免且真正必要的驱动力。每次迭代选择一小组需求，并快速设计、实现和测试，可以得到快速的反馈来自用户、开发人员和测试（例如负载测试和可用性测试）的反馈。迭代开发的优点：1、 在早期而不是

33、晚期缓解高风险（技术、需求、目标、可用性等方面的风险）。2、 早期可见的发展。3、 早期反馈、用户参与和调整，会得到一个更接近项目相关人员真实需求的经过精化的系统。4、 可控复杂性；开发组不会被“分析瘫痪”或长期复杂过程所淹没。5、 在一次迭代中学到的知识可以被有系统地用于改进开发过程本身，下一次迭代也是如此，依次类推，进行下去。up阶段和流程（1） 初始阶段：大体上的构想，业务案例，范围，模糊评估。（2） 细化阶段：已精化的构想，核心架构的迭代实现，高风险的解决，大多数需求和范围的识别，更为现实的评估。（3） 构造阶段：迭代实现遗留下来的风险较低和比较容易的元素，准备部署。（4） 移交阶段：

34、beta测试，部署。细化阶段的一些关键思想和最佳实践包括：1、 做短时间分区的、风险驱动的迭代。2、 尽早开始编程。3、 适应性地设计、实现并测试架构的核心和风险部分。4、 尽早、经常、实际地测试。5、 基于来自测试、用户、开发人员的反馈信息进行调整。6、 通过一系列的研讨会，每个细化迭代一次，详细编写大部分用例和需求。细化阶段中在架构方面重要的是什么：1、早期的迭代建立和证明核心架构。（1）采用“宽且浅”的设计和实现方案。即识别单独的过程、层、软件包和子系统以及它们高层的职责和接口，为了连接它们以及阐明接口而部分实现它们。（2）细化模块间的本地和远程接口。（3）集成已有的组件。2、为了得到反

35、馈信息，调整并证明核心架构是健壮的，细化阶段测试是重要的。七、软件工具：umluml也称为统一建模语言。它提供了一个可视化的建模语言，所谓可视化即通过一些很直观，容易理解的图形化来描述系统。因此用uml实现的文档形式为：“图形化文本描述 相应文档”uml语言很全面，庞大，可以表示各种复杂的问题。这样一个丰富的语言，我们只需要用其20%部分，描述80的问题，因此学习中，我们只需要掌握常用的基本组成部分，关键是要对这些组成部分了解之后，能够应用他所提供的表示方法，进行分析和设计。实际上在真正应用里面，活用uml是非常关键的，虽然它是一个语言，但是应用这个语言要根据分析设计里面需要描述设计模型的需要

36、来应用。而不是说死记一些条目，很死板的去应用。只有活用，才能感受到uml语言的威力。一个比喻：uml中所提供的标准的图符，相当于音乐五线谱里的乐符，学会看乐符才能看得懂乐谱，才能进一步创造音乐。同样，懂得uml中的图符，才能进行系统分析和设计。应用uml的三种方式（1）uml作为草图非正式的、不完整的图（通常是在白板上手绘草图），借助可视化语言的功能，用于探讨问题或解决方案空间的复杂部分。（2）uml作为蓝图相对详细的设计图，用于：1）逆向工程，即以uml图的方式对现有代码进行可视化，使其易于理解。2）代码生成（前向工程），一般情况下，代码生成工具使用图生成一些代码，然后由开发者编写并填充其他

37、代码。（3）uml作为编程语言用uml完成软件系统可执行规格说明。可执行代码能够被自动生成，但并不像通常一样为开发者所见或修改，但是目前在理论、工具的健壮性和可用性方面仍然处于发展阶段。说明：uml和银弹思想，即相信软件中存在某种特殊的工具或技术，可以在生产率、缺陷减少、可靠性和简易性等方面带来极大的变化。工具无法弥补设计上的疏漏。uml的应用对象建模是用例驱动（即建立用例模型，从分析到设计都是以用例为核心来设计）：优势于功能列表（不是站在用户的角度考虑问题）以体系结构为中心（整个系统中强调体系结构的设计）迭代开发过程（由于开发过程不是一下子能够全部完成的，强调迭代化的开发，可以在用例的设计过

38、程中不断的设计和补充）41视图在用uml语言建立相应系统模型时，具体对于软件系统是用什么样的视图描述，通常uml建议采用415 个视图的描述。用例视图：整个系统核心，它是从用户角度对系统的参与和要求的交互过程。描述整个系统具有什么样的功能。它也是后续设计、实现、实施、测试等等所有阶段的核心和基础，所有后续阶段或其他视图都以它为根本。逻辑视图：描述该系统，即用例中的所有功能 ，其内部结构是什么，组成关系是什么。主要应用于分析设计人员，建立相应结构。象静态结构方面：类，对象，及其关系；动态行为方面：并发，消息等相互联系。建立了逻辑视图之后，还要对系统进程、并发等机制进行描述。进程视图：处理并发和同

39、步的线程和进程。实现视图：具体开发时，怎样把大的复杂系统分解成若干小的不同系统，进行搭建，或不同组件进行组合。一般大系统可能有不同组件，到底有哪些组件，哪些文件，这些组件，这些文件怎样连接，构成所要实现的系统。分布视图：系统开发完成后，系统可能是在分布式环境、网络环境下运行，系统不同部分在网络环境下怎样分布、布置，在部署视图中提供。总结：由这样5个视图从不同方面完整的表示了系统的所有功能和需要提供各个方面的要求。uml的组成：uml的词汇表包括3种构造模块：元素、关系、图。（1）元素：模型中重要的抽象。结构元素：uml模型中的名词。是模型中主要的静态部分，代表了概念的或物理的元素。1、用例与协

40、作：前面讲过的用例是表示系统要实现的一个具体功能，要完成这个功能，实际需要一组对象类，及其对象类之间的互相关联来实现的，因此协作是对具体用例的实现进行建模，表示方法为虚椭圆。区别： 用例只是描述对外呈献的行为，不关心这些具体功能是怎样实现的，而协作描述要实现这个用例的功能，具体需要哪些类，类与类之间的关系怎样。因此用例和协作之间是实现的关系。2、主动类：在类里面有一种类和一般类有一定区别，这种类具有主动的行为，一般来讲它可以主动的启动一些控制的活动，对实现来说它通常拥有一个进程或线程。它的表示方式是在外边框加粗。例如：事件管理器，它对事件队列有挂起，刷新功能，该类有一个进程对应，有主动控制的行

41、为，称为主动类。3、构件：在大的系统开发过程中，往往把复杂的系统分成不同的构件，所以系统里面真正可以替代的构件在uml里面也有相应的描述，构件往往和接口一起使用的，因为任何构件的对外服务都是通过接口来描述的。行为元素：uml模型中的动态部分，它是模型中的动词，代表了跨越时间和空间的行为。uml中有两种主要的行为元素：交互作用（interaction）和状态机（state machine）。1、 交互作用：由在特定上下文中为完成特定目的而在对象间交换的消息集组成的行为。交互作用包括许多其他元素：消息、动作序列（由消息激活的行为）、连接（对象间的连接）。2、状态机：对象真正在创建到消亡的过程中，即

42、实际生命周期里，是通过响应一定的事件，经历了不同的状态，所以状态机来描述对象所经历的状态的序列，及触发状态变化的事件。例如：命令处理的状态转换。开始系统一启动，进入初始状态，在初始状态进行初始化，准备工作；初始化完成后，进入空闲状态，循环等待输入的状态。如果接收了键盘输入，就使得系统从空闲状态进入命令处理状态，可能一个命令是由多个字符组成，所以它在接收相应按键之后把相应字符存入命令队列中，然后返回空闲状态，当下一次再有按键进入时，又继续进行处理，如果完整的命令输入完之后，可能要调用相应的命令处理程序执行，如果命令是一个结束的命令，则整个状态机就结束了。所以状态机有一个开始状态，多个结束状态，中

43、间还有不同的中间状态，每个状态转换都有相应的事件触发。分组元素：是uml模型中用来组织元素的元素。在基本的事物组成中，经常把大量事物通过分包的方式进行组合。包：把一类基本元素分类，按照分包的原则可以各种各样。注释元素：是uml模型中解释性的部分。（2）关系：事物之间的连接。真正要构成一个系统，事物之间是有一些关系的。例如：课表和课程之间，课程可以加到课表里，或从课表里删除。课程变化时，课表相应发生变化。课程和课表之间是依赖关系。关联关系：属性可见性。通常需要保持长期，稳定存在的关系。依赖关系：非属性可见性（局部、本地、全局可见性），通常只需要保持短期的，局部的关系。实现关系：把具体形式化的描述

44、与具体实现分离的方法。好处：把对外的形式化描述和具体实现分离，分离后如果内部实现改变，只要对外形式化描述不变，跟外部交互连接的部分不受到影响。（3）图：把事物通过关系连接起来形成图。真正描述模型是用一个个图来描述的。uml的9种图：用例图：定义了系统的功能需求，它完全是从系统的外部观看系统功能，并不描述系统内部对功能的具体实现。类图：描述系统的静态结构，表示系统中的类以及类与类之间的关系。对象图：描述了一组对象以及它们之间的关系，表示类的对象实例。组件图：描述组件以及它们之间的关系，表示系统的静态实现视图。具体系统可能划分成不同组件和模块，有哪些模块，组件之间的关系怎样由组件图描述。例子：在课

45、程注册管理系统中，有两个子系统：收费系统，注册系统。注册系统分为：课程组件，人员管理组件。注册系统在课程注册完后，通过接口调用收费系统，将学生相应注册信息传递给收费系统，形成对学生的收费单，通知学生交费。课程系统又通过接口管理相应课程信息，即课程模块。对于学生教师人员进行管理。通过这两个模块，实现存取相应人员和课程信息，最后实现相应功能。部署图：反映系统中软件和硬件的物理架构，表示系统运行时的处理节点，以及节点中组件的配置。时序图和协作图：都表示一组对象之间的动态协作关系。其中时序图反映对象之间发送消息的时间顺序，协作图反映收发消息的对象的结构组织。时序图和协作图是同构的，即两者之间可以相互转

46、换。状态图：强调同一个类里对象状态变化过程，和相应事件触发过程。所谓状态，是对对象属性值的一种抽象。各对象之间相互触发（即作用）就形成了一系列的状态变化。我们把一个触发行为称作一个事件。对象对事件的响应，取决于接受该触发的对象当时所处的状态，响应包括改变自己的状态或者又形成一个新的触发行为。状态有持续性，它占用一段时间间隔。状态与事件密不可分，一个事件分开两个状态，一个状态隔开两个事件。事件表示时刻，状态代表时间间隔。活动图：反映系统中从一个活动到另一个活动的流程，强调对象间的控制流程。八、敏捷宣言agile software 敏捷过程作为对惯例性过程的挑战，由17位方法学家于2001年2月提

47、出。在该方法论中，他们提出了4项价值以鼓励更好的开发软件：1、个人和交互高于过程和工具。开发过程中，最重要的因素是必须考虑到开发者是如何在一起工作的，因为如果他们不能摆正态度的话，最好的工具和过程也将会失去作用。2、可工作软件高于详尽的文档。3、与客户合作高于合同谈判。只有客户才能告诉开发者他们想要什么。与客户建立合同是重要的，但合同不能代替相互之间的沟通。4、对变化及时做出响应高于遵循计划。变化是软件开发的现实。教学后记*“教学后记”是授课完毕之后，教师对授课准备情况、授课过程及授课效果的回顾与总结，因此，教师应及时手写补充完整本部分内容。时间安排第 周 ，总第 次课章节名称需求工程（4次课

48、）教学目的1、 需求的定义和需求的层次。2、 什么是用例，如何编写用例。3、 如何构建需求模型，如何编写需求规格说明书。教学重点与难点1、需求捕获的方法。2、用例。3、需求模型的构建。4、需求规格说明书的编写。教学内容与过程设计教学内容与过程设计启动软件项目是由于软件需求的存在，资料表明，软件项目中4060的问题都是在需求分析阶段埋下的隐患。软件开发中返工开销占开发总费用的40，而其中7080的返工是由需求方面的错误所导致。因此一个项目成功的关键因素之一就是对需求分析的把握程度。而项目的整体风险往往表现在需求分析不明确，业务流程不合理，所以，需求分析是软件开发的重要一环。软件的需求具有模糊性、

49、不确定性、变化性和主观性的特点，相比硬件的需求，是有形的、客观的、可描述的、可检测的。一、需求的定义需求，是指对用户需要解决的问题的整体描述。需求是软件实现之源，没有了需求，软件也就无从谈起。在ieee软件工程标准词汇表中定义需求为：（1）用户解决问题或达到目标所需要的条件或能力（2）系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力（3）一种反映上面（1）或（2）所描述条件或能力的文档说明二、需求的层次软件需求是指用户对软件的功能和性能的要求。软件人员要准确理解用户的要求，进行细致的调查分析，将用户非形式化的需求陈述转化为完整的需求定义，再由需求定义转化到相应形式的需

50、求规格说明。有时也可以将软件需求按照层次来说明（如上图）。业务需求：反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中说明。用户需求：用户使用产品必须要完成的任务，它们通常使用用例文档（use case）进行说明。功能需求：开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。非功能需求：描述系统展现给用户的行为和执行的操作等。包括：产品必须遵循的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件；质量属性。通常也可以总结为 furps+：functional（功能性）：特性、功能、安全性。usability（可用性）：人性化因素

51、、帮助、文档。reliability（可靠性）：故障频率、可恢复性、可预测性。performance（性能）：响应时间、吞吐量、准确性、有效性、资源利用率。supportability（可支持性）：适应性、可维护性、国际化、可配置性。：表示一些辅助性的和次要的因素，比如：实现（implementation）：资源限制、语言和工具、硬件等。接口（interface）：强加于外部系统接口之上的约束。操作（operation）：对其操作设置的系统管理。包装（packaging）：例如物理的包装盒。授权（legal）：许可证或其他方式。软件需求规格：软件需求规格充分描述了软件系统应具有的外部行为，它描

52、述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；非功能性需求（例如性能要求等）；设计或实现的约束条件及质量属性。软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起到重要的作用。为了强调非功能需求，举例说明：2月27日，中央电视台“第一时间”报道了北京市二中院开庭审理程稚瀚涉嫌盗取北京移动通信公司充值卡密码一案，程稚瀚曾是ut斯达康深圳分公司工程师，被指控利用网络技术手段侵入北京移动通信公司充值中心数据库，修改充值卡原始数据并窃取了充值卡密码，并通过淘宝网和qq向他人出售，致使北京移动通信公司损失近380万元。该栏目主持人认为

53、：1.2亿元网络安全投入，居然不堪一击，中国移动也该好好总结一下了。事实上，程稚瀚在作案过程中使用的大多都是些没有技术含量的攻击手段，但是偏偏没有技术含量的攻击事件，在电信、银行、证券、保险业却屡屡得逞另一个案例：两大学生利用网通adsl用户升级时系统的漏洞，在一个月内盗取了价值70余万元的网易一卡通虚拟游戏点卡。不能不令我们深思。三分技术，七分管理”的网络安全体系建立原则几乎被每个电信和银行业的企业所强调，并成为指导其安全管理体系建设的基本原则。 三、需求工程20世纪80年代中期，形成了软件工程的子领域需求工程。需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理

54、解问题并定义目标系统的所有外部特征的一门学科。四、需求问题的代价在早期阶段，软件是无形的，除了一些文档性的规格说明以外没有什么具体有形的东西，而且比较容易修改。但随着时间的推移，软件产品越来越详细（在设计阶段），越来越具体（在编码阶段），越来越固定（当代码逐渐接近最终的方案时）。在早期可以轻易改变的东西，越到后期就越难得多。很多人不理解这些前期准备的重要性，其实我们可以把软件过程比作食物链。其中程序员是软件食物链的最后一环。架构师吃掉需求，设计师吃掉架构，而程序员则消化设计。在健康的生态环境中，海鸥吃新鲜的鲑鱼。这对海鸥是营养丰富的大餐，因为鲑鱼吃的是新鲜的青鱼，而青鱼吃的是新鲜的水蝽。这是一

55、条健康的食物链。在软件开发中如果食物链的每一级都是健康的食物，那么最终由程序员编写出的代码也是健康的。而在受污染的环境中，水蝽在核废料中游泳，青鱼被聚氯联二苯污染，而吃青鱼的鲑鱼又在泄漏的原油中游荡。海鸥，就成为最不幸的了，因此它吃下去的不仅仅是不健康的鲑鱼体内的原油，还有青鱼体内的聚氯联二苯和水蝽体内的核废料。在软件开发中，如果需求污染了，它就会污染架构，而架构就会污染编码。这样会导致程序员脾气暴躁、营养失调；开发出的软件具有放射性污染，而且周身都是缺陷。五、需求面临的困难“石头”问题：说客户常常会交给她一些项目，她称之为“给我一块石头”。可是当你把石头交给客户时，他会看一会“石头”，然后说：“是的，但是，实际上我想要的是一块小一点的蓝色石头。”而当你交出一块小一点的蓝色石头时，又会引发“一块圆的小一点的蓝色石头”的要求。最终的结果可能是，客户一直都在想要一块小一点的蓝色大理石或者他也许根本不能确定他到底要什么，而不是一块小小的蓝色大理石甚至是猫眼大小的蓝色大理石就已经足够了。而他会在你交出第一块（大的）石头和第三块（蓝色的小）石子之间不断改变对需求的想法。开发人员在与客户会谈时总会提这样的问题：“你想要它做什么？”当开发人员按照客户预先的需求经过艰苦努力终于交