软件工程试验心得

第一篇：软件工程试验心得

心得体会

学了一个学期的软件工程课，终于知道了个软件工程的大概。学的时候总觉得很抽象，理解起来好像不难，但总是摸不着头脑一种很茫然的感觉。学习的过程中和一个宿舍的同学一起做了个小型管理系统的开发，觉得还是有点收获的，对于开设这门课的意义也有所领悟，现在就将我对这门课的体会以及在项目开发过程中遇到的一些问题简单的归纳一下。希望在以后的学习中不断的提高吧。

曾经以为程序就是软件，软件就是程序。现在知道了二者的不同之处，这是学习这门课程第一个收获。事实上在软件开发的早期阶段这也不能说是错误的。那个时候开发的软件都比较简单。当然可以把软件理解成程序，直到软件作坊的出现，使软件在程序的基础上加了个说明。以前做过的一些小型的软件比如加密软件，也只是在程序旁边附上一个软件的说明，看来已经很接近作坊了。不过大的项目没有接触过，用软件工程的方法还是第一次。我想也是程序的不断复杂化导致了软件危机的发生，使得人们不得不探索新的解决方法。这个时候软件工程应运而生了。

掌握软件工程化的思想，对于负责软件开发的管理人员（领导）更为重要。曾经看到过这么一句话，“坐在指挥台上，如果什么也看不见，就不能叫领导。软件工程将有能力的人团结在一起，然后把他们变成工人，因为工业化的生产是效率最高的。这就是根本所在。没有软件工程管理，简直就是乱来，就好象缺乏宏观控制的国家一样，会乱七八糟。

软件除了程序还要有使用和维护该程序所需要的全部文档。包括需求文档、设计文档、测试文档、维护文档以及使用手册。

软件开发特别是大型软件是一项浩大的工程,需要几个人、十几个人、几十个人甚至几百个人合作开发几个月、十几个月甚至几年。要保证系统的协调性、统一性和连续性,就需要在开发之前制定严格、详细的开发规范。开发规范的制定需要花费一定的时间和精力,但是“磨刀不误砍柴功”,它相当于把今后开发过程中开发人员都要遇到的问题提前做了一个考虑。有了开发规范,在后续的开发过程中,设计人员就不必每次考虑如何为一个字段命名,编程人员也不必去想某个程序的结构和布局应当 怎样,测试人员也有了判断程序对错的标准。它约束开发人员的行为和设计、编程风格,使不同子系统和模块的设计、编程人员达成默契,以便形成整个系统的和谐步调和统一风格,也便于今后的系统维护和扩展工作。

第二篇：软件工程试验论文

班级：09级计算机本科班姓名：白路明学号：091220141046

软件工程开发工具case的学习心得

摘要：文章主要前线介绍了什么是计算机辅助软件工程CASE以及它的分类方式和主流的几种CASE工具的特点。

关键字：（1）CASE的基本定义及作用

（2）CASE工具的标准及种类

（3）主流CASE工具的各自特点

参考文献：窦万峰软件工程试验教程

徐培炎 PowerDesigner特点、优势[EB/OL].赛迪网

2006.10

Wendy Boggs, Michael BoggsUML与Rational Rose 2002入门与精通[M].电子工业出版社.2002

徐锋.实战OO：为问题域建模.程序员.2004.2

王文玲，金茂忠.UML模型与其应用.计算机工程与应用.1999

Doug Rosenberg, Kendall Scott.UML用例驱动对象建模.北京：清华大学出版社.200

3软件工程是将计算机科学理论与现代工程方法相结合，着重研究软件过程模型、设计方法、工程开发技术和工具，指导软件生产和管理的一门新兴的、综合的应用科学。随着计算机科学和软件产业的迅猛发展，软件工程学已成为一个重要的计算机分支学科，一个异常活跃的研究领域，正在不断涌现新方法、新技术，蓬蓬勃勃的发展着。软件工程是计算机专业和软件工程专业学生必修的一门专业课程，也是工科各专业学生在计算机应用方面的一门重要选修课程。随着软件工程理论与技术的发展和多种多样的辅助软件开发的case（计算机辅助软件

工程）工具不断涌现，既提高了软件开发效率，同时还大大的节约了开发成本，并且对从事软件及相关行业的人才和大学生提出了新的更高的要求。

一、CASE的基本定义及作用

