2019年Java软件工程与项目案例教程(四).ppt

《2019年Java软件工程与项目案例教程(四).ppt》由会员分享，可在线阅读，更多相关《2019年Java软件工程与项目案例教程(四).ppt（173页珍藏版）》请在三一文库上搜索。

1、Java软件工程与项目案例教程 （四）,主要内容,1、软件的架构设计 2、软件的详细设计,第4章 系统分析设计,在完成需求分析之后，下一步是系统分析设计。系统分析设计的输入是需求分析所提供的需求规格说明书，输出是概要设计说明书和详细设计说明书。在一般情况下，概要设计说明书由系统设计师负责；详细设计说明书则由高级程序员负责。 这两种设计说明书的差异是：,概要设计说明书既要覆盖需求规格说明书的全部内容，又要作为指导详细设计的依据。因此，它注重于框架上的设计，包括软件系统的总体结构设计、全局数据库（包括数据结构）设计、外部接口设计、功能部件分配设计、部件之间的内部接口设计，它要覆盖需求规格说明书中的

2、功能点列表、性能点列表、接口列表。若为C/S或B/A/S结构设计，则要说明部件运行在网络中的哪一个节点上。,第4章 系统分析设计,详细设计说明书既要覆盖概要设计说明书的全部内容，又要作为指导程序设计和编码的依据。因此，它注重于微观上和框架内的设计，包括各子系统的公用部件实现设计、专用部件实现设计、存储过程实现设计、触发器实现设计、外部接口实现设计、部门角色授权设计、其他详细设计等部件。其他设计包括：登录注册模块设计、信息发布模块设计、菜单模块设计、录入修改模块设计、查询统计模块设计、业务逻辑处理模块设计、报表输出模块设计、前台网站模块设计、后台数据处理模块设计、数据传输与接收模块设计等。 对于

3、简单或熟悉的系统，概要设计和详细设计可以合二而一，形成一份文档（称为设计说明书），进行一次评审，实现一个里程碑，确立一条基线。对于复杂或生疏的系统，概要设计和详细设计必须分开，形成两份文档，进行两次评审，实现两个里程碑，确立两条基线。,4.1软件架构设计（软件概要设计）,当对象、类、构件、组件等概念出现并成熟之后，传统意义上的软件概要设计（又叫软件总体设计或软件系统设计）就逐渐改名为软件架构设计。所以说，软件架构设计就是软件概要设计。软件架构设计工作由架构师来完成，架构师是主导系统全局分析设计和实施、负责软件构架和关键技术决策的角色，他的具体职责为： 领导与协调整个项目中的技术活动（分析、设计

4、与实施等）； 推动主要的技术决策，并最终表达为软件构架描述； 确定和文档化系统中对构架而言意义重大的方面，包括系统的需求、设计、实施和部署等“视图”； 确定设计元素的划分，以及这些主要分组之间的接口； 为技术决策提供规则，平衡各类涉众的不同关注点，化解技术风险，并保证相关决定被有效传达和贯彻； 理解、评价并接收系统需求； 评价和确认软件架构的实现。,4.1软件架构设计（软件概要设计）,软件架构建模 软件架构建模是与软件架构的定义和管理相关的分析、设计、文档化、评审及其他活动。 软件架构建模的目的： （1）捕获早期的设计决策。软件架构是最早的设计决策，它将影响到后续设计、开发和部署，对后期维护和

5、演变也有很大的影响。 （2）捕获软件运行时的环境。 （3）为底层实现提供限制条件。 （4）为开发团队的结构组成提供依据。 （5）设计系统满足可靠性、可维护性及性能等方面的要求。 （6）方便开发团队之间的交流。,4.4.1 软件架构设计基本概念 1软件架构定义 系统是部件的集合，完成一个特定的功能或完成一个功能集合。架构是系统的基本组织形式，描述系统中部件间及部件与环境间的相互关系。架构是指导系统设计和深化的原则。 系统架构是实体、实体属性及实体关系的集合。 软件架构是软件部件、部件属性及客观实体之间相互作用的集合，描述软件系统的基本属性和限制条件。,4.1软件架构设计（软件概要设计）,各种角色

