阶段性总结（从软件工程到分层架构）

阶段性总结（从软件工程到分层架构）

写在前面

这篇文字将会将2011年下半年的学习内容做个总结，不求细节只为从宏观上理解它们之间的联系以及学习它们的目的。
内容包括软件工程、ＵＭＬ、设计模式、三层架构还有两门语言，C#和VB.NET

软件工程

什么是软件工程

• 软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。(这是维基百科的定义)
• 其实软件工程的目的就是以健全的工程化的原则，在给定的成本和进度前提下有可修改性、有效性、可靠性、可理解性、可维护性、可重用 软件工程性、可适应性、可移植性、可追踪性和可互操作性并且满足用户需求的软件产品。

我对软件工程的理解

• 软件工程是伴随着软件的整个生命周期了存在的，它科学的指导着软件的计划、需求分析、设计编码、测试、运行维护整个生命周期的每一个阶段。
• 软件工程的兴起源于软件危机，人们不得不思考如何保证软件的可靠性，如何保证软件的开发进度等等问题。于是软件工程出现了。研究软件工程的专家学者们陆续提出了100多条关于软件工程的准则或信条。其中最经典的就是软件工程的七条基本原理。
  • 用分阶段的生命周期计划严格管理
  • 坚持进行阶段评审
  • 实行严格的产品控制
  • 采纳现代程序设计技术
  • 结果应能清楚地审查
  • 开发小组的人员应少而精
  • 承认不断改进软件工程实践的必要性
• 软件工程是一种管理软件开发过程的学科，它并不是一门技术，所以很多人觉得学了它跟没学一个样。那是因为我们还没有真正的去管理一个项目，或者没有管理过大的项目。我觉得小的项目可能体现不出软件工程的价值，很多人不懂软件工程也在开发软件。但是越是大的项目越能体现它的价值。软件工程是前人从无数次失败中总结出的软件开发的原则，如果你要成为一个管理者就必然要学好它。如果你只是想当一个小小的编代码的程序员，也请你最起码的学会写文档。

软件工程流程

请到这里下载http://dl.dbank.com/c0opgpvhjr

UML

定义

• UML：统一建模语言。
• 是一种面向对象的建模语言，它是运用统一的、标准化的标记和定义实现对软件系统进行面向对象的描述和建模。

为什么会出现ＵＭＬ

• 正如它的名字一样，UML就是为软件建模而设计的。最开始建模语言并不是统一的，后来为了交流的方便，便对建模语言进行了统一的设计，就出现了UML。
• 就像盖楼房一样，没有人是直接就动手盖的，在这之前必要的一个阶段就是设计，建模。软件开发也是如此，模型的优势是在设计的时候无需考虑代码实现只需考虑需求和业务逻辑。同时ＵＭＬ也使得合作开发成为可能，结合UML模型和文档，任何人都可以开发独立的模块。

UML模型

• 用例图：展示系统外部的各类执行者与系统提供的各种用例之间的关系
• 类图：展示系统中类的静态结构(类是指具有相同属性和行为的对象，类图用来描述系统中各种类之间的静态结构)
• 对象图：是类图的一种实例化图(对象图是对类图的一种实例化)
• <F4>包图：是一种分组机制。在UML1.1版本中，包图不再看作一种独立的模型图)
• 状态图：描述一类对象具有的所有可能的状态及其转移关系(它展示对象所具有的所有可能的状态以及特定事件发生时状态的转移情况)
• 顺序图：展示对象之间的一种动态协作关系(一组对象组成，随时间推移对象之间交换消息的过程，突出时间关系)
• 合作图：从另一个角度展示对象之间的动态协作关系(对象间动态协作关系，突出消息收发关系)
• 活动图：展示系统中各种活动的执行流程(各种活动的执行顺序、执行流程)
• 构件图：展示程序代码的物理结构(描述程序代码的组织结构，各种构件之间的依赖关系)
• 配置图：展示软件在硬件环境中(特别是在分布式及网络环境中)的配置关系(系统中硬件和软件的物理配置情况和系统体系结构)

UML建模过程

1. 需求
   • 首先描述需求，建立用例图。
2. 建立静态模型。
   • 根据需求建立静态模型，以构造系统的结构。建立类图、包图、对象图、构件图、包图、配置图。
