实验十 软件系统详细设计与概要设计的改进

1、团队项目系统设计改进：

    面向对象设计（Object-Oriented Design，OOD）方法是OO方法中一个中间过渡环节。其主要做用是对OOA分析的结果做进一步的规范化整理，以便可以被OOP直接接受。
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没有考虑,由于考虑过多的实现细节对理解问题和分析用户需求没有多大帮助。

 

    本次实验中，咱们团队基于对OOA与OOD的区别对《软件系统概要说明书》中的系统设计模型进行了完善，包括E-R图和状态图，并加入了系统流程图。在上一次的《软件系统概要说明书》中软件系统结构模型的建模设计作的不够完善，项目系统结构的总体设计不够全面。咱们对上一次的系统设计模型图进行了改进与完善，加入了系统流程图。本来的系统设计模型图描述了项目的功能做用，没有展现出项目的设计流程和实现路线图，改善后的流程图加入了设计实现路线，对于系统功能进行了更为详细的展现。咱们也对文档中存在的错误以及文字描述不许确的地方进行了修改。并将改进后《软件系统概要说明书》发布在团队Github仓库中。
    改进的《软件系统设计说明书》在Github仓库中的连接：https://github.com/FBGfbg/xuqiu

 

2、团队项目系统详细设计的建模：

系统整体设计图：

 

系统流程图：

3、撰写《软件系统详细设计说明书》

    参考国标GB8567——88中《软件系统详细设计说明书》格式，撰写团队项目软件系统详细设计说明书，文档要求使用一致的图形符号和文字描述内容，将该文档上传到团队项目Github仓库。

《软件系统详细设计说明书》在Github仓库中的连接：https://github.com/FBGfbg/xuqiu

4、六个问题

一、何谓软件体系结构、软件设计模式？

    软件体系结构是具备必定形式的结构化元素，即构件的集合，包括处理构件、数据构件和链接构件。处理构件负责对数据进行加工，数据构件是被加工的信息，链接构件把体系结构的不一样部分组合链接起来。这必定义注重区分处理构件、数据构件和链接构件，这一方法在其余的定义和方法中基本上获得保持。

    软件设计模式（Design pattern），又称设计模式，是一套被反复使用、多数人知晓的、通过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性、程序的重用性。毫无疑问，设计模式于己于他人于系统都是多赢的；设计模式使代码编制真正工程化；设计模式是软件工程的基石脉络，如同大厦的结构同样。设计模式主要分三个类型:建立型、结构型和行为型。

建立型模式：单例模式、抽象工厂模式、建造者模式、工厂模式、原型模式。
结构型模式：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式。
行为型模式：模版方法模式、命令模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式（Interpreter模式）、状态模式、策略模式、职责链模式(责任链模式)、访问者模式。

二、什么是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服务器实现，客户端只须要浏览器便可进行业务处理，是一种全新的软件系统构造技术。这种结构更成为当应用软件的首选体系结构。

三、什么是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模式实现了模型和视图的分离，用户界面设计每每将这些对象混在一块儿。

四、结合项目系统设计体验，简要说明一、二、3的内容与软件系统设计的关系。

（1）软件体系结构贯穿于软件研发的整个生命周期内，具备重要的影响。对软件体系结构风格的研究和实践促进了对设计的复用，一些通过实践证明的解决方案也能够可靠地用于解决新的问题。体系结构风格的不变部分使不一样的系统能够共享同一个实现代码。只要系统是使用经常使用的、规范的方法来组织，就可以使别的设计者很容易地理解系统的体系结构。例如，若是某人把系统描述为"客户/服务器"模式，则没必要给出设计细节，咱们马上就会明白系统是如何组织和工做的。

（2）软件设计模式使代码编制真正工程化；设计模式是软件系统设计的基石脉络，如同大厦的结构同样。设计模式令人们能够更加简单方便地复用成功的设计和体系结构。将已证明的技术表述成设计模式也会使新系统开发者更加容易理解其设计思路。

（3）C/S结构，B/S结构是一种的软件系统构造技术。