6、的人员都可以使用架构，如项目经理、开发经理、技术总监、系统架构师、测试人员及开发人员。针对不同角色的人员，架构应提供适当的信息，其详细程度也不同。 软件架构的构建是软件设计的基础，它关心的是软件系统中大的方面，如子系统和部件，而不是类和对象。 软件架构应描述以下问题： （1）软件系统中包含了哪些子系统和部件。 （2）每个子系统和部件都完成哪些功能。 （3）子系统和部件对外提供或使用外部的哪些功能。 （4）子系统和部件间的依赖关系，以及对实现和测试的影响。 （5）系统是如何部署的。,软件架构不包括硬件、网格及物理平台的设计。软件架构只描述创建软件所需要的各种环境，而不是详细描述整个系统。,4.1

7、软件架构设计（软件概要设计）,3软件架构视图 架构视图是指从一个特定的视角对系统或系统的一部分进行的描述。架构可以用不同的架构视图进行描述，如逻辑视图用于描述系统功能，进程视图用于描述系统并发，物理视图用于描述系统部署。 架构视图包含名称、涉众、关注点、建模分析规则等信息，描述如何创建和使用架构视图。架构视图描述见图4-1和表4-1。,图4-1 RUP的4+1视图 表4-1 RUP的4+1视图,4.1软件架构设计（软件概要设计）,4.1软件架构设计（软件概要设计）,（2）考察用户界面部署约束 用户界面的部署约束可概括为以下几种： 经常要离线工作的移动电脑； 手持设备（例如PDA、Java手机）

8、； 支持Interner上的任何一种浏览器（包括低速的拨号上网方式和老版本浏览器）； 支持Internet上的较新版本浏览器； 支持内部网上的较新版本浏览器； 支持内部网上的特定浏览器； 内部网上的专用工作站（传统C/S架构的客户端软件）。,4.1.2 软件架构设计步骤 1确定影响整体技术方案的因素 （1）考察用户界面复杂度 用户界面的复杂度可概括为以下几种： 简单数据输入（Simple Data Input）（例如登入界面）； 数据的静态视图（Static View）（例如商品报价列表）； 可定制视图（Customizable View）（例如可自定义查询报告界面）； 数据的动态视图（Dyn

9、amic View）（例如实时运行监控视窗）； 交互式图形（例如CAD系统）。,4.1软件架构设计（软件概要设计）,（3）考察用户的数量和类型 用户的数量和类型可概括为以下几种： 少数的专业用户：关注功能强大，期望量身定制，乐于学习新特性，例如图形制作系统的用户； 组织内的日常使用者：主流用户，关注便利和易用，例如考勤系统用户； 大量的爱好者：对系统的功能有执着的兴趣，有意愿克服使用时遇到各种困难，包括软件本身的缺陷，例如游戏软件的用户； 数量巨大的消费型用户：关注速度和服务感受，例如商业网站的用户。,（4）考察系统接口类型 系统接口类型可概括为以下几种： 数据传输：仅仅为了满足系统间交换数据

10、的需要，例如电子数据交换EDI接口、数据库同步等； 通过协议提供服务：系统依照协议向外提供特定的服务，例如HTTP协议、SOAP（Web Services）协议等； 直接访问系统服务：按照类似于系统内部调用的方式，直接使用系统的方法，例如RPC远程调用/RMI/Corba等。,4.1软件架构设计（软件概要设计）,（5）考察性能和可伸缩性 性能和可伸缩性方面可概括为以下几种： 只读：只有对数据浏览和查询操作，例如股票行情分析系统； 独立的数据更新：有对数据的修改操作，但各用户的修改完全隔离，相互间不存在任何潜在的冲突，例如网上商店各顾客对自己账单的管理； 并发的数据更新：并发用户对数据的修改将相

11、互影响，或者就是更改了同一数据，例如多个用户同时使用航班预定系统预定同一航班的座位。 对于eGov电子政务系统，它的主要特性如下： 用户界面的复杂度：数据的静态显示/可定制视图（Customizable View）； 用户界面的部署约束：基于独立的桌面电脑或专用工作站的浏览器； 用户的数量和类型：组织内的日常使用者，总共几百人； 系统接口类型：通过HTTP协议提供服务，未来可以使用SOAP的SOA技术； 性能：主要是独立的数据更新，有少量并发处理。,4.1软件架构设计（软件概要设计）,2选择软件构架样式（风格） 所谓软件构架样式（风格），是指关于一组软件元素及其关系的元模型（Meta-mode

