下载文档原格式
售票系统设计⽅案1.架构设计1. 系统架构选型从软件架构⾓度，本系统采⽤了MVC分层的设计思想，各层级只需要关注本⾝的设计，⽽不需要关注其他层级的内部细节，层与层之间定义了良好的交互⽅式。
具体⽽⾔，本系统可以分为三个⽔平层，分别是展⽰层，业务服务层和数据库层；系统总体结构如下图所⽰。
2. 软件架构风格本系统采⽤浏览器-服务模式（B/S模式），该模式是Web兴起后的⼀种⽹络结构模式。
相⽐较传统的C/S模式，B/S结构的重要特征就是分布性强、开发简单、共享性强、总体拥有费⽤低。
这种模式统⼀了客户端，将系统功能实现的核⼼部分集中到服务器上，简化了系统的开发、维护和使⽤。
BS架构优势总结如下：● 分布性强，客户端零维护。
只需有⽹络、浏览器，能够随时随地实⾏查询、浏览等业务处理。
● 业务扩展简单便利，通过添加⽹页就可以添加服务器功能。
● 维护简单便利，只须要更改⽹页，就可以完成全部⽤户的同步更新。
● 开发简单，共享性强。
2. 业务概念原型1. ⽤例设计⽤户主要功能：⽤户注册、⽤户信息维护、查找车票、购买车票、改签及退票后台管理员主要功能：列车信息维护、站点信息维护、车次设置2. UML类图设计根据业务需求描述，结合⾯向对象的思想，抽象出类、属性、⽅法，同时确定概念之间的关系，构建UML类图：3. 数据库设计采⽤关系数据库mysql进⾏设计（1）⽤户表（2）⾓⾊表（3）⽤户⾓⾊关联表（4）车次表（5）列车表字段名称字段类型字段描述userId int主键account varchar账号password varchar密码name varchar姓名sex varchar性别phonenum number电话号码certificate_type varchar证件类型certificate_num number证件号码authority varchar权限info varchar其它信息字段名称字段类型字段描述roleId int主键role_type varchar⾓⾊类型authority varchar权限descr varchar描述字段名称字段类型字段描述urId int主键userId int⽤户主键【外键】roleId int⾓⾊主键【外键】字段名称字段类型字段描述trainSequenceId int主键trainNum number车次号trainId int列车号start_station varchar起点站end_station varchar终点站launch_time datetime启动时间字段名称字段类型字段描述trainId int主键（6）车厢表（7）座位表（8）站点表（9）车次站点表（10）订单表trainName varchar列车名称【外键】type varchar列车类型carriage_num int车厢数status int状态字段名称字段类型字段描述carriageId int主键trainId int列车主键【外键】carriage_number int车厢号carriage_type int车厢类型price_coef int价格系数字段名称字段类型字段描述seatId int座位主键carriageId int车厢主键【外键】trainId int列车主键【外键】seat_number int座位号bitmap int座位站点状态位图字段名称字段类型字段描述stationId int站点主键name varchar站点名称descr varchar站点级别字段名称字段类型字段描述train_sta_Id int车次站点主键trainSequenceId int车次主键【外键】station_sequence int站点序列arrive_time datetime到达时间lanch_time datetime启动时间字段名称字段类型字段描述orderId int订单主键userId int⽤户主键【外键】seatId int座位主键【外键】order_time datetime时间status varchar订单状态（11） 字典表4. 分解视图针对业务模块进⾏分解5. 实现视图项⽬的⽬录结构设计本项⽬采⽤MVC 分层架构，其中，主流的⽬录结构设计是按照controller 、service 、dao 层来进⾏分包。
课程设计名称：数据库应用课程设计专业班级：学生姓名：学号：指导教师：课程设计时间：计算机应用技术专业课程设计任务书目录1．需求分析 (2)（1）功能需求 (2)（2 ）数据流图 (3)2. 概念结构设计 (5)3. 逻辑结构设计 (6)（1）关系模式 (6)（2）外模式： (6)4. 物理结构设计 (8)（1）实验环境： (8)（2）系统软件结构图： (8)5. 数据库实施和维护 (9)6. 数据库的操作界面 (13)7. 课程设计的过程、体会及建议 (14)参考文献........................................... 错误！未定义书签。
1．需求分析系统应具有售票、查询、管理和维护等功能，系统管理员可以进行对车次的更改、票价的变动及调度功能，票价的修改可以通过修改运价来进行，车次调度可通过对发车时刻表的修改来进行，维护功能即可对表进行修改。
（1）功能需求经过分析后确定系统应具备以下功能：（1）售票功能1.销售车票任一售票员均可以售权限范围内车次的客票，权限可按班次、车属等属性由管理员设置。
可售全票、半票2.预订车票预订票可在任一未停止售票的车次上进行操作，预订数量仅受剩余位数量限制。
预订的客票售票员不能售出。
预订的客票也可取消预订，取消预订的客票售票员可以售出。
在订票人来取票时，售票员可将预订的客票从电脑上售出3.退票退票时由退票员输入客票的编号，计算机将根据退票时的时间，自动确定退票手续费的比例,也可由系统管理员指定手续费比例。
对不合法的客票（如已办理退票手续的客票、超过规定时间的客票、没有售出的客票、已经作废的客票、不属于权限范围内售出的票等），计算机将自动识别，不予退票。
（2）查询功能①车次查询，可以查询各个班次和票情况。
②时刻表查询：查询任一时刻的班次和票情况。
③售票情况查询：查询已售票和剩余票数的情况。
（3）、调度功能①运价修改：只有管理员有这一权限，根据各种调整票价。
山西大学商务学院《软件工程课程设计》报告题目: 火车站售票管理系统的设计与实现班级：10软件G2班组长：景巧鑫一、火车站售票管理系统二、小组成员及任务分配情况1. 开发目的和意义 ........ 1.1研究背景............ 1.2开发目的和意义.… 1.3完成情况 ............ 2. 开发技术及方法 ........ 2.1开发环境和开发工具 2.2技术及方法 .......... 2.2.1 B/S 模式 ........ 2.2.2 .NET ........... 2.2.3 ........ 3. 系统分析 .............. 3.1可行性分析 .......... 3.1.1 3.1.2 3.1.3 经济可行性技术可行性 操作可行性 3.2需求分析..... 3.2.1 功能需求 3.2.2数据需求 3.2.3性能需求 4. 系统设计 ....... 4.1总体设计..... 4.2详细设计..... 4.2.1过程设计 4.3数据库设计.. 4.3.1 4.3.2 4.3.3 4.3.4 用户表 ........ 车次详细信息表 订票纪录表 —— 退票纪录表 ……5.系统实现 .......5.1系统登录界面.2..3..3 ..3 ..3 ..3 ..4 ..5 ..5 ..5 ..5 ..5 ..5 ..5 ..8 ..9 10 10 10 10 16 16 17 17信息学院《软件工程课程设计》报告-II -5.2系统管理员登录界面 5.3票务管理员登录界面 5.4乘客登录界面........ 6. 系统测试 .............. 6.1测试方法 ............ 6.2测试过程 ............ 6.3测试结果 ............ 7. 总结 ................... 7.1小结 ................ 7.2实践感想 ............ 参考文献 ................ 附录 附录 附录 附录 1 2 3 4 可行性分析文档 需求分析文档 详细设计文档 系统测试文档19 20 21 22 22 22 22 24 24 24 26 27 30 33 391.开发目的和意义1.1研究背景用信息化推动工业化，用信息技术改造传统产业，这是我国迫切要完成的一项战略性任务。
铁路售票系统架构评审文档虚拟的一人多角色的评估小组，成员列表如下：表1：评估小组成员列表目录铁路售票系统架构评审文档 (1)引言 (3)编写目的： (3)背景： (3)定义： (3)三层架构软件设计 (3)ATAM架构评审模式 (4)参考资料： (5)第0阶段：合作关系及准备工作 (5)第1阶段：评估阶段 (6)项目产品立项表述： (6)架构方法分类： (6)架构表述： (8)初步架构类图： (9)质量属性及采用的战术： (9)生成质量属性效用树： (10)初步分析架构方法： (12)性能 (13)可用性 (14)安全性 (14)战术采用 (15)第2阶段：评估阶段 (16)集体讨论并确定场景的优先级： (16)再次分析架构方法： (17)三层结构选择 (17)LRU缓冲技术分析 (18)MD5加密存储分析 (18)备份数据库 (18)改进架构类图 (19)结果表述 (20)第3阶段：后续阶段 (20)附录 (20)拟采用架构评审方法中的ATAM方法 (20)引言编写目的：本文档的编写目的是对铁路售票系统架构设计进行简略的评审，为后继的详细项目设计等工作提供参考和依据，本文档主要描述的内容有：●表述●调查和分析●测试●形成报告本文档的预期读者为：系统设计人员、测试人员、用户及其它有权限查阅本文档的相关人员。
背景：●系统名称：铁路售票系统●任务提出者：黄东鹏、张付俊、孙帅●开发者（承接单位）：开发小组●用户：网上订购铁路车票的人定义：三层架构软件设计所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机器上。
三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。
通常情况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通讯与中间层建立连接，再经由中间层与数据库进行交换。
12306流程架构设计1.引言1.1 概述12306是中国国家铁路局开发的在线订票系统，为乘客提供便捷的火车票购买和查询服务。
作为中国最大的铁路客运服务平台，12306的流程架构设计至关重要。
本文旨在探讨12306的流程架构设计要点，并为该系统的优化提供参考。
在进行12306流程架构设计之前，我们需要对该系统的概述进行了解。
12306系统一般包括用户界面、业务逻辑、数据库和外部接口等组件。
用户界面提供给用户进行查询、订购、退票等操作的页面，业务逻辑处理用户操作的请求并进行相应的业务处理，数据库储存用户信息、车票信息等数据，外部接口用于与其他系统进行交互。
12306的流程架构设计需要考虑以下几个重要因素。
首先，在用户界面方面，应该注重用户友好性和易用性，确保用户能够轻松地进行操作。
其次，在业务逻辑方面，需要设计合理的流程以满足用户的需求，同时考虑系统的性能和稳定性。
此外，数据库的设计应考虑数据的安全性和可扩展性，以便应对不断增长的用户数量和数据量。
最后，外部接口的设计需要与其他系统进行无缝集成，确保数据的准确和及时交换。
12306的流程架构设计的目的主要是为了提供高效、稳定和安全的服务。
通过合理的架构设计，可以提高系统的性能，并能应对高并发的请求。
此外，良好的架构设计还可以降低系统的维护成本，便于功能的扩展和更新。
综上所述，12306的流程架构设计是一个复杂而重要的任务，需要综合考虑用户界面、业务逻辑、数据库和外部接口等各个方面的因素。
只有通过科学、合理的架构设计，才能为用户提供更好的服务体验，并为系统的优化和发展提供支持。
1.2 文章结构文章结构部分是为了让读者可以清楚地了解整篇文章的组织结构和内容安排。
本文的文章结构如下所述：首先，在引言部分，我们将概述本文的背景和目的，以及阐明文章的重要性和意义。
接着，在正文部分，我们将详细介绍12306流程架构设计的要点。
这些要点将涵盖12306流程的各个方面，包括流程的整体架构和关键环节的设计。
票务系统架构分析报告1．概述该报告用于完成课程设计，旨在了解对构架的分析，以及各种战术的运用。
本文档包含四个方面的内容：案例背景、构架商业周期、质量属性需求和功能需求、架构解决方案。
2．案例背景以目前的市场形势来说，在机票、火车票以及其它旅游票中有着不同的票务系统，票务系统的出现大大降低了买票、查票、退票、改签等活动的难度系数，在日常生活中有着不可替代的作用。
一个良好的票务系统，最基本应具有的质量应该是高性能，高可用，安全性高，易用性强的特征。
本分析报告研究的是一个火车票票务系统的构架。
3．构架商业周期构架MVC 模型票务系统客户在线订票的人开发组织技术环境 Eclipse 设计师经验 Java web 开发经验需求（质量属性） 高可用性 高性能 易用性 高安全性设计师（小组）4．质量属性需求和功能需求4．1 质量属性需求项目经理从开发组织和客户角度，可以将目标简化为如下：A.从开发组织角度：开发一个模块性强、实时性高、界面良好、与外部其它系统兼容良好的系统，这使得开发组织能够把整个产品或者某个木块卖给其他客户，同时由于良好的界面和业务处理效率而受市场的欢迎。
B.从客户的角度：系统容易操作，可维护性号、系统稳定、可以及时准确的处理用户的在线订票或查询业务。
根据上述的目标，将系统质量属性可以划分为两类：优先级较高的质量属性：1.性能2.安全性3.易用性4.可用性重要但是优先级较低的属性：1.模块性2.可维护性3.可修改性4.可测试性4．1 功能需求根据质量属性场景导出一定的功能需求以及对功能的一些规格，针对各质量属性，可以查看下表：质量属性属性求精场景性能响应时间在系统处于高峰时期，保证登陆的每个用户发出的买票或者查询要求在3S以内，如果需要等待，则给出友好的提示。
吞吐量系统可以保证同事响应3000个客户。
易用性界面友好，操作简单要求具有基本电脑操作的人，可以根据友好的界面迅速的学会使用方法。
并且熟手还能够使用快捷键。
学校代码： 10128学号：200810205021 200810205024200810205045 200820205059 课程设计说明书题目:车站售票管理系统-可行性分析报告学生姓名：苗欣宇张玲燕马星周伟学院：信息工程学院班级：软件工程08-2班指导教师：田保军教授张林丰讲师2011年7月15日目录1．引言 (1)1.1编写目的 (1)1.2项目背景 (1)1。
3定义 (1)1.4参考资料 (2)2．可行性研究的前提 (2)2.1要求 (2)2.2目标 (3)2。
3条件、假定和限制 (3)2.4可行性研究方法 (3)2.5决定可行性的主要因素 (3)3．对现有系统的分析 (4)3。
1处理流程和数据流程 (4)3.2工作负荷 (8)3.3费用支出 (8)3。
4人员 (9)3。
5设备 (9)3。
6局限性 (10)4．所建议技术可行性分析 (10)4。
1对系统的简要描述 (10)4.2与现有系统比较的优越性 (10)4。
3采用建议系统可能带来的影响 (10)4。
3.1对设备的影响 (10)4.3。
2对现有软件的影响 (10)4。
3.3对用户的影响 (10)4。
3。
4对系统运行的影响 (11)4。
3.6对运行环境的影响 (11)4.3。
7对经费支出的影响 (11)4。
4技术可行性评价 (11)5．所建议系统经济可行性分析 (11)5。
1支出 (11)5。
1.1基建投资 (11)5.1。
2其他一次性支出 (11)5.1.3经常性支出 (12)5.2效益 (12)5.2。
1一次性收益 (12)5.2。
2经常性收益 (12)5.2.3不可定量收益 (12)5。
3收益/投资比 (12)5.4投资回收周期 (12)5。
5敏感性分析 (13)6．社会因素可行性分析 (13)6。
1法律因素 (13)6。
2用户使用可行性 (13)7．其他可供选择的方案 (13)8.结论意见 (14)1．引言1。
1编写目的可行性研究的目的为明确将要设计的软件是否有开发价值，以最小的代价在最短的时间内确定问题是否可解。
概要设计说明书目录1．引言 (1)1.1编写目的 (1)1.2项目背景 (2)1.3定义 (2)1.4参考资料 (3)2.1目标 (3)2.2运行环境 (4)2.3需求概述 (4)2.4条件与限制 (5)3．总体设计 (6)3.1处理流程 (6)3.2总体结构和模块外部设计 (9)3.3功能分配 (10)4．接口设计 (11)4.1外部接口 (11)4.2内部接口 (11)5．数据结构设计 (12)5.1逻辑结构设计 (12)5.2物理结构设计 (14)5.3数据结构与程序的关系 (15)6．运行设计 (16)6.1运行模块的组合 (16)6.2运行控制 (16)6.3运行时间 (17)7．出错处理设计 (17)7.1出错输出信息 (17)7.2出错处理对策 (17)8.安全保密设计 (18)9.维护设计 (18)1．引言1.1编写目的该阶段开发正式进入软件的实际开发阶段，本阶段完成系统的概要设计并明确数据结构与软件体系结构。
主要是把一个软件需求转化为软件表示的过程。
本文档的目的旨在推动软件工程的规范化，使设计人员遵循统一的概要设计书写规范，节省制作文档的时间，降低系统实现的风险，做到系统设计资料的规范性与全面性，以利于系统的实现、测试、维护、版本升级等。
为这个项目以后的扩展和其他功能开发人员提供背景资料和参考。
完成：1.将系统划分成物理元素，即程序、文件、数据库、文档等。
2.设计软件结构，即将需求规格转换为体系结构，划分出程序的基本模块组成，确定模块的相互关系，并确定数据结构与算法。
读者对象：程序员、测试员。
1.2项目背景火车票出售管理系统是典型的信息管理系统(MIS),其开发主要包括后台数据库的建立和维护以及前端应用程序的开发两个方面。
本项目适用于Windows操作系统，使用SQL Server 2005数据库，利用JAVA开发语言开发系统。
1.3定义1．Windows：微软公司推出的视窗电脑操作系统名为windows,随着电脑硬件和软件系统的不断升级，微软的windows操作系统也在不断升级，从16位、32位到64位操作系统。
铁路客票系统架构设计前言什么才是12306最需解决的问题？1、重大节假日前期，系统登陆难。
2、抢票环节的并发处理能力。
3、余票查询的响应速度。
人们往往有先入为主的观念，导致了解决问题的思维方式收到束缚，难以跳出既定的圈子。
谁能说现在的购票系统的业务逻辑和用户体验是最合理的呢？它的设计合理之处又在哪里呢？我想完全不懂技术的人做产品经理，可以比技术出身的人做的更好，因为不懂技术的产品经理提出的需求不会受技术的束缚，更加注重用户体验。
12306的余票查询的用户体验太糟糕了，为什么非要有帐号才可以查询-_-购票系统的功能架构和技术架构，势必要考虑到峰值的处理能力，尤其是超大规模并发的处理能力。
12306虽说是非盈利性的，但是这毕竟关乎到民生，为何不公开技术架构，让更多的人参与改进呢？以上内容可以忽略。
以下是我的设计思路，主要采用功能适度分离的思想进行设计。
1、余票查询的优化方案将余票查询系统与抢票系统功能分离，余票查询系统部署到镜像站点CDN上，抢票系统应用单独部署，支付和退票应用单独部署。
（这点很关键）数据库的读写分离，主数据库只做写操作，写入购票记录和更新实时余票信息，余票查询库可以通过异步更新获取余票信息。
余票查询功能可以基于部署到CDN上，建议免登陆，建议向社会开放余票资源和API。
（解决查票问题）余票查询系统的系统架构。
我们需要什么级别的实时性？毫秒级？不需要！余票查询的操作远大于抢票，每1秒内信息的变化都难以想象，所以在余票查询上实时性太高意义不大，只能作为抢票前的参考，所以也没必要一定要用关系数据库，NOSQL其实很合适。
系统只要保证购票者在信息获取是平等的，抢票环节是公平的（按照先购先得的原则），然后进行适度优化设计。
余票查询的系统架构，我有2个设计方案1) 内存数据为主、数据库为辅方案。
写一个分布式数据分发系统（主站为SApp，镜像站点为CApp），支持远程调用更新，设计特定的类或数据结构，将所有待出售的车票余票信息存储在特定的类或数据结构中（也可以是数据缓存），常驻内存。
铁路售票系统架构评审文档虚拟的一人多角色的评估小组，成员列表如下：表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)备份数据库 (12)改进架构类图 (13)结果表述 (14)第3阶段：后续阶段 (14)附录 (14)拟采用架构评审方法中的ATAM方法 (14)引言编写目的：本文档的编写目的是对铁路售票系统架构设计进行简略的评审，为后继的详细项目设计等工作提供参考和依据，本文档主要描述的内容有：●表述●调查和分析●测试●形成报告本文档的预期读者为：系统设计人员、测试人员、用户及其它有权限查阅本文档的相关人员。
背景：●系统名称：铁路售票系统●任务提出者：黄东鹏、张付俊、孙帅●开发者（承接单位）：开发小组●用户：网上订购铁路车票的人定义：三层架构软件设计所谓三层体系结构，是在客户端与数据库之间加入了一个中间件层，也叫组件层。
这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有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) 可扩充架构方法分类：进行了架构表述后，评估小组列出他们曾听到的架构方法，以及那些在对文档进行评估前的评审中所了解到的方法：一、分层架构这种架构将软件分成若干个水平曾，每一层都有清晰的角色和分工，不需要知道其他层的细节，层与层之间通过接口通信。
二、事件驱动架构事件是状态发生变化时，软件发出的通知。
事件驱动架构就是通过事件进行通信的软件架构。
分为：事件队列、分发器、事件通道、事件处理器。
三、微核架构又称为“插件架构”，指的是软件的内核相对较小，只要功能和业务逻辑都通过插件实现。
内核通常只包含系统运行的最小功能。
插件则是相互独立的，插件之间的通信，应该减少到最低，避免出现相互依赖的问题。
四、微服务架构是服务导向的架构的升级。
每一个服务都是一个独立的部署单元。
这些单元都是分布式的，互相解耦，通过远程通信协议联系。
五、云架构云架构主要解决扩展性和并发问题，是最容易扩展的架构。
它的高扩展，主要原因是没使用中央数据库，而是把数据都复制到内存中，变成可复制的内存数据单元。
然后，业务处理能力封装成一个个单元。
比如访问量增加，就新建单元处理；访问量减少，就关闭但处理单元。
由于没有中央数据库，所以扩展性的最大瓶颈消失了。
由于每个处理单元的数据都在内存里，最好要进行数据持久化。
这个模式主要分成两部分：处理单元和虚拟中间件。
架构表述：软件架构是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。
软件架构是一个系统的草图。
软件体系结构是构建计算机软件实践的基础。
考虑到票务系统的特点，将使用三层结构进行系统的架构。
初步架构类图：质量属性及采用的战术：生成质量属性效用树：下表给出了在对铁路售票系统评估期间生成的质量属性效用树，有几个质量属性求精没有与之相关的场景。
这种情况经常出现，这并不是问题，对于某个质量属性，人们有时能够想出一个合理的求精，但当让他们在自己的系统的上下文中对该质量属性的用例进行说明时，却发现该求精实际上并不适用。
表 2：对铁路售票系统进行ATAM 评估的效用树表格 质量属性 属性求精 场景性能最大负载响应时间当开票时，用户量剧增，能够同时负载至少500的用户同时访问（H,H ）用户输入数据后在网络畅通的情况下应能在s 内给出相关信息（H,M ）注册验证登录验证密码强度库；当用户登录时，系统将数据加密后再与数据库的内容进行比较，防止传输过程被窃取泄露。
（H,L ） 当用户注册时,为确认为真人操作，存在手机信息验证码验证，并且60s 内不允许重复获取验证码。
（H,L ） 当用户登录时，连续输入两次错误密码后，再次登录需要根据系统给出图片验证码输入正确的验证码才能完成登录，图片验证内容随机生成，并且随机生成条纹遮挡字符，防止机器验证。
（H,L ）当用户注册时系统根据用户的密码显示相应的密码强度以提示用户增强密码强度。
密码强度根据密码内容字符类型以及长度确定。
为了确保基本的安全性以及防止用户遗忘密码，用户密码长度范围限制为6-16位。
（H,L ） 易用性用户通过输入简单的查询信息就能够得到对应的相关数据并让用户轻易完成购买（H,M ）兼容性多系统支持在相同平台的不同系统上也能够正常运行（H,H ）可维护性管理员功能维护管理系统自动报错管理员能够在铁路信息、用户信息需要更新时进行及时更新，并同步数据给用户（H,M）当出现了不可避免的错误时，可以及时进行维护修复（H,M）可以定位出系统报错内容、报错位置（M,L）可扩展性添加新功能在出现新需求时能够添加新功能，如支付渠道的增加支付渠道的选择（M,L）可扩充性功能业务的子模块随着发展和意见的收集，能够根据情况添加新的业务功能，如外卖预定（M,M）可靠性不易出错在程序的使用过程中出错概率要尽量小，出错了要能够及时修复（H,H）表中的场景给出了决策者所分配的优先级。
在每一对有序的字母中，第一个代表能力的重要性，第二个代表设计师对实现该质量属性的难度的估计。
我们需要注意到，一些场景已经很完备了，具备了刺激、环境和响应三个部分；一些场景没有刺激，还有一些场景没有响应。
在这个阶段，只要涉众能够理解场景的含义，不明确的场景说明是允许的。
如果所选择的场景用于进行分析，那么该场景中的刺激和响应必须得到足够的明确。
初步分析架构方法：评估小组首先分析最重要而且最难实现的场景，每次分析一个最高优先级的场景，同时我们的设计师详细地解释了构架如何支持每个场景。
小组成员探查设计师用来实现场景的架构方法，把相关架构决策编成文档，一共确定了个8敏感点，4个风险点，3个无风险决策。
性能可用性安全性战术采用。
