《软件构架文档》doc版.doc

目目 录录 1.简介简介2 1.1目的2 1.2范围2 1.3定义、首字母缩写词和缩略语.2 1.4参考资料.2 2.概述概述2 3.构架目标和约束：构架目标和约束：2 4.现有需求现有需求.3 4.1开发背景.3 4.2可行性分析 .3 4.3需求分析.3 5.系统整体构架系统整体构架.3 5.1体系结构概述3 5.1.1多层体系架构 .4 5.1.2信息系统架构总体视图.5 5.2关键技术设计5 5.2.1网上服务.5 6.系统设计模式系统设计模式.8 6.1用例图.8 6.2类图10 6.3包和对象图 .12 6.4顺序图.14 6.5协作图.16 6.6状态图.17 6.7活动图.18 6.8组件与配置图20 7.布署视图布署视图.20 8.数据视图数据视图.21 9.大小和性能大小和性能.22 10. 质量质量22 软件构架文档参考模板 1.简介简介 1.1目的目的 此文档从构架方面对系统进行综合概述，其中使用了大量不同的构架视图来描述 系统的各个不同方面。它用于记录并表述已在构架方面对系统作出的重要决定。 1.2范围范围 本文档是为 JL4 软件的 Java 版本设计的，按照 RUP 的软件架构文档模板编 写，用于指导 JL4 软件系统的 Java 版本。 1.3定义、首字母缩写词和缩略语定义、首字母缩写词和缩略语 （略） 1.4参考资料参考资料 JL4 软件系统结构 JL4 数据库设计报告 JL4 设计报告 - Mechanisms JL4 设计报告 - Common Elements and Services JL4 设计报告 - Business System 2.概述概述 软件架构的逻辑视图描述了该系统的主要结构和所采用的体系设计模式。设计软 件架构可以最大程度的重用系统的设计和代码，还可以明确系统中每个模块和对 象的功能，避免重复功能的多次开发。系统架构的逻辑视图也描述了最重要的组 件，若干组件构成服务或子系统，子系统构成系统的层。 3.构架目标和约束：构架目标和约束： 系统扩展性和灵活性需求，系统的设计需要具备足够的扩展性，以便于因发展或 改变而对系统功能的调整和增加，便于系统升级和维护。系统的扩展性包括功能 的扩展性和数据扩展性。 需要采用 B/S 结构，使用户能通过互联网访问系统数据，支持远程管理和移动办 公。本软件架构以逻辑视图表示，用 Rational Rose 工具基于统一建模语言(UML)开 发的。 系统要求实现多层体系结构，服务器端考虑扩平台的应用，支持不同的组件协议 （EJB，COM+），交互接口支持不同的风格(Windows 桌面应用、Java 桌面应 用、Web 应用风格)。 4.现有需求现有需求 4.1开发背景开发背景 4.2可行性分析可行性分析 4.3需求分析需求分析 5.系统整体构架系统整体构架 5.1体系结构概述体系结构概述 体系架构视图反映了系统的技术组成和关键技术的集成框架。 整个系统涵盖了业务、行政、辅助决策三大系统，其中对结构影响最大的是业务 和行政系统，业务系统主要处理交易性的事务，行政系统偏重于基于工作流的办 公和管理。因此整个系统整合了事务处理、工作流应用、办公平台、辅助决策支 持等多项技术。 在进行构架设计时，重点考虑了对架构影响的需求： 多层体系结构：系统基于多层体系结构设计。 单点登录：用户只需要登录一次，即可使用不同系统，而不需要重复登录。 门户集成：应用通过 Web 发布，为用户提供个性化服务的能力。 工作流应用：系统中存在多人参与的应用，这些应用需要协作才能完整，并 且要求参与的角色和可能的流程可以被修改。 报表应用：需要处理大量的报表，具有报表管理、定时生成，报表可输出为 多种格式并可后期修改。 信息整合：信息单一存储，减少信息的冗余度。 如何整合历史系统和外部系统：由于系统的历史系统并不能全部在新系统建 立时集成，并且存在一部分外部系统，需要考虑如何集成这些系统到新系统 中。 其它因素，如应用系统的逻辑分层，因为并不影响产品和技术架构，所以在结构 视图中并不过多考虑，而在逻辑视图中体现。 根据以上需求，建立以多层体系为基础的系统架构。 5.1.1多层体系架构多层体系架构 系统建立在多层体系架构上，以提供更好的灵活性和强大的扩展能力。多层体系 对于本系统来说是四层结构，分别从客户端桌面、业务表述处理、业务逻辑处理 和数据服务层进行分配。如下图： 这四层代表了处理一个开放、可扩展性系统应当关注的环节： 数据服务层：数据服务层：永久存储信息由数据服务层提供，包括业务交易数据、人事 管理数据、数据仓库。 业务逻辑层：业务逻辑层：业务的逻辑规则封装在业务组件中，提供给客户端应用或表 述逻辑调用。在本系统中，采用 J2EE 规范的 EJB(Enterprise JavaBean) 组件模型。 表述层：表述层：处理如何将信息反映给使用者，表述层协调与前端应用界面的控 制逻辑（如门户应用）和对信息的加工利用（如报表服务），负责将信息 提供给使用者的渠道。改进表述层还可提供更多的服务类型，如语音服务、 短信息服务。 客户应用层：客户应用层：最终用户的使用界面，包括基于浏览器的使用界面和定制的 图形化客户端界面。 5.1.2信息系统架构总体视图信息系统架构总体视图 系统除了垂直的多层结构之外，在每一层面还存在水平系统的职责分配，在构建 整个系统时需要将这些不同层面和不同系统的应用整合到一起，下图南京地税 “金力”四期信息架构反映了所有产品的整合关系。 5.2关键技术设计关键技术设计 本节说明构架中各项关键技术的具体分析和设计策略。 5.2.1网上服务网上服务 广义上的网上服务是提供给公众和纳税人的信息服务中心，在这里指面向纳税人 的在线服务，主要提供电子申报服务。电子申报指纳税户通过远程的计算机接入 到地税局的信息网络，完成自己的申报业务。 1、网上申报业务流程 一个柜台的纳税申报主要包括填写申报表、校验、实时扣款、打印税票环节。如 下图（为了说明主要问题，异常的处理并没有包括进来）： 输入纳税识别 码和申报类型 属性 填写申报表 校验有效性 返回申报表 连接银行扣款扣款 保存申报信息 提示申报成功 启动 结束 申申报报柜柜台台处处理理人人员员系系统统银银行行系系统统 一个正常的柜台申 报处理过程 如果校验正确 扣款成功 申报成功 纳纳税税户户柜柜台台申申报报流流程程 打印税票 电子申报的流程与柜台纳税申报业务流程基本一致，但在处理某些环节上有一些 差异，柜面处理在处理申报时，会根据申报的结果打印不同的凭证（如完税证、 通用缴款书），而在电子申报时，这种方式从有效性上难以控制，一种做法是在 进行电子申报后到柜台去打票或税务局打票后通过邮递的方式寄给纳税户，这种 方式可以符合国家对税票凭证的要求。如下图： 输入纳税识别 码和申报类型 属性 填写申报表 校验有效性 返回申报表 确认申报 连接银行扣款扣款 保存申报信息 提示申报成功 启动 结束 纳纳税税户户系系统统银银行行系系统统 一个正常的柜台申 报处理过程 如果校验正确 扣款成功 申报成功 纳纳税税户户电电子子申申报报流流程程 取消了税票打印， 采用离线打印的方 式 离线打印税票可以采用两种方式： 输入纳税识别 码 请求打印 打印税票 返回有效税票 启动 申申报报柜柜台台处处理理人人员员系系统统 打印 纳纳税税户户柜柜台台打打印印税税票票流流程程 输入日期 请求打印 批处理打印税 票和信封 查询需要邮递 的税票 启动 邮邮递递申申报报表表处处理理人人员员系系统统 邮邮递递税税票票流流程程 返回税票列表 结束 结束 通过邮政局邮递税 票 电子申报离线税票打印处理方式 。 6.系统设计模式系统设计模式 6.1用例图用例图 用例图 Use case diagrams 描述了作为一个外部的观察者的视角对系统的印象。强调这个 系统是什么而不是这个系统怎么工作。 用例图与情节紧紧相关的。情节 scenario 是指当某个人与系统进行互动时发生的情况。 下面是一个医院门诊部的情节。 “一个病人打电话给门诊部预约一年一次的身体检查。接待员找出在预约记录本上找出最 近的没有预约过的时间，并记上那个时间的预约记录。” 用例 Use case 是为了完成一个工作或者达到一个目的的一系列情节的总和。角色 actor 是发动与这个工作有关的事件的人或者事情。角色简单的扮演着人或者对象的作用。下 面的图是一个门诊部 Make Appointment 用例。角色是病人。角色与用例的联系是通讯联 系 communication association（或简称通讯 communication） 角色是人状的图标，用例是一个椭圆，通讯是连接角色和用例的线。 一个用例图是角色，用例，和它们之间的联系的集合。我们已经把 Make Appointment 作 为一个含有四个角色和四个用例的图的一部分。注意一个单独的用例可以有多个角色。 用例图在三个领域很有作用。 决定特征（需求）。当系统已经分析好并且设计成型时，新的用例产生新的需求 客户通讯。使用用例图很容易表示开发者与客户之间的联系。 产生测试用例。一个用例的情节可能产生这些情节的一批测试用例。 6.2类图类图 类图 Class diagram 通过显示出系统的类以及这些类之间的关系来表示系统。类图是静态 的它们显示出什么可以产生影响但不会告诉你什么时候产生影响。 下面是一个顾客从零售商处预定商品的模型的类图。中心的类是 Order。连接它的是购 买货物的 Customer 和 Payment。Payment 有三种形式：Cash，Check，或者 Credit。订单 包括 OrderDetails（line item），每个这种类都连着 Item。 UML 类的符号是一个被划分成三块的方框：类名，属性，和操作。抽象类的名字，像 Payment 是斜体的。类之间的关系是连接线。 类图有三种关系。 关联 association表示两种类的实例间的关系。如果一个类的实例必须要用另一 个类的实例才能完成工作时就要用关联。在图中，关联用两个类之间的连线表示。 聚合 aggregation当一个类属于一个容器是的一种特殊关系。聚合用一个带菱形 的连线，菱形指向具有整体性质的类。在我们的图里，Order 是 OrderDetails 的容器。 泛化 generalization一个指向以其他类作为超类的继承连线。泛化关系用一个三 角形指向超类。Payment 是 Cash，Check 和 Credit 的超类。 一个关联有两个尾端。每个尾端可以有一个角色名 role name 来说明关联的作用。比如， 一个 OrderDetail 实例是一个 Order 实例的项目。 关联上的方向性 navigability 箭头表示该关联传递或查询的方向。OrderDetail 类可以查询 他的 Item，但不可以反过来查询。箭头方向同样可以告诉你哪个类拥有这个关联的实现； 也就是，OrderDetail 拥有 Item。没有方向性的箭头的关联是双向。 关联尾端的数字表示该关联另一边的一个实例可以对应的数字端的实例的格数，通过这 种方式表达关联的多样性 multiplicity。多样性的数字可以是一个单独的数字或者是一个 数字的范围。在例子中，每个 Order 只有一个 Customer，但一个 Customer 可以有任意多 个 Order。 下面这个表给出了最普遍的多样性示例。 多样性多样性意义意义 010 或 1 个实例. nm 符号表示有 n 到 m 个实例 0* or *没有实例格数的限制（包括没有）. 1只有一个实例 1*最少一个实例 每个类图包括类，关联和多样性表示。方向性和角色是为了使图示得更清楚时可选的项 目。 6.3包和对象图包和对象图 为了简单地表示出复杂的类图，可以把类组合成包 packages。一个包是 UML 上有逻辑 关系的元件的集合。下面这个图是是一个把类组合成包的一个商业模型。 dependencies 关系。如果另一个的包 B 改变可能会导致一个包 A 改变，则包 A 依赖包 B。 包是用一个在上方带有小标签的矩形表示的。包名写在标签上或者在矩形里面。点化线 箭头表示依赖 对象图 Object diagrams 用来表示类的实例。他们在解释复杂关系的细小问题时（特别是 递归关系时）很有用。 这个类图示一个大学的 Department 可以包括其他很多的 Departments。 这个对象图示上面类图的实例。用了很多具体的例子。 UML 中实例名带有下划线。只要意思清楚，类或实例名可以在对象图中被省略。 每个类图的矩形对应了一个单独的实例。实例名称中所强调的 UML 图表。类或实例的 名称可能是省略对象图表只要图的意义仍然是明确的。 6.4顺序图顺序图 类图和对象图是静态模型的视图。交互图是动态的。他们描述了对象间的交互作用。 顺序图将交互关系表示为一个二维图。纵向是时间轴，时间沿竖线向下延伸。横向轴代 表了在协作中各独立对象的类元角色。类元角色用生命线表示。当对象存在时，角色用 一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线。 消息用从一个对象的生命线到另一个对象生命线的箭头表示。箭头以时间顺序在图中从 上到下排列。 6.5协作图协作图 协作图也是互动的图表。他们像序列图一样也传递相同的信息，但他们不关心什么时候 消息被传递，只关心对象的角色。在序列图中，对象的角色放在上面而消息则是连接线。 对象角色矩形上标有类或对象名（或者都有）。类名前面有个冒号（：）。 协作图的每个消息都有一个序列号。顶层消息的数字是 1。同一个等级的消息（也就是 同一个调用中的消息）有同样的数字前缀，再根据他们出现的顺序增加一个后缀 1，2 等 等。 6.6状态图状态图 对象拥有行为和状态。对象的状态是由对象当前的行动和条件决定的。状态图 statechart diagram 显示出了对象可能的状态以及由状态改变而导致的转移。 我们的模型例图建立了一个银行的在线登录系统。登录过程包括输入合法的密码和个人 账号，再提交给系统验证信息。 登录系统可以被划分为四种不重叠的状态：Getting SSN, Getting PIN, Validating, 以及 Rejecting。每个状态都有一套完整的转移 transitions 来决定状态的顺序。 状态是用圆角矩形来表示的。转移则是使用带箭头的连线表示。触发转移的事件或者条 件写在箭头的旁边。我们的图上有两个自转移。一个是在 Getting SSN，另一个则在上 Getting PIN。 初始状态（黑色圆圈）是开始动作的虚拟开始。结束状态也是动作的虚拟结束。 事件或条件触发动作时用（/动作）表示。当进入 Validating 状态时，对象并不等外部事 件触发转移。取而代之，它产生一个动作。动作的结果决定了下一步的状态。 6.7活动图活动图 活动图 activity diagram 是一个很特别的流程图。活动图和状态图之间是有关系的。状态 图把焦点集中在过程中的对象身上，而活动图则集中在一个单独过程动作流程。活动图 告诉了我们活动之间的依赖关系。 对我们的例子来说，我们使用如下的过程。 “通过 ATM 来取钱。” 这个活动有三个类 Customer, ATM 和 Bank。整个过程从黑色圆圈开始到黑白的同心圆 结束。活动用圆角矩形表示。 活动图可以被分解成许多对象泳道 swimlanes ，可以决定哪些对象负责那些活动。每个 活动都有一个单独的转移 transition 连接这其他的活动。 转移可能分支 branch 成两个以上的互斥的转移。保护表达式（在中）表示转移是从一 个分支中引出的。分支以及分支结束时的合并 merge 在图中用菱形表示。 转移也可以分解 fork 成两个以上的并行活动。分解以及分解结束时的线程结合 join 在图 中用粗黑线表示 6.8组件与配置图组件与配置图 组件 component 是代码模块。组件图是是类图的物理实现。 配置图 Deployment diagrams 则是显示软件及硬件的配置。 下面的配置图说明了与房地产事务有关的软件及硬件组件的关系。 物理上的硬件使用节点 nodes 表示。每个组件属于一个节点。组件用左上角带有两个小 矩形的