12、l），这些元素及其关系将基于不同的风格（被元模型所定义）被用来描述目标系统本身。 上述这些元素通常表示为构件（Component）和连接器（Connection），而它们之间的关系则表达为如何组合构件、连接器的约束条件。 传统的软件构架风格可概括为以下几种： （1）数据流系统（Dataflow Systems） 批处理（Batch Sequential） 管道过滤器（Pipes and Filters） （2）调用与返回系统（Call and Return Systems） 主程序与子程序（Main Program andSubroutine） 对象系统（00 Systems） 分层体系系统（

13、Hierarchical Layers）,4.1软件架构设计（软件概要设计）,（3）独立的构件（Independent Components） 通信交互的进程（Communicating Processes） 事件（驱动）系统（Event Systems） 实时系统（Capsule Port Protocol） 在eGov电子政务系统概要设计中，使用分层架构模式。分层模式是一种将系统的行为或功能以层为首要的组织单位来进行分配（划分）的结构模式。一层内的元素只信赖于当前层和之下的相邻层中的其他元素（注意：这并非绝对的要求）。,4.1软件架构设计（软件概要设计）,（1）逻辑层次（Layer） 通常

14、在逻辑上进行垂直的层次（Layer）划分； 关注的是如何将软件构件组织成一种合理的结构，以减少依赖，从而便于管理（支持协同开发）； 逻辑层次划分的标准基于包的设计原则。 （2）物理层级（Tier） 在物理上则进行水平的层级（Tier）划分 关注软件运行时刻的性能及其伸缩性，还有系统级的操作需求（Operational Requirement）； 管理、安全等； 物理层级划分的目标在于确定若干能够满足不同类型软件运行时对系统资源要求的标准配置，各构件部署在这些配置下将获得最优的性能。 我们将eGov电子政务系统应用在职责上至少分成4层：表示层（Presentation Layer）、持久层（Pe

15、rsistence Layer）、业务层（Business Layser）和域模块层（Domain Model Layer）。每个层在功能上都应该是十分明确的，而不应该与其他层混合。每个层要相互独立，通过接口而相互联系。,4.1软件架构设计（软件概要设计）,（3）利用可重用资产 任何软件架构设计都不会从头开始，我们要尽量利用可重用资产。资产类型包括：领域模型，需求规格、构件、模式、Web Services、框架、模板等。我们首先必须理解对这些资产进行考察的上下文，即项目需求、系统的范围、普遍的功能和性能等，之后可以从组织级的资产库或业界资源中搜寻相关的资产，甚至是相似的产品或项目。 在eGov

16、电子政务系统中，使用了设计模式和框架。,（1）设计模式（Design Patterns） 设计模式概念 如果要问起近10年来在计算机软件工程领域所取得的重大成就，那么就不能不提到设计模式（Design Patterns）了。 什么是模式（Pattern）呢？并没有一个很严格的定义。一般说来，模式是指一种从一个一再出现的问题背景中抽象出来的解决问题的固定方案，而这个问题背景不应该是绝对的或者不固定的。很多时候看来不相关的问题，会有相同的问题背景，从而需要应用相同的模式来解决。,4.1软件架构设计（软件概要设计）,模式的概念最开始时是出现在城市建筑领域的。Alexander的一本关于建筑的书中明确

17、地给出了模式的概念，用来解决建筑中的一些问题。后来，这个概念逐渐地被计算机科学所采纳，并在一本广为接受的经典书籍的推动下而流行起来。这本书就是Design Patterns: Elements of Reusable Object-Oriented Software（设计模式：可复用面向对象软件元素），是由4位软件大师合写的（很多时候我们直接用GoF来意指这4位作者，GoF的意思是Gangs of Four，四人帮）。,设计模式是指在软件的建模和设计过程中运用到的模式。设计模式中有很多种方法其实很早就出现了，并且应用得也比较多。但是直到GoF的书出来之前，并没有一种统一的认识。或者说，那时候并

18、没有对模式形成一个概念。这些方法还仅仅是处在经验阶段，并没有能够被系统地整理，形成一种理论。,每一个设计模式都系统地命名，解释和评价了面向对象系统中的一个重要和重复出现的设计。这样，我们只要搞清楚这些设计模式，就可以完全或者说在很大程度上吸收了那些蕴含在模式中的宝贵经验，对面向对象的系统能够有更为完善的了解。更为重要的是，这些模式都可以直接用来指导面向对象系统中至关重要的对象建模问题。如果有相同的问题背景，那么很简单，直接套用这些模式就可以了。这可以省去你很多的工作。,4.1软件架构设计（软件概要设计）, 常用设计模式 在Design Patterns：Elements of Reusable