（4）MVC设计模式有利软件工程化管理。因为不一样的层各司其职，每一层不一样的应用具备某些相同的特征，有利于经过工程化、工具化管理程序代码。控制器也提供了一个好处，就是可使用控制器来联接不一样的模型和视图去完成用户的需求，这样控制器能够为构造应用程序提供强有力的手段。给定一些可重用的模型和视图，控制器能够根据用户的需求选择模型进行处理，而后选择视图将处理结果显示给用户。

（5）MVC设计模式增长系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增长结构的复杂性，并可能产生过多的更新操做，下降运行效率。

五、详细设计的常见工具备哪些？

（1）程序流程图。程序流程图又称为程序框图，是使用最普遍然而也是用得最混乱的一种描述程序逻辑结构的工具。它用方框表示一个处理步骤，菱形表示一个逻辑条件，箭头表示控制流向。其优势是：结构清晰，易于理解，易于修改。缺点是：只能描述执行过程而不能描述有关的数据。
（2）盒图。盒图是一种强制使用结构化构造的图示工具，也称为方框图。其具备如下特色：功能域明确、不可能任意转移控制、很容易肯定局部和全局数据的做用域、很容易表示嵌套关系及模板的层次关系。
（3）PAD图。。PAD是一种改进的图形描述方式，能够用来取代程序流程图，比程序流程图更直观，结构更清晰。最大的优势是可以反映和描述自顶向下的历史和过程。PAD提供了5种基本控制结构的图示，并容许递归使用。PAD的特色有：使用PAD符号设计出的程序代码是结构化程序代码；PAD所描绘的程序结构十分清晰；用PAD图表现程序的逻辑易读、易懂和易记；容易将PAD图转换成高级语言源程序自动完成；便可以表示逻辑，也可用来描绘数据结构；支持自顶向下方法的使用。
（4）PDL。PDL也可称为伪码或结构化语言，它用于描述模块内部的具体算法，以便开发人员之间比较精确地进行交流。语法是开放式的，其外层语法是肯定的，而内层语法则不肯定。外层语法描述控制结构，它用相似于通常编程语言控制结构的关键字表示，因此是肯定的。内层语法描述具体操做，考虑到不一样软件系统的实际操做种类繁多，内层语法于是不肯定，它能够按系统的具体状况和不一样的设计层次灵活选用，实际上任意英语语句均可用来描述所需的具体操做。用它来描述详细设计，工做量比画图小，又比较容易转换为真正的代码。PDL的优势：能够做为注释直接插在源程序中；可使用普通的文本编辑工具或文字处理工具产生和管理；已经有自动处理程序存在，并且能够自动由PDL生成程序代码。PDL的不足：不如图形工具形象直观，描述复杂的条件组合与动做间对应关系时，不如断定树清晰简单。
六、如何绘制符合规范的流程图？

    流程图是揭示和掌握封闭系统运动情况的有效方式。做为诊断工具，它可以辅助决策制定，让管理者清楚地知道，问题可能出在什么地方，从而肯定出可供选择的行动方案。绘制流程图的习惯作法是：事实描述用椭圆形表示行动方案用矩形表示问题用菱形表示箭头表明流动方向。使用流程图须要考虑不少问题，如：过程当中是否存在某些环节，删掉它们后可以下降成本或减小时间？还有其余更有效的方式构造该流程吗？整个过程是否由于过期而须要从新设计？应当将其彻底废弃吗？

详细状况请看连接：https://github.com/FBGfbg/xuqiu

     

团队成员分工：

 

姓名	分工	比例	时间
马美玲	撰写博客内容、查找、编写6个问题、任务二、编写登录注册、课本选择界面代码	45%	一周
马玉婷	撰写《软件系统详细设计说明书》、博客内容、编写年纪选择、课程选择界面代码	45%	一周
益西卓嘎	改善项目系统设计说明书初稿的不足	10%	两天

 

5、团队实验心得

 

    本次实验是在上一次的实验上又作了进一步的补充，也更加证明了软件工程是一个不断迭代的过程，因为每个团队成员都基本肯定了各自的分工，因此更加深入的认识到了本身的那一部分不足，开始进行不断完善。团队成员要及时进行沟通和交流，不断交流想法，不断改进。