架构设计师知识点笔记_精品文档Word文档格式.docx

架构设计师知识点笔记_精品文档Word文档格式.docx

《架构设计师知识点笔记_精品文档Word文档格式.docx》由会员分享，可在线阅读，更多相关《架构设计师知识点笔记_精品文档Word文档格式.docx（8页珍藏版）》请在冰豆网上搜索。

批处理序列；

管道/过滤器。

（2）调用/返回风格：

主程序/子程序；

面向对象风格；

层次结构。

（3）独立构件风格：

进程通信；

事件系统。

（4）虚拟机风格：

解释器；

基于规则的系统。

（5）仓库风格：

数据库系统；

超文本系统；

黑板系统。

二、设计模式的六大原则

1.开闭原则（OpenClosePrinciple）

开闭原则就是说对扩展开放，对修改关闭。

在程序需要进行扩展的时候，不能去修改原有代码，实现一个热插拔的效果。

所以一句话概括就是：

为了使程序的扩展性好，易于维护和升级。

想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会体会到这点

2.里氏代换原则（LiskovSubstitutionPrinciple）LSP

3.依赖倒转原则（DependenceInversionPrinciple）

4.接口隔离原则（InterfaceSegregationPrinciple）

5.迪米特法则（最少知道原则）（DemeterPrinciple）

6.合成复用原则（CompositeReusePrinciple）

原则是尽量使用合成、聚合的方式，而不是使用继承。

UML的五种视图：

5种视图分别描述系统的一个方面，5种视图组合成UML语言完整的模型。

用例视图用户描述系统应具备的功能。

逻辑视图设计人员和开发人员描述用例视图中提出的系统功能的实现。

组件视图开发人员显示代码组件的组织结构。

配置视图开发人员、系统集成人员、测试人员显示系统的具体部署。

部署是指将系统配置到由计算机和设备组成的物理结构上。

并发视图开发人员、系统集成人员显示系统的并发性，解决在并发系统中存在的通信和同步问题。

UML的九种图：

1.用例图（usecasediagrams）

2.静态图

（1）类图（classdiagrams）

（2）对象图（objectdiagrams）

3.交互图

（1）序列图（顺序图）

（2）协作图（Collaborationdiagrams）

4.行为图：

描述系统的动态模型和对象之间的交互关系。

（1）状态图（Statechartdiagrams）

（2）活动图（Activitydiagrams）

5.实现图

（1）构件图（Componentdiagrams）

（2）部署图（Deploymentdiagrams）

创建型模式，就是创建对象的模式，抽象了实例化的过程。

它帮助一个系统独立于如何创建、组合和表示它的那些对象。

关注的是对象的创建，创建型模式将创建对象的过程进行了抽象，也可以理解为将创建对象的过程进行了封装，作为客户程序仅仅需要去使用对象，而不再关心创建对象过程中的逻辑。

结构型模式的作用是解决怎样组装现有的类，设计他们的交互方式，从而达到实现一定的功能的目的。

结构型模式包含了对很多问题的解决。

例如：

扩展性（外观、组成、代理、装饰）封装性（适配器，桥接）。

行为型模式涉及到算法和对象间职责的分配，行为模式描述了对象和类的模式，以及它们之间的通信模式，行为型模式刻画了在程序运行时难以跟踪的复杂的控制流。

说明什么是数据库建模中的反规范化技术，指出采用反规范化技术能获得哪些益处，可能带来哪些问题。

规范化设计后，数据库设计者希望牺牲部分规范化来提高性能，这种从规范化设计的回退方法称为反规范化技术。

采用反规范化技术的益处：

降低连接操作的需求、降低外码和索引的数目，还可能减少表的数目，能够提高查询效率。

可能带来的问题：

数据的重复存储，浪费了磁盘空间；

可能出现数据的完整性问题，为了保障数据的一致性，增加了数据维护的复杂性，会降低修改速度。

（1）增加冗余列：

在多个表中保留相同的列，通过增加数据冗余减少或避免查询时的连接操作。

（2）增加派生列：

在表中增加可以由本表或其它表中数据计算生成的列，减少查询时的连接操作并避免计算或使用集合函数。

（3）重新组表：

如果许多用户需要查看两个表连接出来的结果数据，则把这两个表重新组成一个表来减少连接而提高性能。

（4）水平分割表：

根据一列或多列数据的值，把数据放到多个独立的表中，主要用于表数据规模很大、表中数据相对独立或数据需要存放到多个介质上时使用。

（5）垂直分割表：

对表进行分割，将主键与部分列放到一个表中，主键与其它列放到另一个表中，在查询时减少I/O次数。

逻辑视图：

主要支持系统的功能需求，即系统提供给最终用户的服务。

在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。

逻辑视图。

逻辑视图也称为设计视图，它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。

进程视图：

侧重于系统的运行特性，主要关注一些非功能性的需求，例如系统的性能和可用性。

进程视图。

进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。

开发视图：

也称为模块视图，主要侧重于软件模块的组织和管理。

物理视图：

主要考虑如何把软件映射到硬件上，它通常要考虑到解决系统拓扑结构、系统安装、通信等问题。

部署视图。