19、 Object-Orient Software一书中涉及23个模式，被分类为创建型模式、结构型模式和行为模式，分别从对象的创建、对象和对象间的结构组合及对象交互这3个方面为面向对象系统建模方法给予了解析和指导，几乎可以说是包罗万象了。之后，有很多模式陆续出现，比如分析模式、体系结构模式等。 主要的23个设计模式概述如下：,4.1软件架构设计（软件概要设计）,Abstract Fractory 提供一个创建一系列相关或相互依赖对象的接口，而无须制定具体的类。 Adapter 将一个类的接口转换成客户所希望的另外一个接口。Adapter 模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作

20、。 Bridge 将抽象部分与它的实现部分分离，使它们都可以独立地变化。 Builder 将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的 表示。 Chain of Responsibility 解除请求的发送者和接收者之间的耦合，从而使多个对象都有机会处理这个请求。将这些对象连接成一条链来传递该请求，直到有一个对象处理它。 Command 将一个请求封装为一个对象，从而可以使用不同的请求对客户进行参数化，对请求排队或者记录请求日志，以及支持取消操作。 Composite 将对象组合成树形结构以表示“部分-整体”的层次结构。Composite使得客户对单个对象和复合对象的使

21、用具有一致性。 Decorator 动态地给一个对象添加一些额外的职责。,4.1软件架构设计（软件概要设计）,Facade 为子系统中的一组接口提供一个一致的界面。 Factory Method 定义一个用于创建对象的接口，让子类决定将哪个类实例化。 Flyweight 运用共享技术有效地支持大量细粒度（fine grained）的对象。 Interpreter 给定一个语言，定义它的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。 Iterator 提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露该对象的内部表示。 Mediator 用一个中介对象来封装一系列的对象

22、交互。 Memento 在不破坏封装性的前提下，捕捉一个对象的内部状态，并在该对象之外保存这个状态。,4.1软件架构设计（软件概要设计）,Observer 定义对象间的一种一对多的依赖关系，以便当一个对象的状态发生改变时，所有依赖它的对象都得到通知并自动刷新。 Prototype 用原型实例指定创建对象的种类，并且通过拷贝这个原型来创建新的对象。 Proxy 为其他对象提供一个代理以控制对这个对象的访问。 Singleton 保证一个类仅有一个实例，并提供一个访问它的全局访问点。 State 允许一个对象在其内部状态改变时改变它的行为。 Strategy 定义一系列算法，把它们一个个封装起来，

23、并且使它们可相互替换。,4.1软件架构设计（软件概要设计）,Template Method 定义一个操作中的算法框架，而将一些步骤延迟到子类中。 Visitor 表示一个作用于某对象结构中各元素的操作。 （2）软件框架 接下来我们介绍软件框架概念。在介绍软件框架(Framework)之前，首先要明确什么是框架和为什么要使用框架。这要从企业级软件项目面临的挑战谈起，见图4-2。,图4-2 企业级软件项目面临的挑战,4.1软件架构设计（软件概要设计）,我们可以看到，随着项目的规模和复杂性的提高，企业面临着前所未有的各个方面的挑战。根据优先级排序，主要包括高可靠性（High Availability

24、）、低成本（Cost Effective）、可扩展性（Scalability）、投放市场快速性（Time to Market）、安全性（Secure）、性能（Good Performance）、可集成性（Ability to Integrate）及多平台支持（Multi-channel）等。那么，如何面对并且解决这些挑战呢？这需要采用通用的、灵活的、开放的、可扩展的软件框架，由框架来帮助我们解决这些挑战，然后在框架基础之上开发具体的应用系统，如图4-3所示。,图4-3 框架和应用的关系,这种基于框架的软件开发方式和传统的汽车生产方式是很类似的，如图4-4所示。,4.1软件架构设计（软件概要设计

25、）,图4-4 软件开发方式和传统的汽车生产方式,4.1软件架构设计（软件概要设计）,那么到底什么是软件框架呢？框架（Framework）的定义如下： 是应用系统的骨架，将软件开发中反复出现的任务标准化，以可重用的形式提供使用； 大多提供了可执行的具体程序代码，支持迅速地开发出可执行的应用；但也可以是抽象的设计框架，帮助开发出健壮的设计模型； 好的抽象、设计成功的框架，能够大大缩短应用系统开发的周期； 在预制框架上加入定制的构件，可以大量减少编码量，并容易测试； 分别用于垂直和水平应用。 框架具有以下特点： 框架具有很强（大粒度）的可重用性，远远超过了单个类；它是一个功能连贯的类集合，通过相互协