计算机辅助软件工程CASE是通过一组集成化的工具，辅助软件开发者实现各项活动的全部自动化，是软件产品在整个生存周期中，开发和维护生产率得到提高，质量的保证。CASE环境、case工具、集成化CASE（I-CASE）等，实际是一切现代化软件开发环境（SEE）的代名词。CASE(Computer Aided Software Engineer计算机辅助软件工程)“用自动化手段对结构化概念和设计方法重新进行组装”。CASE的实质是为软件开发人员提供一组优化集成的且能大量节省人力的软件开发工具，以实现软件生存期各个环节的自动化并使之成为一个整体。CASE是一套方法和工具，可使用系统开发商规定的应用规则，并由计算机自动生成合适的计算机程序。CASE工具分成“高级”CASE和“低级”CASE.高级CASE工具用来绘制企业模型以及规定应用要求，低级CASE工具用来生成实际的程序代码。CASE工具和技术可提高系统分析和程序员工作效率。其重要的技术包括应用生成程序、前端开发过程面向图形的自动化、配置和管理及寿命周期分析工具。

CASE的作用有通过自动检查提高软件的质量；使原型的建立成为可行；简化程序的维护工作；加快软件的开发过程；鼓励进化式和递增式的软件开发，使软件部件可重复使用。CASE的基本功能有提供一种机制，是环境中所有工具可以共享软件工程信息；每一个信息项的改变，可以追踪到其他相关信息项；对所有软件工程信息提供版本控制和配置管理；对环境中任何工具，可以进行直接的、非顺序的访问；在标准的分解结构中提供工具和数据的自动支持；是每个工具的用户，共享人机界面的所有功能；收集能够改善过程和产品的各项度量指标；支持软件工程师们之间的通信。

二、CASE工具的标准及种类

CASE 工具分类的标准可分为三种：功能，功能是对软件进行分类的最常用的标准；支持的过程，根据支持的过程，工具可分为设计工具、编程工具、维护工具等；支持的范围，根据支持的范围，可分为窄支持、较宽支持和一般支持工

具。窄支持指支持过程中特定的任务，较宽支持是指支持特定过程阶段；一般支持是指支持覆盖软件过程的全部阶段或大多数阶段。1993 年，Fuggetta 根据 CASE 系统对软件过程的支持范围，提出 CASE 系统可分为三类：支持单个过程任务的工具。工具可能是通用的，或者也可能归组到工作台；工作台支持某一过程所有活动或某些活动。它们一般以或多或少的集成度组成工具集；环境支持软件过程所有活动或至少大部分。它们一般包括几个不同的工作台，将这些工作台以某种方式集成起来。

CASE 方法与其他方法相比有如下几方面的应用特点：解决了从客观世界对象到软件系统的直接映射问题，强有力地支持软件、信息系统开发的全过程；使结构化方法更加实用；自动检测的方法提高了软件的质量；使原型化方法和 00 方法付诸于实施；简化了软件的管理和维护；加速了系统的开发过程；使开发者从大量的分析设计图表和程序编写工作中解放出来；使软件的各部分能重复使用； 产生出统一的标准化的系统文档。

