（建筑工程管理）软件工程(B)教案

(建筑工程管理)软件工程(B)教案软件工程(B)教案课程说明1壹软件工程概述(理论3学时)1附录(壹)常用CASE工具介绍4附录(二)CASE工具的种类及应用特点10附件(三)软件、软件危机、软件工程16附录(四)软件工程的七条基本原理20程说明壹软件工程概述(理论3学时)开发的发展历史分为三个阶段：年代—至今)，工程化的生产危机软件危机(softwarecrisis)指的是于计算机软件的开发和维护过程中所遇到的壹系列严重问件危机”(softwarecrisis)这个名词。包含俩方面问题：壹、如何开发软件，以满足不断增长，日趋复杂的需具体来说，软件危机主要有以下表现： 发成本超出预算，实际进度比预定计划 面是和软件本身的特点有关；另壹方面是由软件开发和维护的方法不确方法主要表现为忽视软件开发前期的需求分析；开发过程没有统壹资料不齐全，忽视人和人的交流；忽视测试阶段的工作，提工程的作用工业界巨头，讨论和制定摆脱“软件危机”的对策。于那次会议上第壹次提出了软件工程 (softwareengineering)这个概念。到今年(2008)，软件工程整整走过了40年的历程。发大型的复杂软件系统过程中遇到的问题。之所以称为软件工程，是程化的过程。软件工程的目标就是找到壹种能指导大型复杂的软件系使用大量人工、时间，涉及到项目管理、人员管理等，因而有许为了理解软件工程中涉及的问题，能够先想象其它的大型复杂设施的构建(机械行业和建筑行业等)。例如，汽车，办公大楼，水立方等。自然会想到以下几个问题，这个项目需要的术等；如何把项目分割成几个便于管理的模块？如何保证模块间的协何用系统化、规范化、数量化等工程原则和方法去进行软件的开发和？工程和传统工程项目的区别以复用现有的软件构件，因为软件往往是个性化的；难以对软件质量进行项目设计系统(辅助经费预算、项目调配以及人员分配等)项目管理系统(辅助健康项目的开发进度)文档工具(辅助编写和组织文档)原型和仿真系统(辅助开发原型系统)界面设计系统(辅助图形用户界面的开发)编程系统(辅助编写程序和调试程序)Bug系统(辅助测试)附录(1)常用CASE工具介绍(壹)图稿绘制：1，visio:这是目前国内用得最多的case工具。它提供了日常使用中的绝大多数框图的绘画功能(包括信息领域的各种原理图，设计图)，同时提供了部分信息领域的实物图。visiovisioword对象绘图工具的朋友肯定会感受到visio于处理框和文字上的流畅，同时于文件管理上，visio东西，可是功能上visio不减从前，各种器件模版有了许多增进。是对不善于自己构造图的人。可是正因为很全，所以某个方面上会造画网络拓扑结构图只要有相应的图素，用什么画均行；且且于某个目录组织。smartdraw也是大手笔，有许多visio没有的方便功能。比如插入表d(二)原码浏览的工具：1，SourceInsigt:不能不说这个东西是个好东东。以工程的方式管理原码,提供非常适合再工程的浏览手段.整个面板分成三个部分.左边树提供工程内的所有变量,函数,宏定义,右边提供程序阅读和编辑,下边显示你鼠标于原码触及的函数或者变量定义.最让人佩服的是igt比，样子土多了,处处透着Linux的乡土气息，不过是干实事的家伙。提供原码高亮显示和含关系分析，提供类的层次关系，这个东西最大的特点是把原码始终供到文件的导航。当然不能说它使用很方便，我壹般不用它，可是它3，Dia：(http:///vpuml.php)目前最合适也是最火的软件了(从这壹年来网站的设计变化a也是java做的，速度仍是很快的。如果不需要使用逆向工程之类的高级功能的话，强烈推 http:///h/sdm/se_tool/rational/rose/rose98.htm1.引言和设计的方法和理论，远离纠缠不清的源代码，达到构建和设计变得更直1)通过用例模型，业务/系统分析能够捕获到业务/系统需求。2)设计者/构架师所作的设计模型能于不同层次的同壹层内清晰表达对象或子系统之间的交3)开发者能快速地将模型转变为壹个可运行的应用程序，寻找类和方法的子集，以及理解。F和框架的建模.于加上他的Rational系列,RUP的方法论,是当之无愧的巨无架进行可视化、理解和改进。利用模型驱动的方法进行软件候，这个构架将软件的其它部分隔离，避免这些部分受到负面和开发团队的其他人员联系起来，帮助加速开发过程。使用RationalRose软件，数据库设。其功能包括：)支持对象模型、数据模型和数据存储模型的创建。辑。4)变换同步选项(于变换期间对数据模型和对象模型进行同步)。向导。的团队成员独立开发、协作沟通和交付更好的软件来统壹开发它的核心则为，它支持本地代码模型，你所有的类及其关联元素(单元，图，文档及事件类元素列表或图集中进行操作，如果你已有准备，你即可从模型中生成源代码单元，且可由如代码注释选项，代码次序，方法使用等等)，且且可为多种需求重新生成单元(调试代码，自动生成的大量注释代码等)。于内的应用程序。且把它们导入到源代码中。能够使用自带的HelpFileGenerator生成其使用效果图如下所示：仍可为数据仓库制作结构模型，也能对团队设计模型进行控制。它可于企业级建模上它的功能也很强大。很多公司当下于用三个不同的产品，成问题是比如需求改了，数据改了，对哪个类有关系，跟哪个流程有r2.4EnterpriseArchitect除了开发类模型之外，仍包括事态模型，组件和布局，系统管理，非功能需求，用户界面设其主要特点包括：软件建模方案。该产品不仅特性丰富，而且性价比极高，能够用2)特性丰富系统设计ML的软件。除此，它仍包含特性灵活的高品质文档输出。用户指南能够于3)端到端跟踪EnterpriseArchitect提供了从需求分析、软件设计壹直到执行和部署整个过程的全面可跟explorerEA仍含有壹个所见即所提供强大的文档生成和方案工具，能够生成复杂详细的方案，方案能。5)EA具备源代码的前向和反向工程能力，支持多种通用语言，包括进行源代码的进壹步开发。代码生成模板仍允许您对生成的源代码进持，令您的应用程序可视化，从源代码、Java.jar文件甚至是.Net二进制汇编语言中获取利用该工具进行建模的界面如下所示2.5MicrosoftVisualVisio目前国内用得最多的case工具之壹。它提供了日常使用中的绝大多数框图的绘画功能(包括信息领域的各种原理图，设计图)，同时提供了部分信息领域的实物图。它是最通用的硬表设计软件。好处是易用性高，特别是对不善于自己构造图的人。可是正他绘图工具的朋友肯定会感受到visio于处理框和文字上的流畅，同时于文件管理上，visio工具的集成如下图所示：非商业用途,于网站上提供了各组件企业和专业版本的KeyFile,附件(3)软件、软件危机、软件工程 于1950年代，软件伴随着第壹台电子计算机的问世诞生了。以写软件为职业的人也开始出本世纪中叶软件产业从零开始起步，于短短的50年的时间里迅速发展成为推动人类社会发批百万、亿万富翁。随着信息产业的发展，软件对人类社会性越人类而言是壹个全新的东西，其发展历史不过四、五十年。人们硬件通常用来执行壹个单壹的程序，而这个程序又是为壹个特定通用硬件成为平常事情的时候，软件的通用性却是很有限的。大多个人或机构研制的，软件往往带有强烈的个人色彩。早期的软件开化软件开发方式，但软件的数量急剧膨胀，软件需求日趋复杂，维护这样开始了！些被认为是优秀的程序常常很难被别人见懂，通篇充满了程序技巧。当下的程序除了功能正确，性能优良之外，仍应该容易见懂、容易使用、容易的软件的定义是：e能和性能要求执行的指令序列；数据是是程序能正常操纵信息软件同传统的工业产品相比，有其独特的特性：1)软件是壹种逻辑实体，具有抽象性。这个特点使它和其它工程对象有着明显的差异。人纸上、内存、和磁盘、光盘上，但却无法见到软件本身的形态，必须通过2)软件没有明显的制造过程。壹旦研制开发成功，就能够大量拷贝同壹内容的副本。所以但会为了适应硬件、环境以及需求的变化而进行修改，而这些修改有不可避免的引入错误，弃。4)软件对硬件和环境有着不同程度的依赖性。这导致了软件移植的问题。5)软件的开发至今尚未完全摆脱手工作坊式的开发方式，生产效率低。6)软件是复杂的，而且以后会更加复杂。软件是人类有史以来生产的复杂度最高的工业产的各行各业、方方面面，软件开发常常涉及其它领域的专门知识，这7)软件的成本相当昂贵。软件开发需要投入大量、高强度的脑力劳动，成本非常高，风险8)软件工作牵涉到很多社会因素。许多软件的开发和运行涉及机构、体制和管理方式等问心理。这些人的因素，常常成为软件开发的困难所于，直接影件危机”(softwarecrisis)这个名词。包含俩方面问题：壹、如何开发软件，以满足不断增长，日趋复杂的需具体地说，软件危机主要有以下表现： 发成本超出预算，实际进度比预定计划 面是和软件本身的特点有关；另壹方面是由软件开发和维护的方法不壹个简单介绍。软件开发和维护的不正确方法主要表现为忽视软件开析；开发过程没有统壹的、规范的方法论的指导，文档资料不齐全，忽视人视测试阶段的工作，提交用户的软件质量差；轻视软件的维护。这些大多数工业界巨头，讨论和制定摆脱“软件危机”的对策。于那次会议上第壹次提出了软件工程 ngineering于这30年的发展中，人们针对软件危机的表现和原因，经过不断的实践和总结，越来越认下面我们给出壹个软件工程的定义，然后简单讨论壹下软件工程所包括的内容：何用系统化、规范化、数量化等工程原则和方法去进行软件的开发和软件开发项目的失败，且不是由于软件开发技术方面的原因。它们的理造成的。遗憾的是，尽管人们对软件项目管理重要性的认识有所提方法学和实现方法学上的进步小，至今仍提不出壹附录(4)软件工程的七条基本原理格证明它们是壹个完备的集合，可是能够证明，于此之前已经提下面简要介绍软件工程的七条原理：上的失败项目是由于计划不周而造护的漫长生命周期中，需要完成许多性质各异的工作。这条原理意味期分成若干阶段，且相应制定出切实可行的计划，然后严格按照计划里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计束需求。可是实践告诉我们，需求的改动往往是不可避免应这种要求。也就是要采用变动控制，又其它各个阶段的文档或代码随之相应变动，以保证软件的发技术，到最近的面向对象技术，从第壹、第二代语言，到分认识到：方法大似气力。采用先进的技术即能够提高软件开发的不着的逻辑产品。软件开发小组的工作进展情况可见性差，难于评价管理，应根据软件开发的总目标及完成期限，尽量明确地规定开发小量和开发效率的重要因素，应该少而精。这壹条基于俩发人员的效率比低素质开发人员的效率要高几倍到几十倍，开发工作中犯NNNN好地实现软件的工程化生产。可是，它们只是对现有的经必要性作为软件工程的第七条原理。根据这条原理，不仅要积极采纳要注意不断总结经验，收集进度和消耗等数据，进行出错类型和问题能够用来评估新的软件技术的效果，也能够用来指明必须着重注意的附录(5)软件模型设计基础(1)年,其数量从不到十种增加到了五十多种,哎，百家争鸣。于众多的建模语言中,语言的创造根据自身应用特点选择合适的建模语言。90年代中,种独立于语言的表示符。这种方法用对象模型、动态模型、功能模型和用例模型,共同完成发的分析、设计和实现的全过程,软件引入了外部角色的概念。用例的概念是精确描述需求的重要武器,但用例贯穿于整个开发过程,包括对系统的测试和验证。OOSE比较适合支持商业工程和需求分析。此外,仍有单、易学,适合于面向对象技术的初学者使用,但由于该方法于处理能力方面的局限,目前已概括起来,首先,面对众多的建模语言,用户由于没有能力区别不同语言之间的差别,因此很难找到壹种比较适合其应用特点的语言;其次,众多的建模语言实际上各有千秋;第三,虽然不,极大地妨碍了用户之间的交流。因此于客总结面向对象技术应用实践的基础上,组的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析和设计,仍支持从需求面简述：附录(6)增量迭代Refactoring不仅仅是壹种编码的方法。他同时是壹种设计方法。本文从软件工程学的演变增量迭代自从有软件工程壹说开始,大大小小出现了许多方法,其中壹些仍常常被我们挂于嘴边.这些般来说,WaterFall方法把软件开发的过程严格地分为几个阶段,包括：应当说，WaterFall模型由它自己的很多优点。WaterFall强制每壹阶段均必须产生所有的产品通过关联的审核后才能开始下壹阶段的工作，而这些产品中相当重要件预算用于维护阶段。而WaterFall模型强制每壹阶段必须有详细文档，所以，见起来壹旦需求方案被用户承认，你就开始起草Specification文档，它指出了软件需要做什么东西。Specification文档通常很长、很详细、很直白，因此很容易让人见着生厌。用户通常均很难完全见懂软件的Specification文档，他几乎不可能判断你讲得是否正确，但通常他流是否能够完全使用文档来实现，即使你能够使用更加高级的面是他们于《TheTreeofLife》壹书中的答案：是的事情。于接受到外部刺激，被重构翻译成内部信号，从而引发内部活动。所冲向出口。他身旁的另壹个日本人，正好于睡觉，因此根本没有接收没有转化成内部信号。壹个不懂日语的人注意到有个人进来大叫，可接收到任何特别的信息。每壹个人从大叫接收到的东西端依赖于他的中，壹个日本人能够接受到大量信息而非日本人却不知所云的重要原因是大喊的人和那个于房间里的日本人有壹个共同的经验：日语。软件需求获取者、Specification撰写者和用户之间往往不可能有这样的共同经验。够达到很好的交流也是不可能的。文档有助于增进理解，可是它不可能达到完整的理解。Waterfall试图依赖非常详细的完美。事实上，对文档的理解且不依赖于文档的详细程度。而是依赖于文。如果我和你之间均具有设计模式的背景，那么我说壹句："使用visitor模式"，可能比俩个能壹趋而就。当然，于壹个软件公司内部，长期的合作可能使，譬如，于进行设计的时候，你说："就像上多的设计信息也能够完全实现。这种长期的合作关系是很少见的。因此，除非你对该用户的领域非常解用户的壹举壹动。否则，你不可能壹次就完成设计，你对用户的理下人和人之间，壹个人需要和所实现的目标进行交流。这就是我们所求阶段、标书阶段、设计阶段或是实现阶段，问题的解决要依赖于你。理解越深刻，问题的解决就和完美。而这样的理解是不可能壹次达。Waterfall的另外壹个问题就是用户于最终产品交付之前不能见到任何用户的东西。而用户对提交产品的见法最后既有可能是："IknowthisiswhatIaskedfor，butitisn'treallywhatIwanted。"通过纸上的文档理解到的东西远远不及真正能够使用的软件产品那么多。Waterfall对需求和Specification如此的依赖，直接就可能产生且非用户为了解决这个问题，我们需要使用增量模型。不同于waterfall和快速原型模型，增量模型不试图壹次性地发布完全符合用户需求的软件。相反，最终的产品被划分为几个build，按照壹个壹个build进行。任何壹个阶段，用户均能够获得际可操作的软件。而不是象前面的模型壹般，需要等待几个月、壹年适应用户的变化。变化是每壹个成长中的用户组织固有的特点，改变的要求同时也是软件开发的壹部分。这也是我们说"软件是软的"所包含的意义。从客户的财务观题，。其中的壹个难点就是每壹个新发布的build必须能够平滑地集而不会破坏已经存于的东西。从这个角度来讲，壹个增量模型下的设计可能需要比Waterfall更加复杂的设计。因为Waterfall壹次性地考虑所有问题，它能够提前见到设计、实现中的所有问题(于他自己的范围之内)，既然问题已经全部摆出，你就增量模型则不同，于构建当前的build时，你不会去考虑以后的build。所以，以后的build可能需要当前build不可预料的支持，它也可能以不可预料close加build也不会破坏原来的系统。同时，它通过各种面向对象特有的机制，多态和继承，使得系统能够以增量的方式平滑地集成。可是，是不可能达到这样的目标。显然，你需要壹种方法，能够于壹个模块外部行为不变的情况下改变内部的结构，使得增量能够顺利地进行下去。Refactoring是增l MessDefinedProcessBlackbox箱的输入输出不断进行度量，于此基础上，结合经验判断对黑箱进行调控，使其不越出设定的边界，，使项目组工作于混沌的边沿，充分发挥人的创造力。如将经验性过程按确定性过程来处理(如瀑布模型)，必将使过程缺乏适应力。1.计划和体系结构设计(确定性过程)建立系统体系结构(如为已有系