背景：昨天元宵佳节同事聚餐，大家聊起今年的网上订票系统，毁誉参半呀。从程序员的角度我们是怎么看这个铁老大斥资几千万的大系统的，这里我就不说了。要写的是如果我是这个系统的架构师（呵呵夸口了，如果也许假设是，然而未必不见得，嘿嘿），我会如何设计这个系统。2月我会利用零星的时间，就这个系统演练下系统设计的能力，作为这个月送给自己的玩具，呵呵，不足之处欢迎大家批评指正踊跃拍砖。
目标：
本系统主要实现对火车车次的查询、车票预订功能。
关注在大用户量集中访问情况下，比如春运订票高峰期，系统承载能力。
当然细节方面也要注意系统的易用性、用户体验，比如在查询两车站间没有直达车时给出中转站，输入车站名简称时有提示，管理员可修改预售期、增减车次信息等。
功能：
- 两站之间的车次查询
- 具体某车次的查询
- 进出某车站所有车次的查询
- 车票预订（车票预定后，所需的座位被声明，其余座位解锁）
- 乘客取票（首先根据身份证号查询订单，然后修改订单状态）
- 用户的注册和登录，修改密码
- 订单管理（订单的查询和撤销等）
- 后台管理员系统（编辑列车、车票、预售期等相关信息）
系统设计：
一、分析阶段
（1）需求分析
- 业务需求：本系统主要的业务需求包括车次查询、车票预订
- 用户需求（用例图描述）：
- 行为需求（用例规约描述）
（2）领域建模
首先按照功能进行模块化的分离。
然后对分离出来的模块进行抽象。下面以查询和预订模块为例：
二、架构设计阶段
1. 概念型架构设计
（1）确定关键需求
车票预订是本系统的关键需求。
（2）概念性架构设计
步骤一、鲁棒性分析
鲁棒图（静态）：
鲁棒顺序图（动态）：
步骤二、 引入架构模式
步骤三、 质量属性分析
2. 实际架构设计
(1) 逻辑架构
车票预订的逻辑架构如下：
车票查询的逻辑架构如下：
票的状态图如下：
(2) 开发架构
(3) 运行架构
(4) 物理架构
(5) 数据架构
附加：
- 可增加求购和转让信息发布功能。
- 恰当使用AJAX技术进行信息的异步传输。
- 经常查询的数据要设置缓存。
- 系统可以扩展个make charge的模块，调用服务商提供的接口，这样就可以增加信用卡或支付宝支付功能，最好还能提供送票服务。
- 注意半段的车票可以继续出售问题的设计。
- 注意学生票、军人票等特殊票种的处理情况。
准备知识：
(1) 逻辑架构
l 思想：
逻辑架构的设计着重考虑功能需求，即系统应向用户提供什么服务。
规定了软件架构由哪些逻辑元素组成，以及这些逻辑元素之间的关系。
逻辑架构的设计往往是从用例分析开始的，然后综合这些用例分析成果，得到整个软件系统的逻辑架构。
逻辑架构设计要实现层、子系统、模块等的划分决定交互接口和交互机制（交互机制是指不同软件单元之间交互的手段。交互机制的例子有：方法调用、基于RMI的远程方法调用、发送消息等。）
l 关注点：功能需求、行为和职责的划分，将不同的职责分配给逻辑层、功能模块、类等不同力度的逻辑单元。
l 工作任务：
- 细化功能单元
- 发现通用机制（机制Mechanism是模式的实例。机制必须进一步细化才能成为特定模型中的协作，因此机制是独特上下文中重复出现的问题的特定解决方案。）
- 细化领域模型
- 确定子系统接口和交互机制
l 描述方式：
静态：包图、类图、对象图。
动态：序列图、协作图、状态图、活动图。
(2) 开发架构
l 思想：开发架构的设计着重考虑开发期质量属性，例如可扩展性、可重用性、可移植性、易理解性、易测试性等。
l 关注点：软件模块的实际组织方式，具体涉及源程序文件、配置文件、源程序包、编译及打包后的目标文件、第三方库文件等。
l 工作任务：
- 确定要开发或直接利用的程序包之间的依赖关系
- 确定采用的技术
- 确定采用的框架等
l 关系：
开发架构和逻辑架构是什么关系？开发架构和逻辑架构之间存在一定的映射关系：比如逻辑架构中的逻辑层一般会映射到开发架构中的多个程序包；开发架构中的源码文件可以包含逻辑架构中的一到多个类。
l 描述方式：包图、类图、组件图。
(3) 运行架构
l 思想：运行架构的设计着重考虑运行期质量属性。
l 关注点：进程、线程、对象等运行时概念，已经相关的并发、同步、通信等问题。
l 工作任务：
- 确定引入哪些进程与线程
- 确定主动对象、被动对象、以及控制流关系
- 处理相关问题：进程线程的创建、销毁、通信机制、资源争用等
- 协议设计（可选，例如基于TCP/IP协议定义本系统的“应用协议”）
l 关系：
开发架构和运行架构是什么关系？开发架构偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，运行架构比较关注的是这些运行时单元的交互问题。运行架构是在开发架构的基础上，从宏观上规划多条控制流的并发和同步。
l 描述方式：
静态方面可用包图、类图、对象图
动态方面可用序列图、协作图
(4) 物理架构
l 思想：
物理架构的设计着重考虑安装和部署需求。
规定了软件架构由哪些物理元素组成，以及这些物理元素之间的关系，以及这些物理元素部署到硬件上的策略。
物理架构反映出软件系统动态运行时的组织情况。
物理元素就是进程、线程、作为类的运行时实例的对象等，而进程调度、线程同步、进程或线程通信等则进一步反映物理架构的动态行为。
架构设计中可能需要专门说明数据是如何产生、存储、共享、复制的，这时可以利用物理架构，展示软件系统在运行期间数据是由哪些运行时单元产生、如何产生、数据如何被使用、如何被存储、哪些数据需要跨网络复制和共享等方面的设计决策。
软件系统在计算机中运行期间的并发和交互情况（物理架构设计方案中规定了软件系统如何使用进程和线程完成期望的并发处理，进程线程这些主动对象会调用哪些被动对象参与处理，交互机制(如消息)为何等问题，从而为详细设计和编程实现提供了工作目标的动态视图。）
l 关注点：安装和部署需求。
l 工作任务：
- 确定物理配置方案（网络方案）
- 确定如何将目标程序映射到物理节点
l 关系：
物理架构和运行架构是什么关系？物理架构重视目标程序的静态位置问题，运行架构关注目标程序的动态执行情况。
l 描述方式：
部署图、组件图
(5) 数据架构
l 思想：数据架构的设计着重考虑数据需求。
l 关注点：持久化数据的组织。
l 工作任务：
l 描述方式：
E-R图和数据流图
类图和活动图（可以用类图替代E-R图，用带对象流的活动图替代数据流图） |
