| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2016级计算机科学与工程学院软件工程（西北师范大学） |
| 这个作业的要求在哪里 | 实验十 团队作业6：团队项目系统设计改进与详细设计 |
| 团队名称 | 《hello--world团队》 |
| 作业学习目标 | （1）掌握面向对象软件设计方法；（2）掌握面向对象详细设计内容、设计原理和技术。 |
Part0.简要目录
- 团队项目github仓库地址链接
- 团队项目系统设计改进总结
- 团队项目详细设计过程总结
- 问题解答
Part1.团队项目github仓库地址链接
仓库地址链接：点击此处查看更新的《软件系统概要设计说明书》以及《软件详细设计说明书》Part2.团队项目系统设计改进总结
不足之处：在分析上次实验编写的系统设计时，发现有很多地方设计结构不够合理，而且在使用面向对象方法时，使用的不够准确，经过系统的学习面向对象设计方法之后，在项目的改进中加入了缺失的系统的类图，在类图中可以清晰的了解到各个类之间的关系，在系统的总体用例图中也进行了进一步优化。利用面向对象方法，详细分析系统设计模型，并且学习了软件体系结构、软件设计模式以及C/S与B/S结构，MVC设计模式等内容。再每次实验前，都会对上次的实验结果做一个改进，目的是让尽早的发现系统存在的问题，减少后期不必要的花费，这种对一个项目进行不断迭代的过程，也是为了让项目在设计过程中做的更完善。Part3.团队项目详细设计过程总结
在这次的设计过程中，我们遇到了不少的难题。其中一些是因为缺少编程经验而出现的简单错误。其中也有较为复杂的，通过小组内成员的讨论和钻研得到绝大部分的解决，这对我们在编程方面有一定的帮助和积累经验作用。 在这个过程中，首先遇到的就是数据库的建立问题。怎样合理的建表，设定几个字段名称，数据类型以及其他属性需要根据运行功能不断修改完善。第二个问题时由于时间的仓促，很多信息的输入没有做好有效字符的限定设置，就显得没有那么正规。其次，就是程序设计的模板化的问题，一个好的软件，都将一些较为常用的功能模块化，使用于整个工程，很方便的实现调用，不但减少了代码的重复性，还使程序简洁易懂。这都是我们程序中有待改善的地方。| 团队成员在系统设计的具体分工以及占整个系统设计文档任务的工作量比例 | ||
|---|---|---|
| 姓名 | 任务 | 比重 |
| 杨天超 | 分析项目系统设计的不足、修改系统设计说明书 | 25% |
| 孙锦喆 | 团队项目实施过程的心得总结，github的上传工作 | 25% |
| 王小倩 | 回答所给出的问题、实验作业博客的撰写 | 25% |
| 杜娣 | 撰写《软件系统详细设计说明书》 | 25% |
Part4.问题解答
一：何谓软件体系结构？虽然软件体系结构已经在软件工程领域中有着广泛的应用，但迄今为止还没有一个被大家所公认的定义，许多专家学者从不同角度和不同侧面对软件体系结构进行了刻画，较为典型的定义有：
（1）Mary Shaw和David Garlan认为软件体系结构是软件设计过程中的一个层次，这一层次超越计算过程中的算法设计和数据结构设计。体系结构问题包括总体组织和全局控制、通讯协议、同步、数据存取，给设计元素分配特定功能，设计元素的组织，规模和性能，在各设计方案间进行选择等。软件体系结构处理算法与数据结构之上关于整体系统结构设计和描述方面的一些问题，如全局组织和全局控制结构、关于通讯、同步与数据存取的协议，设计构件功能定义，物理分布与合成，设计方案的选择、评估与实现等
（2）Kruchten指出，软件体系结构有四个角度，它们从不同方面对系统进行描述：概念角度描述系统的主要构件及它们之间的关系；模块角度包含功能分解与层次结构；运行角度描述了一个系统的动态结构；代码角度描述了各种代码和库函数在开发环境中的组织。
（3）Hayes Roth则认为软件体系结构是一个抽象的系统规范，主要包括用其行为来描述的功能构件和构件之间的相互连接、接口和关系。
（4）David Garlan和Dewne Perry于1995年在IEEE软件工程学报上又采用如下的定义：软件体系结构是一个程序/系统各构件的结构、它们之间的相互关系以及进行设计的原则和随时间进化的指导方针。
（5）Barry Boehm和他的学生提出，一个软件体系结构包括一个软件和系统构件，互联及约束的集合；一个系统需求说明的集合；一个基本原理用以说明这一构件，互联和约束能够满足系统需求。
（6）1997年，Bass，Ctements和Kazman在《使用软件体系结构》一书中给出如下的定义：一个程序或计算机系统的软件体系结构包括一个或一组软件构件、软件构件的外部的可见特性及其相互关系。其中，"软件外部的可见特性"是指软件构件提供的服务、性能、特性、错误处理、共享资源使用等。
软件体系结构虽脱胎于软件工程，但其形成同时借鉴了计算机体系结构和网络体系结构中很多宝贵的思想和方法，最近几年软件体系结构研究已完全独立于软件工程的研究，成为计算机科学的一个最新的研究方向和独立学科分支。软件体系结构研究的主要内容涉及软件体系结构描述、软件体系结构风格、软件体系结构评价和软件体系结构的形式化方法等。解决好软件的重用、质量和维护问题，是研究软件体系结构的根本目的。研究软件体系结构的首要问题是如何表示软件体系结构，即如何对软件体系结构建模。根据建模的侧重点的不同，可以将软件体系结构的模型分为5种：结构模型、框架模型、动态模型、过程模型和功能模型。
==================================================================================================================================
二：何谓软件设计模式？
设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案，这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的；设计模式使代码编制真正工程化；设计模式是软件工程的基石脉络，如同大厦的结构一样。项目中合理地运用设计模式可以完美地解决很多问题，每种模式在现实中都有相应的原理来与之对应，每种模式都描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案
设计模式分为四种类型：
1.创建型模式：单例模式、抽象工厂模式、建造者模式、工厂模式、原型模式。
2.结构型模式：适配器模式、桥接模式、过滤器模式、装饰模式、组合模式、外观模式、享元模式、代理模式。
3.行为型模式：模版方法模式、命令模式、 空对象模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式、状态模式、策略模式、责任链模式、访问者模式。
4.J2EE模式：MVC 模式、业务代表模式、组合实体模式、数据访问对象模式、前端控制器模式、拦截过滤器模式、服务定位器模式、传输对象模式。
设计模式的六大原则
1、开闭原则（Open Close Principle）
开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。
2、里氏代换原则（Liskov Substitution Principle）
里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。—— From Baidu 百科
3、依赖倒转原则（Dependence Inversion Principle）
这个是开闭原则的基础，具体内容：真对接口编程，依赖于抽象而不依赖于具体。
4、接口隔离原则（Interface Segregation Principle）
这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。还是一个降低类之间的耦合度的意思，从这儿我们看出，其实设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。所以上文中多次出现：降低依赖，降低耦合。
5、迪米特法则（最少知道原则）（Demeter Principle）
为什么叫最少知道原则，就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。
6、合成复用原则（Composite Reuse Principle）
原则是尽量使用合成/聚合的方式，而不是使用继承。
==================================================================================================================================
三：什么是C/S结构？
C/S结构，即客户机和服务器结构 （Client/Server）。它是软件系统体系结构，通过它可以充分利用两端硬件环境的优势，将任务合理分配到Client端和Server端来实现，降低了系统的通讯开销。
C/S结构可以看做是胖客户端架构。客户端实现绝大多数的业务逻辑处理和界面展示，作为客户端的部分需要承受很大的压力，从分利用客户端的资源，对客户机的要求较高。
其实现可以是客户端包含一个或多个在用户的电脑上运行的程序，而服务器端有两种，一种是数据库服务器端，客户端通过数据库连接访问服务器端的数据；另一种是Socket服务器端，服务器端的程序通过Socket与客户端的程序通信。
目前大多数应用软件系统都是Client/Server形式的两层结构，由于现在的软件应用系统正在向分布式的Web应用发展，Web和Client/Server 应用都可以进行同样的业务处理，应用不同的模块共享逻辑组件；因此，内部的和外部的用户都可以访问新的和现有的应用系统，通过现有应用系统中的逻辑可以扩展出新的应用系统。这也就是目前应用系统的发展方向。
传统的C／S体系结构虽然采用的是开放模式，但这只是系统开发一级的开放性，在特定的应用中无论是Client端还是Server端都还需要特定的软件支持。由于没能提供用户真正期望的开放环境，C/S结构的软件需要针对不同的操作系统系统开发不同版本的软件，加之产品的更新换代十分快，已经很难适应百台电脑以上局域网用户同时使用。而且代价高， 效率低。
C/S结构优缺点：
C/S结构的优点:
<1>.C/S结构的界面和操作简单丰富。
<2>.C/S结构的管理信息系统具有较强的事务处理能力。
<3>.C/S结构的安全性能可以很容易保证，实现多层认证也不难。
<4>.C/S结构的响应速度快。由于客户端实现与服务器的直接相连，没有中间环节，只有一层交互，因此响应速度较快。
C/S结构的缺点:
<1>.适用面窄，通常用于局域网中。
随着互联网的飞速发展，移动办公和分布式办公越来越普及，这需要我们的系统具有扩展性。这种方式远程访问需要专门的技术，同时要对系统进行专门的设计来处理分布式的数据。
<2>.客户端需要安装专用的客户端软件。
由于程序需要安装才可使用，因此不适合面向一些不可知的用户。涉及到安装的工作量，其次任何一台电脑出问题，如病毒、硬件损坏，都需要进行安装或维护。特别是有很多分部或专卖店的情况，不是工 作量的问题，而是路程的问题。
<3>.维护升级成本高，进行一次维护升级，需要所有客户端的程序进行重新安装。
<4>.对客户端的操作系统一般也会有限制。
可能适应于WinXP, 但不能用于WinVista或Win7。或者不适用于微软新的操作系统等等，还有Linux、Unix等等操作系统。
四：什么是B/S结构？
B/S（Browser/Server）结构即浏览器和服务器结构。它是随着Internet技术的兴起，对C/S结构的一种变化或者改进的结构。在这种结构下，用户工作界面是通过WWW浏览器来实现，极少部分事务逻辑在前端（Browser）实现，但是主要事务逻辑在服务器端（Server）实现，形成所谓三层3-tier结构。这样就大大简化了客户端电脑载荷，减轻了系统维护与升级的成本和工作量，降低了用户的总体成本（TCO）。
B/S结构可以看作是瘦客户端，只是把显示的较少的逻辑交给了Web浏览器，事务逻辑数据处理在放在了Server端，这样就避免了庞大的胖客户端，减少了客户端的压力。B/S结构的系统无须特别安装，只有Web浏览器即可。当然AJAX\Flex等等的普遍使用也有富客户端的发展方向。
以目前的技术看，局域网建立B/S结构的网络应用，并通过Internet/Intranet模式下数据库应用，相对易于把握、成本也是较低的。它是一次性到位的开发，能实现不同的人员，从不同的地点，以不同的接入方式（比如LAN, WAN, Internet/Intranet等）访问和操作共同的数据库；它能有效地保护数据平台和管理访问权限，服务器数据库也很安全 。特别是在JAVA这样的跨平台语言出现之后，B/S架构管理软件更是方便、快捷、高效。
C/S和B/S结构优缺点
B/S结构优缺点：
B/S结构的优点:
<1>.无需安装，客户端不需要安装有浏览器即可。
<2>.分布性特点，可以随时随地进行查询、浏览等业务处理。
<3>.业务扩展便捷，通过增加页面即可增加服务器功能。
<4>.升级维护便捷，无需升级多个客户端，升级服务器即可，就可以实现所有用户的同步更新。
<5>.共享性强特点，可以直接放在广域网上，通过一定的权限控制实现多客户访问的目的，交互性较强。
B/S结构的缺点:
<1>.在跨浏览器上，BS结构不尽如人意。
<2>.在速度和安全性上需要花费很多设计成本，响应速度不及C/S，随着AJAX技术的发展，相比传统B/S结构软件速度有很大提升。
<3>.用户体验不是很理想，B/S需要单独界面设计，各个浏览器厂商的对浏览器的解析的标准不同。
客户端服务器端的交互是请求-响应模式，通常需要刷新页面，这并不是客户乐意看到的。（在Ajax风行后此问题得到了一定程度的缓 解）
==================================================================================================================================
五：什么是MVC设计模式？
MVC设计模式是模型-视图-控制器的全称，是一种非常经典的软件架构模式，在UI框架和UI设计思路中扮演着非常重要的角色。从设计模式的角度来看，MVC模式是一种复合模式，它将多个设计模式在一种解决方案中结合起来，用来解决许多设计问题。MVC模式把用户界面交互分拆到不同的三种角色中，使应用程序被分成三个核心部件：Model（模型）、View（视图）、Control（控制器）。它们各自处理自己的任务：
（1）模型：模型持有所有的数据、状态和程序逻辑。模型独立于视图和控制器，只包含纯应用程序数据，不包含描述如何将数据呈现给用户的逻辑
（2）视图：用来呈现模型。视图通常直接从模型中取得它需要显示的状态与数据，对于相同的信息可以有多个不同的显示形式或视图，视图向用户显示模型的数据。视图知道如何访问模型的数据，但它不知道这些数据意味着什么，也不知道用户可以做什么来操作它。
（3）控制器：位于视图和模型中间，负责接受用户的输入，将输入进行解析并反馈给模型，通常一个视图具有一个控制器。
MVC模式将它们分离以提高系统的灵活性和复用性，不使用MVC模式，用户界面设计往往将这些对象混在一起。mvc模式就是这样，把原本杂乱无章的类，分为三堆，严格监管，按规则行事。说到底一切都是为了使类之间的耦合性更松散。好的代码应该对扩展开放，对修改关闭。MVC模式实现了模型和视图的分离，这带来了几个好处。
（1）一个模型提供不同的多个视图表现形式，也能够为一个模型创建新的视图而无须重写模型。一旦模型的数据发生变化，模型将通知有关的视图，每个视图相应地刷新自己。
（2）模型可复用。因为模型是独立于视图的，所以可以把一个模型独立地移植到新的平台工作。
（3）提高开发效率。在开发界面显示部分时，你仅仅需要考虑的是如何布局一个好的用户界面；开发模型时，你仅仅要考虑的是业务逻辑和数据维护，这样能使开发者专注于某一方面的开发，提高开发效率。