软件构架文档

软件构架文档软件构架文档 缺陷管理系统缺陷管理系统 2.0 中国软件架构师网 版权所有（C） 修订历史修订历史 日日 期期版本版本作作 者者审审 核核说说 明明 2006-9-2810胡协刚 初稿 目目 录录 1简介简介.6 1.1目的目的.6 1.2范围范围.6 1.3术语词汇表术语词汇表.6 1.4参考资料参考资料.6 2构架表示方式构架表示方式.6 3构架设计目标与约束构架设计目标与约束.7 3.1关键功能需求关键功能需求.7 3.2关键质量要求关键质量要求.7 3.2.1有效性有效性.7 3.2.2性能性能.7 3.2.3性能可扩展性能可扩展.7 3.2.4功能可扩展功能可扩展.7 3.3开发策略开发策略.7 3.3.1软件复用策略软件复用策略.7 3.3.2使用开源构件使用开源构件.7 3.3.3使用商业构件使用商业构件.8 3.4其它设计约束其它设计约束.8 4用用例视图例视图.8 4.1概述概述.8 4.2关键用例关键用例.9 4.2.1关键的系统主角（关键的系统主角（ACTOR）.9 4.2.2关键的系统用例关键的系统用例.10 4.3关键系统用例简述关键系统用例简述.10 4.3.1录入缺陷的基本流录入缺陷的基本流.11 5逻辑视图逻辑视图.12 5.1概述概述.12 5.2系统层次结构模型系统层次结构模型.13 5.3主要的设计包和子系统主要的设计包和子系统.14 5.3.1应用层应用层.14 5.3.2业务逻辑层业务逻辑层.16 5.3.3业务实体层业务实体层.18 5.3.4集成层集成层.19 5.4架构机制（架构机制（ARCHITECTURAL MECHANISM） .19 5.4.1日志机制日志机制（LOG MECHANISM）.19 5.4.2实体持久化（实体持久化（ENTITY PERSISTENCE MECHANISM）.20 5.5关键用例实现描述关键用例实现描述.22 5.5.1录入和编辑缺陷用例实现录入和编辑缺陷用例实现.22 6进程视图进程视图.24 6.1概述概述.24 6.2总体进程结构总体进程结构.25 7部署视图部署视图.26 7.1概述概述.26 7.2部署方案部署方案.26 7.3CLIENT & MOBILE CLIENT.26 7.4WEBSERVER.26 7.5DBSERVER.26 8实施视图实施视图.27 8.1概述概述.27 8.2实施模型总体结构实施模型总体结构.27 8.3WEBROOT 结构结构.27 8.4SRC 包结构包结构.28 软件构架文档软件构架文档 BugManager 缺陷管理系统缺陷管理系统 2.0 1 11 1 简介简介 1.1 目的目的 本文档全面与系统地表述目标软件系统的构架，并通过使用多种视图来从不同角度描 述系统的各个主要方面，以满足相关涉众（客户、设计人员等）对目标系统的不同关注焦 点。 本文档记录并表述了架构师对系统构架方面做出的重要决策；项目经理将根据构架定 义的构件结构制定项目的开发计划；设计员将据此进行各构件的详细设计；测试设计员按 照构架设计系统的总体测试框架；另外构架文档还用于指导各构件的实施、集成及测试。 1.2 范围范围 本文档适用于“BugManager 缺陷管理系统 2 代”的总体应用构架。 1.3 术语词汇表术语词汇表 此处未完成 1.4 参考资料参考资料 客诉管理制度 前景文档 2 22 2 构架表示方式构架表示方式 本文档以一系列的视图（View）来表示系统的软件构架，主要包括用例视图、逻辑视 图、进程视图、部署视图、实施视图（即 RUP 推荐的 4+1 视图）等；每个视图拥有一个或 多个模型（Model） （例如逻辑视图包含分析模型、设计模型和数据模型等） ；并围绕相关视 图来描述系统的基本结构、组成机制与工作原理等。 本文档还将系统的构架机制描述也放在了逻辑视图之下。 本文档主要使用统一建模语言（UML）来充当相关模型的表达语言；主要图表 （Diagram）引用自目标系统的 Rose Model。 3 33 3 构架设计目标与约束构架设计目标与约束 描述构架设计必须满足的关键系统功能需求和质量约束，这些功能需求和质量要求对 软件构架有重大的影响，并决定了构架的设计。 本节同时还列明影响构架的其他相关因素，如软件的复用策略、使用商业构件、设计 与实施的策略等。 3.1 关键功能需求关键功能需求 跨地域的系统外部用户通过 Internet 网来使用系统的功能。 内部用户、系统管理员在安全性较高的内网中使用系统的功能。 消息通知系统是目标系统为了实现相关功能而需要进行协作的一个外部系统，它能够 向用户发送 email，或者发送短消息。 3.2 关键质量要求关键质量要求 3.2.1 3.2.1 有效性 系统平均可用时间大于 99.99%。 3.2.2 3.2.2 性能 系统并发用户在线数大于 50。 普通数据录入、查找等操作，每单步操作最大延迟时间应小于 5 秒。 一般查询统计，结果集在 100 条记录以内情况下，最大延迟时间不超过 30 秒。 所有统计，其最大延迟时间不超过 2 分钟。 3.2.3 3.2.3 性能可扩展 支持硬件系统性能升级与数量扩充。 3.2.4 3.2.4 功能可扩展 系统应支持新的缺陷处理业务。 3.3 开发策略开发策略 ..1 软件复用策略软件复用策略 系统中重要基础构件应当具备较高的设计与构建质量，可以在产品中复用。 ..2 使用开源构件使用开源构件 系统基础框架主要采用业界的一些主流开源框架，包括： struts、spring、hibernate、log4j 等。 单元测试使用 junit 框架。 ..3 使用商业构件使用商业构件 不适用。 3.4 其它设计约束其它设计约束 目标构架总体上应采用分层结构，并全面应用面向对象设计、编程技术使系统具有较 好的扩展性与重用性。 本系统支持与其他系统进行集成，所以要提取出良好的集成接口。 4 44 4 用例视图用例视图 4.1 概述概述 用例视图从用户使用的角度描述系统构架的基本外部行为特性，通常包含业务用例模 型与系统用例模型。业务用例模型不适用于本系统，这里只关注系统用例。 这里选取了用例模型中对系统构架的内容产生重大影响的应用场景与用例集合，这些 用例代表了系统主要的核心功能，往往决定了系统构架的基本组成元素。有些用例强调或 决定了构架的某些具体然而重要的细节，通常也可以列在本节内，总之所列的用例集合应 基本覆盖系统构架的主要方面。 4.2 关键用例关键用例 ..1 关键的系统主角（关键的系统主角（ActorActor） ..2 关键的系统用例关键的系统用例 4.3 关键系统用例简述关键系统用例简述 本节包括关键用例的首要流程的简述。 请参见相关用例详述文档与 Rose Model。 ..1 录入缺陷的基本流录入缺陷的基本流 1 选择创建一个新的缺 陷记录【触发事件】 【客服工程师/产品用户】期望添加缺陷记录时，选择“创 建一个新的缺陷记录”功能，从而启动本用例的执行 2 创建并显示新的缺陷 记录 2.1 创建缺陷记录并填写 缺省信息 系统创建一新的缺陷记录，分配一个唯一的 ID；并填写缺 省信息，包括创建时间、提交人等；如果是产品用户直接提 交的，则填入他在注册时已录入的联系方式、缺省的软硬件 环境等 2.2 显示新的缺陷记录信 息 系统显示缺陷记录录入与编辑界面，显示当前记录的缺省信 息 3 录入和编辑提交时间、 提交人基本信息 【客服工程师/产品用户】可以根据需要修改提交时间、提 交人等基本信息 4 录入和编辑缺陷基本 信息 【客服工程师/产品用户】录入如下信息：缺陷发现单位、 产品名称、版本、发布时间和缺陷概述 5 录入和编辑优先级和 处理时限 【客服工程师/产品用户】录入缺陷紧急程度（参见关于 缺陷紧急程度的确定规则 ） 、要求处理时限 6 录入和编辑缺陷详情 6.1 录入和编辑缺陷详细 描述 【客服工程师/产品用户】清楚描述缺陷发生时的详细错误 提示、缺陷现象、软件状态，期望结果，实际与期望的差异 等 6.2 录入和编辑缺陷重现 步骤 包括是否可以重现，清楚描述出经过什么样的操作步骤后， 导致了此缺陷的发生 6.3 录入和编辑缺陷产生 软硬件环境 为了便于诊断或者修复缺陷，需要将发生缺陷的计算机的软 硬件详细信息填写清楚 7 选择提交缺陷记录【客服工程师/产品用户】选择提交功能 8 完成缺陷提交 8.1 验证录入数据的格式 和有效性 系统验证录入数据的格式是否正确，以及其是否有效 8.2 更新缺陷记录并加入 缺陷库中 系统用录入的数据更新缺陷记录，并将其加入缺陷库中 8.3 通知相关人员系统将该缺陷报表以电子邮件或其它形式通知给该产品的相 关负责人和客服人员 5 55 5 逻辑视图逻辑视图 5.1 概述概述 逻辑视图从系统内在逻辑结构的角度描述系统的基本结构与动态行为，通常包括分析 模型（Analysis Model）、设计模型（Design Model）以及数据模型（Data Model）等。 设计模型说明了系统的组成元素、组织架构和关系，并描述了各组成元素的协作以及 状态转换关系等（通过用例实现 Use Case Realization 予以表达）。本节将分别在系统层 次结构模型中描述系统的层次组织结构；在主要的包和子系统中说明系统的具体组成；并 在架构机制中详述系统中的各种构架机制；最后在关键用例实现中通过描述最重要的用例 实现，来说明构架的典型协作（动态行为）。 分析模型对等于设计模型，是在更高的抽象层次上定义系统的结构，作为可选项，本 文档将不予说明。 5.2 系统层次结构模型系统层次结构模型 Foundation Resource Integration Business Entities Business Logic Applications Libraries 本系统主要分成 5 个逻辑层：应用层（Applications）、业务逻辑层（Business Logic）、业务实体层（Business Entities）和集成层（Integration）。另外还有一个 Foundation 的包作为全局可用的基础设施。目标系统还使用了其它的第三方组件，它们被 分在 Libraries 包里面。 资源层 本层主要包括数据库、中间间等底层的服务，或者外部系统的直接接口等；这些构件 通常不在本项目中开发。 集成层 本层主要包括整个系统的底层服务，是对其它外部系统的封装，本层多为外部系统在 目标系统中的接口边界类之设计实现，通过对数据库、或消息通知系统等外部系统的封装 来隔离外部系统变化对上层代码所产生的影响。 应用层 本层包含很多用户界面边界类的设计实现，通过对用户界面以及界面上逻辑的封装来 隔离界面变化对下层代码产生的影响。 业务实体层 本层包含了系统中的各个业务实体，对实体进行持久化的功能也包含在本层。另外业 务实体层还包含一些业务里面的常量定义。 业务逻辑层 业务服务层以业务服务的方式组织系统中的各种业务逻辑，将一些相关的、内聚的业 务逻辑组织在一起成为一个业务服务，使得业务逻辑可以以业务服务为单位进行重用和替 换。 Foundation 包 主要包含配置文件读取、状态机、通用异常类、特殊类型等全局通用的代码，这个包 里面的内容很多并不是专为目标系统而做的，是可以在其它系统中进行重用的。 Library 包 包含系统用到的第三方的组件，包括测试框架、struts、spring、hibernate、log4j 等。 5.3 主要的设计包和子系统主要的设计包和子系统 本节描述各层与服务包中具体的设计包与子系统组织结构。 ..1 应用层应用层 本层包括若干个应用子系统，以及实现 MVC 界面交互模式的相关类。 BugEditing SystemAdministr ation BugProcessing 实现 Web 交互机制的相关类主要包括：JSP 页面（UI Pages） 、交互数据（UI Datas） 、 转发控制器（UI Controller）这三部分。 UI Pages UI Datas UI Controller 其中，JSP 页面做为与用户交互的展现界面运行在客户端浏览器上，并由其将用户的 操作转换为向服务器端的 Controller 发送的请求，同时还将用户操作发生的相应数据（UI Datas）传给 Controller 处理或转发。 系统的应用层主要应用 MVC 模式，使用 Struts 框架来实现，在这个框架中开发应用 层时，实现机制如下图所示： ActionFormDispatchAction ActionServlet BusinessServiceFactory (from Business Services) XXXAction XXXActionForm BasicAction SearchForm XXXSearchForm BasicForm XXXVO (from Business Objects) 上图中 ActionSerlvet 充当 MVC 中的 Controller 角色；BasicAction（自定义）对 DispatchAction 做了扩展，用于处理一些安全相关的公用显示逻辑；XXXAction（将放在 UI Controller 包中）从 BasicAction 继承，实现某用例的一组具体的交互动作（这是 TB2.3 的遗留做法，应当改进，让 XXXAction 只承担一个动作）：XXXAction 先从 XXXForm（Struts 框架中的数据传递是通过 ActionForm 统一包装的，这些具体的 XXXForm 将放在 UI Datas 包中）读取用户录入或交互中产生的数据，并赋值给一个相应的 XXXDTO 对象（来自业务对象层），之后从 BusinessServiceFactory 工厂（来自业务服务层）获得 相应的 BusinessService 的具体实现实例，将 XXXDTO 传给它，并调用它进行相关的业务逻 辑操作。 本系统中从 ActionForm 扩展了一个基类 BasicForm，普通非查询类 XXXForm 将从其继 承；另外还专门扩展了一个用于查询的基类 SearchForm，查询类 XXXForm 将从其继承。 ..2 业务逻辑层业务逻辑层 本层中包含业务服务的定位机制实现，与一系列业务服务子系统和用于传递参数的数 据传输对象 DTO： Business Processes Services Locater Bug Manager Bug Processor User Manager SystemUtils Common DTOs 为了方便上层（应用层）调用业务服务，Services Locater 包中包括：一个用于创建 BusinessService 的工厂类BusinessServiceFactory、一些 BusinessService 接口及 其实现的子系统（其下包含若干类）。 业务服务主要被应用层中的 XXXAction 调用，其调用关系如下图所示： BusinessServiceFactory XXXActionForm (from Applications) IXXXBusinessService XXXBusinessServiceFacade XXXAction (from Applications) lo. XXXBO (from Business Objects) XXXVO (from Business Objects) call 个 个 个 个 个 个 个 个 servicemapping.xml 个 个 个 个 个 个 Service 个 个 上图注释标签中提到的 XML 文件 servicemapping.xml 是所有 Service 的一个配置文 件。应用层的 XXXAction 将做为这一层的客户端， 由 Action 使用 Service 工厂类 （BusinessServiceFactory）通过读取配置文件初始化一个 XXXService 实例，然后 Action 调用 Service 中的方法进行业务逻辑处理。 ..3 业务实体层业务实体层 本系统的业务对象层主要包括一些业务实体。 Bug Customer Product ..4 集成层集成层 5.4 架构机制（架构机制（ArchitecturalArchitectural MechanismMechanism） 描述系统中的构架机制。 ..1 日志机制（日志机制（LogLog MechanismMechanism） 系统日志机制主要使用 log4j 框架来实现，仅仅是简单的直接应用，用于记录调试信 息，而没有用到审计功能。 应用途径应用途径 在代码中每个类取得一个 Logger 实例： 然后调用 Logger 的接口方法（debug/warn/info/error/fatal）进行日志记录： ..2 实体持久化（实体持久化（EntityEntity PersistencePersistence MechanismMechanism） 为了满足不同情形的实体对象持久化，这里定义了三种不同的设计机制实现。 机制概要图机制概要图 Entity Persistence-Common XXXEntityVO IXXXEntityDao XXXEntityDaoHibernate Entity Persistence-Cache XXXEntityVO IXXXEntityDao XXXEntityDaoCache Entity Persistence-File XXXEntity IXXXEntityDao XXXEntityDaoFile 【适用范围】 所有存取响应时间要求不高的业 务领域实体类 【分析机制特征范围】 粒度：150KB 数量：1000100万 访问频度：10100次/秒 可靠性：高 【适用范围】 所有存取响应时间要求高的业务 领域实体类 【分析机制特征范围】 粒度：150KB 数量：1000100万 访问频度：1001000次/秒 可靠性：中 【适用范围】 结构关系特别复杂的实体类，例 如CAD图形 【分析机制特征范围】 粒度：110M 数量：10010000 访问频度：1050次/秒 可靠性：高 如上图所示，分别适用于不同分析机制特征的设计机制实现有：普通 Common、缓存 Cache、文件 File 等三种。 机制的参与类视图机制的参与类视图 普通 Common 型持久化机制的参与类： BaseObject (from appfuse) Dao (from appfuse) BaseDaoHibernate (from appfuse) 【分析机制特征】（实体持久 化机制）： 粒度15kbyte 数量10200 访问频度 Create: 0200 per day Read: 10 access per hour Update: 100 per day Delete: 5 per day XXXEntityVO xxx实体类 IXXXEntityDao XXXEntityDaoHibernate 机制协作实现机制协作实现 普通 Common 型持久化机制的 load 数据库数据的协作序列： client codeclient codefactoryfactory : IXXXEntityDao : IXXXEntityDao : XXXEntityDaoHibernate : XXXEntityDaoHibernate : HibernateDaoSupport : HibernateDaoSupport : HibernateTemplate : HibernateTemplate : XXXEntityVO : XXXEntityVO getDao getXXXEntity getHibernateTemplate( ) get(XXXEntityVO.Class, Id) 访问DB，并给XXXEntity赋值 create 赋值 return XXXEntityVO return XXXEntityVO return XXXEntityDaoHibernate as IXXXEntityDao Interface 应用途径应用途径 5.5 关键用例实现描述关键用例实现描述 描述系统的各组成元素（类、包或子系统），为了实现各关键用例，而相互协作的顺 序和交互关系。通常使用序列图、协作图来表达，根据需要也可以使用活动图或状态转换 图。 这里选取了用例视图中最关键的几个用例，对其用例实现加以描述。 .1 .1 录入和编辑缺陷用例实现录入和编辑缺陷用例实现 参与类视图： 序列图： : BugEditPage : BugEditPagetomcat : HttpServer tomcat : HttpServer : ActionServlet : ActionServlet bugrecord data : BugInputForm bugrecord data : BugInputForm : NewABugRecordAction : NewABugRecordAction : BugEditDispatcher : BugEditDispatcher resultInfo : BugSubmitedSuccessPage resultInfo : BugSubmitedSuccessPage : BugRecordVO : BugRecordVO : BizServiceFinder : BizServiceFinder : IBugManager : IBugManager - Web Server - OnSubmitRecClick( ) Http Request set Data of BugRecord execute( ) create processEvents( ) fetch data of BugRecord showResults( ) create set data create GetBugManager( ) return BugManagerFacade as IBugManager verifyBugRecord(BugRecordVO, BugAppendVO) submitBugRecord(BugRecordVO, BugAppendVO) 6 66 6 进程视图进程视图 6.1 概述概述 进程视图从系统运行时刻的角度，描述系统划分为进程、线程的结构，及其动态关系。 模型主要说明进程、线程的分类，系统构架敏感的主要边界类、控制类对象等在进程、线 程中的分布，以及它们之间的创建、交互与消息通讯关系等。 6.2 总体进程结构总体进程结构 系统是以 Tomcat 这个 Web 应用服务器为基础运行的。在服务器启动时通过每个应用的 web.xml 初始化并启动所用到的 Servlet，在本系统中是 struts 框架提供的 ActionServlet。当客户端浏览器产生 Web 请求时，服务器找到 ActionServlet，将请求交 给 Servlet 来处理；Servlet 对每个请求向 Tomcat 申请开启一个线程，并调用相应的 Actio