AIS机票销售管理系统上交文档 yz212Word文件下载.docx
《AIS机票销售管理系统上交文档 yz212Word文件下载.docx》由会员分享，可在线阅读，更多相关《AIS机票销售管理系统上交文档 yz212Word文件下载.docx（24页珍藏版）》请在冰豆网上搜索。
5.1.2信息系统架构总体视图。
6
5.2关键技术设计。
5.2.1网上服务。
6.系统设计模式6
6.1用例图9
6.2类图9
6.3包和对象图11
6.4顺序图12
6.5协作图13
6.6状态图13
6.7活动图14
6.8组件与配置图15
7.布署视图16
8.数据视图16
9.大小和性能16
10.质量20
软件构架文档
•简介
目的
此文档从构架方面对系统进行综合概述，其中使用了大量不同的构架视图来描述系统的各个不同方面。
它用于记录并表述已在构架方面对系统作出的重要决定。
范围
本文档是为机票管理销售系统的web版本设计的，用于指导机票销售的的web版本。
定义、首字母缩写词和缩略语
SQLSERVER:
系统服务器所使用的数据库管理系统（DBMS）。
SQL:
一种用于访问查询数据库的语言
主键：
数据库表中的关键域。
值互不相同。
外部主键：
数据库表中与其他表主键关联的域。
预订单:
客户在网上填写订单后生成的未确认订单
订单:
可以包含多个预定机票，有唯一的订单ID号
订单状态：
可分为预定、已确认、送票。
参考资料
[1]张海潘.软件工程导论.北京：
清华大学出版社，2008.2
[2]张有生软件体系结构；
清华大学出版社，2009.7
•概述
软件架构的逻辑视图描述了该系统的主要结构和所采用的体系设计模式。
设计软件架构可以最大程度的重用系统的设计和代码，还可以明确系统中每个模块和对象的功能，避免重复功能的多次开发。
系统架构的逻辑视图也描述了最重要的组件，若干组件构成服务或子系统，子系统构成系统的层。
•构架目标和约束：
系统扩展性和灵活性需求，系统的设计需要具备足够的扩展性，以便于因发展或改变而对系统功能的调整和增加，便于系统升级和维护。
系统的扩展性包括功能的扩展性和数据扩展性。
需要采用B/S结构，使用户能通过互联网访问系统数据，支持远程管理和移动办公。
本软件架构以逻辑视图表示，用PowerDesiger工具基于统一建模语言（UML）开发的。
系统要求实现多层体系结构，服务器端考虑扩平台的应用，交互接口支持Web应用风格。
•系统分析
开发背景
机票的销售面对的用户是数以万计的，如果大量的机票仅用人工管理的话，很容易就会出错的，所以为了航空公司的售票能够得到统一管理，合理售票，便于管理，可以查看统计信息，为此我们开发了机票销售管理系统。
可行性分析
◆可行性研究的前提
组织目标和战略
企业管理是以优质的产品和销售服务向顾客提供物质或服务为目标，以使企业能够顺利发展。
具体分解为：
（1）最大限的满足顾客的所有要求和采纳顾客的合理建议和意见；
（2）每年增加新产品或服务及相关信息；
（3）及时了解全国该行业的最新信息以促进企业改革；
（4）对销售的产品或提供的服务及时统计，发布，以决定如何控制市场；
（5）不断改进企业各方面的管理办法，提高效率，方便管理；
（6）建立机票销售管理信息系统，全面提高管理水平和工作效率。
业务概况
假定该企业为国有企业，大型规模的机票销售型企业。
设有市场部，企划部等。
存在的问题
由于整个过程中牵涉到很多的部门，又是大企业客户之间的贸易往来，所以数据量极大，为了管理号这些信息并协调各部门之间的业务从而不得不投入大量的人力财力加以管理，导致效率低，人员消耗厉害，往往也达不到很好的效果形成事倍功半的局面。
◆拟建立的信息系统
简要说明
企业对该系统有以下几项基本要求:
（1）建立对整个企业业务提供全面管理的信息系统；
（2）对员工信息等的全面管理；
（3）对仓库的入库、出库、库存提供全面管理；
（4）对常旅客，大客户等提供全面管理。
对组织的意义与影响
本系统的开发能够减少企业一些不必要的投入，减少人员消耗，及时获得员工、旅客信息以及机票库存信息，提高工作效率。
◆经济可行性分析
运用该系统可以对员工、常旅客，大客户及机票的库存通过数据库加以统一管理，财务部门可以通过该系统得到最新的机票销售信息，企业可以征对这些信息制定本阶段公司的对各个航线的政策。
◆技术可行性分析
本系统初步设想是运用web以及数据库知识开发的，由于本小组人员有一定的数据库开发以及web编程知识，所以开发中不存在太多技术问题，完全是可行的。
◆社会可行性分析
目前很多的企业在管理运行中都在采用科学的信息系统管理方法加以统一管理，运用科学的管理方法可以在同样的收益下，因为投入的相对减少而获得经济利润的增加，这样的成功例子有很多，因此，该系统具有可行性。
◆可行性研究结论
通过经济，技术，社会等方面的可行性分析，可以确定本系统开发的必要性而且是完全可行的，可以马上立项开发。
需求分析
◆引言
编写目的
本文档是征对某公司编制的物流信息管理系统的需求分析。
主要目的是为下阶段的设计、开发提供依据，为项目组成员对需求的详尽理解，以及在开发过程中的协同工作提供强有利的保证。
同时本文档也作为项目评审验收的依据之一。
◆任务概述
目标
系统能够提供友好的用户界面，使操作人员的工作量最大限度地减少；
系统有良好的运行效率，能够达到提高生产率的目的；
系统应有良好的可扩充性，可以容易地加入其它系统的应用；
平台的设计具有一定的超前性，能够适应企业生产配置的变化；
用户的特点
①用户
用户是指在这个机票管理系统中通过客户端登陆本系统，查看信息明细，选择需要的服务。
老用户可直接登陆，新用户需注册之后在登录。
②管理用户
管理系统的用户主要是某公司管理人员，完成目标为：
（1）．统计机票销售信息
增加新闻
新增新闻信息，供物流信息服务平台用户浏览。
修改新闻
修改或删除已有新闻信息
新闻查询
根据条件查询满足条件的新闻信息。
（2）．物流需求项目发布：
发布新项目信息
某公司代替物流需求企业发布新的需求项目。
物流需求项目维护
某公司管理人员对还没有发布的信息进行维护（包括服务平台上物流需求企业发布的需求项目和该公司替物流需求企业发布的需求项目）。
物流需求项目审批
某公司管理人员对物流需求企业发布的项目进行维护。
物流需求项目停用
对于已经发布的项目，某公司管理员可以选择停用。
（3）．数据字典：
区域维护
维护区域信息，用于对物流信息平台的用户按照所在区域进行划分。
行业维护
维护行业信息，用于对物流信息平台的用户按照所从事行业进行划分。
（4）．平台用户管理
企业信息管理
管理员对物流信息服务平台的企业进行管理：
包括增加、启用、停用修改、查询服务平台企业。
网站用户管理
对物流信息平台的用户进行管理：
包括增加、启用、停用、修改、查询服务平台用户。
以及给用户分配角色。
网站用户审批
对于注册未审批的用户进行审批操作。
网站角色管理
对角色进行管理:
包括增加、删除、修改、查询角色，以及给角色分配权限。
管理系统用户管理
对管理系统的用户进行管理：
包括增加、启用、停用、修改、查询管理系统用户，以及给用户分配角色。
管理系统角色管理
对角色进行管理：
◆需求规定
对功能的规定
物流管理系统可以分为两个主要的组成部分，一个是客户端子系统，一个是管理端子系统。
客户端子系统功能主要是指用户通过登陆物流信息网站进行操作的功能，即信息查看功能，选择功能。
管理端子系统功能是某公司的管理人员可发布相关物流信息，发布新闻等功能。
客户端功能分析
客户端需实现的功能：
（1）查看货源信息。
用户（包括普通用户和会员）登录到物流管理系统网站可以看到系统发布的相关货源信息，用户可以进行查看，同时对自己感兴趣的可以选择详细查看，查看详情。
（2）查看车源信息。
用户（包括普通用户和会员）登录到物流管理系统网站可以看到系统发布的相关车源信息，用户可以进行查看，同时对自己感兴趣的可以选择详细查看，查看详情。
（3）查看专线信息。
用户（包括普通用户和会员）登录到物流管理系统网站可以看到系统发布的相关专线信息，用户可以进行查看，同时对自己感兴趣的可以选择详细查看，查看详情。
（4）查看企业信息。
用户（包括普通用户和会员）登录到物流管理系统网站可以看到系统发布的相关企业信息，用户可以进行查看，同时对自己感兴趣的可以选择详细查看，查看详情。
（5）查看仓库信息。
用户（包括普通用户和会员）登录到物流管理系统网站可以看到系统发布的相关仓库信息，用户可以进行查看，同时对自己感兴趣的可以选择详细查看，查看详情。
（6）查看招聘息信。
用户（包括普通用户和会员）登录到物流管理系统网站可以看到系统发布的相关招聘信息，用户可以进行查看，同时对自己感兴趣的可以选择详细查看，查看详情，详情包括招聘职位，招聘时间，招聘人数，招聘要求限制等。
（7）会员同时可以发布信息，普通用户可以申请成为会员，享有更高的权利。
以上各功能的执行者都是用户，前置条件是在用户登录系统之后，后置条件是可以点击自己感兴趣的内容进行详细查看。
基本路径是：
用户登录到系统首页，显示车源、货源、专线、企业、招聘信息，发布新闻、消息的日期。
点击自己感兴趣的内任何一项容，即可以查看详细信息。
3.3.2管理端子系统需实现的功能：
管理员登录到物流管理系统网站可以看到系统发布的相关货源信息，同时可以发布新的货源信息。
管理员登录到物流管理系统网站可以看到系统发布的相关车源信息，同时可以发布新的货源信息。
管理员登录到物流管理系统网站可以看到系统发布的相关专线信息，同时可以发布新的货源信息。
管理员登录到物流管理系统网站可以看到系统发布的相关企业信息，同时可以发布新的货源信息。
管理员登录到物流管理系统网站可以看到系统发布的相关仓库信息，同时可以发布新的货源信息。
管理员登录到物流管理系统网站可以看到系统发布的相关招聘信息，同时可以发布新的货源信息。
（7）发布消息。
管理员可以以管理员的身份登录，发布消息。
（8）信息管理。
管理员可以以管理员的省份登录，对信息进行管理。
（9）用户管理。
管理员可以以管理员的省份登录，对用户进行管理。
（10）新闻管理。
管理员可以以管理员的省份登录，对新闻进行管理。
以上各功能的执行者都是管理员，查看信息的前置条件是在打开系统首页之后，后置条件是可以点击自己感兴趣的内容进行详细查看。
而发布信息的前置条件是管理员必须以管理员的身份登录系统，后置条件是对所要发布信息进行添加即可添加新的发布信息。
基本路径是：
•登录系统，打开系统首页，显示车源、货源、专线、企业、招聘信息，发布新闻、消息的日期。
•点击自己感兴趣的内任何一项容，即可以查看详细信息。
或者进入消息发布区，对所要发布的信息进行发布。
•系统整体构架
体系结构概述
体系架构视图反映了系统的技术组成和关键技术的集成框架。
在进行构架设计时，重点考虑了对架构影响的需求：
•多层体系结构：
系统基于多层体系结构设计。
•单点登录：
用户只需要登录一次，而不需要重复登录。
•门户集成：
应用通过Web发布，为用户提供个性化服务的能力。
•工作流应用：
系统中存在多人参与的应用，这些应用需要协作才能完整，并且要求参与的角色和可能的流程可以被修改。
•信息整合：
信息单一存储，减少信息的冗余度。
•如何整合历史系统和外部系统：
由于系统的历史系统并不能全部在新系统建立时集成，并且存在一部分外部系统，需要考虑如何集成这些系统到新系统中。
其它因素，如应用系统的逻辑分层，因为并不影响产品和技术架构，所以在结构视图中并不过多考虑，而在逻辑视图中体现。
根据以上需求，建立以多层体系为基础的系统架构。
◆多层体系架构
关于三层架构（3-tierapplication）通常意义上的三层架构就是将整个业务应用划分为：
表现层（UI）、业务逻辑层（BLL）、数据访问层（DAO）。
区分层次的目的即为了“高内聚，低耦合”的思想。
１、表现层（UI）：
通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。
２、业务逻辑层（BLL）：
针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。
３、数据访问层（DAO）：
该层所做事务直接操作数据库，针对数据的增、删、改、查。
三层结构原理：
3个层次中，系统主要功能和业务逻辑都在业务逻辑层进行处理。
所谓三层体系结构，是在客户端与数据库之间加入了一个“中间层”，也叫组件层。
这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机器上。
三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。
通常情况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通讯与中间层建立连接，再经由中间层与数据库进行交互。
表示层 位于最外层（最上层），离用户最近。
用于显示数据和接收用户输入的数据，为用户提供一种交互式操作的界面。
业务逻辑层 业务逻辑层（BusinessLogicLayer）无疑是系统架构中体现核心价值的部分。
它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计，也即是说它是与系统所应对的领域（Domain）逻辑有关，很多时候，也将业务逻辑层称为领域层。
例如MartinFowler在《PatternsofEnterpriseApplicationArchitecture》一书中，将整个架构分为三个主要的层：
表示层、领域层和数据源层。
作为领域驱动设计的先驱EricEvans，对业务逻辑层作了更细致地划分，细分为应用层与领域层，通过分层进一步将领域逻辑与领域逻辑的解决方案分离。
业务逻辑层在体系架构中的位置很关键，它处于数据访问层与表示层中间，起到了数据交换中承上启下的作用。
由于层是一种弱耦合结构，层与层之间的依赖是向下的，底层对于上层而言是“无知”的，改变上层的设计对于其调用的底层而言没有任何影响。
如果在分层设计时，遵循了面向接口设计的思想，那么这种向下的依赖也应该是一种弱依赖关系。
因而在不改变接口定义的前提下，理想的分层式架构，应该是一个支持可抽取、可替换的“抽屉”式架构。
正因为如此，业务逻辑层的设计对于一个支持可扩展的架构尤为关键，因为它扮演了两个不同的角色。
对于数据访问层而言，它是调用者；
对于表示层而言，它却是被调用者。
依赖与被依赖的关系都纠结在业务逻辑层上，如何实现依赖关系的解耦，则是除了实现业务逻辑之外留给设计师的任务。
数据层（dataaccessObject） 数据访问层：
有时候也称为是持久层，其功能主要是负责数据库的访问，可以访问数据库系统、二进制文件、文本文档或是XML文档。
•系统设计模式
用例图
机票销售管理系统可以分为两个主要的组成部分，一个是客户端子系统，一个是管理端子系统。
客户端子系统功能主要是指用户通过登陆机票销售信息网站进行操作的功能，即预定机票，确定机票，退票，查询订单。
系统的主用例如图1-2,1-3
图1-2客户用例图
图1-3管理员用例图
类图
类图Classdiagram通过显示出系统的类以及这些类之间的关系来表示系统。
类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响。
下面是一个顾客从零售商处预定商品的模型的类图。
中心的类是Order。
连接它的是购买货物的Customer和Payment。
Payment有三种形式：
Cash，Check，或者Credit。
订单包括OrderDetails（lineitem），每个这种类都连着Item。
UML类的符号是一个被划分成三块的方框：
类名，属性，和操作。
抽象类的名字，像Payment是斜体的。
类之间的关系是连接线。
类图有三种关系。
•关联association－表示两种类的实例间的关系。
如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联。
在图中，关联用两个类之间的连线表示。
•聚合aggregation－当一个类属于一个容器是的一种特殊关系。
聚合用一个带菱形的连线，菱形指向具有整体性质的类。
在我们的图里，Order是OrderDetails的容器。
•泛化generalization－一个指向以其他类作为超类的继承连线。
泛化关系用一个三角形指向超类。
Payment是Cash，Check和Credit的超类。
一个关联有两个尾端。
每个尾端可以有一个角色名rolename来说明关联的作用。
比如，一个OrderDetail实例是一个Order实例的项目。
关联上的方向性navigability箭头表示该关联传递或查询的方向。
OrderDetail类可以查询他的Item，但不可以反过来查询。
箭头方向同样可以告诉你哪个类拥有这个关联的实现；
也就是，OrderDetail拥有Item。
没有方向性的箭头的关联是双向。
关联尾端的数字表示该关联另一边的一个实例可以对应的数字端的实例的格数，通过这种方式表达关联的多样性multiplicity。
多样性的数字可以是一个单独的数字或者是一个数字的范围。
在例子中，每个Order只有一个Customer，但一个Customer可以有任意多个Order。
下面这个表给出了最普遍的多样性示例。
多样性
意义
0..1
0或1个实例.n..m符号表示有n到m个实例
0..*or*
没有实例格数的限制（包括没有）.
1
只有一个实例
1..*
最少一个实例
每个类图包括类，关联和多样性表示。
方向性和角色是为了使图示得更清楚时可选的项目。
包和对象图
为了简单地表示出复杂的类图，可以把类组合成包packages。
一个包是UML上有逻辑关系的元件的集合。
下面这个图是是一个把类组合成包的一个商业模型。
dependencies关系。
如果另一个的包B改变可能会导致一个包A改变，则包A依赖包B。
包是用一个在上方带有小标签的矩形表示的。
包名写在标签上或者在矩形里面。
点化线箭头表示依赖
对象图Objectdiagrams用来表示类的实例。
他们在解释复杂关系的细小问题时（特别是递归关系时）很有用。
每个类图的矩形对应了一个单独的实例。
实例名称中所强调的UML图表。
类或实例的名称可能是省略对象图表只要图的意义仍然是明确的。
顺序图
类图和对象图是静态模型的视图。
交互图是动态的。
他们描述了对象间的交互作用。
顺序图将交互关系表示为一个二维图。
纵向是时间轴，时间沿竖线向下延伸。
横向轴代表了在协作中各独立对象的类元角色。
类元角色用生命线表示。
当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线。
消息用从一个对象的生命线到另一个对象生命线的箭头表示。
箭头以时间顺序在图中从上到下排列。
协作图
协作图也是互动的图表。
他们像序列图一样也传递相同的信息，但他们不关心什么时候消息被传递，只关心对象的角色。
在序列图中，对象的角色放在上面而消息则是连接线。
协作图的每个消息都有一个序列号。
顶层消息的数字是1。
同一个等级的消息（也就是同一个调用中的消息）有同样的数字前缀，再根据他们出现的顺序增加一个后缀1，2等等。
状态图
对象拥有行为和状态。
对象的状态是由对象当前的行动和条件决定的。
状态图statechartdiagram显示出了对象可能的状态以及由状态改变而导致的转移。
我们的模型例图建立了一个银行的在线登录系统。
登录过程包括输入合法的密码和个人账号，再提交给系统验证信息。
登录系统可以被划分为四种不重叠的状态：
GettingSSN,GettingPIN,Validating,以及Rejecting。
每个状态都有一套完整的转移transitions来决定状态的顺序。
状态是用圆角矩形来表示的。
转移则是使用带箭头的连线表示。
触发转移的事件或者条件写在箭头的旁边。
初始状态（黑色圆圈）是开始动作的虚拟开始。
结束状态也是动作的虚拟结束。
事件或条件触发动作时用（/动作）表示。
活动图
活动图activitydiagram是一个很特别的流程图。
活动图和状态图之间是有关系的。
状态图把焦点集中在过程中的对象身上，而活动图则集中在一个单独过程动作流程。
活动图告诉了我们活动之间的依赖关系。
活动图可以被分解成许多对象泳道swimlanes，可以决定哪些对象负责那些活动。
每个活动都有一个单独的转移transition连接这其他的活动。
转移可能分支branch成两个以上的互斥的转移。
保护表达式（在[]中）表示转移是从一个分支中引出的。
分支以及分支结束时的合并merge在图中用菱形表示。
转移也可以分解fork成两个以上的并行活动。
分解以及分解结束时的线程结合join在图中用粗黑线表示
组件与配置图
组件component是代码模块。
组件图是是类图的物理实现。
配置图Deploymentdiagrams则是显示软件及硬件的配置。
下面的配置图说明了机票销售管理系统有关的软件及硬件组件
•布署视图
由于本方案采用Web模式设计，客户端只需要安装基本的操作系统和互联网浏览器就可以使用本系统，因此，系统的网络拓扑非常简单，如下图所示。
图中显示，本系统的网络结构主要由数据库服务器、应用服务器、WEB服务器和客户端组成。
物理上，这些服务器可在一台机器上运行，而可分别占用一台机器。
应用采用JSP方式运行。
图8-1web访问数据库，然后该网站显示页面图
•数据视图
系统主要涉及实体的E—R图如下图9-1：
图9-1
表名
功能说明
表类型（基础表？
业务表？
Airline
航空公司的基础信息
基础表
TypesOfCompanies
公司类型表（国内,国际）
Airway
航线的基本信息
TypeOfAirway
航线类型表，包括优惠航线和非优惠航线
City
城市表，中外的城市
Province
省份表
Country
国家家
FlightSchedu
升级会员 