IT伯伯

怎样才能开发出好的软件呢？首先软件工程的思想要贯穿软件开发、运行、维护的整个过程，利用分层的思想使得软件的生命力更强，灵活性更好，便于维护，也便于合作开发，当然采用合作开发是为了提高效率，想要合作开发就要有统一的建模。在开发过程中适当的加入设计模式可以提高效率。

首先来说一下软件工程，软件工程就是把软件的开发工程化，在给定成本、进度的前提下，开发出具有可修改性、有效性、可靠性、可理解性、可维护性、可重用性、可适应性、可移植性并且满足用户需求的软件产品。软件工程主要有一下内容：需求、设计、编码、测试。其过程中需要产生以下一些文档：可行性研究报告、软件需求说明书、数据库设计说明书、概要设计说明书、详细设计说明书、用户手册、测试分析报告等。这些文档贯穿软件开发的整个过程。

那么这些文档里都是些什么内容呢？要想系统的结构表达的更清楚是不是图表更有表现力呢？所以UML图（统一建模语言）就成为了文档的得力助手，画UML图的工具有很多，Rational Rose是一个应用比较广泛而且功能比较强大的工具。UML有九种图，分别从不同的侧面不同的粒度描述系统的结构流程。

1.                用例图描述角色以及角色与用例之间的连接关系，说明的是谁要使用系统，以及他们使用该系统可以做些什么，主要用在需求说明书中来表明系统需要实现的主要功能；

2.                包图描述了系统的整体架构，每一个包是一个程序集，用在概要设计说明书中；

3.                类图描述系统中的类以及各个类之间的静态关系视图，也用在概要设计说明书中表示各个类之间的调用关系；

4.                活动图描述每个用例进行的活动以及活动之间的关系，主要用在概要设计说明书中用来表示整个系统的运行流程；

5.                状态图描述类的对象所有可能的状态，以及事件发生时状态的转移条件，是对类图的补充；

6.                交互图包括协作图和顺序图，这两种图都是表达的对象与对象之间的交互，顺序图表现的是消息如何在对象之间被发送和接收的，主要强调时间和顺序，而协作图显示对象间的动态合作关系，主要强调上下级之间的关系，交互图用在详细设计说明书中；

7.                图描述代码构件的物理结构以及各种构件之间的依赖关系；

8.                部署图用来建模系统的物理部署。例如计算机和设备，以及它们是如何连接的；

系统架构就是系统的骨骼，如果骨骼没有设计好，做出来的软件也会是畸形，怎样的架构才是合理的，怎样的架构才能造就一个健康的软件，那么健康的软件是什么样的？首先要满足用户需求，其次要有可修改性、灵活性、可维护性，也就是当用户需求改变时，尽量少更改已经封装好的东西，而且还要达到目的，这样的要求传统的面向过程的编码方式是很难实现的，而MVC三层架构就能实现这一切，V代表界面层，C代表业务逻辑层，M代表数据访问层。这个三层架构只是宏观意义上的三层，其实根据系统架构的需要可以分为更多层。除了这三层外还有一层是实体层，实体层对应着数据库中的表，每一张表映射为一个实体，下面介绍一下三层架构具体是什么样的：

1.      界面层只负责与用户交互，用户输入信息，在界面进行基本验证（是否为空、是否是数字等）将数据传到业务逻辑层，经过业务逻辑层处理后返回给界面层信息，界面将信息显示给用户。

2.      业务逻辑层负责接受界面的数据，进行业务处理（包括一些逻辑判断，计算等），需要数据库中的数据就调用数据访问层的方法，业务处理后给界面返回数据。

3.      数据访问层主要是一些操作数据库的类，查出的数据返回到业务逻辑层。

4.      实体层中每一个实体对应着数据库中的每一张表，实体类作为参数在三层之间传递。

下面以添加用户为例：

界面层（UI）：当用户按下添加按钮后，首先检查输入框中的数据是否合法，然后将数据赋值给用户实体中的每个字段，调用B层的添加用户方法，将用户实体作为参数传递。

业务逻辑层（Bll）：首先判断界面传进来的用户实体是否已经存在（调用D层操作用户表中的检查用户方法），如果已经存在则抛出异常，如果不存在则向用户表中插入该用户实体（调用D层的操作用户表中的插入方法）。

数据访问层（Dal）：对数据库的操作，与数据库的连接字符串放在app.configer文件中，方便更换。其中的两个方法分别是检查数据库中是否存在某个用户，想数据库中用户表中插入一条记录。

实体层：表中的字段都是私有的属性，他们的值的读写是通过属性过程来完成的。

三层架构的基本形式在上面中已经讲过了，为了提高程序可维护性、可扩展性、可复用性、灵活性，可以在其中加入设计模式，设计模式有23种，这些设计模式可以分为三大类：创建型模式、结构型模式、行为型模式。下面就分别介绍一下这些设计模式的基本结构、使用的好处以及使用场合

创建型模式有抽象工厂模式、建造者模式、工厂方法、原型模式、单例模式。

抽象工厂模式：

这个设计模式客户端只与抽象工厂以及抽象产品打交道，而与具体的实现是隔离的，主要用在可能变更的地方，比如更换数据库。当需要不同类型的产品的话直接添加一个工厂和产生的产品即可。

建造者模式：

这个设计模式主要用于构造一个产品时，使所有的产品都有一些必须的部件，抽象建造者中定义了抽象的建造方法，具体的建造者继承抽象建造者时就必须实现抽象建造者中的所有组装方法，由于建造者隐藏了产品是如何组装的，所有如果想要改变一个产品的内部组装，只需要再定义一个具体建造者就可以了。

工厂方法模式：

          工厂方法模式定义了一个用于创建对象的接口（抽象工厂类），让子类决定实例化那个类，它使一个类的实例化延迟到其子类（具体工厂）。它与抽象工厂模式的区别是：抽象工厂模式中的具体工厂用于生产一个品牌的所有产品，而工厂方法模式中的具体工厂用于生产具有相同功能的一类产品。

原型模式：

当创建多个类似的对象时就可以用原型模式，原型模式的关键点就在于Clone（）方法，它使得相同的对象或类似的对象可以直接Clone，对于与原来对象不同的属性可以重新定义，但是大体上还是不会变的，如果更改的很多的话就要考虑是不是这个设计模式用的不恰当。用这个设计模式隐藏了对象的创建细节，而且不用重新初始化对象，对性能又是一个大的提高。

单例模式：

这个模式是我认为最简单的一个模式，之所以这么说是因为它简单到都不用画图来表示（开玩笑啦~~），这个类只有一点：就是保证一个类只有一个实例，并且提供一个访问它的全局访问点。那怎样才能做到这一点呢？办法就是让类自身保存它的唯一实例，这个类可以保证没有其他实例可以被创建，并且它可以提供一个访问该实例的方法。也就是说这个类中的构造方法设置为私有，不让外界利用new创建该类的实例，然后编写一个静态方法，这个方法保证这个类只有一个实例（如果实例不存在就创建一个实例，然后就返回实例）。