《软件体系结构》 第七章 基于体系结构的软件开发
https://blog.csdn.net/shujian_tianya/article/details/80905601
开发人员技术等级说明书 V1.3
0、象棋高手
下过象棋的人都都知道，学习经典残局是进阶高手的一个方法，它的本质在于：每个特定的残局，走那一步可以赢得对局，就是说对于类似的残局可以使用相同的套路来出牌而最终获胜。
1、什么是模式（pattern）
每个模式描述了一个问题，该问题反复在我们的周围出现，每个模式给出了对该问题的核心解决方法，因此，人们可以反复使用给解决方法解决类似问题。
就好比象棋的经典残局，每一个套路就类似一个设计模式。
2、为什么学习模式
帮助你学习他们成功的经验，从而避免失误。
3、模式和框架的比较
模式（patterns）支持软件结构和设计的重用；
框架（Frameworks）支持细节设计和代码的重用；
设计模式和框架有助于提高软件的质量。
设计模式比框架更抽象
和框架相比，设计模式是更小的单元的架构元素
从使用的广度来说，设计模式比框架更广，它与应用的相关性更小。
4、设计模式分类：
创建型模式（Creational Patters）
结构型模式（Structural Patters）
行为型模式（Behavioral Patters）
指导模式设计的三个概念：
（1）重用（reuse）：是目标
（2）接口和实现分离：灵活性，多态性
（3）Decouple松耦合：降低复杂性
描述一个模式
名称
问题、动机
约束
上下文
解决方案：
结构（Structure）
参与者（Participants）
写作（Collaboration）
实现（Implementation）
评测
相关模式
5、举例
（1）命令模式
（2）适配器模式（Adopter）
总结：
学完这个马上就结束UML视频了，下面该开始使用UML画机房系统的几种图了。刚刚了解了什么是设计模式，后面还有很多需要补充学习，了解回顾继续完善。
————————————————
模型是什么
建模的价值
统一建模语言UML
模型是什么？
是现实的简化
同一个系统，基于不同简化动机和简化水平，可以得到多个模型
模型可以描述系统动态行为和静态结构
模型是一组具有完整语言的信息
现实的简化----Diagram及其包含的元素和关联
认知的主题----View
建模的价值？
建模是捕捉系统本质的过程
利用模型可以更简化的表示系统，理解系统
建模可以是基于特定视角的、有助于解决问题的、并且是完整的某一部分的信息
便于团队成员之间的有效沟通
统一建模语言UML
Unified Modeling Language
OMT、Booch、OOSE
统一----UML的核心
客户、分析师、设计师、程序员、测试工程师等沟通
建模----体现UML的使用价值
- 业务建模、
- 数据建模
语言----UML普遍价值的表现
- 特定规则和模式组成的符号系统
- 有效沟通的必要条件
分析和设计的逻辑模型
针对不同的研究目标和阶段可分：
1. 业务模型----Business Model
2. 数据模型----Data Model
3. 需求模型----Requirements Model
4. 应用模型----Application Model
每个模型可能包含概念、逻辑和物理等不同的层次
软件开发过程的生命周期
需求理解
需求分析
软件系统设计
软件系统实现
软件系统测试
软件系统维护
面向对象的优势
1. 减少沟通障碍
求解空间的要素和问题空间的要素一致
2. 提高开发生产率
“复用”－－方案架构、代码
非“基于复制的复用”
3. 增强对变化的适应能力
局部需求变化只会修改解决空间的局部
抽象－－Abstraction
反映事物最重要、最本质的特征
结构特征和行为特征
封装－－Encapsulation
将对象特征的实现隐藏在一个公共接口之后的黑盒中
保护该对象的内部状态
保护其他对象与该对象的沟通方式
层次－－Hierarchy
一个描述分类的结构
目的是表述并使用事物之间的相似性
主要的表现形式为类之间的泛化关系(Generalization)
2.面向对象设计原则
参考（面向对象设计原理 -SOLID原则）
- 单一职责原则 (Single Responsibility Principle, SRP)
类的职责要单一，不能将太多的职责放在一个类中
- 开闭原则 (Open-Closed Principle, OCP)
软件实体对扩展是开放的，但对修改是关闭的，即在不修改一 个软件实体的基础上去扩展其功能
- 里氏代换原则 (Liskov Substitution Principle, LSP)
在软件系统中，一个可以接受基类对象的地方必然可以接受一个子类对象
- 依赖倒转原则(Dependency Inversion Principle, DIP)
要针对抽象层编程，而不要针对具体类编程
- 接口隔离原则(Interface Segregation Principle, ISP)
使用多个专门的接口来取代一个统一的接口
- 合成复用原则(Composite Reuse Principle, CRP)
在系统中应该尽量多使用组合和聚合关联关系，尽量少使用甚至不使用继承关系
- 迪米特法则(Law of Demeter, LoD)
这里是引用 一个软件实体对其他实体的引用越少越好，或者说如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用，而是通过引入一个第三者发生间接交互.
抽象
封装
对象
类
对象之间的关系
导航性
多重性
接口
多态
结构元素----Structual Elements
行为元素----Behavioral Elements
分组元素----Grouping Elements
注释元素----Annotational Elements
是静态实体，不显示动态行为
构成UML模型的名词
表示一个物理元素或概念元素
包括7种结构建模元素：
类 Class 接口 Interface 用例 Use Case
协作 Collaboration 主动类 Active Class
组件 Component 节点 Node
表示动态模型的元素成为行为元素
分为：交互(interaction)和状态机(state machine)
交互，是对象间传递的消息，使对象间可以进行交互以完成一项特定的任务
状态机，描述一个对象响应事件时存在的不同的状态
表示组织方面的部分UML模型称为分组元素
包 package是唯一的分组元素
使用注释元素用来描述UML的角色
元素“note （注解）”用来记录与元素相关的约束与注释
依赖 Dependency
> 两个元素之间的语义关系，一个元素发生变化将导致另一个元素也发生变化
关联 Association
> 关联是一个结构关系， 对象间完成特定任务所进行的交互是通过关联来实现的
泛化 Generalization
> 是一般和特殊的关系， 特殊化的对象（子类）继承泛化类（父类）的属性、操作、关系和语义
实现 Realization
> 是接口和类或实现接口的组件之间存在的关系
类图 Class Diagram
> 显示了一组类、接口和协作以及他们之间的关系
对象图 Object Diagram
> 显示了一组对象和他们之间的关系
用例图 Use Case Diagram
> 显示了用例和参与者以及他们之间的关系
顺序图 Sequence Diagram
> 显示了消息的时间顺序
协作图 Collaboration Diagram
> 显示了交互对象的结构组成
状态图 Statechart Diagram
> 表示状态机，由状态、转换、事件和操作组成
活动图 Activity Diagram
> 表示系统中从一个活动向另一个活动的流动
组件图 Component Diagram
> 显示了系统中一组组件的组织和依赖关系
部署图 Deployment Diagram
> 显示了节点和驻留在这些节点上的组件
描述拟建系统与外部环境之间的关系
类图表示方法
类名
类的属性
类的方法
存取权限
类之间的关系
依赖
泛化
关联
使用关影响使用者系，被使用者为被依赖者，其改变可能
由超类和子类的关系组成，is a kind of
结构化关系，存在稳定的连接，可用于传递消息
一般为另一类的属性
是关联关系的一种强化，表示整体和部分的关系
整体多于1表示，部分可被多个整体共享
整体消失，部分实例依然存在
是进一步强化的聚合关系
必须同时存在，且整体不能共享部分的实例
扫一扫
7371
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
