软件工程四大部分总结

课程实验总结

（1）需求获取总结

需求通常是指人对客观事物需要的表现，体现为愿望、意向或兴趣，因此成为行动的一个直接原因。需求获取就是获取软件用户对软件功能需求、性能需求、质量属性、对外接口、约束等实际需求。在进行需求分析与设计时，要明白参与者与系统、参与者与参与者之间的关系，以及功能需求的实现的可能性！这些需要和用户通过面谈、需求专题讨论会、填写调查问卷等形式来获取用户需求信息！在了解和掌握用户需求后，需要撍写需求规格说明书。需求规格说明书包括用例视图、用例描述、领域模型与用户字典、非功能性需求表四大部分。

在用例视图中，需要勾画出系统的整体框架体系。把参与者在系统中的角色和各个用例的关系体现出来，将系统划分成几个层面，然后每个层次的参与者与用例之间发生关系！当用例相对较多时，可以用包来解决，在同一层面的用例可以放入同一个包！

在用例描述时，要对每个用例进行详细的描述，包括每层的中文名、英文名、参与者名，并简要说明一下该层面的功能，具体描述一下事件流！

写出特殊需求，例如姓名、ID的合法性！

在用例视图和用例描述都完善后，需要进行领域建模！在领域建模里，将各个类之间的关系表示出来，关系有三种，分别为一对一、一对多、多对多的关系，然后创建用户词典，将领域建模中的每一个类和属性，及其功能进行说明！每一个类及其类的属性都要创建一个表，类说明表里标明实体名、说明、基本属性，属性说明表里标明实体名、说明、从属实体！类说明表实体名即类名（例如：Customer(客人)）、属性说明表从属实体表示该属性属于哪一个类！在建用户词典时，要一个类一个类的有序的见表，每一个类的用户词典要有序排列！一般都是类说明表，接着是属性说明表！

在领域建模与用户词典完善后，考虑到用户的非功能性需求，需要创建一个非功能性需求表，包括质量属性和分析后的约束！质量属性以表格的形式来体现，包括有性能、安全性、易用性、持续可用性、可伸缩性、互操作性、可靠性、鲁棒性、易理解性、可扩展性、可重用性、可测试性、可维护性、可移植性等，分析后的约束主要有技术上约束、平台环境的约束、数据库约束、界面风格的约束、时间约束、其他等！

在捕获需求分析时，多考虑到用户的体验问题，以及用户的功能需求合理性和实现性，与用户协商，通过双方的洽谈来达成相互的认可和接受！从而解决需求困难问题，当然需求也需要验证，在需求获取中要考虑到是否正确和充分地支持业务需求，渐渐细化系统需求！

通过这一部分的学习，明白了需求获取与分析是软件工程所最终的目的，所有的工作都将要围绕着需求来做，如果需求不准确，会给后续的开发带来困难，而且往往所做的后期工作因与需求不一样而导致失败！让我体会到了这个部分的重要性和主导性，一个项目是否成功往往由需求分析和设计是否成功来决定！所以需求分析是最关键最重要的部分！

（2）架构分析与设计总结

在进行架构分析与设计时，大体上主要分两大部分！第一部分主要是架构分析部分和概要架构设计！

在进行架构分析时，通过视图来来体现系统的架构体系和具体的流程！通常

会用序列图来来进行架构分析！选取关键需求添加客人用例，根据需求中的用例描述，进行系统分析。大体上可分为三个分析类，其分别为界面类、实体类、持久化类。详细的表示出他们间的交互关系！界面类即用户登录的界面，操作或选择的菜单界面，在这个界面里实现对实体类和持久化类的操作，持久化类的数据需要保存到数据库中，按照序列图的特点层层递进，分析类与分析类之间发生访问和操作，这样是每个分析类的功能结构清晰明了，有助于后期的软件开发！

在概要架构设计时，开始概要的划分一下层，比如将显示界面的类，或窗口的类划分为界面层，如图1所示，可以讲Login用例划分为界面层。

Login

图1

将进行对数据操作和功能的展现部分化分为实体层！

第二部分为架构设计部分与细化架构设计。在这一部分主要是画视图，通过视图来了解系统架构。主要有逻辑视图、开发视图、部署视图三大类。逻辑视图设计到了系统逻辑层次图，开发视图有系统开发环境图、系统开发依赖关系视图、系统开发交互关系视图。系统逻辑层次图就是将各层之间的逻辑关系以及层内部调用关系体现出来！系统开发视图，主要是体现出系统开发的环境和开发所用工具，以及系统所基于的平台，各个层的基础框架和系统运行过程中文件的生成种类与先后的关系！系统开发依赖关系视图和系统开发交互关系视图，全是展示出类之间的调用、继承、泛化，部署视图从整体系统部署上来展示系统所涉及到的运行平台和支撑平台！