26、作为应用系统提供服务和预制行为； 框架中的不变部分，定义了接口、对象的交互和其他不变量； 框架中的变化部分（应用中的个性）。,4.1软件架构设计（软件概要设计）,一个好的框架定义了开发和集成组件的标准。为了利用、定制或扩展框架服务，通常需要框架的使用者从已有框架类继承相应的子类，以及通过执行子类的重载方法，用户定义的类将会从预定义的框架类获得所需要的消息。这会给我们带来很多好处，包括代码重用性和一致性、对变化的适应性，特别是它能够让开发人员专注于业务逻辑，从而大大缩短了开发时间。图4-5对有没有使用框架对项目开发所需工作量（以人*月来衡量）的影响进行了对比。,4.1软件架构设计（软件概要设计）

27、,图4-5 有没有使用框架对项目开发所需工作量的比较,4.1软件架构设计（软件概要设计）,从图4-5中我们不难看出，对于没有使用框架的项目而言，开发所需的工作量（以Man days即人*月来衡量）会随着项目复杂性的提高（以Business function即业务功能来衡量）以几何级数递增；而对于使用框架的项目而言，开发所需的工作量会随着项目复杂性的提高以代数级数递增。举个例子：假定开发团队人数一样，一个没有使用框架的项目所需的周期为69个月的话，那么同样的项目如果使用框架则只需要35个月。 eGov电子政务系统主要使用了Struts-Spring-Hibernate三个开源框架，如图4-6所示

28、。,图4-6 Struts-Spring-Hibernate三个开源框架,4.1软件架构设计（软件概要设计）, Struts框架 一般来讲，一个典型的Web应用的前端应该是表示层，这里可以使用Struts框架。 下面是Struts所负责的：,管理用户的请求，做出相应的响应； 提供一个流程控制器，委派调用业务逻辑和其他上层处理； 处理异常； 为显示提供一个数据模型； 用户界面的验证。 以下内容，不该在Struts表示层的编码中经常出现，与表示层是无关的。 与数据库直接通信； 与应用程序相关联的业务逻辑及校验； 事务处理。 在表示层引入这些代码，则会带来高耦合和难以维护的后果。,4.1软件架构设计

29、（软件概要设计）, Hibernate框架 典型的Web应用的后端是持久层。开发者总是低估构建持久层框架的挑战性。系统内部的持久层不但需要大量的调试时间，而且还经常因为缺少功能使之变得难以控制。这是持久层的通病。幸运的是，有几个对象/关系映射（Object/Relation Mapping，ORM）开源框架很好地解决了这类问题，尤其是Hibernate。 Hibernate为Java提供了持久化机制和查询服务，它还给已经熟悉SQL和JDBC API的Java开发者创造了一个学习桥梁，使他们学习起来很方便。Hibernate的持久对象是基于POJO（Plain Old Java Object）和

30、Java集合（collections）的。此外，使用Hibernate并不妨碍你正在使用的IDE（Integrated Development Enviroment）。,4.1软件架构设计（软件概要设计）, Spring框架 一个典型Web应用的中间部分是业务层或者服务层。从编码的视角来看，这层是最容易被忽视的一层。我们往往在用户界面层或持久层周围看到这些业务处理的代码，这其实是不正确的。因为它会造成程序代码的高耦合，这样，随着时间的推移，这些代码将很难维护。幸好，针对这一问题有多种框架（Framework）存在。最受欢迎的一个框架是Spring，也被称为轻量级容器（micro contain

31、er），它能让我们很好地把对象搭配起来。这里我们将关注于Spring的依赖注入和面向方面编程。另外，Spring把程序中所涉及的包含业务逻辑和数据存取对象（Data Access Object）的Objects例如Transaction Management Handler（事务管理控制）、Object Factory（对象工厂）、Service Objects（服务组件）都通过XML来配置联系起来。,4.1软件架构设计（软件概要设计）,下面是Spring所负责的： 处理应用程序的业务逻辑和业务校验； 管理事务； 提供与其他层相互作用的接口； 管理业务层级别对象的依赖； 在表示层和持久层之间增

