第1部分-软件工程基础-新

2014年9月,高级软件工程,主讲：蒋朝iangchaohui,主要内容,第1章软件工程概述,第2章系统策划,第3章需求分析,第4章软件设计,第5章编码,第6章软件测试,第7章软件实施与维护,第8章软件项目管理,第9章软件过程管理,第一章软件工程概述,本章主要内容,1.1软件与软件工程,1.2软件生存周期与开发模型,1.3软件工程过程,1.4软件开发工具简介,1.5学习指南,11软件及软件工程软件,软件的定义,在运行中能提供所希望的功能与性能的程序使程序能够正确运行的数据及其结构描述软件研制过程和方法所用的文档,软件的特点,软件是一种逻辑实体，不是具体的物理实体。软件产品的生产主要是研制。软件具有“复杂性”，其开发和运行常受到计算机系统的限制。软件成本昂贵，其开发方式目前尚未完全摆脱手工生产方式。软件不存在磨损和老化问题，但存在退化问题。,11软件及软件工程软件,磨合调整,磨损用坏,t,失效率,硬、软件产品失效率曲线,50,60,70,80,90,硬件,软件,11软件及软件工程软件,软件的分类,11软件及软件工程软件工程,软件危机,软件开发的生产率远远不能满足客观需要开发的软件产品往往不能满足用户的实际需要软件产品的质量低下且可维护性差很难估计软件开发的进度计划与成本,软件危机的主要特征,软件开发周期大大超过规定日期;软件开发成本严重超标;软件质量难于保证。,例:Windows95有1000万行代码Windows2000有5000万行代码Exchange2000和Windows2000开发人员结构,改正一个问题需付出的代价,需求分析,概要设计,详细设计,编码,集成测试,系统测试,现场,改正一个问题的估计费用,改正一个问题估计的工作量,20,200,2000,1000,5.0,2.5,0.05,0.5,(美元),(人天),11软件及软件工程软件工程,软件神话,有了软件开发书籍，就可以解决软件开发中的一切问题进度滞后了？好，增加程序员只要程序正确，项目就成功，文档可有可无软件质量只能在正式投入运行后才知道,11软件及软件工程软件工程,软件工程的定义,IEEE定义：软件工程是将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件。通俗地说，软件工程是指导软件开发和维护的一门工程学科。它采用工程的概念、原理、技术和方法，把经过时间检验而证明是正确的管理技术和当前能够得到的最好的技术方法结合起来，用于开发和维护软件。,11软件及软件工程软件工程,软件工程层次化技术,软件工程三个要素：方法、工具、过程,11软件及软件工程软件工程,软件工程三要素：方法、工具和过程,软件工程方法：研究软件开发“如何做”的技术。软件工具：研究支撑软件开发方法的工具、软件工具的集成环境计算机辅助软件工程CASE。软件工程过程：将软件工程方法与软件工具相结合实现合理、及时地进行软件开发的目的。,11软件及软件工程软件工程,软件工程的基本原理,用分阶段的生存周期计划严格管理坚持进行阶段评审实行严格的产品控制采用现代程序设计技术结果应能清楚地审查开发小组的人员应该少而精承认不断改进软件工程实践的必要性,12软件生存周期与开发模型生存周期,软件生存周期,人的生存周期,婴儿幼儿儿童少年青年中年老年死亡,软件的生存周期,软件定义,软件开发,软件支持,问题定义,可行性分析,需求分析,概要设计,详细设计,编码,测试,软件发布,软件运行,维护或退役,12软件生存周期与开发模型生存周期,软件定义阶段,问题定义可行性分析立项或签订合同,软件开发阶段,需求分析软件设计编码与测试发布或安装验收,软件维护阶段,软件的使用、运行软件维护,12软件生存周期与开发模型开发模型,问题的提出软件工程需要解决什么问题？,软件开发模型,做什么软件？怎么做软件？软件如何适应变化？,软件开发过程概括，是软件工程思想的具体化它是跨越整个软件生存周期的各个阶段所需要的全部工作与任务的结构框架,软件过程模型,典型的软件过程模型有：瀑布模型（waterfallmodel）演化模型（evolutionarymodel）增量模型（incrementalmodel）原型模型（prototypingmodel)螺旋模型（spiralmodel）喷泉模型（waterfountainmodel）基于构件的开发模型（component-baseddevelopmentmodel）敏捷开发模型,瀑布模型,问题定义,可行性研究,需求分析,总体设计,详细设计,编码与单元测试,综合测试,软件维护,软件定义时期,软件开发时期,软件维护时期,问题定义,可行性研究,需求分析,总体设计,详细设计,编码与单元测试,综合测试,软件维护,要解决的问题是什么？,问题性质、工程目标和规模的报告,分析员：实际用户+负责人,是否有解决办法？,分析员,高层逻辑模型，准确和具体的工程规模和目标，成本/效益分析等可行性报告,为了解决的问题，目标系统必须做什么？准确确定系统的功能,系统的逻辑模型（数据流图+数据字典+简要算法）,如何解决这些问题,模块划分软件结构,如何具体地实现系统：每个模块的流程图（程序的详细规格说明）,通过各种类型的测试，使软件达到预定的要求,写出正确的容易理解和容易维护的程序模块,通过各种必要的维护活动使系统持久地满足用户的需要,特征接受上一阶段的结果作为本阶段的输入开发阶段严格按线性方式进行对本阶段的工作进行评审每一阶段具有相关的里程碑和交付产品缺点缺乏灵活性，难以适应需求不明确或需求经常变化的软件开发开发早期存在的问题往往要到交付使用时才发现，维护代价大适用在开发的早期阶段软件需求被完整确定,许多软件项目在开发早期对软件需求的认识是模糊的、不确定的，因此软件很难一次开发成功。可以在获取了一组基本的需求后，通过快速分析构造出该软件的一个初始可运行版本(原型)，然后根据用户在试用原型的过程中提出的意见和建议、或者增加新的需求，对原型进行改造，获得原型的新版本，重复这一过程，最终得到令客户满意的软件产品。演化模型的开发过程就是从构造初始的原型出发，逐步将其演化成最终软件产品的过程。演化模型适用于对软件需求缺乏准确认识的情况。典型的演化模型有：增量模型、原型模型、螺旋模型。,演化模型,增量模型,增量模型将软件的开发过程分成若干个日程时间交错的线性序列，每个线性序列产生软件的一个可发布的“增量”版本，后一个版本是对前一版本的修改和补充，重复增量发布的过程，直至产生最终的完善产品。增量模型融合了瀑布模型的基本成分(重复地应用)和演化模型的迭代特征增量模型特别适用于：需求经常变化的软件开发市场急需而开发人员和资金不能在设定的市场期限之前实现一个完善的产品的软件开发,原型是预期系统的一个可执行版本，它反映了系统性质的一个选定的子集。一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型。原型方法从软件工程师与客户的交流开始，其目的是定义软件的总体目标，标识需求。然后快速制订原型开发的计划，确定原型的目标和范围，采用快速设计的方式对其建模，并构建原型。被开发的原型应交付给客户试用，并收集客户的反馈意见，这些反馈意见可在下一轮迭代中对原型进行改进。在前一个原型需要改进，或者需要扩展其范围的时候，进入下一轮原型的迭代开发。,原型模型,原型的类型：探索型（exploratoryprototyping）其目的是要弄清目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。实验型（experimentalprototyping）其目的是验证方案或算法的合理性，它是在大规模开发和实现前，用于考核方案是否合适，规格说明是否可靠。演化型（evolutionaryprototyping）其目的是将原型作为目标系统的一部分，通过对原型的多次改进，逐步将原型演化成最终的目标系统。,原型的使用策略：废弃（throwaway）策略主要用于探索型和实验型原型的开发。这些原型关注于目标系统的某些特性，而不是全部特性，这种原型通常被废丢，然后根据探索或实验的结果用良好的结构和设计思想重新设计目标系统。追加（addon）策略主要用于演化型原型的开发。这种原型通常是实现了目标系统中已明确定义的特性的一个子集，通过对它的不断修改和扩充，逐步追加新的要求，最后使其演化成最终的目标系统。原型可作为单独的过程模型使用，它也常被作为一种方法或实现技术应用于其它的过程模型中。,是瀑布模型和演化模型的结合，并增加了风险分析螺旋模型沿着螺线旋转，在四个象限上分别表达四个方面的活动，即：制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件风险分析：评价所选的方案，识别风险，消除风险工程实施：实施软件开发，验证工作产品客户评估：评价开发工作，提出修正建议,螺旋模型,螺旋模型应用场所：开发风险较大的软件项目螺旋模型指引的软件项目开发沿着螺线自内向外旋转，每旋转一圈，表示开发出一个更为完善的新软件版本。如果发现风险太大，开发者和客户无法承受，则项目就可能因此而终止。多数情况下沿着螺线的活动会继续下去，自内向外，逐步延伸，最终得到所期望的系统。,喷泉模型,喷泉模型是一种支持面向对象开发的模型，体现迭代和无间隙特征。迭代：各开发活动常常重复工作多次，相关的功能在每次迭代中随之加入演进的系统。无间隙：开发活动之间不存在明显的边界。,支持软件复用（reuse）。利用预先包装好的软件构件（包括组织内部开发的构件和现存商品化构件COTS）来构造应用系统。基于构件的开发模型对提高软件生产率、提高软件质量、降低成本、提早上市时间起到很大的作用。根据AT其中，MyCircle是接受消息的对象名，Show是消息选择符(即消息名)，圆括号内的GREEN是消息的变元。当Mycircle接收到这个消息后，将执行在Circle类中所定义的Show操作。,33面向对象的需求分析-面向对象的概念,33面向对象的需求分析-面向对象的概念,消息面向对象技术的封装机制使对象是相互独立的，并且彼此之间信息是隐藏的在面向对象的技术中，消息是对象之间相互请求或相互协作的惟一途径对象间的联系只能通过传递消息来进行对象也只能在收到消息时才被激活消息通信机制是对象之间联系的唯一合法途径，使对象间的行为能够相互配合，从而共同完成一定的功能，形成一个统一的系统,服务,为了完成某一任务，一个对象所提供的并体现其责任的操作称为服务属于同一类的所有对象共享相同的服务,33面向对象的需求分析-面向对象的概念,33面向对象的需求分析-面向对象的概念,服务和消息,通常，一个对象会向另一个对象发出消息请求某项服务，接收消息的对象响应该消息，激发所要求的服务操作，并将操作结果返回给请求服务的对象,33面向对象的需求分析-面向对象的概念,服务和消息(续)消息的性质同一对象可接收不同形式的多个消息产生不同的响应，达到提供不同服务的目的相同形式的消息可以送给不同的对象所做出的响应可以是截然不同的，即不同的对象可针对同一消息提供不同的服务消息的发送可以不考虑具体的接收者对象可以响应消息，也可以对消息不予理会对消息的响应并不是必须的消息的类别公有消息对象所接收的消息是由外部对象直接发送给它的消息私有消息对象所接收的消息是由对象发送给自身的消息,33面向对象的需求分析-面向对象的概念,服务和消息(续)在面向对象编程中，服务的启动是通过将“消息”传递给对此操作负责的对象来完成的。消息对服务的要求进行编码，并且伴随着执行要求所需的附加信息（参数）一起传递。“接受者”就是消息发送的对象如果接受者接受了消息，那么他同时也接受了消息所包含的服务责任接受者响应消息，执行相应的方法已实现要求消息传递与过程调用“接受者”就是消息发送的对象，过程调用没有指定的接受者消息的解释由接受者决定解释选择响应消息的方法虽接受者的不同而不同,封装,所谓封装就是把某个事物包起来，使外界不知道该事物的具体内容。在面向对象的程序中，把数据和实现操作的代码集中起来放在对象内部。,*数据与方法代码的内部细节对外界隐藏，这样对其的任何改变可能引起的副作用只能作用在内部，不会传播。*封装是软件复用的基础。*被封装对象间的接口大大地简化了，对象之间通过消息联系它时不再关心对象内部的数据结构，系统的耦合度降低了。,含义,优点,33面向对象的需求分析-面向对象的概念,继承,含义,分类,类之间的继承关系是现实世界中遗传关系的直接模拟，它表示类之间的内在联系以及对属性和操作的共享，即子类可沿用父类(被继承)的某些特征。当然也可以具有自己独有的属性和操作。,单重继承,多重继承,子类仅从一个父类继承属性和行为，而且子类可以覆盖父类的部分属性和方法,子类可从多个父类继承属性和方法,33面向对象的需求分析-面向对象的概念,类继承实例,汽车是抽象层次较高的概念，在汽车类的基础上可以分出轿车类与货车类等，如果再细分，还可在轿车类的基础上分出商用轿车与家用轿车等。由于商用轿车与家用轿车作为轿车在绝大多数的属性和行为上是一致的，可以把轿车类看成是家用轿车的父类，而家用轿车这个子类继承了父类所拥有的属性与行为，并在父类的基础上加入了特殊化的属性与行为而形成了新的类。,在类的层次结构中，相对上层的是超类(superclass)，相对下层的是子类(subclass),33面向对象的需求分析-面向对象的概念,33面向对象的需求分析-面向对象的概念,类和类层次类类是OO技术中最重要的概念OOP中所有的操作都可归结为对类的操作类的概念符合人类对事物按照一定特点进行分类的思想例如：,33面向对象的需求分析-面向对象的概念,类和类层次类(续)类是一组具有相同数据结构和相同操作的对象的集合类的一个实例就是对象所有对象都是类的实例在响应消息时调用何种方法由类的接收者来决定一个特定类的所有对象使用相同的方法来响应相似的消息类与实例之间的关系，可以看成是抽象与具体的关系例如：书是一个对象类。UML和模式应用是“书”对象类的一个实例,33面向对象的需求分析-面向对象的概念,类和类层次类(续)类的定义公式表示具有相同属性和服务的一组对象的集合它为属于该类的全部对象提供了统一的抽象描述，其内部包括属性和服务两个主要部分例如：C+中对象类的定义,类=(组)数据属性+(组)数据操作,33面向对象的需求分析-面向对象的概念,CLASSpersonPrivate:,33面向对象的需求分析-面向对象的概念,类和类层次类的表示类名类的名称类名一般为名词，由一个单词组成，英文首字母大写属性类的一个特性，描述了类的对象所具有的一系列特征值每一对象的属性是一些有着确定值的，用于描述对象状态信息的数据属性一般只能通过执行对象的操作来改变属性名一般小写操作类能够提供的服务操作名一般小写,33面向对象的需求分析-面向对象的概念,类和类层次类的表示(续),33面向对象的需求分析-面向对象的概念,类和类层次类层次类可以组织成一个有层次的继承结构由很多类构成一个层次化的结构处于上层的类称为父类或基类，下层类是上层类的子类一个子类继承层次树中更高一层的父类的属性抽象父类是指没有具体实例的类（如哺乳动物），它只是用来生产子类的,33面向对象的需求分析-面向对象的概念,类和类层次(续)类层次示例,33面向对象的需求分析-面向对象的概念,多态是指在父类中定义的属性或服务被子类继承后，可以具有不同的数据类型或表现出不同的行为多态的本质是一个消息可以与不同的实例结合，而且这些实例属于不同类不同层次的类可以共享一个操作，但却有各自不同的实现当一个对象接收到一个请求时，它根据其所属的类，动态地选用在该类中定义的操作多态是可以大大减少需要用于扩展现存OO系统工作量的特性，是OO的基本特征之一,33面向对象的需求分析-面向对象的概念,多态主要表现运算符重载同一个运算符可作用于多种数据类型上虚函数与动态联接这是OO方法特有的动态性质当将重载的函数名标识为虚函数时，该函数就有较大的灵活性。它既可以表示子类中的同名函数，也可表示父类中的同名函数。动态联接方式是灵活性的关键。,动态联接方式允许在运行中才按照具体的数据类型、参量和确定选用哪一个函数。,33面向对象的需求分析-面向对象的概念,多态主要表现（续）函数名重载相同的函数名可作用于不同的对象类上，并产生不同的行为效果有时不同的类中具有相同名称的操作，多态的特性使每次调用操作时都要确定究竟调用哪个同名操作例如门、窗、盒等类都有名为“打开”的操作，每个类的对象都自己知道如何执行自己的“打开”操作,33面向对象的需求分析-面向对象的概念,多态示例说明例如在一个应用中需要画图，现实现了圆、矩形、三角形、平行四边形。在传统方法中一般使用下面的控制逻辑,caseofgraphtype:circle:DrawCircle();rectangle:DrawRectangle();triangle:DarwTriangle();parallelogram:DrawParallelogram();endcase;,33面向对象的需求分析-面向对象的概念,多态示例说明（续）这样的设计很直接，但当加入新的图形类型时可能非常麻烦，需要对每种新图形都创建一个新的画图程序，然后每种控制画图类型的控制逻辑都需要被更新使用OO方法，将图形抽象为一个基类graph，每种图形都是该基类的子类，每个子类中定义操作draw，完成该子类的画图操作，一个对象可以传递draw消息给任意子类的任意实例对象，画出相应的图形，由此前面的程序段将简化为,graphtypedraw();,33面向对象的需求分析-面向对象的概念,多态示例说明（续）当新的图形类型加入到系统中时，将创建一个具有自己的操作draw的子类，但是在任何希望画图的对象中不需要进行任何的改变，因为消息draw是不变的当系统的其他部分请求绘制一个几何图形时，消息中的服务都是“draw”，但每个子类接收到该消息时却各自执行不同的绘图算法,33面向对象的需求分析-面向对象方法简介,识别对象和类描述对象和类之间的关系通过描述每个类的功能定义对象的行为。,向对象方法,Booch方法：提出面象对象的软件工程的概念OMT方法：提出面象对象的建模技术方法OOSE方法：用例贯穿于软件整个开发过程,在Booch方法、OMT方法和OOSE方法的基础上推出了统一的建模语言(UML)，1997年被国际对象管理组织(OMG)确定为标准的建模语言,UML,面向对象方法支持三种基本的活动,33面向对象的需求分析-面向对象分析过程,面向对象方法实际上是一整套的软件开发方法，它包括面向对象的分析OOA、面向对象的设计OOD、面向对象的编程OOP、面向对象的测试OOT等，可以看出面向对象方法可以贯穿软件开发的整个过程。OOA方法的关键，是识别问题域内的对象，并分析它们相互间的关系，最终建立起问题域的简洁、精确、可理解的正确模型。这是面向对象分析的首要任务在实际工作中，建模的步骤并不一定严格按照前面讲述的次序进行,OOA分析过程,分析用户需求,识别类与对象,确定对象的内部特征,识别对象之间的关系,定义主题词,系统分析员应该深入地理解用户需求，抽象出目标系统的本质属性，并用模型准确来表示；另外要向领域专家学习。,确定问题域中的类和对象,确定对象的属性的操作,分类关系(一般/特殊)、组成关系(整体/部分)，还有反映对象属性之间联系的实例连接、反映对象行为之间依赖关系的消息等,概念上把大型的、复杂的系统包含的内容分解成若干个范畴,33面向对象的需求分析-面向对象分析过程,34UML概述,1997年UML1.1被对象管理组织OMG确定为标准建模语言是软件工程领域最重要的、具有划时代重大意义的事件。UML是一种定义良好、易于表达、功能强大且普遍适用的标准的图形化建模语言,用它可以简明、准确地为目标系统建立模型。它融入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。,34UML概述-UML的结构,一、UML中的基本构造块UML建模的积木块,构成UML模型的基本构造块有三种积木元素或积木组合体,即：,反应的是类与类之间联系的方法与性质，关系有依赖、关联、继承、实现和聚合5种,图是软件系统在不同角度上的投影，它是一组元素的表示，包含了事物及其关系的组合。UML有九种图,事物是UML模型中的静态元素，UML中共有11种不同的事物,事物,关系,图,UML中的“事物”,34UML概述-UML的结构,二、UML中的规则UML建模的“粘合剂”,UML中的规则是为了将UML中的构造块有机地组装在一起形成一个结构良好的模型而对事物进行描述的语义规则。,5种规则,1、为事物、关系命名的命名规则2、给一个名字以特定含义的范围规则3、使名字可见或如何使用的可见性规则4、描述事件正确、一致地相互联系的完整性规则5、描述运行或模拟动态模型含义的执行规则,34UML概述-UML的结构,三、应用于UML的通用机制UML模型的图纸说明,为了对UML模型进行进一步的说明，同时增强其表达能力，UML提供了4种在整个语言中可以一致应用的“通用机制”，可以认为是对UML模型的图纸说明,四种机制,规格说明,修饰,通用划分,扩展机制,UML图形每个部分后面的语法语义描述,UML表示法中每个元素都有一个基本符号,UML构造块有两种划分，即类与对象、接口与实现,提高UML语言表达能力，它包含构造型、标记值和约束等3种类型,34UML概述-UML的结构,34UML概述-UML的图,UML主要用图来表达模型的内容，而图又由代表模型元素的图形符号组成。学会使用UML的图，是学习、使用统一建模语言UML的关键。UML的重要内容可以由下列五类图(共9种图形),UML图,用例图(Use-casediagram),静态图(Staticdiagram),行为图(Behaviordiagram),交互图(Interactivediagram),实现图(Implementationdiagram),34UML概述-UML的应用,UML的目标是用面向对象的图形方式来描述任何类型的系统，因此，具有很宽的应用领域。其中最常用的是建立软件系统模型，但是它同样也可以用于描述非计算机软件的其他系统，如机械系统、商业系统、企业机构或业务过程、处理复杂数据的信息系统、具有实时要求的工业系统或工业过程等。总之，UML是一个通用的标准建模语言，可以为任何具有静态结构和动态行为的系统建立模型。,UML适用于系统开发全过程,需求分析,分析,设计,编码,测试,捕获用户的需求、用例建模,用UML的逻辑视图和动态视图来描述问题域中的基本概念(例如抽象、类和对象等)和机制。类图描述系统的静态结构，协作图、顺序图、活动图和状态图描述系统的动态行为。,把分析阶段的结果扩展成技术解决方案，加入新的类来定义软件系统的技术方案细节。设计阶段用和分析阶段类似的方式使用UML。,这个阶段的任务是把来自设计阶段的类转换成某种面对象程序语言的代码(如VB、C+、Java等),UML模型可作为测试阶段的依据。单元测试使用类图和类规格说明；集成测试使用构件图和协作图；系统测试使用用例图来验证系统的行为,34UML概述-UML的应用,一、UML的应用领域,二、UML的建模机制,UML9个模型,UML9种图,UML5个视图,业务模型、领域模型、用例模型、分析模型、设计模型、过程模型、部署模型、实现模型、测试模型,用例视图、设计视图、进程视图、实现视图、实施视图,用例图、静态图（包括类图、对象图和包图）、行为图（包括状态图和活动图）、交互图（包括顺序图和协作图）、实现图（构件图和配置图）,34UML概述-UML的应用,静态建模,动态建模,反映的是目标系统的静态数据，用例图、类图、对象图、包、构件图、配置图等是静态建模机制，其中尤以用例图和类图最为重要。,强调的是系统的行为，动态建模所建立的模型或者可以执行，或者表示执行时的时序状态或交互关系。它包括状态图、活动图、顺序图和协作图等四个图形,是标准建模语言UML的动态建模机制。,UML建模,34UML概述-UML的应用,在UML中可以通过用例图来构造目标系统的用例模型，它通过用例来捕获用户需求，通过用例建模,描述对系统感兴趣的外部角色及其对系统(用例)的功能要求。它从系统外部观察系统，而不涉及到技术上如何做这些事。,34UML概述-UML中的需求分析（用例图的创建）,一、用例模型(Usecasemodel),描述的是外部执行者(Actor)所理解的系统功能。用例模型用于需求分析阶段。,在UML中，一个用例模型由若干个用例图描述，用例图的主要元素是用例和执行者。,用例模型是开发者和用户对需求规格达成的共识,用例模型,描述了待开发系统的功能需求；它将系统看作黑盒，从外部执行者的角度来理解系统；它驱动了需求分析之后各阶段的开发工作，影响开发工作的各个阶段和UML的各个模型。,用例模型功能,34UML概述-UML中的需求分析（用例图的创建）,二、用例(usecase),一个用例是用户与计算机之间的一次典型交互过程。在UML中，用例表示为一个椭圆,含义,1、用例捕获某些用户可见的需求，实现一个具体的用户目标。2、用例由执行者激活，并提供确切的值给执行者。3、用例可大可小，但它必须是对一个具体的用户目标实现的完整描述。,特点,34UML概述-UML中的需求分析（用例图的创建）,举例,以测评系统为例，“一个学生测评某位老师”和“管理员进行测评数据处理”便是两个典型的用例,34UML概述-UML中的需求分析（用例图的创建）,三、执行者(Actor),含义,执行者是指用户在系统中所扮演的角色。其图形化的表示是一个小人。,通信联系,不带箭头的线段将执行者与用例连接到一起，表示两者之间交换信息,注意,尽管执行者在用例图中是用类似人的图形来表示的，但执行者未必是人。,意义,面对一个大系统，要列出用例清单常常是十分困难。这时可先列出执行者清单，再对每个执行者列出它的用例，问题就会变得容易很多,34UML概述-UML中的需求分析（用例图的创建）,四、使用和扩展(UseandExtend),扩展关系,当一个用例使用另一个用例时，这两个用例之间就构成了使用关系,当一个用例与另一个用例相似，但所做的动作多一些，就可以用到扩展关系,使用关系,说明,使用和扩展是两种不同形式的继承关系,34UML概述-UML中的需求分析（用例图的创建）,34UML概述-UML中的需求分析（用例图的创建）,用例图的元素(a)用例、执行者、通信联系；(b)使用；(c)扩展,34UML概述-UML中的需求分析（用例图的创建）,使用当几个用例存在相同的动作时，为避免重复，把相同的动作构造成另一个用例，则该用例与这几个用例之间的关系就是使用关系。使用关系是UML预定义的构造型模型元素，它是泛化关系的构造型模型元素。使用关系的图符表示与泛化关系的图符表示一样，用带空心三角形的连线表示，在连线上标注使用。使用关系的表示如上图(b)所示。,34UML概述-UML中的需求分析（用例图的创建）,扩展扩展是指用例之间的一种关系。有两个用例和，与功能相似，但是的动作比的动作多一点，则与之间的关系是扩展关系，扩展。扩展关系也是泛化关系的构造型模型元素，也是预定义构造型模型元素。扩展关系的图符表示与使用关系的图符表示相同，只是在扩展关系的连线上标注扩展。扩展关系的表示如上图(c)所示。扩展与使用之间有相似之处和不同之处。这两者都从几个用例中抽取公共的行为放入一个单独的用例中，以便其他几个用例使用或扩展。但是这两个关系的目的是不同的。可采用下列方法来区别应使用哪种关系。当描述一般行为的变化时，采用扩展；当在两个或多个用例中出现重复描述而又想避免重复时，采用使用。,34UML概述-UML中的需求分析（用例图的创建）,扩展扩展是指用例之间的一种关系。有两个用例和，与功能相似，但是的动作比的动作多一点，则与之间的关系是扩展关系，扩展。扩展关系也是泛化关系的构造型模型元素，也是预定义构造型模型元素。扩展关系的图符表示与使用关系的图符表示相同，只是在扩展关系的连线上标注扩展。扩展关系的表示如上图(c)所示。扩展与使用之间有相似之处和不同之处。这两者都从几个用例中抽取公共的行为放入一个单独的用例中，以便其他几个用例使用或扩展。但是这两个关系的目的是不同的。可采用下列方法来区别应使用哪种关系。当描述一般行为的变化时，采用扩展；当在两个或多个用例中出现重复描述而又想避免重复时，采用使用。,五、用例模型的获取,步骤,获取执行者,使用系统的主要功能(主要使用者)。谁需要系统支持他们的日常工作。谁来维护、管理使系统正常工作(辅助使用者)。系统需要操纵哪些硬件。系统需要与哪些其它系统交互，包含其它计算机系统和其它应用程序。,获取用例,执行者要求系统提供哪些功能(执行者需要做什么)？执行者需要读、产生、删除、修改或存储的信息有哪些类型。必须提醒执行者的系统事件有哪些？或者执行者必须提醒系统的事件有哪些？怎样把这些事件表示成用例中的功能？为了完整地描述用例，还需要知道执行者的某些典型功能能否被系统自动实现？系统需要何种输入输出？输入从何处来？输出到何处？当前运行系统(也许是一些手工操作而不是计算机系统)的主要问题？,34UML概述-UML中的需求分析（用例图的创建）,举例,教师测评系统用例模型,34UML概述-UML中的需求分析（用例图的创建）,34UML概述-UML中的需求分析（用例图的创建）,金融贸易系统的用例图,第四章软件设计,本章内容,软件设计基本概念概要设计详细设计面向对象的分析与设计,41软件设计基本概念,软件设计,软件设计是一个把需求转换为某种软件表达方式的过程。基本目标是用比较抽象概括的方式确定目标系统如何完成预定的任务。,软件表达方式,详细设计表达,概要设计表达,软件结构图,数据流图,流程图,N-S图,PAD图,PDL语言,41软件设计基本概念,软件设计工作内容,将软件需求转化为软件体系结构，确定系统级接口、全局数据结构或数据库模式。,确立每个模块的实现算法、局部数据结构，用适当方法表示算法和数据结构的细节。,41软件设计基本概念,软件模块定义,所谓模块，是指具有相对独立性的，由数据说明、执行语句等程序对象构成的集合。程序中的每个模块都需要单独命名，通过名字可实现对指定模块的访问。在高级语言中，模块具体表现为函数、子程序、过程等。一个模块具有输入/输出(接口)、功能、内部数据和程序代码四个特征。输入/输出用于实现模块与其他模块间的数据传送，即向模块传入所需的原始数据及从模块传出得到的结果数据。功能指模块所完成的工作。模块的输入/输出和功能构成了模块的外部特征。内部数据是指仅能在模块内部使用的局部量。程序代码用于描述实现模块功能的具体方法和步骤。模块的内部数据和程序代码反映的是模块的内部特征。,模块的基本属性,模块实现什么功能,模块的内部实现逻辑,该模块使用时的环境和条件,41软件设计基本概念,软件模块定义,模块化是指将整个程序划分为若干个模块，每个模块用于实现一个特定的功能。划分模块对于解决大型复杂的问题是非常必要的，可以大大降低解决问题的难度。为了说明这一点，我们可对问题复杂性、开发工作量和模块数之间的关系进行以下推理。首先，我们设C(x)为问题x所对应的复杂度函数，E(x)为解决问题x所需要的工作量函数。对于两个问题P1和P2，如果：C(P1)C(P2)即问题P1的复杂度比P2高，则显然有：E(P1)E(P2)即解决问题P1比P2所需的工作量大。,41软件设计基本概念,软件模块定义,在人们解决问题的过程中，发现存在有另一个有趣的规律：C(P1+P2)C(P1)+C(P2)即解决由多个问题复合而成的大问题的复杂度大于单独解决各个问题的复杂度之和。也就是说，对于一个复杂问题，将其分解成多个小问题分别解决比较容易。由此我们可以推出：E(P1+P2)E(P1)+E(P2)即将复杂问题分解成若干个小问题，各个击破，所需要的工作量小于直接解决复杂问题所需的工作量。,41软件设计基本概念,软件模块定义,根据上面的推理，我们可以得到这样一个结论，模块化可以降低解决问题的复杂度，从而降低软件开发的工作量。但是不是模块划分得越多越好呢？虽然增加程序中的模块数可以降低开发每个模块的工作量，但同时却增加了设计模块接口的工作量。通过图4.1所示的模块数与软件开发成本的关系图中可以看出，当划分的模块数处于最小成本区时，开发软件的总成本最低。虽然目前还不能得到模块数M的精确取值，但总成本曲线对我们进行模块划分具有重要的指导意义。模块化不但可以降低软件开发的难度，而且可以使程序结构清晰，增加易读性和易修改性。此外，模块化还有利于提高代码的可重用性及团队合作开发大型软件的可行性。,41软件设计基本概念,图4.1模块数与软件开发成本,41软件设计基本概念,软件体系结构设计概述,体系结构设计的任务在体系结构设计过程中，首先要根据需求分析阶段产生的成果寻求实现目标系统的各种可能的方案，然后由系统分析员对所有可能的方案进行综合分析比较，从中选择出一个最佳方案向用户推荐。在与用户达成共识之后，系统分析员就可以着手对选择出的最佳方案进行体系结构的设计，并为软件确定数据结构及设计数据库。体系结构设计阶段结束时，系统分析员需要提交软件的体系结构说明书并参加该阶段的评审。体系结构设计的主要任务：软件体系结构设计（功能性）数据结构和数据库设计系统可靠性、安全性设计（非功能性）,41软件设计基本概念,软件体系结构设计概述,1、软件体系结构设计设计软件的体系结构需要在对需求分析阶段生成的数据流图进一步分析和精化的基础上，首先将系统按照功能划分为模块，接着需要确定模块之间的调用关系及其接口，最后还应该对划分的结果进行优化和调整。良好的软件结构设计对详细设计及编码阶段的工作都是至关重要的。,2、数据结构和数据库设计体系结构设计中应对需求分析阶段所生成的数据字典加以细化，从计算机技术实现的角度出发，确定软件涉及的文件系统及各种数据的结构。主要包括确定输入、输出文件的数据结构及确定算法所需的逻辑数据结构等。在需求分析阶段仅为系统所需的数据库建立了概念数据模型(最常采用的是E-R模型)。体系结构设计阶段需要将原本独立于数据库实现的概念模型与具体的数据库管理系统的特征结合起来，建立数据库的逻辑结构，主要包括确定数据库的模式、子模式及对数据库进行规范和优化等。,41软件设计基本概念,软件体系结构设计概述,3、系统可靠性、安全性设计可靠性设计也称为质量设计，目的是为了保证程序及其文档具有较高的正确性和容错性，并对可能出现的错误易于修改和维护。安全性设计的主要目的是为了增强系统的自我防护能力和运行的稳定性，防止系统遭受到有意或无意地入侵和破坏，保证系统在安全的环境下正常地工作。,41软件设计基本概念,体系结构设计中可采用的工具,HIPO图HIPO(HierarchyPlusInput/Processing/Output)图是IBM公司在20世纪70年代发展起来的用于描述软件结构的图形工具。它实质上是在描述软件总体模块结构的层次图(H图)的基础上，加入了用于描述每个模块输入/输出数据和处理功能的IPO图，因此它的中文全名为层次图加输入/处理/输出图。,41软件设计基本概念,图4.2工资计算系统的H图,41软件设计基本概念,图4.3计算工资模块的IPO图,41软件设计基本概念,体系结构设计中可采用的工具,结构图在软件工程中，软件结构经常采用20世纪70年代中期由Yourdon等人提出的结构图(SC，StructureChart)这种图形工具来表示。结构图能够描述出软件系统的模块层次结构，清楚地反映出程序中各模块之间的调用关系和联系。结构图中的基本符号及其含义见表4.1。,41软件设计基本概念,表4.1结构图中的基本符号,41软件设计基本概念,体系结构设计的原则,体系结构设计的原则有如下6点：(1)降低模块的耦合性，提高模块的内聚性。为了提高软件中各个模块的独立性，提高程序的可读性、可测试性和可维护性，在软件体系结构设计时应尽可能采用内聚性高的模块，如最好实现功能内聚；尽量只使用数据耦合，限制公共耦合的使用，避免控制耦合的使用，杜绝内容耦合的出现。（2）保持适中的模块规模。程序中模块的规模过大，会降低程序的可读性；而模块规模过小，势必会导致程序中的模块数目过多，增加接口的复杂性。对于模块的适当规模并没有严格的规定，但普遍的观点是模块中的语句数最好保持在10100之间。为了使模块的规模适中，在保证模块独立性的前提下，可对程序中规模过小的模块进行合并或对规模过大的模块进行分解。,41软件设计基本概念,体系结构设计的原则,体系结构设计的原则有如下6点：(3)模块应具有高扇入和适当的扇出。在模块调用中，某个模块的上级模块数被称为该模块的扇入(如图4.5(a)所示，模块M的扇入数为n)；而某个模块可以调用的下级模块数被称为该模块的扇出(如图4.5(b)所示，模块M的扇出数为k)。显然，一个模块的扇入表明了共有多少个模块需要调用该模块，而其扇出表明了该模块可以控制的下级模块的数目。,41软件设计基本概念,体系结构设计的原则,图4.5模块的扇入和扇出(a)扇入；(b)扇出,41软件设计基本概念,体系结构设计的原则,模块应具有高扇入和适当的扇出模块的扇入越大，则说明共享该模块的上级模块数越多，或者说该模块在程序中的重用性越高，这正是程序设计所追求的目标之一。当多个模块具有一部分相同功能时，应将这部分相同的功能分离出来，编写成独立的模块供需要的模块调用。通过消除不同模块中的重复内容，提高代码的可重用性，可以减少程序的总代码量，便于程序的测试和维护。模块的扇出若过大，如在一个模块中要调用八个下级模块，则会使该模块的调用控制过于复杂。这种现象发生的原因通常都是由于设计阶段，模块细化的过程中，分解速度过快造成的。最常见的解决办法是通过在此模块和下级模块间增加一个中间层来控制模块分解的速度。模块的扇出过小，如扇出为1(下级模块层中只有一个模块)，在系统设计中通常是不可取的。常见的解决方法是考虑将其合并到上级模块中。但若合并会影响模块的独立性，则将其保留下来也未尝不可。根据实践经验，设计良好的典型系统中，模块的平均扇出通常为3或4。,41软件设计基本概念,体系结构设计的原则,模块应具有高扇入和适当的扇出可以看出：在一个好的软件结构中，模块应具有较高的扇入和适当的扇出。但绝不能为了单纯追求高扇入或合适的扇出而破坏了模块的独立性。此外，经过对大量软件系统的研究后发现，在设计良好的软件结构中，通常顶层的扇出数较大，中间层的扇出数较小，底层的扇入数较大，如图4.6所示。,图4.6软件结构图示例,41软件设计基本概念,体系结构设计的原则,体系结构设计的原则有如下6点：(4)软件结构中的深度和宽度不宜过大。所谓深度，是指软件体系结构中控制的层数，它能够粗略地反映出软件系统的规模和复杂程度；所谓宽度，是指软件体系结构内同一层次上模块个数的最大值，通常宽度越大的系统越复杂。如图4.6所示的软件结构图中，深度为5，宽度为8。深度在程序中表现为模块的嵌套调用，嵌套的层数越多，程序就越复杂，程序的可理解性也就随之下降。对宽度影响最大的因素是模块的扇出，即模块可以调用的下级模块数越多，软件结构的宽度就越大。深度过大可通过将结构中过于简单的模块分层与上一级模块合并来解决；而宽度过大则可通过增加中间层来解决。显然，软件结构中的深度和宽度是相互对立的两个方面，降低深度会引起宽度的增加，而降低宽度又会带来深度的增加。,41软件设计基本概念,体系结构设计的原则,体系结构设计的原则有如下6点：(5)模块的作用域应处于其控制域范围之内。模块的作用域是指受该模块内一个判定条件影响的所有模块范围。模块的控制域是指该模块本身以及所有该模块的下属模块(包括该模块可以直接调用的下级模块和可以间接调用的更下层的模块)。例如，在图4.7中，模块C的控制域为模块C、E和F；若在模块C中存在一个对模块D、E和F均有影响的判定条件，即。由于模块D在模块C的作用域中，因此模块C对模块模块C的作用域为模块C、D、E和F(图中带阴影的模块)，则显然模块C的作用域超出了其作用域D的控制信息必然要通过上级模块B进行传递，这样不但会增加模块间的耦合性，而且会给模块的维护和修改带来麻烦(若要修改模块C，可能会对不在它控制域中的模块D造成影响)。因此，软件设计时应使各个模块的作用域处于其控制域范围之内。若发现不符合此设计原则的模块，可通过下面的方法进行改进：将判定位置上移。如将图4.7中的模块C中的判定条件上移到上级模块B中或将模块C整个合并到模块B中。将超出作用域的模块下移。如将图4.7中的模块D移至模块C的下一层上，使模块D处于模块C的控制域中。,41软件设计基本概念,体系结构设计的原则,图4.7模块的作用域和控制域,41软件设计基本概念,体系结构设计的原则,体系结构设计的原则有如下6点：(6)尽量降低模块的接口复杂度。由于复杂的模块接口是导致软件出现错误的主要原因之一，因此在软件设计中应尽量使模块接口简单清晰，如减少接口传送的信息个数以及确保实参和形参的一致性和对应性等。降低模块的接口复杂度，可以提高软件的可读性，减少出现错误的可能性，并有利于软件的测试和维护。,41软件设计基本概念,模块划分的原则,划分模块的重要目标是提高模块的独立性。度量模块独立性的两个准则是模块间的内聚性和耦合性。好的软件结构应该具有高内聚、低耦合的模块化结构。,内聚性,耦合性,内聚性是一个模块内部各个元素彼此结合的紧密程度的度量。,耦合性是模块间互相连接的紧密程度的度量。它取决于各个模块之间接口的复杂度、调用方式以及哪些信息通过接口。,41软件设计基本概念,内聚性,模块内聚按照模块独立性由高到低的顺序叙述如下：,(1)功能内聚(2)逻辑内聚(3)时间内聚(4)过程内聚(5)通信内聚(6)顺序内聚(7)偶然内聚,41软件设计基本概念,功能内聚：这是最强的内聚，指模块内所有元素共同完成一个功能，缺一不可。逻辑内聚：这种模块把几种相关的功能组合在一起，每次被调用时，由传送给模块参数来确定该模块应完成哪一种功能。时间内聚：把需要同时执行的动作组合在一起形成的模块为时间内聚模块。过程内聚：构件或者操作的组合方式是，允许在调用前面的构件或操作之后，马上调用后面的构件或操作，即使两者之间没有数据进行传递。通信内聚：指模块内所有处理元素都在同一个数据结构上操作（有时称之为信息内聚），或者指各处理使用相同的输入数据或者产生相同的输出数据。顺序内聚：指一个模块中各个处理元素都密切相关于同一功能且必须顺序执行，前