首页  思维笔记  详情

软件体系结构

2023-02-23 20:58:57   0  举报





主要复习了，UML以及设计模式部分

UML

设计模式

软件体系结构

作者其他创作

大纲/内容

设计模式

概念

描述软件开发过程中若干重复出现问题的解决方案，这些方案由UML图表达，被反复使用，多数人知晓，经过分类编目的代码设计经验的总结，使用设计模式可以使代码的复用性和扩展性更好，可靠性更高，更容易理解

模式设计原则

开闭原则

对扩展开放，对修改关闭——对外界变化而进行的扩展开放，对原有代码修改的禁止

对扩展的开放和对修改的关闭含义：1> 软件需求的变化是设计变化的主要诱因 2> 软件的扩展性和稳定性可以和谐共存

组合\聚合复用原则

面向对象提供继承、复用两种技术，在复用时更倾向于组合因为： 1> 组合\聚合技术更加符合面向对象编程的思想(针对接口约定进行编程，不破坏对象的封装性，依赖关系也弱) 2> 组合\复用比继承更加灵活3> 组合\聚合适于表达多个构件组成的复杂对象 4> 组合\聚合可防止类爆炸现象的出现

高内聚低耦合原则

耦合是两个对象相互依赖于对方的程度。内聚是一个对象内部之间功能的相关联程度。高内聚低耦合具有更好的扩展性和复用性需要注意两个原则：类的单一职责、接口的隔离

创建型设计模式

抽象工厂

问题：系统由不同类型的对象构成、不同类型下有不同的型号，建立对象在每个类型中选择一种型号对象创建，对于组合创建需同一方式操作

解决方案：

效果：

优点
①抽象工厂模式隔离了具体产品/类的生成，使得客户并不需要知道什么被创建。由于这种隔离，更换或增加一个具体工厂就变得相对容易，所有的具体工厂都实现了抽象工厂中定义的那些公共接口，因此只需改变具体工厂的实例，就可以在某种程度上改变整个软件系统的行为。
②当一个族中的多个对象被设计成一起工作时，它能够保证客户端始终只使用同一个族中的对象。
③增加新的族很方便，无须修改已有系统，符合“开闭原则”。
缺点：
增加新的等级结构麻烦，需要对原有系统进行较大的修改，甚至需要修改抽象层代码，这显然会带来较大的不便，违背了“开闭原则”。

案例：代码

生成器

问题：构成系统的对象不仅需要创建也需要装配，创建和装配一起属于紧耦合，当希望同样的创建过程不同的装配流程时

解决方案：创建过程和装配分开，Director负责产品的创建过程，具体的装配在Builder中，最终只返回装配结果

效果：优点
将一个对象分解为各个组件。装配方式多样
将对象组件的构造封装起来
可以控制整个对象的生成过程
缺点
对不同类型的对象需要实现不同的具体构造器的类，即创建流程不能变

案例

工厂模式

问题：不同类型的创建对象拥有共同的使用方式

解决方法：在抽象类中定义用于创建对象的接口，让子类决定实例化哪个类

效果：优点：子类只关心如何实现抽象方法来创建一个具体对象，之后就自动拥有对该对象的扩展功能。缺点：在Creator和Product下容易产生平行类，即每个Creator子类对应产生一个具体子类

原型模式

问题：一定数量的对象需要装配成多样的组合对象。如果用类定义的方式，则会出现类急剧增加或平行类的现象

解决方法：用若干原型对象进行克隆并装配成组合对象

效果：优点：用同一的接口克隆对象，装配成组合对象，避免类数量极具增加体现了开闭原则。组合对象由克隆对象装配而成，各组合独享之间也是彼此独立的。缺点：如果克隆对象本身也是一个组合对象，进行克隆操作时，构件对象是克隆，还是共享需要权衡

单件模式

问题：对象占用大量资源时，希望类的对象只有一个

解决方法：类的构造方法封装起来，导致外部无法实例化，在类内使用静态方法定义类的声明。提供静态方法完成单件逻辑，即当静态声明没有引用对象时，实例化对象。在引用类对象时，返回对象的引用。

效果：优点：保证了一个类仅有一个实例，提供了某个对象的全局访问点。缺点：只考虑了对象创建的管理，没考虑销毁的管理，且对象的序列化

结构型设计模式

行为型设计模式

中介者模式

问题：系统对象增多，对象之间的耦合关系愈加复杂，如何降低对象之间的耦合度

解决方案：所有对象通过中介者进行通信，从而将对下个间复杂的耦合关系封装在中介者中

效果：优点：将对象间强耦合变弱耦合，中介者将原本分布于多个对象间的行为集中起来，改变这些行为只需要产生中介者的子类。缺点：中介者模式将对象的复杂性变成中介者的复杂性。可能使得自身变成难以维护的产物

状态模式

问题：对象的状态决定对象的行为，状态变化后行为也变化。通常采用case语句，但这违背了开闭原则

解决方案：状态对象化。State为抽象状态类，下面派生出可能状态的子类，运行时可以选择状态进行实例化