32、加了一个灵活的机制，使得它们不直接联系在一起； 通过揭示从表示层到业务层之间的上下文（Context）来得到业务逻辑（Business Services）； 管理程序的执行（从业务层到持久层）。,3子系统的划分和接口定义 （1）为什么要划分子系统和设计模型组织结构 设计模型组织结构的最终目标是支持个人或团队进行独立的开发。 层次、包的划分，为团队的分工协作提供最直接的依据。 子系统的划分，使得团队成员之间的依赖关系最小化，从而支持并行开发（方便构建）。 为方便测试而进行划分，包、子系统及其接口的定义，应当支持被独立地加以测试。,4.1软件架构设计（软件概要设计）,（2）使用子系统的好处 子系统

33、可以用来将系统划分成相互独立的部件，它们将可以： 独立地被定制（Ordered）、配置（Configured）或交付（Delivered）； 在接口保持不变的情况下，被独立开发； 跨越一系列分布式计算节点来被独立部署； 被独立地变更而不打破系统其他部分。 子系统也可以用来： 将系统中访问关键资源而需要有安全限制的部分分割出来，成为独立控制的单元； 在设计中代表已有产品或外部系统（例如构件）。,（3）识别系统的接口（Interface） 目标：基于职责来识别系统的接口 步骤： 为所有的子系统识别一组候选的接口； 考察接口间的相似性； 定义接口间的依赖关系； 将接口对应到子系统； 定义接口规定的行

34、为； 将接口打包。,4.1软件架构设计（软件概要设计）,（4）设计接口 命名接口：接口名称要反映系统中的角色。 描述接口：接口描述要传达职责信息。 定义操作：名称应当反映操作的结果，描述操作做了什么、所有的参数和结果。 文档化接口：打包支持信息，如序列图、状态图、测试计划等。,4优化设计（包括去冗余和提高可重用性） （1）最小冗余设计及其优势 系统设计的优劣可以通过最终实施编码的冗余程度来衡量。 冗余程度小的设计，其优势有： 减小系统的物理尺寸（即代码量），降低实施的成本； 缩小因变更而引起的更改范围，降低维护成本； 简化系统的复杂度，便于理解和扩展。,4.1软件架构设计（软件概要设计）,（2

35、）去冗余途径 去冗余是通过抽取共性元素，从而在结构上保持组成元素的（形式）单一存在。去冗余途径包括划分、泛化、模板化、元层次化和面向方面编程5种。 通过划分而去冗余 将系统划分为职责更为集中和明确的模块（例如对象、子系统、子程序等），相同的行为将通过调用一个模块来实现，从而避免重复的组成元素分散于系统各处； 在结构化范型下，主要将重复代码抽取出来重构为子程序、子函数； 在面向对象范型下，主要方式有：,识别对象，并将职责分配给合适的对象，其他对象将委托它来完成对应的行为； 为对象定义通用的原语方法，而在更高级别通过调用它们而实现粒度更大的职责； 让对象通过组合来复用已有对象的服务。,4.1软件架

36、构设计（软件概要设计）, 通过泛化而去冗余 将共性的行为抽取出来，专门在一处单独定义；所有类似行为的实现，将关注于那些个性方面，共性方面直接从前述之处继承，而不再重复实现； 在结构化范型下，可以在主函数中定义一个统一（共性）的执行过程，然后使用钩子函数等途径来回调个性化的扩展函数； 在面向对象范型下，父类实现共性的行为，并定义一些可重载的方法，在父方法中调用，然后让子类重载它们以便扩展个性行为（参考模板方法模式）； 泛化的去冗余途径，主要是避免重复实现一些较大粒度框架性的行为，小粒度的行为复用应当使用前述的划分途径。 通过模板化（泛型化）而去冗余 使用模板来定义共性的结构和行为，并留出某些变量

37、，这些变量对模板而言是行为敏感的；在具体的应用场景中，通过引入不同的参数变量，从而导出众多个性化的行为组合； 在结构化范型下，将一组类似的行为并入一个函数，而通过传入参数控制不同行为的组合； 在面向对象范型下，主要有模板类、模板函数等方式； 模板化去冗余途径，形式主义是一种结构（引入变量）与（模板）行为的二元组合，其实质是避免行为的重复定义。,4.1软件架构设计（软件概要设计）, 通过元层次化而去冗余 利用元数据来表达某种领域行为（“元”意味着更高层次的，即用更少的篇幅却能表达更多、更复杂的语义），然后使用相关机制来实例化，从而实现元数据所定义的行为内容（例如，工作流引擎对某流程定义的解释执行

