软件设计与体系结构论文

《软件设计与体系结构论文》由会员分享，可在线阅读，更多相关《软件设计与体系结构论文（21页珍藏版）》请在金锄头文库上搜索。

1、word软件设计与体系结构非卷面试题设计题目 快餐店多功能点餐系统院 系 电子与信息工程学院专 业 计算机科学与技术学生某某 学生学号 任课教师 倪 启 东快餐店多功能点餐系统摘 要随着计算机软件行业的开展和互联网的普与，软件进入到人们生活的各个行业之中。在这个软件爆炸的时代，软件系统有一个好的设计与结构显得尤为重要。通过快餐店多功能点餐系统的设计，将软件体系结构与设计的所学的知识，运用到实际系统中，是对知识、技术的巩固，也是能力的提升。本系统主要运用增量模型，随着知识的学习同步进展系统的开发。主要采用了策略模式、观察者模式、装饰者模式、工厂模式、单例模式。同时，伴随着设计原如此的思想，使得系

2、统更加稳定而高效。关键词点餐系统；体系结构；设计模式；java目录第1章 绪论1111第2章 需求分析33333332.3.2 外部需求44444第3章 结构设计55567778第4章 设计模式999101010101111121213131313141415151515结论16致谢17参考文献18 / 第1章 绪论1.1 引言当今世界已进入信息时代，Internet成为21世纪最受关注的行业之一,它的飞速开展和在全球X围的普与应用正在给人类生活带来革命性变化。网络技术的开展也取得了巨大的成就，为开发提供了很好的技术支持。正基于这个背景，产生了快餐店多功能点餐系统。就我而言，主要是想通过快餐店

3、多功能点餐系统的开发，让自身在软件开发的知识水平提升一个档次，特别是对软件开发形成一种概念。也正如Head First设计模式中所说，对象村里的每个人都在使用设计模式。对于刚刚入住对象村的我，需要有一个和大师交流的机会，而快餐店多功能点餐系统无疑是我跻身上流社会的一个桥梁。“把模式装进脑子里，然后在你的设计和已有的应用中，寻找何处可以使用他们。使用设计模式的最好方法。把自己学到的模式和原如此，套用到开发的系统之上，在开发系统的同时也掌握的设计模式的根本思想。在起初没有使用设计模式的系统中，更能明显的看出设计模式的威力所在。1.2 系统开发目标为快餐行业的网互联化提供支持，使商家和定餐者都能便捷

4、高效的完成自己的需求和响应。具体目标如下：用户能够在没有经过培训以与不了解原有系统的情况下使用系统；系统应将订单处理流程加快20%以上；用户可以节省一半的查看菜单详细信息；当用户在快餐店用餐时，可以仅用没有系统所用时间的30%来完成订餐；当用户叫外卖时，不需要再找外卖单以与订餐；会员得知优惠的效率提高90%以上。1.3 开发环境本系统采用目前最流行的web开发技术之一J2EE进展开发。主要开发语言采用Java，网页采用JSP、css以与javascript,后台处理采用servlet技术，数据库使用的是MySQL5.5，服务器使用的是Tomcat7。可以配置在Windows,Linux,Uni

5、x等常用操作系统平台。第2章 需求分析2.1 项目概述适用于快餐店的多功能点餐系统，实现会员记录的增、删、查、改、存、读、的根本功能，根据功能，指导系统的模式。分别对于普通用户、会员、管理员开设系统。对于普通用户，有管理个人信息、查看菜单、订餐、结帐四种操作。对于会员，在普通用户的根底上，可以查看优惠信息、使用优惠券。对于管理员，可以进展管理员管理、普通用户管理、会员管理、菜单管理。2.2 功能需求快餐店多功能点餐系统在功能上应满足三类用户的需求，使得用户使用更加方便而高效。2.2.1 用户需求管理员可以通过网络进展菜单更新、会员管理、普通用户管理、发布优惠信息、查看选定时间段的营业情况；所有

6、用户可以选定菜单的特定子集进展查看菜单；普通用户可以查看今日特价、查看菜单、查看菜目详情、预订菜目、查看消费金额；会员在普通用户功能的根底上能够查看会员优惠、使用优惠券；普通的浏览者可以浏览菜单。2.2.2 系统需求系统能将用户每次的消费设置唯一的标识符记录到用户的信息上；系统可以提供适当的浏览器供用户查看电子等；2.3 非功能需求为了使用用户能够更好的使用系统，系统应具有的性能需求分为以下几个方面。2.3.1 产品需求系统应在30秒之内响应用户的所有请求；系统每周7天、每天24小时都可以使用；对于一个没有使用经验的管理员而言，可以经过20分钟的培训使用系统；对于没有使用经验额普通用户和会员能

7、够直接使用系统；系统的安全性、稳定性和可靠性可以让用户放心的使用；系统应具有良好的可移植性。2.3.2 外部需求系统的设计应具有较高道德用户体验度以与较高的互操作性。2.4 业务需求快餐店多功能点餐系统为快餐行业服务，需要为快餐店的管理员、会员与普通用户服务。2.4.1 业务要求具体业务要求如下：l 各种菜目的预订、查询和管理；l 使用计算机实现菜单的日常管理，提供工作效率和服务质量；l 用户通过网络来实现订餐，改变原有的预订方式；l 会员通过网络来进展优惠查询与管理，更加方便和高效；l 管理员可以更直观的管理用户和会员，分析其数据，可以更好的辅助决策。2.4.2 客户与用户快餐店的所有者或者