通过对这部分的学习和联系，我学会了视图的画法，以及看明白各种视图所体现的意义，比较全面的理解和认知到一个项目的子系统的架构设计和分析！在子系统的架构设计和分析时，自己需要做哪些工作，需要画哪些视图！一个系统的架构是怎样搭建的，是怎样安排和规划的！明白了架构分析和设计的目的是一些复杂信息的隐藏、使整个项目得到智能控制，从而管理项目的复杂性并保持系统的完整性和一体性！这为后期的模块的复用提供了坚实的基础，也为后期的管理奠定了基础！

（3）子系统与类分析与设计总结

这一部分就是开始将前期的工作开始投入到具体实现中！要考虑到各个类之间的调用关系的清晰！子系统结构的精简化和易扩展性、可重用性、易维护性！这一部分主要是各个层次内部各个类之间的调用的设计！需要画类的结构图纵览、类结构图界面层、类结构图实体层、类结构图细节、类结构图分层，在类的结构图纵览图里，把系统涉及到的所有的类都以某种关系展现出来，层内部类与类的相互关系，调用的接口，以及用到的设计模式，都以类图展现出来！在这一部分的学习中，学到了设计模式，使自己的代码的重用性、可扩展性渐渐提高，提倡高内聚低耦！在类的设计中，创建初始的设计类，根据将要设计的分析类类型来采用不同的方法设计类，分析类类型有边界类、实体类（或控制类）！边界

类控制着界面层，是登陆界面的类的一部分！由边界类来调用控制类，控制类控制着实体层类的生成和关系！为了实现系统的功能，类与类之间必须发生联系，彼此又相对独立！在每层能用设计模式的都用设计模式来解决，我的这部分用到的设计模式有简单工厂模式、工厂方法模式、抽象工场模式、桥接模式！特别是桥接模式，我对它的印象很深！它解决了我以前不能解决的闹心问题！

这个问题就是顾客订房时，对所需要客房的定义的问题，由于客房种类不同、租金各异、大小不一，所以一直让我很纠结，如果要定义类就定义几十个，增加了代码的复杂度！桥接模式能够很好的分离变量，然后变量之间的类自由的组合，使问题变得简单的多，这里可以定义两个抽象类客房类型Sort和客房House，然后由Sort派生三个子类，普通间(ordinary)、标准间(standard)、豪华间(fashion)，由House类派生出三个子类，单人间(smallsize)、两人间(middlesize)、三人间(largesize),然后只需在House的私有成员部分，定义一个Sort类型的对象指针就可以了！这样只需要八个类，不然的话要需要二十七个类！这样就可以很轻松的定义一个房间的类了！通过这部分的学习，让我学会了面向对象的巧妙应用！

还有一个设计模式给我的印象也很深，那就是适配器模式！在用到某一个模块式，可以借用别人已经写好的接口，不需要知道是怎样实现的，只需要明白调用某个接口能实现什么功能！然后自己可以构建一个自己的类和自己的接口的定义，在类的私有部分定义一个别人写好的类的对象，在接口的实现部分调用别人的接口来实现自己想要的功能！通过对设计模式的理解，感觉到了面向对象程序设计的灵活性和多变性！为自由以后的编程带来很大的帮助！

（4）数据库设计总结

在数据库的设计的学习中，给人的感觉就是，不是创建表就是画E-R图！我在做这部分的作业时，是按照要求先画E-R图，在创建表！

在画E-R图的过程中，首先要找该系统的实体集，把实体集找完后，分析实体集的属性，然后判断哪些属性可以作为实体集的主键，以便于与其他实体集区别开来！我的这个实验系统的有关实体集有“客房”、“订单”、“收银员”、“顾客”，其各自对应的主键分别为房间号、订单号、员工号、ID号，在实体集的属性分析完后，开始考虑各个实体集之间的关系！一般分为三种关系，有一对一、一对多、多对多三种关联关系！还有相互产生的联系如收银员打印订单、收银员提供客房、订单包括客房、订单属于客人，客人入住客房！在分析实体集之间的关系时，需要考虑到一些问题，比如就拿订单和客房、客人三个实体集来说，一个客人可以有多个订单，一个订单可以对应一个房间也可以对应多个房间，一个房间可以入住一个客人，也可以入住多个客人！这之间的关系比较混乱，所以比较难以确定！我采用的是客房与订单是多对多，客人和客房是一对一，客人和订单是一对多的关系！

在创建表，我用的是Microsoft Access 这个工具来建表！在建表时，每一个表要有一个主键，将每一个实体集都对应建立一个数据表，在把表建成功后，找表与表之间的关系！在建表时，根据E-R图，来确定相关联的数据表！这里订单里面包含有顾客的ID、客房的房号、收银员的员工号，所以订单是关键的数据表，它与顾客、客房、收银员数据表相连！实现表的连接时，将某表的主键拖到含有该主键的数据表中的该主键上，则会产生联系，形成连线！在这一部分发现自己只能实现一对多的关联，且该关联不能修改！这个至此也没有找到怎样修改Access 中表之间的关联关系！通过这一部分的学习，让我对数据库有了一个