CASE 工具种类繁多，适应了不同方面的要求，随着技术的发展，还有不但推陈出新的趋势。给软件人员提供了更多的选择余地。例如： Enterprise Architect、Poseidon、ArgoUML、ModeIMaker、Gaphor、Visio、object Domain、UMLStudio、Visual Paradigm for UML、Rational Rose、Umbrello TOgether、Low-tech、Jude、ARIS、MagicDraw、CodeLogic、omondo、Micro Gold omnigraffle(Mac OSX only）、Embarcadero Technologies 等等。主流的CASE工具有Visio、Smartdraw、SourceInsigt、Telelogic、ModelMaker、ArgoUML、Rose、vss、cvs、Project、PowerDesigner、WinRunner、LoadRunner、Eclipse。

三、主流CASE工具的各自特点

Rational Rose

目前市面上最流行的UML Case工具,绘制的图形简洁美观它支持Java,J2EE,C++,MCF等语言和框架的建模.在加上他的Rational系列,RUP的方法论,是当之无愧的巨无霸.IBM Rational Rose 是一个完整的可视建模方案，开

发人员、项目经理、工程师和分析人员可以在提交编码之前对需求和构架进行可视化、理解和改进。利用模型驱动的方法进行软件开发，可以保证系统的可扩展性、灵活性和可靠性，使您更快更好地创建软件。其功能包括： 支持对象模型、数据模型和数据存储模型的创建。映射逻辑和物理模型，从而灵活地将数据库设计演变为应用程序逻辑。支持数据模型、对象模型和已定义数据语言（DDL）文件／数据库管理系统（DBMS）之间的双向工程。变换同步选项（在变换期间对数据模型和对象模型进行同步）。数据模型-对象模型比较向导。支持一次性对整个数据库进行正向工程。集成了其他 IBM Rational Software Development 生命周期工具。能集成任何兼容 SCC 的版本控制系统，包括 IBM Rational ClearCase 软件。能够以 Web 页面的方式发布模型和报告，以此来提高整个团队的沟通效率。其最突出特点就是通过使所有的团队成员独立开发、协作沟通和交付更好的软件来统一开发团队，建立稳定、有弹性、基于构件的系统构架，以可控、可管理、可确认的方式进行开发，从而降低成本，加快面市的速度。一个无缝集成所有领先的 IDE 与最新技术的工具可满足您的所有技术需要，最大化开发工作的速度和简便性。

ModelMaker

一个非常强大的软件工具，其功能与所有强大且具有多面性的产品一样。但ModelMaker的复杂性却会让一个新手望而却步。

ModelMaker常被认为是一个UML图形工具或是Delphi Case工具,然而，它比一般的图形工具和Case工具要快得多，有时，它可为你写一些人工智能式的代码。它是可扩展的，支持UML图，设计模式，逆向生成与分解的双向代码管理工具等。

它的核心则为，它支持本地代码模型，你所有的类及其关联元素（单元，图，文档及事件类型等等）都是模型内部的对象。ModelMaker为活动模型提供了多种视图，允许你在类列表，元素列表或图集中进行操作，如果你已有准备，你即可从模型中生成源代码单元，并可由Delphi来进行编译，以后生成的单元每次也可重新生成。你可对各种不同的设置进行修改(例如代码注释选项，代码次序，方法使用等等)，并且可为多种需求重新生成单元(调试代码，自动生成的大量注释代码等)。

Enterprise Architect

以目标为导向的软件系统。它覆盖了系统开发的整个周期，除了开发类模 型之外，还包括事务进程分析，使用案例需求，动态模型，组件和布局，系统管理，非功能需求，用户界面设计，测试和维护等。其主要特点包括：为整个团队提供高级的UML 2.0建模工具；特性丰富系统设计；端到端跟踪；EA提供使用工具，能够跟踪依赖关系、支持大型模型，帮助您管理大型复杂的工程；含有CVS或SCC提供工具，以时间快照为基线，通过比较来跟踪模型变动，从而实现版本控制；含有类似explorer的项目视窗，为您提供直观高性能的工作界面。EA还含有一个所见即所得形式的模板编辑器，提供强大的文档生成和报告工具，能够生成复杂详细的报告，报告可以按照公司或客户要求的格式提供所需信息。EA具备源代码的前向和反向工程能力，支持多种通用语言；EA还提供变换模板，编辑和开发均非常简单，支持先进的模型驱动结构体系（MDA）。

Visual Paradigm

是由一家香港公司开发的 UML 工具。功能的强大不次于rose等case工具。可以和其他工具整合，包括Eclipse/IBM WebSphere 等并且支持多平台简单介绍如下特性：支持UML2.0;支持生成Html,PDF,Writer的报表;可以导入Rose 的UML图;汇出为XMI;可以生成Java代码;有.Net的Add-In;支持E-R图建模;支持ORM;智能化的提示即当你把鼠标移到一个UML图上时,周围自动显示能和此UML图相关的UML图可快速地添加。

第三篇：软件工程心得

学习软件工程这门课程已经有一个学期了，整一个学期下来，应该说还是有许多值得肯定的地方的，其实在我看来，软件工程与其说是一门课程，不如说是一门思想。是一个如何去分析和处理问题的过程，应该说其范畴已经远远不止局限于该门课程，成为了一个综合的一个能够解决问题的思想集合。

在上课的时候我还是很认真地去听老师所讲述的内容的，我觉得他的思想和我一向而来的培养计算机学生综合素质的理解还是在一定程度上不谋而合了，所谓的需求获取，那就是一个谈判，辩论，交流的过程，已经不是单纯的编编程序就能解决的问题了。从我所看到的听到的来说，我最怕的就是计算机系的学生被别人说成是个带着厚眼镜的，只能够在电脑前编编程序的，在交际场上不知道说什么而一个字都说不出来的人。我觉得这样的人进入社会之后是没有什么前途的，起码他们缺乏了与人沟通交流的能力。而这门课程在一定程度上给了我们这些学生一个机会来锻炼自己在另一方面的能力，设想一下，一个又有技术又能够与人交流合作的人所取得的成就自然要比一个单单只会编程序的人要大得多。

其次，这门课程教给了我们在完成一个实际项目时的一般程序及过程，我认为这是一份非常具有实际意义的教学内容。当我们在毕业之后，这是我们实际要运用的一项非常有用的技能，而且不仅仅局限于软件工程的范畴，我们即使是从事与其它行业，不也是要从需求获取开始，一直有条有理地到最后成品的出炉吗？应该说这就是这门课的价值所在。无论是在上课，还是在学生会里面做学生工作，我都深深地感觉到，技术性的工作就好比变魔术，其实原理是非常简单的，甚至可以说简单的可笑，但是当你就是做出这么一个简单的东西出来之后，一些外行们有时候会用崇拜的眼光看着你，觉得你很厉害，很高深莫测。但是制作的过程他们却不知道，也许知道之后他们只是会哑然失笑，原来这个东西的制作过程是如此的简单。这个可以说就是技术的魅力了，而作为需求获取及之后的一系列过程则是类似于魔术揭秘的过程，但是作为这个秘密我们并不需要一揭到底，至于揭的程度如何那就是我们那就是我们学出的程度如何了，我们要让对方知道我们在做什么？以及如何去做？这些东西需要我们以一定的技巧叙述出来，所起到的作用就是能够让对方了解自己的进度，却又能够不让对方来干涉自己的工作过程。因为我们是技术员，对方只是外行，即使对方知道了这个魔术的操作过程，也并不代表他们就能够向变着魔术的我们来随便修改这个魔术的变法，况且我们能够用不同的过程来得出一个同样的结果，这个过程的得出的主动权如何掌握在我们的手上，就看我们如何以高明的方式来揭开这个魔术的谜底了。

当然了，在纯粹的理论上，我觉得开设这样一门课程是很成功的。但是毕竟现实里有太多的不确定的因素。最重要的因素就是授课的老师和听课的学生。这两个可以说是这门课成与败的决定性的因素。

作为老师方面来说，我觉得给我们上试验课的老师非常的优秀，作为一名了有十几年工作经验的老船长，看问题的确是有他自己独特的一套方法，我的话对他也是非常崇拜的。但是周日晚上的课程我还是有比较大的意见，首先，作为学生来说，最不希望上课的时间就是周五的晚上和周日的晚上，因为这是个我们进行调整的时候，前者的调整是为了假期的到来，后者的调整是为了准备学习的开始，这个时候的上课一般来说都是学生比较反感的。其次，对于我来说，原来小的时候非常崇拜那些有着高学历的人才，什么硕士，博士，博士后都是被放在神坛上的人物，觉得他们很厉害，走路都会散发光环。但是在我上了他们这些人的课之后我发觉我真的是很失望。作为一个具有高学历的人来说，他能够自己迅速的吸收知识这点的确是令人敬佩，但是他能不能够把自身所吸收的知识传授给他的学生，那就是一个未知之数了，虽然的确这是一门枯燥的课程，但是并不代表老师就可以在讲台上讲课没有一点激情，或者说没有一点能够让我们想听下去的欲望，这个不得不说是一件非常讽刺的事情。子不教，父之过；教不严，师之惰。虽然学生们也有一部分的责任，但是把一切责任都推到学生们的身上那也是非常的不公平的。

作为我们学生来说，当然也应该负起比较主要的责任。在大学里有了太多的基础课程，基础课程大多都比较枯燥无味，也许在第一个学期里我们还能够保持着新鲜感，但是在5个学期之后，可以说再有新鲜感就是一件比较困难的事情了，我们都已经开始变得迟钝了，现在出现了一门新鲜的课程，可能同学们比较难把那样不好的状态一下子改变过来。其次的，学生们没有认识到这门课程的价值。这门课的价值我已经在上面说过了，是不言而喻的。但是并不是每个同学毕业之后都回从事计算机行业，也不是每个同学都知道这门课程的意义已经不仅仅局限于计算机这个范畴，但是他们不知道，无知者无畏也。既然和我没什么关系，那我就不听，反正听了也没什么用，很多同学报着的就是这么个心态。对于这样的心态，我表示理解，也表示悲哀。在没有彻底了解一件事物的本质之前，我们是没有资格向这件事物随便的指手画脚的。最怕的就是在没有了解之前就把这件事物否定。如果有了这样先入为主的思想，那就比较没救了。所以作为我们来说，还是更需要得深入了解下这门课所起到的作用之后再下结论也不迟。只是有一点我还是觉得比较奇怪，现在被人嗤之以鼻的传销在当时能够吸引如此大的一批人，而且那些受害者明知道这件事情是不好的但是还会去做，就是因为“洗脑者”的口才说服了他们，那作为老师来说，如何来说服学生们来上一门正确的课程应该说是要相对的容易很多吧，但是我觉得这样的过程在我们的大学课程里真的是少之又少啊。今天在这里写了很多，算是我对软件工程这门课程的一点点心得体会，也许是正确的，也许在一定的程度上存在着观点的偏激错误，但是起码这些东西是我觉得存在着的一些问题，但愿软件工程这门课程能够开的越来越好，让更多的学生们能够从这门课程中受益，在以后社会残酷的竞争之中存活下来！

第四篇：软件工程课程心得

软件工程项目总结

在我们整个软件工程过程中，我体会到了许多，也学到了许多。

在项目要进行自由分组后，我们的项目小组便诞生了。我们小组由七个成员组成，在相互商量后我们也确定了我们组的项目，是做一个校园 b2c电子商务网站。我们也随即做了分工，由于我们团队只有我和另一名成员有类似的项目开发经验，所以我们便要担负起更重的任务。最后由于在整个团队中，对于界面开发这一块只有我的开发经验较深，所以我便担任了主要的界面设计人员。我们的项目也正式开始了。

需求调研和分析对于软件开发过程至关重要。我们在开发时如果不进行调研和分析，那么对于后来的项目进展将产生致命的后果。我们在项目的开发中便遇到了这样的问题。老师作为我们的客户，他对这个校园 b2c电子商务网站的要求便是我们必须了解的，我们也必须以客户的要求为根本构建我们的这个系统。我们开始自己随意的计划整个网站的设计，然后报给老师，老师作为一个客户并不是全部认同，随后我们也必须按着客户的要求更改我们的设计报告。我也明白了，再做一个系统时，必须随时和客户保持沟通，随时了解他们需要什么，他们想要什么功能。如果我们不去和客户沟通，不去调研客户的需求，做出来的系统即使在我们看来是一个很好，很完美的产品，但是如果客户不认同，那么我们所做的一切都是徒劳，还要返工去修改，费时费力。所以在做任何一个项目时，前期的需求调研和需求分析都是必须的，这是在做一个项目的基本，是关系成败的重要一环。

对于一个项目，它的需求设计也非常重要。在我们的校园 b2c电子商务网站开发的过程中，遇到了一些问题，如客户提交购买确认后，我们如何确定应该以什么方式将货物给客户，还有以什么确定货物的送达地点，客户的订单在哪里处理，订单以什么方式惊醒处理，在管理员应该实现的功能上反复增删等，这些问题很多都是由于设计不够清晰，不够完善而导致的。出现的这些问题很多都是非常棘手的，我们为了解决这些棘手的问题浪费了大量的时间，我们不得不在工程代码上改了又改，在数据库里增表、删表、加数据、减数据，当然，在文档里也要做出相应的修改以适应新的功能。还好，我们能及时地发现问题，通过相互

沟通讨论，问题也得到了解决。通过总结，我们也意识到，我们大家在做需求分析和进行需求了解时仅仅考虑了一些基本的功能，而至于管理员和客户之间的联系，以及具体的一些流程我们都没有深究，而导致我们到后期花费了大量的时间用于修复之前没有考虑周全而带来的问题。如果我们的需求设计能够比较清晰和完善，那么我们在开发过程中便会很明白的知道我们应该实现什么样的功能，在数据库里应该怎样建表，以什么方式插入数据，从而可以避免反复修改工程的问题，也能避免出现可能毁坏整个工程的问题。整个工程的需求设计对于一个项目的顺利进展至关重要。

对于文档在软件工程中的作用，我在这次项目开发过程中有了更加深刻的理解。文档在软件开发过程中是很有用的，文档是一项必不可少的东西，但文档也不能太多，太过繁琐，如果是那样就不太好了。首先我们要明确开发过程中为什么要写这些文档，文档的最根本的作用是为了更好的沟通。一个项目或产品可能需要延续很长的时间，开发过程中可能需要很多的环节，可能会遇到很多的问题和很多的解决的方法，这时，我们需要文档的帮助，我们需要有一个东西来记录，我们需要有一个共同的声音。文档只不过是一个准绳，将开发中的各个树枝树叶扶正。如果，这个准绳太多太紧，大树可能会发育的很高很直，但是就是有些畸形，如果这个准绳太少太松，大树可能就会变成灌木丛。文档的多少、繁简是有度的，绝对不能说越多越好。我觉得，文档需要说明解决问题的方法而不是解决问题的理论，因为解决问题的理论是在文档形成中做到的。文档完整即可，每一份文档说明一个问题，无需将多个文档的内容放在一个文档的里面。除了重要阶段形成文档，其它部分都只是讨论或者说是想法。不要让文档成为累赘，如果真是这样，我认为就是该考虑写这些文档的必要性的时候了。我们在文档的时候，一定要明白为什么要写这些。

在整个项目开发过程中，我们也同时遇到了许多程序接口问题，页面和功能相结合的问题，数据库建表的问题，这些问题都是源于我们项目小组成员之间的沟通不足。我深刻认识到，在项目开发时，项目小组中各个成员之间的相互沟通是非常重要的。如果我们要在功能方面作出修改，那么程序人员和页面人员及数据库人员就必须相互沟通，共同对整个程序作出相应的修改，这样才能避免最终整合时出现问题。

在这十个周里，我还对软件工程有了新的理解。在我以前的理解当中，软件工程，无非就是一个人或者几个人或一个团队集中在一起进行编写代码的工作，以实现开发出所用的软件。但现在我明白了，软件工程的作用，就是告诉人们怎样去开发软件和管理软件。具体地讲，它表现在与软件开发和管理有关的人员和过程上。所以，软件工程就不仅仅是单一的编程过程了。它包括了系统分析->建模->概要设计->详细设计->编码->测试->维护。编码可以理解为编程，这个只占总时间的20％左右。编程只是其中的一小部分。

在这次项目里我完成了许多工作，在界面设计上我完成了，首页、全部的商品页面、全部的用户页面及部分管理员页面的制作，在后期项目整合过程中修改了功能和界面结合时出现的bug，还有数据库插入数据及解决数据库集中整合时出现的问题。这些工作我都顺利完成了，虽然并不能算是非常的出色，但也算是尽力了。现在看到自己辛劳的成果，我感到很欣慰。

当然，在这次项目过程中我也发现了自己的一些问题。如现在的网站开发技术还不够强，在和小组成员相互沟通上还不够积极等。我希望以此为契机，在将来的项目开发中能做得更好。

第五篇：软件工程实验心得

早在我选择民政职业技术学院就读软件开发与项目管理这门专业的时候，我一直认为软件开发无非是努力的敲代码，从敲代码的过程中去体会各行代码的意思和用处，在没学软件工程时我一直都是努力的敲代码去学习软件开发这门专业。在大一的时候我敲代码的激情很好，但是到大二的时候就出现问题了，我根本就不喜欢敲代码了，看见代码就头疼。所以感觉厌恶这门专业，对学习也不感兴趣了。而且，还有一件更头疼的事是在写一个简单的程序时竟然老是出错，难一点的，复杂一点的程序竟然无从下手。但是去看程序的参考答案时都看得懂，又感觉很容易。学了软件工程以后，我就感觉我以前的学习方法是错误的。以前我只注重于代码，而不注重理论知识以及编程的思路，程序的架构。以至于在些程序时没有写程序的思路，不能形成程序的架构。只想到看脑袋里是否有与此类似的代码。越想程序越乱，最后脑袋里一片空白。不知道程序从哪个方面下手了。

软件工程这门课程是做软件开发的人必学的课程，通过学这门课程，程序员就会注重软件开发的理论知识，以及做项目开发的思路。学了这门课程后你写程序就不会去盲目的去套用代码，而是理清此程序的架构以及思路。程序该从什么时候开始，什么时候结束。在中间需要添加什么样的功能，以完善该软件。其实学软件工程并不难，而且很容易。软件工程与日常生活联系起来的话，就是在一天中你该先做什么，后做什么。理解了先做什么，后做什么了以后写程序就不是那么难了，再复杂的程序也可以分成几大块。你理清程序的思路后就可以一步步的解决其中的难题，最终实现软件的功能。如果没学软件工程不知道理清程序的思路的话，做一个大的项目开发，那么多的代码，没有一个很好的结构，最终只会导致程序混乱，错误百出，知道代码再多也会素手无策的。

总而言之，作为一个程序员学习软件工程这门课程是至关必要的，如果没学习软件工程，你就不会做项目开发，也不可能开发出一个完善的软件出来。

软件工程实验心得（2）：

曾经看过一本书叫《道法自然》，内容略记得一二，但我最欣赏的是它的书名。软件设计没什么太神秘有东西，只要用心体会，其实一切都很自然。软件的设计之“道”，也不在于设计有多么的华丽、精巧，而在于其朴实、自然，最终达到“以无招胜有招”，进入一个全新的境界。

一、软件设计理论的层次

以我的拙见，软件设计领域中的各种概念，可以分为以下几个层次来进行理解：

1、软件设计的目的：重用性、扩展性。

这是最高的层次，是应对软件危机的需要。

2、设计原则：低耦合、高聚合。

各种软件设计的原则，如依赖倒置原则、单一职则原则、面向接口等，以及各种设计模式，其根本的目的其实只是为了降低耦合这么简单。因为只有低耦合才能更好的适应变化，更好的重用和扩展。

3、实现方法：运用设计模式封装变化、降低耦合。

设计模式只是用来“封装变化、降低耦合”的工具而已。它是面向对象设计时代的产物，其本质就是充分运用面向对象的三个特性，即：封装、继承和多态，进行灵活的组合运用。

二、关于耦合1、耦合的粒度

耦合无论如何也是不可避免的。当我们实现接口、继承父类的时候，就会不可避免的产生耦合。耦合是有不同粒度的，我们解耦到什么粒度为止，我认为应以模块的重用粒度为准。尽量解除重用模块或对象之间的耦合。而重用模块之内的耦合，应属于聚合的范畴，所以不要盲目的去解耦，否则就陷入了误区。

2、解耦的原理

怎样才能解耦呢，或者说为什么各种设计模式能达到解耦的目的呢?我觉得有以下几个思路：

(1)将具体的东西抽象处理

(2)将分散的东西集中处理

而面向对象中的接口、继承正为我们提供了这样的一种机制。通过访问接口或基类或抽象类，而不是具体的实现类，从而与具体的实现类达到了解耦的目的。我们还可以设计一些控制类，像润滑剂一样，协调各实现类之间的访问，也可以达到耦的目的。

事实上，各种设计模式的基本思想也就是这样。创建型模式是为了解除创建对象时产生的耦合，实际上是解除对类称名的依赖，而结构型和行为型是为了解除对象属性或方法的直接调用。不管什么设计模式，都是将对具体实现类的访问提升为对接口、基类或用于协调的控制类的访问。

三、关于接口

这一节更具体，谈一谈接口，因为使用接口是软件设计的重要手段，但已经不属于“道”了~

1、接口与继承

接口描述的是对象某一个方面行为特征。使用接口与使用继承关系各有优缺点，使用子类继承可以继承父类的功能，体现了重用的精神。而接品更加灵活，因为它解除了子类与父类之间的高度耦合，它体现在灵活扩展的精神。

2、接口与纯虚类

理论上接口可以由纯虚基类实现类似的功能，那为什么还我们不去掉接口的概念，而直接使用虚类呢?

接口存在的理由就是它更加灵活，关系简单，易于理解。比如一个类可以实现十几个甚至几十个接口，但一般开发工具只支持单继承(由于多继承太容易导致混乱和冲突)，如果要继承十几层，系统结构想必会无法理解了，我以为这是接口存在的最重要的原因。

如果接口和虚类继承结合使用，可以产生强大的威力，这也是许多设计模式的“杀手锏”。

以上算是总结一下自己的心得。肯定有不少片面之处，请各位指教。