效果：优点：状态对象化后，如果有新的状态可以对State扩展出新的子类，而不改变Context的代码体现了开闭原则。缺点：如果状态多，会导致具体类变多

案例：

UML

概述

Language

是一种可视化建模语言，有语法和语义，消除了自然语言的歧义

Mode

用于描述系统核心 | 模型：是系统抽象的概括，强调系统设计特定的重要方面，忽略大量底层的实现细节

Unified——统一

软件设计者使用相同的符号进行沟通和交流

四层模型体系结构

实例层 - 模型层 - 元模型层 - 元元模型层

特点

1> 建模设计上可视化和标准化的结合 2> 建模设计上语言的无关性 3> 建模设计上标准性和扩展性的统一

工具

PowerDesigner

特点：1> 构造模型并进行详细说明，可以检查模型语法正确与否 2> 可同时进行正向工程和逆向工程 3> 便于团队对模型的共享访问和安全管理 4> 对模型对象进行档案管理

(4+1)视图:描述软件系统的不同方面

视图和图的关系？

1>视图可以看成是图的一种划分角度。

视图

用例图：表达需求。逻辑视图：定义系统静态结构和动态行为。构件视图：表达系统物理构件。进程视图：表达系统的并发行为。部署视图：表达构件在计算机和服务器上的物理分布。

UML图

用例图

模型元素：椭圆—用例—被驱动的功能(完整|外部可见|相互独立)、火柴人—参与者—驱动用例的角色，可人可物、关联关系：包含 —B包含A则b要执行必须先执行A,扩展、继承。用例图的表述：包含几个角色、用例。用例之间的关系分别是什么，代表了什么。角色之间的关系

类图和对象图

类图和对象图的区别

类图VS对象图
1）类具有3个分栏，自上而下依次为名称、属性和操作；对象只有两个分栏，自上而下依次为名称、属性

2）在类的名称分栏中只有类名；对象的名称形式为“对象名：类名”，匿名对象的名称形式为“：类名”；

3）类的属性分栏定义了所有属性的特征；对象则只定义了属性的当前值，以便用于测试用例或例子中；

4）类中列出了操作；对象图中不包括操作，因为对于同属于同一个类的对象而言，其操作是相同的；

5）类使用关联连接，关联使用名称、角色、多重性以及约束等特征定义。类代表的是对对象的分类所以必须说明可以参与关联的对象的数目；对象使用链连接、链拥有名称、角色，但是没有多重性。对象代表的是单独的实体，所有的链都是一对一的，因此不涉及到多重。

关联和链接的关系

在对象图中与关联对应的是链接。面向对象设计中对象之间的相互作用在类图中表现为关联、在对象图中是链接，在代码级则在引用实现。

类图细节：斜体表示抽象类、静态属性和专属于类的方法有下划线，长式表示法有属性部分，短式没有

泛化关系(空心箭头)一般由子类指向抽象类。抽象类的声明可以引用所有具体的子类—引用关系可替换。不同的引用对象可发送相同的消息——多态性。

依赖关系(带有箭头的虚线)：类型：类与对象之间的依赖关系、对接口使用的依赖关系、类之间的依赖关系(依赖类、引用类)

关联关系(类与类之间的连线)：用于描述两个类之间的作用关系，关联的类型：个数区分：一元关联(自关联\递归关联)、二元、三元、多元关联。四种特殊关联：关联类(类与类之间的关系，例：公司类和员工类)、受限关联(如文件内姓名作为限制可限制重名)、聚合关联(部分是整体的一部分,部分可能隶属于多个整体)、组合关联(整体拥有部分，部分仅隶属于这个整体)

顺序图|序列图

描述对象之间动态的消息交互关系，体现对象间消息传递的时间顺序

协作图

描述互相合作对象间的交互关系。模型元素：类元\对象(对象在交互中扮演的角色)。链接(用实线表示两个对象的链接)、消息

链接种类：全局性——链接是类中关联的实例化。 2> 局部性：链接是方法中的一个局部变量 3> 参数性：链接是方法中的传入参数 4> 自我性：链接是自身发送的消息

UML图的演化关系

活动图——描述系统需求用例内的活动执行顺序或类方法中程序的执行流程

活动图和状态图的异同点

相同点：1> 图中的建模元素有相似之处。2>对系统或对象在生存周期的状态和行为进行描述。不同点：1> 状态图中迁移发生时，必须有事件发生或条件满足，活动图的迁移则可以无条件或没有事件发生。2> 状态图对系统状态的描述可以横跨多个用例，活动图则是针对同一个用例内部动作的描述

构件图 —— 描述构件及其相互依赖关系。逻辑设计和物理模块相对应

案例1：潜在问题：1> 属性冗余：零件数目庞大，零件存在相同信息，造成内存浪费 2> 维护困难：零件属性值变动，造成维护困难 3> 当仓库没有零件时，零件的属性信息无法在计算机中体现。小结：对象数量较大时，可以将属性信息放置在另一个对象中并通过引用得到属性信息，从而降低冗余度。 2> 使用组合方式创建复杂对象 3> 组件对象和构件对象拥有一个抽象类，保证了接口一致性的同时也便于对象的组装