基于.Net平台应用系统设计方法

1.1           设计原则

在进行应用系统的设计时，一般遵循以下几个原则：

Ø         “开放-封闭”原则：系统应该对扩展（extension）开放，同时对修改（change）封闭。

尽量避免重新编译，判断是否遵守这个原则的一个简单实用的标志就是“在做扩展时，软件本身不必重新编译，甚至扩展部分再扩展也不必重新编译”。

Ø         依赖倒转原则：针对抽象（如接口），而不是针对实现编程。

接口是对象能响应的请求的集合。只根据对象的接口来操作对象，它带来的好处是：

a)         客户无须知道他们使用对象的特定类型，只须对象具有客户所期望的接口；

b)         客户无须知道他们使用的对象是如何实现的，只须知道定义接口的抽象类。

这将大大减少子系统实现之间的相互依赖关系。

Ø         合成/聚合复用原则：优先使用对象组合，而不是类继承实现复用机制。

继承破坏了封装性，使得子类和父类具有紧密的依赖关系，且无法在运行时刻改变对象的行为；相反，对象组合要求对象遵守彼此的接口约定，不破坏封装性，对象之间具有较少的依赖关系，可以在运行时动态改变行为。因此，优先使用对象组合有助于我们设计灵活的、可复用的软件。

Ø         客户请求是使对象执行操作的唯一方法，操作又是对象改变内部数据的唯一方法。

对象的内部状态是被封装的，对外部不可见，不能被直接访问。

1.2           具体实现

1.2.1           模块组织

根据需求分析的结果，一般地采纳需求分析的模块划分。明确模块要实现的任务，考察以下问题：

Ø         模块的任务是什么？

Ø         这个模块要与哪几个模块有交互关系，接口如何？

Ø         这个模块以何种形式提供？

Ø         当前构件库中的构件是否能够满足要求，是否可以使用构件库中构件？

1.2.2           确定与其它系统的接口

如果系统与其它系统（如数据库、中间件等）有数据交互，必须明确如下问题：

Ø         在完成什么任务时，要与其它系统发生交互？

Ø         交互数据格式是什么？

Ø         其它系统有没有提供调用的接口？

Ø         如果有，是如何调用？

Ø         如果没有，本系统要做什么样的额外设计？

1.2.3           界面设计

根据需求，把交互的细节加入到用户界面的设计中，包括有效的人机交互所必需的实际显示和输入，如Windows窗口，Web页面。界面设计主要由以下几个方面组成。

（1）        用户按角色分类。

（2）        描述人及其任务的场景。对以上定义角色，列出对以下问题的考虑：什么角色，目的，特点，过程，结束标记。

（3）        界面行为设计:首先，根据人机交互活动的准则，对处理过程自顶而下，逐步分解，设计出可用的操作。其次，排列操作层次，把使用最频繁的操作放在前面，按照用户的工作步骤排列。再次，组织所有操作，利用菜单或工具条或按钮，菜单或功能树的深度不要超过3层。最后，考察是否在完成必须任务的前提下，把用户的操作（如点取，拖动等）减到最少，去除多余的操作。

（4）        完善用户界面:确定界面布局，字型,颜色等。这部分工作也可暂缓,一般由美工完成。

1.2.4           类的发现

   发现类的主要途径是通过从需求规格说明书中抽取关键性的名词和短语，通过寻找应用领域中物理对象、概念实体和外部接口的名词和更大范畴的对象来建立候选类表，对象的属性和候选的超类也在此时标识出来，以形成继承关系的初步层次结构。面向对象的设计过程开始于发现类和对象，它们形成我们的问题领域的词汇，它停止于我们发现没有新的简单的抽象和结构时，或者停止于我们已发现的类和对象可以通过从存在的可重用的软件部件组合实现时。

   通过考虑每个类的目标来发现类的任务，并把任务分配给类。通过在需求规格说明书中找出动词，可以找到软件系统中类的行为；无论何时提到信息，信息必然可以被归入一个类中去。要精炼每个类的用途以详细说明任务，还要找出类与类之间的相互关系。试着均匀地把责任分配给各个类，把行为尽可能的分散给各个类。分配责任要做到系统的负担均匀分布，行为与相关的信息封装在一起，任务由相关的类分担。

 建议采用用例分析，根据用例来发现类。

