就如何利用面向对象的软件开发方法来开发软件心得体会
面向对象技术是软件技术的一次革命，在软件开发史上具有里程碑的意义。
随着OOP（面向对象编程）向OOD（面向对象设计）和OOA（面向对象分析）的发展，最终形成面向对象的软件开发方法 OMT(LbjectModellingTechnique）。
这是一种自底向上和自顶向下相结合的方法，而且它以对象建模为基础，从而不仅考虑了输入、 输出数据结构，实际上也包含了所有对象的数据结构。
所以OMT彻底实现了PAM没有完全实现的目标。
不仅如此，OO技术在需求分析、可维护性和可靠性这三 个软件开发的关键环节和质量 指标上有了实质性的突破，彻底地解决了在这些方面存在的严重问题，从而宣告了软件危机末日的来临。
自底向上的归纳 OMT的第一步是从问题的陈述入手，构造系统模型。
从真实系统导出类的体系，即对象模型包括类的属性，与子类、父类的继承关系，以及类之间的关 联。
类是具有相似属性和行为的一组具体实例（客观对象）的抽象，父类是若干子类的归纳。
因此这是一种自底向上的归纳过程。
在自底向上的归纳过程中，为使子 类能更合理地继承父类的属性和行为，可能需要自顶向下的修改，从而使整个类体系更加合理。
由于这种类体系的构造是从具体到抽象，再从抽象到具体，符合人类 的思维规律，因此能更快、更方便地完成任务。
这与自顶向下的Yourdon方法构成鲜明的对照。
在Yourdon方法中构造系统模型是最困难的一步，因为 自顶向下的“顶”是一个空中楼阁，缺乏坚实的基础，而且功能分解有相当大的任意性，因此需要开发人员有丰富的软件开发经验。
而在ＯＭＴ中这一工作可由一般 开发人员较快地完成。
在对象模型建立后，很容易在这一基础上再导出动态模型和功能模型。
这三个模型一起构成要求解的系统模型。
自顶向下的分解 系统模型建立后的工作就是分解。
与Yourdon方法按功能分解不同，在OMT中通常按服务（Service）来分解。
服务是具有共同目标的相关 功能的集合，如I／O处理、图形处理等。
这一步的分解通常很明确，而这些子系统的进一步分解因有较具体的系统模型为依据，也相对容易。
所以OMT也具有自 顶向下方法的优点，即能有效地控制模块的复杂性，同时避免了Yourdon方法中功能分解的困难和不确定性。
OMT的基础是对象模型 每个对象类由数据结构（属性）和操作（行为）组成，有关的所有数据结构（包括输入、输出数据结构）都成了软件开发的依据。
因此Jackson方法 和PAM中输入、输出数据结构与整个系统之间的鸿沟在OMT中不再存在。
OMT不仅具有Jackson方法和PAM的优点，而且可以应用于大型系统。
更重 要的是，在Jackson方法和PAM方法中，当它们的出发点——输入、输出数据结构（即系统的边界）发生变化时，整个软件必须推倒重来。
但在OMT中系 统边界的改变只是增加或减少一些对象而已，整个系统改动极小。
需求分析彻底 需求分析不彻底是软件失败的主要原因之一。
即使在目前，这一危险依然存在。
传统的软件开发方法不允许在开发过程中用户的需求发生变化，从而导致种种问题。
正是由于这一原 因，人们提出了原型化方法，推出探索原型、实验原型和进化原型，积极鼓励用户改进需求。
在每次改进需求后又形成新的进化原型供用户试用，直到用户基本满意，大大提高了软件的 成功率。
但是它要求软件开发人员能迅速生成这些原型，这就要求有自动生成代码的工具的支持。
OMT彻底解决了这一问题。
因为需求分析过程已与系统模型的形成过程一致，开发人员与用户的讨论是从用户熟悉的具体实例（实体）开始的。
开发人员必须搞清现实系统才能导出系统模型，这就使用户与开发人员之间有了共同的语言，避免了传统需求分析中可能产生的种种问题。
可维护性大大改善 在OMT之前的软件开发方法都是基于功能分解的。
尽管软件工程学在可维护方面作出了极大的努力，使软件的可维护性有较大的改进。
但从本质上讲，基于功能分解的软件是不易 维护的。
因为功能一旦有变化都会使开发的软件系统产生较大的变化，甚至推倒重来。
更严重的是，在这种软件系统中，修改是困难的。
由于种种原因，即使是微小的修改也可能引入 新的错误。
所以传统开发方法很可能会引起软件成本增长失控、软件质量得不到保证等一系列严重问题。
正是OMT才使软件的可维护性有了质的改善。
OMT的基础是目标系统的对象模型，而不是功能的分解。
功能是对象的使用，它依赖于应用的细节，并在开发过程中不断变化。
由于对象是客观存在的，因此当需求变化时对象的性质要比对象的使用更为稳定，从而使建立在对象结构上的软件系统也更为稳定。
更重要的是OMT彻底解决了软件的可维护性。
在OO语言中，子类不仅可以继承父类的属性和行为，而且也可以重载父类的某个行为（虚函数）。
利用这 一特点，我们可以方便地进行功能修改：引入某类的一个子类，对要修改的一些行为（即虚函数或虚方法）进行重载，也就是对它们重新定义。
由于不再在原来的程 序模块中引入修改，所以彻底解决了软件的可修改性，从而也彻底解决了软件的可维护性。
OO技术还提高了软件的可靠性和健壮性。
学习《软件工程》心得和体会
软程学习心得在期的软件工程课程的学习中，我们学习了十一章容。
第一章软软件工程的概念，这一章主要讲解的是一些概念性和基础性的内容，例如软件的概念、特性，软件危机的主要表现，软件工程的概念以及软件生存期、典型生存期模型等等。
第二章软件工程方法与工具，这一章主要对软件工程方法进行介绍，包括三种方法：传统方法、面向对象方法、形式化方法。
还引出了工具UML。
第三章软件需求获取与结构化分析方法，本章详细介绍了需求获取与需求分析阶段的任务以及结构化分析方法，画分层的数据流图、E-R图以及状态图式本节的重点。
第四章结构化分析方法，这一章重点讲解了使用变换型映射方法和事务型映射方法生成初始的模块结构以及模块结构的改进。
第五章编码，这一章重点讲解了编码的风格及规范，还告诉我们编码规范说带来的好处，并告诫我们将来一点要形成好的编码风格。
第六章软件测试方法，本章讲解了软件测试相关的概念及重要性，软件测试与开发各个阶段的关系；还介绍了白盒测试技术以及黑河测试技术。
第七章统一建模语言UML概述，本章详细介绍了UML的基本模式、事物、关系及建模时用到的各种图进行了介绍。
第八章面向对象分析，这一章主要讲解了面向对象分析的3种模型，包括功能模型、静态模型和动态模型。
第九章软件体系结构与设计模式，本章对软件体系结构的基本概念、典型风格等进行了讲解。
第十章面向对象设计，本章的重点是对面向对象分析时建立的对象模型进行调整和细化。
第十一章软件维护，本章主要介绍软件维护的任务、软件维护活动以及软件维护方法进行了介绍。
要学习软件工程，学会如何系统的思考，以及养成良好的编码习惯，想学好软件工程，就必须知道软件工程的目标、过程和原则： 软件工程目标：生产具有正确性、可用性以及开销合宜的产品。
正确性指软件产品达到预期功能的程度。
可用性指软件基本结构、实现及文档为用户可用的程度。
开销合宜是指软件开发、运行的整个开销满足用户要求的程度。
这些目标的实现不论在理论上还是在实践中均存在很多待解决的问题，它们形成了对过程、过程模型及工程方法选取的约束。
软件工程过程：生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。
软件工程过程主要包括开发过程、运作过程、维护过程。
它们覆盖了需求、设计、实现、确认以及维护等活动。
需求活动包括问题分析和需求分析。
问题分析获取需求定义，又称软件需求规约。
需求分析生成功能规约。
设计活动一般包括概要设计和详细设计。
概要设计建立整个软件系统结构，包括子系统、模块以及相关层次的说明、每一模块的接口定义。
详细设计产生程序员可用的模块说明，包括每一模块中数据结构说明及加工描述。
实现活动把设计结果转换为可执行的程序代码。
确认活动贯穿于整个开发过程，实现完成后的确认，保证最终产品满足用户的要求。
维护活动包括使用过程中的扩充、修改与完善。
伴随以上过程，还有管理过程、支持过程、培训过程等。
软件工程的原则是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。
我们学习了详细设计的方法，其原则是过程描述是否易于理解、复审和维护，进而过程描述能够自然地转换成代码，并保证详细设计与代码完全一致。
包括程序流程图、N-S图、PAD图、HIPO图程序流程图：程序流程图又称之为程序框图，它是软件开发者最熟悉的一种算法表达工具。
它独立于任何一种程序设计语言，比较直观和清晰地描述过程的控制流程，易于学习掌握。
在流程图中只能使用下述的五种基本控制结构：顺序型；选择型；while型循环；until型循环；多情况型选择。
N-S图：一种符合结构化程序设计原则的图形描述工具，称为盒图，又称为N-S图。
在N-S图中，为了表示五种基本控制结构，规定了五种图形构件。
顺序型；选择型；WHILE重复型；UNTIL重复型；多分支选择型。
PAD图：它是用结构化程序设计思想表现程序逻辑结构的图形工具。
PAD也设置了五种基本控制结构的图示，并允许递归使用。
HIPO图：HIPO图是由一组IPO图加一张HC图组成。
它是美国IBM公司在软件设计中使用的主要表达工具。
HC图既是层次图，用于表示软件的分层结构。
HC图中的每一个模块，均可用一张IPO图来描述。
IPO 图由输入、处理和输出三个框组成，需要时还可以增加一个数据文件框，这种图形的优点，是能够直观地显示输入—处理—输出三者之间的联系。
还有测试方法:按照测试过程是否在实际应用环境中来分，有静态分析与动态测试。
测试方法有分析方法（包括静态分析法与白盒法）与非分析方法（称黑盒法）。
静态分析技术：不执行被测软件，可对需求分析说明书、软件设计说明书、源程序做结构检查、流程分析、符号执行来找出软件错误。
动态测试技术：当把程序作为一个函数，输入的全体称为函数的定义域，输出的全体称为函数的值域，函数则描述了输入的定义域与输出值域的关系。
还学习了其他很多工具、语言、方法等，虽然不是都学得很透彻，但我相信在今后的学习中一定会慢慢的完善的。
软件工程对于初学者来说，知识基础较薄弱，对一些应用操作、概念、工具方法等理解起来较为困难，要能从整体概念上较好地理解和把握、学好软件工程，不是仅仅把几本专业书籍细致地看几遍，然后上机练习几次就可以成功，学习过程中要注意多看多练要注意结合实际，更要多思考，面对错误不要一范就问，要尝试自己去解决。
但是还要注意什么都学，肯定是什么都学不透的，要集中精力打攻坚战，学习软件工程首先要明白自己的学习目标究竟是什么，根据自己的实际工作出发，有针对性的在相应的学习方向上进行提高，制定出详细的学习规划。
还要注意与其他科目的相辅相成，就像我们在学习面向对象分析的时候要结合大一学习的面向对象及其方法学这一专业科目进行研究拓展;在学习语言时，要看看与C语言的联系，多思多想，把从各个科目学到的知识通汇贯通。
在软件工程的学习中，我了解到了软件并非是一些代码这么简单，在开发软件的过程中，编写代码的工作量其实只占不到所有工程量的30%，而后期的管理和维护更是占了60%到80%之多。
一个完整的项目规划须包括，软件的定义，可行性分析报告，项目开发计划，软件需求说明书，概要设计说明书，详细设计说明书，用户操作手册，测试计划，测试分析报告，开发进度报告，项目开发总结报告，软件维护手册，软件问题报告，软件修改报告，等多个文档，每个文档都要上级验收审查，而文档数量众多，要做好这点真的不是很容易，而恰恰写好文档正能保证完成软件工程其中一个目的的关键，既研究如何用最小的开销做出生存期较长的软件，再加上各个阶段都要进行周密的策划、详细的分工部署和人员安排，且各阶段要据具体情况不断的反复才能达成，所以代码只是开发软件这个浩大的工程的一个小小的过程。
而编码的学习中，我更了解到形成自己独特的规范的编码风格是非常重要的事。
因为这影响到了软件后期繁重的维护，大家都要阅读你的程序，如果你写的程序毫无规范可言，那么别人怎么能读懂你的程序
读不懂程序，维护又从何谈起呢
所以，我们在今后的学习中，一定要注意这方面的培养，在写程序的过程中，要逐步的在规范的基础上形成属于自己的风格，即方便自己的修改，也方便日后他人的阅读。
在学习中，我们还要注意比较三种方法的优缺点，例如：传统方法虽然使软件摆脱了混乱和无序，但其在适应需求变化的方面不够灵活，而且传统方法要么面向行为，要么面向数据，缺乏两者的有机结合。
而面向对象方法的程序设计和问题求解更符合人们日常自然的思维习惯，适合大型、复杂及交互性比较强的系统。
形式化方法则是一中基于形式化数学变换的软件开发方法，它可将系统的规格说明转换为可执行的程序。
在今后的学习中要注意多读书、多思考、多练习、多讨论，不断熟悉书本的基础，并以此为基础将其扩散开来，应用于今后的实践。
不断锻炼自己，向一名合格的程序设计师迈进。
软件工程中面向对象方法学的优点
1与人类习惯的思维方法一致2稳定性好3可重用性好4较易开发大型软件产品5可维护性好
如何理解面向对象的系统分析方法
使用MVC进行项目开发已经有一段时间了，在这段时间里感触最深的就是自己对宏观性面向对象分析方法的缺乏。
面向对象分析是当今流行的系统分析方法之一，下面就谈谈在做项目的过程中我的一些小经验。
在面对简单系统时程序员可以很顺利的提出问题的解决方案，并且一般情况下都是可行的。
这是由于问题域关系简单，所涉及到的内部构造、联系比较容易解释。
而对于当前越来越复杂的系统，其问题域也就显示的越来越复杂，而且内部的关系也不是很容易解释，有些大的系统常常超出了人的解决问题的能力。
在这种情况下，以往的面对过程的解决方法已经不能满足日益增长的复杂系统分析的需要，在这种情况下，面向对象的分析方法就显得尤为总要了。
在面向对象设计领域中，在横向上把问题域分为数个不同的、低耦合、高内聚的问题域，而在纵向上又继续分解各个不同的小的问题域，最后分解为叶节点问题域，从而解决问题。
在面对对象分析方法中，用数个对象间的消息传递来完成整个问题。
下面看一看复杂系统的5个属性：1． 杂性经常是以层次的形式表现出来，复杂系统是由相互关联的子系统组成，而这些子系统又是由他们各自的子系统构成，并由此类推到最底层的基本构件。
2． 对系统中最基本的构件的选择是任意的，而且在很大程度上取决于系统观察者的判断力。
3． 一般而言，各构件内的连接总是要强于构件间的连接。
在从构件的低频动态中分离出高频动态时，这一属性是相当有用的。
这是因为高频动态涉及到各部件的内部结构，而低频动态涉及到构件间的交互。
4． 层次系统通常都是由仅仅少数不同的子系统通过不同的排列组合方式组成。
5． 我们发现正运行的复杂系统总是由以前运行的简单系统演化而来……任何胡乱凑合设计出来的复杂系统都不可能正常运转，也不可能被修补好。
我们必须由运行中的简单系统开始。
对于第一点，正像我上面所说的那样，系统是层次结构的。
能够给一个复杂的系统进行正确的层次分析，才能够保证对系统的正确估计，包括可行性、可维护性、可扩展性……等等。
而且对于日后对该系统进行维护(maintenance)、演化(evolution)、维持(preservation)都能够很好的支持。
对于其中的第二点，强调了观察者的判断力，其实我认为其中也包括观察者的身份角度。
对于一个系统而言，观察者并不是只进行分析设计的工程师，编码阶段的程序员，还应该包括用户等所有这些同该系统有关的人员。
作为不同的人员，对于系统就有不同的观察点、观察角度、身份等特殊因素。
因此在不同身份的人（指参与者）甚至同一身份的人眼中说观察到的系统特性都是不尽相同的。
在大学里大家都接触过透明性的概念，这就是不同观察者所观察角度不同的直观反应。
对于用户来说，基本上底层的操作、算法、通讯对于他们来说都是透明的，他们根本不用理会（其实也不知道）内部用了什么。
而对于一个负责某模块的程序员来说就不会考虑其他模块的实现，对于他们来说其他模块是透明的，他们只需要负责管理好提供的模块接口就OK了。
对于第三点，讲的就是面对对象分析设计的方向，在面对对象分析设计系统时，被分解的各个模块一定要做到高内聚、低耦合。
有良好高内聚、低耦合系统常常会很容易维护，一个地方改动通常不需要牵扯到大的改动，维护行强。
而且对于像VC程序这种更要求效率的程序来说，高内聚、低耦合也可以提高程序的运行期效率，应为对象内部的调用一般情况下会相比模块间的调用占用更少的执行时间，这样将高频动态封装在一个对象内部就会一定程度上提高程序运行期执行效率。
第四点则说明了面向对象程序设计对程序设计可复用性的优点。
在这点中所“层次系统由仅仅少数不同的子系统构成”那么多数子系统在不同的复杂系统中都是能够重复使用的。
比如说建筑一栋大厦和建筑桥梁，虽然两者都是复杂的系统，但是对于其结构中就会有很多相似甚至相同之处，没有必要建筑好大厦回头建筑桥梁的时候又要重新设计每一快砖瓦。
第五点提醒我们在系统设计时，尽量使用以往能够正常运行的子系统来重新构件新的系统。
这一点不仅说明第四点中的复用性，而且也说明了一个我们常常要犯的错误。
就是将并没有通过严格测试的子系统，匆忙的加入到大系统中，这样做不利于对系统的基层，常常引入了其他错误，使得系统频频崩溃，最严重会导致系统的重新分析。
这是我对面向对象的一点心得体会，虽然我们大家在平时工作中所面对的问题、问题域不同，使用的开发工具不同，但是面向对象是一种思维方式，有利于分析、解决问题的一种方法，并不和任何语言挂钩（当然语言对于面向对象特性的支持程度有所不同）。
所以希望各位同事能够尽量使用科学的方法分析解决问题，形成一种设计模式，以供大家互相交流。
软件设计是一种艺术，也是一门工程学。
结构化程序设计和面向对象程序设计的主要特征各是什么
“面程程序设计”、主要是为拉大工程计算或者为拉完个任务而求出结果界面则要求不高 其优点是运行速度快“面向对象程序设计”主要是对各种事物能形象的描述并且模拟在计算机上运行它兼容以上面向过程的好多功能 优点是界面比较好做 缺点执行速度和容量没有上面的快 结构化程序设计 对于以上二者均适合 这只是说明设计是的思路和方法 按照俺自己的理解：前者是按照人们日常做事的顺序来设计语言，即无论做什么事都是按照顺序来执行的，一个个的功能模块都是联系在一起的。
总之：做事是有一个个的动作完成的。
后者则是把我们客观世界里的事物都封装起来，各个事物之间是相互独立的。
做什么事情都是由一个个的事物共同完成的，而不是顺序执行。
总之:做事是由一个个的事物共同完成的。
谁能给我发个面向对象程序设计论文的例文啊
1、软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。
它涉及程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。
在现代社会中，软件应用于多个方面。
典型的软件有电子邮件、嵌入式系统、人机界面、办公套件、操作系统、编译器、数据库、游戏等。
同时，各个行业几乎都有计算机软件的应用，如工业、农业、银行、航空、政府部门等。
这些应用促进了经济和社会的发展，也提高了工作效率和生活效率 。
2、开发流程▪ 需求分析 ▪ 概要设计▪ 详细设计▪ 编码▪ 测试▪ 软件交付▪ 验收▪ 维护3、软件架构（softwarearchitecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。
软件架构是一个系统的草图。
软件架构描述的对象是直接构成系统的抽象组件。
各个组件之间的连接则明确和相对细致地描述组件之间的通讯。
在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。
在面向对象领域中，组件之间的连接通常用接口_(计算机科学)来实现。
软件体系结构是构建计算机软件实践的基础。
与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。
软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。
特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特征。
在“软件构架简介”中，David Garlan 和 Mary Shaw认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。
结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。
但构架不仅是结构；IEEE Working Groupon Architecture 把其定义为“系统在其环境中的最高层概念”。
构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。
它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。
在Rational Unified Process 中，软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。
从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。
一个软件架构师需要有广泛的软件理论知识和相应的经验来事实和管理软件产品的高级设计。
软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。
一般而言，软件系统的架构（Architecture）有两个要素：它是一个软件系统从整体到部分的最高层次的划分。
一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。
详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（Task-flow）。
所谓架构元素，也就是组成系统的核心砖瓦，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。
建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。
建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。
显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。
4、自己写了
学软件工程有前途吗
软件工程专业是计算机领域发展最快的学科分支之一，国家非常重视软件行业的发展，对软件人才的培养给予了非常优惠的政策。
本专业培养掌握计算机软件基本理论知识，熟悉软件开发和管理技术、能够在计算机软件领域中从事软件设计、开发和管理的高级人才。
2、软件工程专业主修课程：软件工程专业除了学习公共基础课外，还将系统学习离散数学、数据结构、算法分析、面向对象程序设计、现代操作系统、数据库原理与实现技术、编译原理、软件工程、软件项目管理、计算机安全等课程，根据学生的兴趣还可以选修一些其它选修课。
3、软件工程专业毕业去向:除考取国内外名牌大学研究生外，主要毕业去向是计算机软件专业公司﹑信息咨询公司﹑以及金融等其它独资、合资企业。
从我周围的例子来看，软件工程学出来，如果编程能力强的话，找到一份4000左右的工作还是可以的，但是，问题就是非常的累，而且竞争比较激烈，如果年龄大了但却不能往上走的话，一直作程序员是比较没有前途的。
不过，如果学的好话，其实和计算机专业差不多，都有机会进比较大的IT公司，我有个学软件的同学就去了IBM，当然，竞争也是很激烈的。
总结起来，我觉得这碗饭并不太好吃，还是看兴趣吧
