基于UML和ASP.NET实现三层B/S结构系统开发(1)

    架构设计是软件开发的基础，并往往决定一个项目的成败。三层结构是目前流行的架构设计模式，它是在由Buschmann等提出的“层模式”^[1]基础上发展起来的，由表示层、业务逻辑层和数据访问层三个层次结构组成。它通过分解来管理问题的复杂性，同时还可以有效地重复使用业务逻辑并保留与昂贵资源（如数据库）的重要连接^[2,3]。

    基于ASP.NET能够充分发挥其完全面向对象的技术特点，实现三层结构B/S系统架构，从而提高开发效率，增强系统的可维护性和扩展性。本文结合一个“学生成绩管理系统”的开发，研究如何基于UML进行三层B/S结构的系统建模，及其在ASP.NET下的应用实现。

    架构设计是非常高级的设计，也是系统设计的关键，主要是定义和说明包（子系统），以及包与包之间的相互依赖与通信机制。系统构架模型的合理与否将决定系统的可维护性、扩展性和开发效率。

    包通常所需要处理的是要么是一个具体的功能区域（业务逻辑），要么是一个具体的技术区域（技术逻辑）。业务逻辑主要考虑的是对系统业务功能的实现，而技术逻辑则是进一步考虑用户界面、数据库或通信机制等形成的技术方案。把技术逻辑和业务逻辑区分开来是极其重要的，这是为了当修改程序的某一部分时不会对另一部分产生影响，更加便于进行“复用”，同时易于应对来自业务逻辑的变更需求。

    三层结构是一种成熟、简单并得到普遍应用的应用程序架构，它将应用程序结构划分三层独立的包，包括用户表示层、业务逻辑层、数据访问层。其中将实现人机界面的所有表单和组件放在表示层，将所有业务规则和逻辑的实现封装在负责业务逻辑组件中，将所有和数据库的交互封装在数据访问组件中。其结构如下图1所示：

图1 三层结构示意图

    三层结构是一种严格分层方法，即数据访问层只能被业务逻辑层访问，业务逻辑层只能被表示层访问，用户通过表示层将请求传送给业务逻辑层，业务逻辑层完成相关业务规则和逻辑，并通过数据访问层访问数据库获得数据，然后按照相反的顺序依次返回将数据显示在表示层。

    下面通过一个学生管理系统的开发，说明三层B/S结构系统从UML建模到基于ASP.NET进行实现的完整开发过程，UML建模工具采用的是Rational Rose。

    软件需求分析是系统开发的第一步也是最重要的一个环节，其基本任务是准确地回答“系统做什么？”这个问题，这需要在对用户需求进行充分调研的基础上，深入理解并描述出软件的功能、性能、接口等方面的需求，可以使用UML建模作为需求分析和系统设计的有效方法。

    分析的目的是为了获得和描述系统中所有的要求，因此分析阶段是一种典型的与用户或客户合作的过程，通常由开发人员同用户或客户共同完成。在这个阶段，开发人员不应该考虑代码或程序实现的细节，而应该把精力放在对现有业务逻辑的理解上，通过与用户之间的充分沟通，逐步理解并描述出得到用户确认的系统模型，包括用例模型和领域（domain，系统中关键的类）模型。

2.1.1 用例模型

    软件开发人员在对用户进行需求调研的过程中，用户往往并不能立即准确描述出未来系统应该提供一些什么样的功能。因此，需要开发人员理解和分析需求，并将系统应该具有的功能通过用例图直观的描述出来，方便用户理解并做出评判，开发人员从而可以根据用户的反馈不断调整用例模型，直至完全正确、充分描述清楚系统功能。

    用例建模主要是分离出系统的活动参与者(Actor)和用例(Use Case)，用例是指对系统提供的功能的一种描述，而活动参与者是那些可能使用这些用例的人或外部系统，通过用例图可以描述出系统外部的执行者、系统的用例，以及它们之间的联系。本学生管理系统的用例图见图2。

用例模型还需要进一步对每个用例进行详细描述，进一步说明用例的名称、基本事件流和备选事件流、前置条件和后置条件等，并形成文档。限于篇幅，这里就不多说了。

2.1.2 领域建模

    分析过程中还要详细地列举领域(domain ，系统中关键的类)，为了进行领域分析，需要充分理解用例模型，也可以与用户及领域专家组织一次集体研讨会谈，尝试找出所有必须处理的关键概念以及它们之间的相互关系，并最终分析出域类图。下图3为本系统的域类图。

    需要强调的是：在本阶段，对领域进行分析的类图还是处于“草图”状态。定义的操作和属性不是最后的版本，只是在本阶段看来比较合适。后期将通过动态行为分析不断得出新的操作，这是一个逐步完善和发展的过程。

    系统设计的目的是产生一个可用的、完整的解决方案，并且能够比较容易地将方案转换成程序代码。这个阶段在三层结构的架构设计模型基础上，将考虑所有的实现技术问题，对分析阶段的模型进行扩展和细化，分析阶段定义的类进一步扩充，定义新的类来处理技术方面的问题，并形成最后的UML模型。

    推动不断进行详细设计的方法是对每个用例进行动态建模，描述如何通过类图中的对象协作实现用例中的功能，由于一开始对系统的认识是很不够的，前面建立的类往往随着动态建模的深入，发现存在缺陷或不够完整，需要对分析中得到的域类图进行不断修正和调整，扩展形成业务逻辑包。同时，随着对用户界面、数据库访问等技术实现的深入建模，不断建立新的用户界面类（如窗体、控件）和数据访问类，形成用户界面包和数据访问包。

     本学生管理系统经过详细设计后，在域类图基础上进行扩展后形成的业务逻辑包类图如下图4所示。

图3 域类图

图4 业务逻辑包类图