1.2.4.1                  类的分类
1.2.4.1.1      边界类

   边界是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。常见的边界类有窗口、通信协议、打印机接口、传感器和终端。如果您在使用 GUI 生成器，您就不必将按钮之类的常规接口部件作为单独的边界类来建模。通常，整个窗口就是最精制的边界类对象。边界类还有助于获取那些可能不面向任何对象的 API（例如遗留代码）的接口。 边界类帮助系统接口与系统外部进行交互。边界对象将系统与其外部环境的变更（与其他系统的接口的变更、用户需求的变更等）分隔开，使这些变更不会对系统的其他部分造成影响。

一个系统可能会有多种边界类：

Ø         用户界面类 - 帮助与系统用户进行通信的类。

Ø         系统接口类 - 帮助与其他系统进行通信的类。

Ø         设备接口类 - 为用来监测外部事件的设备（如传感器）提供接口的类。

1.2.4.1.2        控制类

   控制类用于对一个或几个用例所特有的控制行为进行建模。控制类一般独立于环境（不随环境的变更而变更），用于确定用例中的控制逻辑（事件顺序）和事务，在实体类的内部结构或行为发生变更的情况下，几乎不会变更。控制类使用或规定若干实体类的内容，因此需要协调这些实体类的行为。
   控制类能够表示系统的动态行为，处理主要的任务和控制流；由于事件流具有多种状态，因此控制类不是每次被激活后都以同样的方式执行。控制对象（控制类的实例）通常用于控制其他对象，因此它们的行为具有协调性质。控制类将用例的特有行为进行封装。

1.2.4.1.3        实体类

   实体类是用于对必须存储的信息和相关行为建模的类。一个实体对象通常不是某个用例实现所特有的；有时，一个实体对象甚至不专用于系统本身，其属性和关系的值通常由主角指定，执行系统内部任务时也可能要使用实体对象。实体对象的行为可以和其他对象构造型的行为一样复杂，但是，与其他对象不同的是，这种行为与实体对象所代表的现象具有很强的相关性。实体对象是独立于环境（主角）的，实体对象代表了开发中的系统的核心概念。例如，在银行系统中，实体类的典型示例是账户和客户。

1.2.5           确定类与类的继承关系和引用关系

   使用不同的关系类型，如类之间的继承关系，实例关系和使用关系；定义对象之间的结构的动态和静态语义；决定类和对象之间的可见性。设计过程中要不断重复这一步。
   通过检查与每个类相关的任务开始，考虑需要哪些其他类的合作才能完成该类的各项任务，以此来确定合作关系。对每个类可以询问类似下列的问题来找出类之间的相互协作关系：

Ø         这个类需要与谁合作以完成它的任务？

Ø         哪些其他的类需要这个结果？

Ø         谁需要利用这个类的任务？

Ø         这个类会在何种情形下实例化？

Ø         实例化对象是一个还是多个？

1.3           表现方法和工具

   根据软件设计的要求，可以使用的Case工具有Microsoft Visio 2003、Rose等。

1.4           完成设计文档

   基本设计阶段完成后，应完成基本设计书。在基本设计书中，必须说明模块组织。也要说明用户界面设计和与其他系统交互接口设计（如果有，尤其是与数据库的交互）。一般地，也要说明各个模块的核心类和接口，类的主要属性和方法，及其相互关系。
   详细设计阶段完成后，完成详细设计书。在详细设计书中，根据基本设计书的指导，发现所有类，详细说明各个类的方法，属性，以及方法的实现流程。可以采用VISIO文件作为设计文档，要求达到同上述基本设计书相同的详细程度。

1.5 数据库设计
    根据项目需要进行数据库设计.

结束语:纯属个人理解,有不正确的地方请多斧正.