铁路售票系统架构评审文档
虚拟的一人多角色的评估小组，成员列表如下：
表1：评估小组成员列表
成员 角色 评估小组负责人、评估总结者、提问者、场景书记员、时间管理者 评估负责人、提问者、架构设计师、提问者、进展书记员、数据收集人、提问者、领域专家、资料员 时间管理者、提问者、场景书记员、资料员
目录
铁路售票系统架构评审文档 ........................................................................................................... 1 引言 .................................................................................................................................................. 3
编写目的： ............................................................................................................................... 3 背景：....................................................................................................................................... 3 定义：....................................................................................................................................... 3
三层架构软件设计 ........................................................................................................... 3 ATAM架构评审模式 ....................................................................................................... 3 参考资料： ............................................................................................................................... 4 第0阶段：合作关系及准备工作 ................................................................................................... 4 第1阶段：评估阶段 ....................................................................................................................... 5
项目产品立项表述： ............................................................................................................... 5 架构方法分类： ....................................................................................................................... 5 架构表述： ............................................................................................................................... 6 初步架构类图： ....................................................................................................................... 7 质量属性及采用的战术： ....................................................................................................... 7 生成质量属性效用树： ........................................................................................................... 8 初步分析架构方法： ............................................................................................................... 9
性能 ................................................................................................................................... 9 可用性 ............................................................................................................................. 10 安全性 ............................................................................................................................. 10 战术采用 ......................................................................................................................... 10
第2阶段：评估阶段 ..................................................................................................................... 11
集体讨论并确定场景的优先级： ......................................................................................... 11 再次分析架构方法： ............................................................................................................. 12
三层结构选择 ................................................................................................................. 12 LRU缓冲技术分析 ........................................................................................................ 12 MD5加密存储分析 ....................................................................................................... 12 备份数据库 ..................................................................................................................... 13 改进架构类图 ................................................................................................................. 14 结果表述 ................................................................................................................................. 14 第3阶段：后续阶段 ..................................................................................................................... 14 附录 ................................................................................................................................................ 15
拟采用架构评审方法中的ATAM方法 ................................................................................ 15
引言
编写目的：
本文档的编写目的是对铁路售票系统架构设计进行简略的评审，为后继的详细项目设计等工作提供参考和依据，本文档主要描述的内容有：
? 表述
? 调查和分析 ? 测试 ? 形成报告
本文档的预期读者为：系统设计人员、测试人员、用户及其它有权限查阅本文档的相关人员。
背景：
? ? ? ?
系统名称：铁路售票系统
任务提出者：黄东鹏、张付俊、孙帅 开发者（承接单位）：开发小组 用户：网上订购铁路车票的人
定义：
三层架构软件设计
所谓三层体系结构，是在客户端与数据库之间加入了一个中间件层，也叫组件层。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机器上。三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通讯与中间层建立连接，再经由中间层与数据库进行交换。
ATAM架构评审模式
1.概述
Architecture Tradeoff Analysis Method(构架权衡分析方法）。他是评价软件构架的一种综合全面的方法。这种方法不仅可以揭示出构架满足特定质量目标的情况，而
且（因为它认识到了构架决策会影响多个质量属性）可以使我们更清楚地认识到质量目标之间的联系——即如何权衡诸多质量目标。
ATAM评估方法的主要目的： 1) 提炼出软件质量属性需求的精确描述； 2) 提炼出构架设计决策的精确描述； 3) 评估这些构架设计决策，并判定其是否令人满意的实现了这些质量需求。 ATAM评估方法并非把每个可以量化的质量属性都进行详尽的分析，而是使众多的风险承担者（包括经理、开发人员、测试人员、用户、客户等等）都参与进来，由此而达到上述目标的。
ATAM是一种挖掘潜在风险，降低或者缓和现有风险的软件构架评估方法。因此，以下三点是评估中要特别注重的：风险、敏感点和权衡点。
2构架涉众
普通用户、用户管理员、票务管理员、开发人员、测试人员
参考资料：
Software ArchitectureinPractical（第三版）
第0阶段：合作关系及准备工作
此次对项目的评估方法经小组协商讨论是采用ATAM架构评估综合方法。待评估的项目系统为铁路售票系统。这是一个基于B/S的体系的常见应用，基于网络连接实现铁路票务的相关业务。对其进行架构评估主要有如下几个原因：
1.在架构搭建的过程中一定会碰见许多一致或者未知的问题和困难，如果在核心功能模块或者架构本身的设计根本上出现缺陷，尽早的发现对于晚发现，甚至完成项目后才发现的综合成本要低得多；
2.由于该架构面向多个用户多平台，因此要有足够的健壮性，稳定性，可拓展性以及可修改性；
3.由于该系统借助了网络的传播性，可以随时随地的对系统进行管理和维护，但是网络的泛滥使得网络环境总是充斥着有意无意的攻击，为了避免系统所部属的服务器沦为肉鸡的下场，或者内部数据被恶意破坏造成重大损失，所以系统应保证相对的安全性，使得入侵者所花费的入侵成本>入侵系统的获利成本或客户损失。
第1阶段：评估阶段
项目产品立项表述：
随着现代交通的发展，在基于经济以及便利的考虑基础上，铁路出行成为广大人民首选的性价比最高的交通方式。但随着经济的发展，人工售票逐渐不能满足庞大人口数量的基本购票需求。随着互联网的发展，网络购票的普及解决了这个主要矛盾。 根据上述目标，质量属性可以划分为两类： 1．高优先级质量属性： 1) 性能 2) 安全性 3) 易用性 4) 兼容性
2．重要但优先级较低的属性： 1) 可扩展性 2) 可维护性 3) 可靠性 4) 可扩充
架构方法分类：
进行了架构表述后，评估小组列出他们曾听到的架构方法，以及那些在对文档进行评估前的评审中所了解到的方法：
一、 分层架构
这种架构将软件分成若干个水平曾，每一层都有清晰的角色和分工，不需要知道其他层的细节，层与层之间通过接口通信。 二、 事件驱动架构
事件是状态发生变化时，软件发出的通知。事件驱动架构就是通过事件进行通信的软件架构。分为：事件队列、分发器、事件通道、事件处理器。 三、 微核架构
又称为“插件架构”，指的是软件的内核相对较小，只要功能和业务逻辑都通过插件实现。
内核通常只包含系统运行的最小功能。插件则是相互独立的，插件之间的通信，应该减少到最低，避免出现相互依赖的问题。 四、 微服务架构
是服务导向的架构的升级。
每一个服务都是一个独立的部署单元。这些单元都是分布式的，互相解耦，通过远程通信协议联系。 五、 云架构
云架构主要解决扩展性和并发问题，是最容易扩展的架构。
它的高扩展，主要原因是没使用中央数据库，而是把数据都复制到内存中，变成
铁路售票系统架构评审文档