38、）； 元数据驱动（meta data driven）的主要方式有： 声明规格（declarative specification）通过代码生成器将高层定义转换为具体的最终代码实现，需要使用编译器进行事前转换； 指令规格（imperative specification）元数据定义的行为，在运行时刻被专门的机制解释执行，不需要事前转换。 通过面向方面编程（AOP）来去冗余 将分散在系统代码之间、行使类似职能的代码抽取出来，作为一个方面（aspect），集中到一块来处理（这些职能包括：日志记录、权限验证、资源的释放、异常处理等），避免类似代码到处重复泛滥； 面向方面编程（AOP）技术的提出，就是为

39、了解决前述所有途径都难以解决的、类似职能代码横向交错（cross-cut）的冗余问题；,4.1软件架构设计（软件概要设计）,AOP技术将系统中随处可见的行为，抽象成若干个行为方面，然后将它们与主体对象的固有行为结合在一起，实现了纷繁复杂的多样系统行为。 其中，构架分析设计所面对的通用问题，往往可以抽象为方面，包括： 选择候选层级（Tier）； 如何保持会话状态； 确定共同的用户界面交互机制； 确定共同的数据存取机制（OR Mapping）； 解决并发和同步冲突； 支持事务处理； 接口的定位与实例化机制（常用途径：名字服务）； 设计统一的异常机制；,4.1软件架构设计（软件概要设计）,安全机制的

40、实施。 这里我们特别介绍一下AOP与分析设计的关系。 从方法论的角度来看，区分分析与设计的终极目的在于简化开发，分析关注目标系统所处理的领域问题（或称业务功能），而设计要关注系统完成上述领域功能时，在性能、部署等方面应当满足的动作需求（非功能需求）。 AOP（Aspect Oriented Programming，面向方面编程）正是一种实施层面的技术，它直接在代码级别上，支持将处理动作需求方面的代码与处理业务逻辑的代码相隔离，使得开发人员将注意力集中于核心的业务逻辑上； AOP、MDA的模型转换技术等都是支持分析与设计分离方法论的绝佳途径。 关于AOP的详细介绍，有兴趣的读者可以参考Sprin

41、g部分的内容。,概要设计文档 eGov电子政务系统概要设计说明书 1 引言 1.1 编写目的 此文档对eGov电子政务系统概要设计进行说明。 预期的读者有（甲方）的需求提供者、项目负责人、相关技术人员等，北京亚思晟商务科技有限公司（乙方）的项目组成员，包括项目经理、客户经理、分析设计/开发/测试等人员。,4.1软件架构设计（软件概要设计）,1.2 背景 eGov电子政务系统是基于互联网的应用软件。在研究中心的网上能了解到已公开发布的不同栏目（如新闻，通知等）的内容，各部门可以发表栏目内容（如新闻、通知等），有关负责人对需要发布的内容进行审批。其中，有的栏目（如新闻）必须经过审批才能发布，有的栏

42、目（如通知）则不需要审批就能发布。系统管理人员对用户及其权限进行管理。 1.3 定义 无 1.4 参考资料 eGov电子政务系统需求规格说明书 eGov电子政务系统详细设计说明书,4.1软件架构设计（软件概要设计）,2 总体设计 2.1 需求规定 eGov电子政务系统按模块可以分成3部分：一是一般用户浏览的内容管理模块；二是系统管理；三是内容和审核管理。而它们各自又由具体的小模块组成。具体需求见eGov电子政务系统需求规格说明书。 2.2 运行环境 操作系统：Windows 2003/XP、Linux； Web服务器：Tomcat 5.5以上； 数据库服务器：MySQL 5.0以上，能够处理数

43、据并发访问，访问回馈时间短。 2.3 基本设计概念 1系统整体方案 （1）eGov电子政务系统主要特性 我们从以下5个方面确定目标系统特性： 用户界面的复杂度：数据的静态显示/可定制视图（Customizable View）； 用户界面的部署约束：基于独立的桌面电脑或专用工作站的浏览器； 用户的数量和类型：组织内的日常使用者，总共几百人； 系统接口类型：通过HTTP协议提供服务，未来可以使用SOAP的SOA技术； 性能：主要是独立的数据更新，有少量并发处理。,4.1软件架构设计（软件概要设计）,从上述特性可以判断eGov电子政务系统属于中大型项目，因此我们使用基于Struts-Spring-H