8、管理员、普通用户、快餐店的会员。2.4.3 特性能够在网络上完成订餐与优惠管理，使普通用户和会员更加方便。快餐店管理员可以通过电子给会员发送优惠信息，大大节省了人力物力。第3章 结构设计3.1 整体设计通过分析整个系统的需求，结合UML建模语言，对系统整体用例图分析如图3.1.1所示。图3.1.1 系统用例图3.1.1 普通用户活动图普通用户可以进展菜单查看，点单，查看消费金额等活动，系统活动图如图3.1.2所示。图3.1.2 普通用户活动图3.1.2 会员活动图会员在普通用户的根底上可享受更多优惠，系统活动图如图3.1.3所示。图3.1.3 会员活动图3.1.3 管理员活动图管理员可以进展菜

9、单管理、普通用户管理、会员管理等活动，系统活动图如图3.1.4所示：图3.1.4 管理员活动图3.2 详细设计对于系统的设计，根据软件工程的相关理论，遵循模块化原如此，使得系统在“高内聚、低耦合的要求之下更加稳定、已扩展，在后期的维护方面可以更加方便。3.2.1 模块划分按照系统开发的要求，可以分为前台与后台。前台与用户交互的界面设计应满足简洁大方，以小清新为主题风格。后台代码实现应条理清晰，方便之后的扩展与管理。具体模块与关系如图3.2.1所示。图3.2.1 模块划分图3.2.2 简单业务流程设计对于整个系统的业务流程，主要包括三个主要参与方。订餐者的点餐信息通过服务器的处理可以反应给管理员

10、，而管理员发布相关的优惠也是通过服务器的处理通知给会员。业务流程图如图3.2.2所示。图3.2.2 简单业务流程图第4章 设计模式4.1 工厂方法模式4.1.1 模式说明工厂方法模式，就是定义一个创建产品对象的工厂接口，让子类决定实例化哪一种实例对象，也就是将实际创建实例对象的工作推迟到子类当中，核心工厂类不在负责具体产品创建。实质上是通过继承的方式实现应用程序的解耦。 应用在本系统中，有一个数据库的操作类工厂，名字叫DAOFactory,有四个数据库操作类，UserDAO、DishesDAO和TableDAO，分别对用户、菜单和餐桌消息进展管理。4.1.2 模式类图图4.1.1 工厂方法模式

11、类图4.1.3 所用原如此 “开闭原如此一个软件实体应对扩展开放，对修改关闭。在设计软件模块的时候应该使这个模块可以在不修改的前提下被扩展。在本系统中，将Dao类的实现推迟到对象子类中实现。 依赖倒置原如此不论工厂还是产品都依赖于抽象，而不是具体的实现类。这样以来，无论底层组件怎么变化，只要抽象组件不变，高层组件就不会发生变化。4.2 抽象工厂模式4.2.1 模式说明抽象工厂模式提供了一个接口，用于创建相关或者依赖对象的家族，而不需要制定具体的实现类。抽象工厂模式允许客户使用抽象接口来创建一组相关的产品，客户类和工厂类分开，客户需要任何产品的时候，只需要向工厂请求即可，客户无需修改就可以获得新

12、产品，这样一来，客户就从具体产品中解耦。实质上是通过对象组合的方式实现应用程序的解耦。而这样的模式正好适用于订餐者的点餐：快餐店生产食物的工厂；各种食物工厂生产的产品；订餐者客户。角色关系如如下图4.2.1所示。图4.2.1 抽象工厂模式角色关系图4.2.2 模式类图图4.2.2 抽象工厂模式类图4.2.3 所用原如此(1) 多用对象组合，少用继承所谓对象组合，就是让对象作为类的成员变量，通过构造函数或者set方法给类的对象的实例变量赋值。在本系统中，在订餐者的类中存在一个FastFactory抽象工厂类型的实例变量，订餐者类通过构造方法将对象传入。(2) 针对抽象编程，而不是针对实现编程当设

13、计一个软件系统的时候，要尽可能的对软件系统中出现的事物进展抽象，从而建立根底的抽象底层，这样做的目的就是让软件的结构更加框架化、系统化，系统结构更加灵活，易维护、易扩展。(3) 产品对象通过对象暴露的方法创建一个软件系统要达到“高内聚、低耦合的要求，应尽量防止在对象实例中使用new关键字创建其他对象实例。在客户类中，没有创建对象实例的语句，而是调用抽象工厂暴露的方法获得对象实例，创建对象实例的工作全部都是在具体工厂中实现的。4.3 观察者模式4.3.1 模式说明观察者模式发布/订阅模式，定义了对象间的一种一对多的依赖关系，当一个对象的状态发生变化时，所有依赖他的对象都将得到通知并自动更新。在本

14、系统中，会员与管理员之间便是这种关系：管理员被观察的对象，会员观察者。当管理员发布优惠信息的时候，主动发出对每个会员的通知。在具体的实现中，让被观察者管理观察者的对象的接口类型，然后调用接口方法更新观察者。4.3.2 模式类图图4.3.1 观察者模式类图4.3.3 所用原如此(1) “开闭原如此观察者对象将自己注册到被观察者的容器中时，被观察者不过问观察者的具体类型，而是使用观察者的接口。(2) 单一职责原如此在该模式中，一个被观察者可以对应多个观察者，观察者对象都是基于接口而不是具体的实现，这一点为程序提供了更大的灵活性。当被观察者发生改变时，他可以将消息注意发送给观察者；而每一个观察者关注于处理各自的内容，不与其他观察者对象产生任何影响，这就是所谓的单一职责原如此。(3) 依赖倒置原如此在观察者模式中，抽象观察者角色定义了更新的接口，在被观察者对象中，存储的是该抽象类型的集合。4.4 策略模式4.4.1 模式说明策略模式定义了一系列的算法，将每一种算法封装起来并可以相互替换使用，策略模式让算法独立于使用它的客户应