实验十 软件系统详细设计与概要设计的改进
一、团队项目系统设计改进：
OOD的主要工作有：
1. 问题域部分的设计：
问题域部分的设计是任何OOD方法都必须完成的工作,它主要是对OOA结果进行改进和精化,并将其由问题域转化到解域,具体来说,有以下几个方面:
• 属性:有些属性在分析阶段有助于问题的理解,而到了设计阶段则可以由其他属性导出或根本没必要保留。因此,应将它们去掉。相反地,为了实现服务算法还需要增加相应的一些属性。
• 服务:OOA只给出了服务的接口,其具体实现算法要在OOD阶段完成。
• 类及对象:在OOA阶段有助于问题理解的一些类在OOD阶段成为冗余,需要删除,而为了优化调整继承关系还要增加一些类。所有的类都确定以后还要明确哪些类的对象会引发哪些类创建新对象。
• 结构:对类间结构进行优化调整。
• 对象行为:明确对象间消息传递的实现算法,依据动态模型确定对象间消息发送的先后顺序,并设计相应算法,协调对象的行为。
2. 人机交互与应用控制部分的设计：
有些设计方法并没有提到交互界面的设计,一方面是因为这些系统中交互界面不十分重要;另一方面是因为这部分的设计很有规律,设计方法也比较成熟,但为完整起见,仍将其列出。主要工作包括:
（1） 交互界面子系统的设计:与界面有关的类及类间结构的设计,以及有关算法的设计。
（2） 交互界面子系统和应用之间接口的设计
（3） 应用控制部分的设计:这部分对象主要完成应用的驱动工作。这部分对象不同于从现实世界中抽象出来的对象,在现实世界和问题域中没有原型,它们同界面子系统中的对象及问题对象发生作用,控制系统的运行。
OOA与OOD的区别
由于OOA和OOD的划分没有公认的标准,有些工作是在OOA阶段完成还是在OOD阶段完成还存在着争议。有人认为OOA和OOD可以交叉进行;有人认为OOD是对OOA结果的改进和细化,所以只提OOA;有人则更强调OOD。尽管OOA和OOD存在着某些交叉和联系,但它们之间仍有许多差别,如:
1. OOA将现实世界中的实体抽象为问题对象,并构造问题域中的系统需求模型;OOD将问题对象转化为解域中的类并在解域中构造出问题的解。
2. OOA侧重于用户需求的分析和对问题域的理解,分析人员关心的是系统结构及对象间的关系;OOD则侧重于系统的实现,设计人员关心的是对象的行为及其实现。
3. OOA标识了一组对象,并通过其相互作用来刻划系统,该阶段的工作与程序设计语言无关;OOD定义了一组类,并设计出系统的实现蓝图,概要设计与程序设计语言无关,但详细设计则与之有比较密切的联系。
4. OOA识别的对象是对客观世界实体的抽象,标识对象的准则是:该对象的引入是否有助于对问题域的理解;OOD中构造类的准则是:该类的构造是否可行,是否有效地实现了抽象数据类型,是否有助于系统的实现和提高软件质量。
5. 两个阶段都没有提及系统对象,但原因不同。在OOA阶段,分析与实现无关,分析所涉及的范围与解域无关,系统对象自然不用考虑。OOD建立的对象模型本身就是要设计的软件系统,对系统对象的考虑是隐含的。
6. 组装结构和分类结构在两个阶段所起的作用不同。在OOA阶段,它们的引入主要是为了理解问题;而在OOD阶段,它们的引入则主要是针对软件的构造和实现。分类结构通过继承机制来实现,因而代码得到了有效地复用;组装结构则将一些类组合在一起构成较大的软件构件。
7. OOA并没有考虑对象的产生问题,当其对应的实体在现实世界中出现时,它也就在问题域中产生了。OOA也不考虑对象属性的取值和服务算法的实现。而在OOD阶段这些问题都必须详细考虑。
8. OOD涉及到重载问题;而OOA没有考虑,因为考虑过多的实现细节对理解问题和分析用户需求没有多大帮助。
改进的《软件系统设计说明书》在Github仓库中的链接：https://github.com/FBGfbg/xuqiu
结构型模式：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式。
行为型模式：模版方法模式、命令模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式（Interpreter模式）、状态模式、策略模式、职责链模式(责任链模式)、访问者模式。
2、什么是C/S与B/S结构？
C/S结构(Client/Server结构)是大家熟知的客户机和服务器结构。它是软件系统体系结构，通过它可以充分利用两端硬件环境的优势，将任务合理分配到Client端和Server端来实现，降低了系统的通讯开销。目前大多数应用软件系统都是Client/Server形式的两层结构，由于现在的软件应用系统正在向分布式的Web应用发展，Web和Client/Server 应用都可以进行同样的业务处理，应用不同的模块共享逻辑组件；因此，内部的和外部的用户都可以访问新的和现有的应用系统，通过现有应用系统中的逻辑可以扩展出新的应用系统。这也就是目前应用系统的发展方向。
B/S结构（Browser/Server，浏览器/服务器模式），是WEB兴起后的一种网络结构模式，WEB浏览器是客户端最主要的应用软件。这种模式统一了客户端，将系统功能实现的核心部分集中到服务器上，简化了系统的开发、维护和使用。客户机上只要安装一个浏览器（Browser英 ['braʊzə]美 ['braʊzɚ]），如Netscape Navigator或Internet Explorer，服务器安装SQL Server、Oracle、MYSQL等数据库。浏览器通过Web Server 同数据库进行数据交互。
B/S（浏览器/服务器模式)是随着Internet的兴起，对C/S结构的一种改进。在这种结构下，软件应用的业务逻辑完全在应用服务器端实现，用户表现完全在Web服务器实现，客户端只需要浏览器即可进行业务处理，是一种全新的软件系统构造技术。这种结构更成为当应用软件的首选体系结构。
3、什么是MVC设计模式？
MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。MVC指MVC模式的某种框架，它强制性的使应用程序的输入、处理和输入分开。使用MVC应用程序被分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。最典型的MVC就是JSP +servlet+javabean的模式。
模型-视图-控制器（MVC模式）是一种非常经典的软件架构模式，在UI框架和UI设计思路中扮演着非常重要的角色。从设计模式的角度来看，MVC模式是一种复合模式，它将多个设计模式在一种解决方案中结合起来，用来解决许多设计问题。MVC模式把用户界面交互分拆到不同的三种角色中，使应用程序被分成三个核心部件：Model（模型）、View（视图）、Control（控制器）。它们各自处理自己的任务：
模型：模型持有所有的数据、状态和程序逻辑。模型独立于视图和控制器。
视图：用来呈现模型。视图通常直接从模型中取得它需要显示的状态与数据。对于相同的信息可以有多个不同的显示形式或视图。
控制器：位于视图和模型中间，负责接受用户的输入，将输入进行解析并反馈给模型，通常一个视图具有一个控制器。
MVC模式将它们分离以提高系统的灵活性和复用性，不使用MVC模式，MVC模式实现了模型和视图的分离，用户界面设计往往将这些对象混在一起。
4、结合项目系统设计体验，简要说明1、2、3的内容与软件系统设计的关系。
（1）软件体系结构贯穿于软件研发的整个生命周期内，具有重要的影响。对软件体系结构风格的研究和实践促进了对设计的复用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。体系结构风格的不变部分使不同的系统可以共享同一个实现代码。只要系统是使用常用的、规范的方法来组织，就可使别的设计者很容易地理解系统的体系结构。例如，如果某人把系统描述为"客户/服务器"模式，则不必给出设计细节，我们立刻就会明白系统是如何组织和工作的。
（2）软件设计模式使代码编制真正工程化；设计模式是软件系统设计的基石脉络，如同大厦的结构一样。设计模式使人们可以更加简单方便地复用成功的设计和体系结构。将已证实的技术表述成设计模式也会使新系统开发者更加容易理解其设计思路。
（3）C/S结构，B/S结构是一种的软件系统构造技术。
（4）MVC设计模式有利软件工程化管理。由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化管理程序代码。控制器也提供了一个好处，就是可以使用控制器来联接不同的模型和视图去完成用户的需求，这样控制器可以为构造应用程序提供强有力的手段。给定一些可重用的模型和视图，控制器可以根据用户的需求选择模型进行处理，然后选择视图将处理结果显示给用户。
（5）MVC设计模式增加系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。
5、详细设计的常见工具有哪些？
（1）程序流程图。程序流程图又称为程序框图，是使用最广泛然而也是用得最混乱的一种描述程序逻辑结构的工具。它用方框表示一个处理步骤，菱形表示一个逻辑条件，箭头表示控制流向。其优点是：结构清晰，易于理解，易于修改。缺点是：只能描述执行过程而不能描述有关的数据。
（2）盒图。盒图是一种强制使用结构化构造的图示工具，也称为方框图。其具有以下特点：功能域明确、不可能任意转移控制、很容易确定局部和全局数据的作用域、很容易表示嵌套关系及模板的层次关系。
（3）PAD图。。PAD是一种改进的图形描述方式，可以用来取代程序流程图，比程序流程图更直观，结构更清晰。最大的优点是能够反映和描述自顶向下的历史和过程。PAD提供了5种基本控制结构的图示，并允许递归使用。PAD的特点有：使用PAD符号设计出的程序代码是结构化程序代码；PAD所描绘的程序结构十分清晰；用PAD图表现程序的逻辑易读、易懂和易记；容易将PAD图转换成高级语言源程序自动完成；即可以表示逻辑，也可用来描绘数据结构；支持自顶向下方法的使用。
（4）PDL。PDL也可称为伪码或结构化语言，它用于描述模块内部的具体算法，以便开发人员之间比较精确地进行交流。语法是开放式的，其外层语法是确定的，而内层语法则不确定。外层语法描述控制结构，它用类似于一般编程语言控制结构的关键字表示，所以是确定的。内层语法描述具体操作，考虑到不同软件系统的实际操作种类繁多，内层语法因而不确定，它可以按系统的具体情况和不同的设计层次灵活选用，实际上任意英语语句都可用来描述所需的具体操作。用它来描述详细设计，工作量比画图小，又比较容易转换为真正的代码。PDL的优点：可以作为注释直接插在源程序中；可以使用普通的文本编辑工具或文字处理工具产生和管理；已经有自动处理程序存在，而且可以自动由PDL生成程序代码。PDL的不足：不如图形工具形象直观，描述复杂的条件组合与动作间对应关系时，不如判定树清晰简单。
6、如何绘制符合规范的流程图？
流程图是揭示和掌握封闭系统运动状况的有效方式。作为诊断工具，它能够辅助决策制定，让管理者清楚地知道，问题可能出在什么地方，从而确定出可供选择的行动方案。绘制流程图的习惯做法是：事实描述用椭圆形表示行动方案用矩形表示问题用菱形表示箭头代表流动方向。使用流程图需要考虑很多问题，如：过程中是否存在某些环节，删掉它们后能够降低成本或减少时间？还有其他更有效的方式构造该流程吗？整个过程是否因为过时而需要重新设计？应当将其完全废弃吗？
详细情况请看链接：https://github.com/FBGfbg/xuqiu
团队成员分工：
|
姓名 |
分工 |
比例 |
时间 |
|
马美玲 |
撰写博客内容、查找、编写6个问题、任务2、编写登陆注册、课本选择界面代码 |
45% |
一周 |
|
马玉婷 |
撰写《软件系统详细设计说明书》、博客内容、编写年纪选择、课程选择界面代码 |
45% |
一周 |
|
益西卓嘎 |
改善项目系统设计说明书初稿的不足 |
10% |
两天 |
五、团队实验心得
本次实验是在上一次的实验上又做了进一步的补充，也更加证实了软件工程是一个不断迭代的过程，由于每一个团队成员都基本确定了各自的分工，所以更加深刻的认识到了自己的那一部分不足，开始进行不断完善。团队成员要及时进行沟通和交流，不断交流想法，不断改进。