44、ibernate框架的分层架构设计方案。 （2）架构分层 在eGov电子政务系统架构设计中，我们使用分层模式。具体地说，我们将eGov电子政务系统应用在职责上分成3层：表示层（Presentation Layer）、持久层（Persistence Layer）和业务层（Business Layer）。每个层在功能上都应该是十分明确的，而不应该与其他层混合。每个层要相互独立，通过一个通信接口而相互联系。 （3）模式和框架使用 在分层设计基础上，我们将使用设计模式和框架，这些是可以重用的资产。 MVC模式,4.1软件架构设计（软件概要设计）,图1,MVC（Model-View-Controller

45、，模型-视图-控制器）模式就是一种很常见的设计模式， 其结构图如图1所示。,4.1软件架构设计（软件概要设计）,Model端 在MVC模式中，模型是执行某些任务的代码，而这部分代码并没有任何逻辑决定用户端的表示方法。Model只有纯粹的功能性接口，也就是一系列的公共方法，通过这些公共方法，便可以取得模型端的所有功能。 View端 在MVC模式中，一个Model可以有几个View端，而实际上多个View端是使用MVC的原始动机。使用MVC模式可以允许多于一个的View端存在，并可以在需要时动态注册所需要的View。 Controller端 MVC模式的视图端是与MVC的控制器端结合使用的。当用户

46、端与相应的视图发生交互时，用户可以通过视图更新模型的状态，而这种更新是通过控制器端进行的。控制器端通过调用模型端的方法更改其状态值。与此同时，控制器端会通知所有注册了的视图刷新用户界面。,4.1软件架构设计（软件概要设计）,那么，使用MVC模式有哪些优点呢？MVC通过以下3种方式消除与用户接口和面向对象的设计有关的绝大部分困难。 控制器通过一个状态机跟踪和处理面向操作的用户事件。这允许控制器在必要时创建和破坏来自模型的对象，并且将面向操作的拓扑结构与面向对象的设计隔离开来。这个隔离有助于防止面向对象的设计走向歧途。 MVC将用户接口与面向对象的模型分开。这允许同样的模型不用修改就可使用许多不同

47、的界面显示方式。除此之外，如果模型更新由控制器完成，那么界面就可以跨应用再使用。,MVC允许应用的用户接口进行大的变化而不影响模型。每个用户接口的变化将只需要对控制器进行修改，但是控制器包含很少的实际行为，那么它是很容易修改的。 面向对象的设计人员在将一个可视化接口添加到一个面向对象的设计中时必须非常小心，因为可视化接口的面向操作的拓扑结构可以大大增加设计的复杂性。 MVC设计允许一个开发者将一个好的面向对象的设计与用户接口隔离开来，允许在同样的模型中容易地使用多个接口，并且允许在实现阶段对接口作大的修改而不需要对相应的模型进行修改。,4.1软件架构设计（软件概要设计）, 框架 根据项目特点，

48、我们使用3种开源框架：表示层用Struts；业务层用Spring；而持久层则用Hibernate，如图2所示。 表示层 一般来讲，一个典型的Web应用的前端应该是表示层，这里可以使用Struts框架。,图2,4.1软件架构设计（软件概要设计）,下面是Struts所负责的： 管理用户的请求，做出相应的响应； 提供一个流程控制器，委派调用业务逻辑和其他上层处理； 处理异常； 为显示提供一个数据模型； 用户界面的验证。 以下内容，不该在Struts表示层的编码中经常出现，与表示层是无关的。 与数据库直接通信； 与应用程序相关联的业务逻辑及校验； 事务处理。 在表示层引入这些代码，则会带来高耦合和难以

49、维护的后果。 持久层 典型的Web应用的后端是持久层。开发者总是低估构建持久层框架的挑战性。系统内部的持久层不但需要大量的调试时间，而且还经常因为缺少功能使之变得难以控制。这是持久层的通病。幸运的是，有几个对象/关系映射（Object/Relation Mapping，ORM）开源框架很好地解决了这类问题，尤其是Hibernate。Hibernate为Java提供了持久化机制和查询服务，它还给已经熟悉SQL和JDBC API的Java开发者创造了一个学习桥梁，使他们学习起来很方便。Hibernate的持久对象是基于POJO（Plain Old Java Object）和Java集合（collections）的。此外，使用Hibernate并不妨碍你正在使用的IDE（Integrated Development Enviroment）。,4.1软件架构设计（软件概要设计）,下面是Hibernate所负责的： 如何查询对象的相关信息。 Hibernate是通过一个面向对象的查询语言（HQL）或者正则表达的API来完