软件工程复习总结(二)

四、系统设计

理解面向对象的设计原则(7个)

  • 单一职责原则

解释:可以降低类的复杂度,一个类只负责一项职责

  • 里氏替换原则

解释:超类存在的地方,子类是可以替换的。

  • 依赖倒置原则

解释:尽量依赖抽象,不依赖具体实现

  • 接口隔离原则

解释:为客户端提供尽可能小的单独的接口,而不是提供大的总的接口

  • 迪米特法则

解释:最少知识原则,一个软件实体应当尽可能少的与其他实体发生相互作用。

  • 开闭原则

解释:面向扩展开发,面向修改关闭

  • 组合/聚合复用原则

解释:尽量使用合成/聚合达到复用,尽量少用继承。原则:一个类中有另一个类的对象。

明确概要(系统)设计阶段的任务

制定软件系统的总体设计,确定了各个模块的功能及模块之间的联系,再进一步就要考虑如何实现各个模块所规定的功能

掌握数据库设计方法(E-R图–与关系模型)

实体-联系图的数据模型
1.实体(数据对象)
2.属性是实体或联系所具有的性质,一个实体对应多个属性
3.联系

  • 一对一的关系映射为数据库表的主外键关联,在任意端的属性中加入另一端的主键做外键;
  • 一对多的关系映射为数据库表的主外键关联,一端的主键加入n端成为外键;
  • 多对多的关系映射为一个单独的表,两个多端的主键成为该表的外键,两个外键的组合成为该表的主键。

E-R图 矩形为实体,菱形表示联系,属性表示椭圆

MVC 设计模式

模型层、视图层、控制层
使用MVC的目的是增强代码的重用性,降低数据描述和应用操作的可耦合度,提高代码可读性,及软件的可维护性、可修复性、灵活性和封装性。

软件体系结构的特点(C/S与B/S)

C/S(Client/Server)结构,即客户机和服务器结构,客户端实现绝大多数数业务逻辑处理和界面显示,客户端复杂度大于服务器端。

B/S(Browser/Server)结构,即浏览器和服务器结构,用户工作界面通过浏览器实现,主要事务逻辑在服务器端实现,简化了客户端电脑载荷。

理解软件结构设计原则

  • 模块化:将功能相同或相近的代码写成模块, 便于分工合作,便于调试,便于移植,便于改进;

  • 抽象:抽取事务最基本的特征和行为,忽略非本质细节;

  • 逐步求精:即将系统功能按层次进行分解,每一层不断将功能细化,到最后一层都是功能单一、简单易实现的模块。

  • 信息隐藏:采用封装技术,将程序模块的实现细节隐藏起来,使模块接口尽量简单;

  • 局部化:保证模块之间具有松散的耦合关系,使模块内部具有较高的内聚性;

  • 高内聚低耦合:主要是看类的内聚性是否高,耦合度是否低。

理解模块内聚性

内聚性又称快内联系,指模块的功能强度的度量,模块中组成元素结合得越紧密,内聚性越高,模块的独立性也就越高。理想的类聚性要求模块的功能应明确、单一,一个模块只做一件事。耦合性又称块间联系,模块之间联系越紧密,耦合性越强。

  • 偶然内聚:指一个模块内的各处理元素之间没有任何联系;

  • 逻辑内聚:模块内执行几个逻辑上相似的功能,通过参数确定该模块完成哪一个功能;

  • 时间内聚:把需要同时执行的动作合在一起形成的模块为时间内聚模块;

  • 通信内聚(信息内聚):指模块内所有处理元素都在同一个数据结构上操作,或指各处理使用相同的输入数据或者产生相同的输出数据;

  • 顺序内聚:指一个模块中各个处理元素都密切相关于同一功能且必须顺序执行,前一功能元素输出就是下一功能元素的输入;

  • 功能内聚:最强的内聚,指模块内所有元素共同完成一个功能,缺一不可。

理解模块间的耦合性(6)及原则

  • 非直接耦合:如果两个模块之间没有直接关系,它们之间的联系完全是通过主模块的控制和调用来实现的,这就是非直接耦合。这种耦合的模块独立性最强。

  • 数据耦合:如果一个模块访问另一个模块时,彼此之间是通过数据参数(不是控制参数、公共数据结构或外部变量)来交换输入、输出信息的,则称这种耦合为数据耦合。

  • 印记耦合:如果一组模块通过参数表传递记录信息,就是标记耦合。

  • 控制耦合:如果一个模块通过传送开关、标志、名字等控制信息,明显地控制选择另一模块的功能,就是控制耦合。

  • 外部耦合:一组模块都访问同一全局简单变量而不是同一全局数据结构,而且不是通过参数表传递该全局变量的信息,则称之为外部耦合。

  • 公共耦合:若一组模块都访问同一个公共数据环境,则它们之间的耦合就称为公共耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。 这种耦合会引起下列问题:
    所有公共耦合模块都与某一个公共数据环境内部各项的物理安排有关,若修改某个数据的大小,将会影响到所有的模块。
    无法控制各个模块对公共数据的存取,严重影响软件模块的可靠性和适应性。
    公共数据名的使用,明显降低了程序的可读性。
    公共耦合的复杂程度随耦合模块的个数增加而显着增加。若只是两个模块之间有公共数据环境,则公共耦合有两种情况。
    若一个模块只是往公共数据环境里传送数据,而另一个模块只是从公共数据环境中取数据,则这种公共耦合叫做松散公共耦合。若两个模块都从公共数据环境中取数据,又都向公共数据环境里送数据,则这种公共耦合叫做紧密公共耦合。只有在模块之间共享的数据很多,且通过参数表传递不方便时,才使用公共耦合。否则,还是使用模块独立性比较高的数据耦合好些。

  • 内容耦合:如果发生下列情形,两个模块之间就发生了内容耦合。
    一个模块直接访问另一个模块的内部数据;
    一个模块不通过正常入口转到另一模块内部;
    两个模块有一部分程序代码重叠(只可能出现在汇编语言中);
    一个模块有多个入口。
    在内容耦合的情形,所访问模块的任何变更,或者用不同的编译器对它再编译,
    都会造成程序出错。好在大多数高级程序设计语言已经设计成不允许出现内容
    耦合。它一般出现在汇编语言程序中。这种耦合是模块独立性最弱的耦合。

(*^▽^*)