软件构架文档文档格式.docx
《软件构架文档文档格式.docx》由会员分享，可在线阅读，更多相关《软件构架文档文档格式.docx（27页珍藏版）》请在冰豆网上搜索。
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架构机制（ArchitecturalMechanism）19
5.4.1日志机制（LogMechanism）19
5.4.2实体持久化（EntityPersistenceMechanism）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&
MobileClient26
7.4WebServer26
7.5DBServer26
8实施视图27
8.1概述27
8.2实施模型总体结构27
8.3WebRoot结构27
8.4Src包结构28
BugManager缺陷管理系统2.0
11
简介
1.11.1
目的
本文档全面与系统地表述目标软件系统的构架，并通过使用多种视图来从不同角度描述系统的各个主要方面，以满足相关涉众（客户、设计人员等）对目标系统的不同关注焦点。
本文档记录并表述了架构师对系统构架方面做出的重要决策；
项目经理将根据构架定义的构件结构制定项目的开发计划；
设计员将据此进行各构件的详细设计；
测试设计员按照构架设计系统的总体测试框架；
另外构架文档还用于指导各构件的实施、集成及测试。
1.21.2
范围
本文档适用于“BugManager缺陷管理系统2代”的总体应用构架。
1.31.3
术语词汇表
此处未完成
1.41.4
参考资料
●●
《客诉管理制度》
《前景文档》
22
构架表示方式
本文档以一系列的视图（View）来表示系统的软件构架，主要包括用例视图、逻辑视图、进程视图、部署视图、实施视图（即RUP推荐的4+1视图）等；
每个视图拥有一个或多个模型（Model）（例如逻辑视图包含分析模型、设计模型和数据模型等）；
并围绕相关视图来描述系统的基本结构、组成机制与工作原理等。
本文档还将系统的构架机制描述也放在了逻辑视图之下。
本文档主要使用统一建模语言（UML）来充当相关模型的表达语言；
主要图表（Diagram）引用自目标系统的RoseModel。
33
构架设计目标与约束
描述构架设计必须满足的关键系统功能需求和质量约束，这些功能需求和质量要求对软件构架有重大的影响，并决定了构架的设计。
本节同时还列明影响构架的其他相关因素，如软件的复用策略、使用商业构件、设计与实施的策略等。
3.13.1
关键功能需求
跨地域的系统外部用户通过Internet网来使用系统的功能。
内部用户、系统管理员在安全性较高的内网中使用系统的功能。
消息通知系统是目标系统为了实现相关功能而需要进行协作的一个外部系统，它能够向用户发送email，或者发送短消息。
3.23.2
关键质量要求
3.2.13.2.1
有效性
系统平均可用时间大于99.99%。
3.2.23.2.2
性能
系统并发用户在线数大于50。
普通数据录入、查找等操作，每单步操作最大延迟时间应小于5秒。
一般查询统计，结果集在100条记录以内情况下，最大延迟时间不超过30秒。
所有统计，其最大延迟时间不超过2分钟。
3.2.33.2.3
性能可扩展
支持硬件系统性能升级与数量扩充。
3.2.43.2.4
功能可扩展
系统应支持新的缺陷处理业务。
3.33.3
开发策略
3.3.13.3.1
软件复用策略
系统中重要基础构件应当具备较高的设计与构建质量，可以在产品中复用。
3.3.23.3.2
使用开源构件
系统基础框架主要采用业界的一些主流开源框架，包括：
struts、spring、hibernate、log4j等。
单元测试使用junit框架。
3.3.33.3.3
使用商业构件
不适用。
3.43.4
其它设计约束
目标构架总体上应采用分层结构，并全面应用面向对象设计、编程技术使系统具有较好的扩展性与重用性。
本系统支持与其他系统进行集成，所以要提取出良好的集成接口。
44
用例视图
4.14.1
概述
用例视图从用户使用的角度描述系统构架的基本外部行为特性，通常包含业务用例模型与系统用例模型。
业务用例模型不适用于本系统，这里只关注系统用例。
这里选取了用例模型中对系统构架的内容产生重大影响的应用场景与用例集合，这些用例代表了系统主要的核心功能，往往决定了系统构架的基本组成元素。
有些用例强调或决定了构架的某些具体然而重要的细节，通常也可以列在本节内，总之所列的用例集合应基本覆盖系统构架的主要方面。
4.24.2
关键用例
4.2.14.2.1
关键的系统主角（Actor）
4.2.24.2.2
关键的系统用例
4.34.3
关键系统用例简述
本节包括关键用例的首要流程的简述。
请参见相关用例详述文档与RoseModel。
4.3.14.3.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
通知相关人员
系统将该缺陷报表以电子邮件或其它形式通知给该产品的相关负责人和客服人员
55
逻辑视图
5.15.1
逻辑视图从系统内在逻辑结构的角度描述系统的基本结构与动态行为，通常包括分析模型（AnalysisModel）、设计模型（DesignModel）以及数据模型（DataModel）等。
设计模型说明了系统的组成元素、组织架构和关系，并描述了各组成元素的协作以及状态转换关系等（通过用例实现UseCaseRealization予以表达）。
本节将分别在系统层次结构模型中描述系统的层次组织结构；
在主要的包和子系统中说明系统的具体组成；
并在架构机制中详述系统中的各种构架机制；
最后在关键用例实现中通过描述最重要的用例实现，来说明构架的典型协作（动态行为）。
分析模型对等于设计模型，是在更高的抽象层次上定义系统的结构，作为可选项，本文档将不予说明。
5.25.2
系统层次结构模型
本系统主要分成5个逻辑层：
应用层（Applications）、业务逻辑层（BusinessLogic）、业务实体层（BusinessEntities）和集成层（Integration）。
另外还有一个Foundation的包作为全局可用的基础设施。
目标系统还使用了其它的第三方组件，它们被分在Libraries包里面。
资源层
本层主要包括数据库、中间间等底层的服务，或者外部系统的直接接口等；
这些构件通常不在本项目中开发。
集成层
本层主要包括整个系统的底层服务，是对其它外部系统的封装，本层多为外部系统在目标系统中的接口边界类之设计实现，通过对数据库、或消息通知系统等外部系统的封装来隔离外部系统变化对上层代码所产生的影响。
应用层
本层包含很多用户界面边界类的设计实现，通过对用户界面以及界面上逻辑的封装来隔离界面变化对下层代码产生的影响。
业务实体层
本层包含了系统中的各个业务实体，对实体进行持久化的功能也包含在本层。
另外业务实体层还包含一些业务里面的常量定义。
业务逻辑层
业务服务层以业务服务的方式组织系统中的各种业务逻辑，将一些相关的、内聚的业务逻辑组织在一起成为一个业务服务，使得业务逻辑可以以业务服务为单位进行重用和替换。
Foundation包
主要包含配置文件读取、状态机、通用异常类、特殊类型等全局通用的代码，这个包里面的内容很多并不是专为目标系统而做的，是可以在其它系统中进行重用的。
Library包
包含系统用到的第三方的组件，包括测试框架、struts、spring、hibernate、log4j等。
5.35.3
主要的设计包和子系统
本节描述各层与服务包中具体的设计包与子系统组织结构。
5.3.15.3.1
本层包括若干个应用子系统，以及实现MVC界面交互模式的相关类。
实现Web交互机制的相关类主要包括：
JSP页面（UIPages）、交互数据（UIDatas）、转发控制器（UIController）这三部分。
其中，JSP页面做为与用户交互的展现界面运行在客户端浏览器上，并由其将用户的操作转换为向服务器端的Controller发送的请求，同时还将用户操作发生的相应数据（UIDatas）传给Controller处理或转发。
系统的应用层主要应用MVC模式，使用Struts框架来实现，在这个框架中开发应用层时，实现机制如下图所示：
上图中ActionSerlvet充当MVC中的Controller角色；
BasicAction（自定义）对DispatchAction做了扩展，用于处理一些安全相关的公用显示逻辑；
XXXAction（将放在UIController包中）从BasicAction继承，实现某用例的一组具体的交互动作（这是TB2.3的遗留做法，应当改进，让XXXAction只承担一个动作）：
XXXAction先从XXXForm（Struts框架中的数据传递是通过ActionForm统一包装的，这些具体的XXXForm将放在UIDatas包中）读取用户录入或交互中产生的数据，并赋值给一个相应的XXXDTO对象（来自业务对象层），之后从BusinessServiceFactory工厂（来自业务服务层）获得相应的BusinessService的具体实现实例，将XXXDTO传给它，并调用它进行相关的业务逻辑操作。
本系统中从ActionForm扩展了一个基类BasicForm，普通非查询类XXXForm将从其继承；
另外还专门扩展了一个用于查询的基类SearchForm，查询类XXXForm将从其继承。
5.3.25.3.2
本层中包含业务服务的定位机制实现，与一系列业务服务子系统和用于传递参数的数据传输对象DTO：
为了方便上层（应用层）调用业务服务，ServicesLocater包中包括：
一个用于创建BusinessService的工厂类——BusinessServiceFactory、一些BusinessService接口及其实现的子系统（其下包含若干类）。
业务服务主要被应用层中的XXXAction调用，其调用关系如下图所示：
上图注释标签中提到的XML文件servicemapping.xml是所有Service的一个配置文件。
应用层的XXXAction将做为这一层的客户端，由Action使用Service工厂类（BusinessServiceFactory）通过读取配置文件初始化一个XXXService实例，然后Action调用Service中的方法进行业务逻辑处理。
5.3.35.3.3
本系统的业务对象层主要包括一些业务实体。
5.3.45.3.4
5.45.4
架构机制（ArchitecturalMechanism）
描述系统中的构架机制。
5.4.15.4.1
日志机制（LogMechanism）
系统日志机制主要使用log4j框架来实现，仅仅是简单的直接应用，用于记录调试信息，而没有用到审计功能。
应用途径
在代码中每个类取得一个Logger实例：
然后调用Logger的接口方法（debug/warn/info/error/fatal）进行日志记录：
5.4.25.4.2
实体持久化（EntityPersistenceMechanism）
为了满足不同情形的实体对象持久化，这里定义了三种不同的设计机制实现。
机制概要图
如上图所示，分别适用于不同分析机制特征的设计机制实现有：
普通Common、缓存Cache、文件File等三种。
机制的参与类视图
普通Common型持久化机制的参与类：
机制协作实现
普通Common型持久化机制的load数据库数据的协作序列：
5.55.5
关键用例实现描述
描述系统的各组成元素（类、包或子系统），为了实现各关键用例，而相互协作的顺序和交互关系。
通常使用序列图、协作图来表达，根据需要也可以使用活动图或状态转换图。
这里选取了用例视图中最关键的几个用例，对其用例实现加以描述。
5.5.15.5.1
录入和编辑缺陷用例实现
参与类视图：
序列图：
66
进程视图
6.16.1
进程视图从系统运行时刻的角度，描述系统划分为进程、线程的结构，及其动态关系。
模型主要说明进程、线程的分类，系统构架敏感的主要边界类、控制类对象等在进程、线程中的分布，以及它们之间的创建、交互与消息通讯关系等。
6.26.2
总体进程结构
系统是以Tomcat这个Web应用服务器为基础运行的。
在服务器启动时通过每个应用的web.xml初始化并启动所用到的Servlet，在本系统中是struts框架提供的ActionServlet。
当客户端浏览器产生Web请求时，服务器找到ActionServlet，将请求交给Servlet来处理；
Servlet对每个请求向Tomcat申请开启一个线程，并调用相应的Action类方法，在Action中转调XXXDispatcher的processEvent（）方法，在此方法中通过调用单子类BizServiceFinder，为每个线程创建一个接口为IXXXBizService的实例，最后调用XXXBizServiceFacade上的方法与数据库进程交互。
业务逻辑处理完成后将结果返回到客户端浏览器显示。
77
部署视图
7.17.1
部署视图从系统软硬件物理配置的角度，描述系统的网络逻辑拓扑结构。
模型包括各个物理节点的硬件与软件配置，网络的逻辑拓扑结构，节点间的交互与通讯关系等。
同时还表达了进程视图中的各个进程具体分配到物理节点的映射关系。
7.27.2
部署方案
7.37.3
Client&
MobileClient
Client&
MobileClient为普通PC机和Notebook，客户端浏览器要求IE6.0以上版本。
7.47.4
WebServer
操作系统为Windows2000Server。
WebServer上部署的是我们的应用程序PALH_HRS，该应用程序运行在tomcat4.x、jre1.4.2环境下，另外还将部署第三方的考勤管理系统。
7.57.5
DBServer
操作系统为Windows2000。
数据库为MSSQLServer2000。
88
实施视图
8.18.1
实施视图从软件编译与构建的角度，描述系统实施构件的组织结构与依赖关系（主要是编译依赖）。
模型包括实施子系统和构件结构，及其依赖关系。
同时还表达了逻辑视图中各个包和类分配到实施视图中的子系统和构件的映射关系。
8.28.2
实施模型总体结构
8.38.3
WebRoot结构
8.48.4
Src包结构
升级会员 