3. 描述系统的行为。
   • 建立的模型包括状态图、活动图、顺序图和合作图等四种图。
4. 前两个步骤建立的构成了uML的静态建模机制，第三步构成了ＵＭＬ的动态建模机制。

UML如何描述一个系统

1. 系统的使用实例：从系统外部的操作者的解度描述系统的功能
2. 系统的逻辑结构：描述系统内部的静态结构和动态行为，即从内部描述如何设计实现系统功能
3. 系统的构成：描述系统由哪些程序构件所组成
4. 系统的并发性：描述系统的并发性，强调并发系统中存在的各种通信和同步问题
5. 系统的配置：描述系统的软件和各种硬件设备之间的配置关系

UML总结

• 建模是开发前必不可少的，不要嫌画图麻烦，在脑子里思考模型终究不是可靠的。在画图的过程中可以很好的思考系统的设计。越是大的系统越能体现出建模的重要性。就像盖个鸡窝可能就不需要设计建模，但是盖个摩天大楼不画图建模是不可能的。代码并不是软件开发的全部，写文档，画图都是软件开发的重要的一部分，永远不要只知道写代码。我觉得建模特别能培养全局观念，建模可以让你站在构架师的角度思考软件开发。所以对于学习来说，不管多小的系统都应该去建模，毕竟这是一个锻炼的机会。
• 推荐一个网站 软件工程组织

设计模式

• 设计模式是前人智慧的结晶，我觉得在学习过程中要体会前人的思想，在学习过程中不能只想着如何使用这些模式更重要的是体会为什么这么设计。
• 设计模式无非还是本着高内聚低耦合的面向对象思想，利用面向接口编程总结出的模式。
• 当然学习的话还是要从模仿开始，但是不能止步于模仿。
• 我觉得设计模式里最核心的就是那几大原则。

原则	含义	具体方法
开闭原则	对扩展开发，对修改关闭	多使用抽象类和接口
里氏替换原则	基类可以被子类替换	使用抽象类继承，不使用具体类继承
合成复用原则	要依赖于抽象，不要依赖于具体	针对接口编程，不针对实现编程
接口隔离原则	使用多个隔离的接口，比使用单个接口好	建立最小的接口
迪米特法则	一个软件实体应当尽可能少地与其他实体发生相互作用	通过中间类建立联系
依赖倒置原则	尽量使用合成/聚合，而不是使用继承	尽量使用合成/聚合，而不是使用继承

• 关于设计模式的原则我总结了几篇文章：
• 详见我的博客点击打开链接
• 具体的模式就不总结了，在最初的学习阶段尽量多用设计模式，慢慢才能理解的深刻。

三层架构

• 在使用三层开发之前查了很多资料，但是直到具体开发的过程中，才逐渐明白何为分层，等开发完成才恍然大悟，发现自己做的并不好。
• 关于三层架构的总结详见我的这篇博客( 我对三层的理解 点击打开链接 ）

总结

1. 软件工程、UML、设计模式、三层架构，这些东西都懂了才可以勉强称作进入了软件开发的大门。
2. 这些东西都是软件开发过程中必不可少的，也是相互联系的。
   • 软件工程指导着整个软件开发的过程，存在于软件的整个生命周期。
   • UML在软件开发的初期用于需求分析和设计，在设计完成以后编码阶段作为系统编写的模型，是系统编写工程过程中最重要的资料。
   • 设计模式以及三层架构选择和设计出现在软件开发的设计阶段，在UML中以类图或包图的形式展现出来。
   • 软件开发最难的不是编码阶段而是需求分析和设计阶段，所以使用好UML为系统建立合适的模型就等于是成功了一大半。
3. 无论是软件工程、设计模式还有三层，难免会给人以抓不住的感觉，好像很难理解，即使理解了用的时候也不得心应手。这些东西是软件开发的一个坎，这个坎过不去就很难成为一个优秀的程序员。
4. 如果不想只是成为一个会写代码的代码工人，我们就不得不去学习代码之外的东西，例如软件工程，架构等。这些前人无数个天才总结出的精华，是我们走向更高层次的阶梯。
5. 站在巨人的肩膀上是我想说的全部。