部署视图把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构。

场景：

可以看作是那些重要系统活动的抽象，它使四个视图有机地联系起来，从某种意义上说，场景是最重要的需求抽象。

逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。

对于不同的软件系统来说，侧重的角度也有所不同。

例如，对于管理信息系统来说，比较侧重于从逻辑视图和开发视图来描述系统，而对于实时控制系统来说，则比较注重于从进程视图和物理视图来描述系统。

实体类映射需求中的每个实体，实体类保存需要存储在永久存储体中的信息。

控制类用于对一个或几个用例所特有的控制行为进行建模，控制对象通常控制其他对象，因此它们的行为具有协调性。

边界类用于封装在用例内、外流动的信息或数据流。

边界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。

结构化分析方法的基本思想是自顶向下，逐层分解，把一个大问题分解成若干个小问题，每个小问题再分解成若干个更小的问题。

经过逐层分解，每个最低层的问题都是足够简单、容易解决的。

结构化方法分析模型的核心是数据字典，围绕这个核心，有三个层次的模型，分别是数据模型、功能模型和行为模型（也称为状态模型）。

在实际工作中，一般使用E-R图表示数据模型，用DFD表示功能模型，用状态转换图表示行为模型。

这三个模型有着密切的关系，它们的建立不具有严格的时序性，而是一个迭代的过程

基于软件架构的开发（ArchitectureBasedSoftwareDevelopment，ABSD）强调由商业、质量和功能需求的组合驱动软件架构设计。

它强调采用视角和视图来描述软件架构，采用用例和质量属性场景来描述需求

面向对象的分析模型主要由顶层架构图、用例与用例图和领域概念模型构成

设计模型则包含以包图表示的软件体系机构图、以交互图表示的用例实现图、完整精确的类图、描述复杂对象的状态图和用以描述流程化处理过程的活动图等

状态图：

用来描述一个特定对象的所有可能状态以及其引起状态转移的事件。

活动图：

用来描述操作的行为，也用于描述用例和对象内部的工作过程。

两者有本质区别：

状态图和活动图用于不同的目的，状态图着重描述一系列的状态及状态间的转移，状态间的变迁需要外部事件的触发。

活动图用于捕获动作及动作的结果，活动图中一个活动结束将立即进入下一个活动，是内部处理驱动的流程。

MVC架构风格最初是Smalltalk-80中用来构建用户界面时采用的架构设计风格。

其中M代表模型（Model），V代表视图（View），C代表控制器（Controller）。

在该风格中，模型表示待展示的对象，视图表示模型的展示，并能接收用户的输入数据，但是它不进行任何实际业务处理，控制器负责把用户的动作转成针对模型的操作。

模型通过更新视图的数据来反映自身的变化。

EJB中Bean分这三种类型：

SessionBean,EntityBean,Message-DrivenBean.

SessionBean的职责：

维护一个短暂会话，当客户端执行完成后，SessionBean和它的数据会消失。

EntityBean的职责：

维护一行持久稳固的数据，如果客户端终止或者服务结束，底层的服务会负责entityBean数据的存储。

Message-DrivenBean的职责：

结合了SessionBean和JMS，允许异步接收消息。

在EJB里面，会话Bean分为两种，一种是有状态的会话Bean，另一种是无状态的会话Bean，本节主要讲解一下两者之间的区别。

对于有状态的会话Bean，这种情况属于，服务端与你单独开辟了一块空间与你进行交互。

而客户端感觉服务端单独为他自己服务似的。

而无状态的会话Bean，则服务端不提供了一个资源但是谁用都行，他不负责。

所以客户端在使用的时候，则会感到这个服务与其他人共享似的。

1.有状态会话bean：

每个用户有自己特有的一个实例，在用户的生存期内，bean保持了用户的信息，即“有状态”；

一旦用户灭亡（调用结束或实例结束），bean的生命期也告结束。

即每个用户最初都会得到一个初始的bean。

2.无状态会话bean：

bean一旦实例化就被加进会话池中，各个用户都可以共用。

即使用户已经消亡，bean的生命期也不一定结束，它可能依然存在于会话池中，供其他用户调用。

由于没有特定的用户，那么也就不能保持某一用户的状态，所以叫无状态bean。

但无状态会话bean并非没有状态，如果它有自己的属性（变量），那么这些变量就会受到所有调用它的用户的影响，这是在实际应用中必须注意的

（1）概念模式。

概念模式（模式、逻辑模式）是数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图。

一个数据库只有一个概念模式数据库系统概念模式通常还包含有访问控制、保密定义、完整性检查等方面的内容，以及概念/物理之间的映射。

（2）外模式。

外模式（子模式、用户模式）用以描述用户看到或使用的那部分数据的逻辑结构，用户根据外模式用数据操作语句或应用程序去操作数据库中的数据。

外模式主要描述组成用户视图的各个记录的组成、相互关系、数据项的特征、数据的安全性和完整性约束条件。

（3）内模式。

内模式是数据物理结构和存储方式的描述，是数据在数据库内部的表示方式。

一个数据库只有一个内模式。

内模式定义的是存储记录的类型、存储域的表示以及存储记录的物理顺序