软件架构复习.docx

软件架构复习.docx

《软件架构复习.docx》由会员分享，可在线阅读，更多相关《软件架构复习.docx（11页珍藏版）》请在冰豆网上搜索。

软件架构复习

概念题：

☐进一步理解软件架构定义

☐架构是一个或多个系统的抽象

☐是由抽象的组件来表示的

☐组件具有外部的可见特性

☐组件相互之间是有联系的

什么是模块，连接件，连接关系：

模块（组件）：

客户、服务器、数据库、中间件、程序包、过程、子程序、进程等——切碎、再切碎（粒度）

连接件：

过程调用、共享变量访问、信号灯、进程通信、消息传递、访问/网络协议等

连接关系：

信号灯亮代表什么

模块：

按钮，连接件：

消息机制，连接关系：

什么按钮对应什么内容（例如，点击“文件”按钮，弹出“文件”的内容）

架构={组件、连接件、约束}

☐组件：

一组程序代码、进程、接口

☐连接件：

调用、管道、消息

☐约束：

组件之间的连接关系

软件架构的作用

（1）软件架构定义了软件计算的组件、局部和总体的构成关系、以及这些组件之间的相互作用

（2）除了描述系统的构成和结构关系外，软件构架还表达了系统关键需求与系统构成之间的对应关系，这为系统的设计，提供了分析和评价的依据

2.2.1汽车控制系统架构演变的案例分析

定时扫描结构的特点：

☐定时时钟是整个系统协调一致的核心

☐周期地扫描采样，得到系统的各状态信息

☐循环扫描方式、固定的定时时间间隔、没有考虑采集部件不同的需要

☐改善的思路：

可根据具体硬件的情况、位置、性能、自我处理能力等，区别对待。

2.2.3关键质量属性需求与系统功能的正交性

功能性：

系统完成所期望工作的能力

☐实现功能的方法

☐没有内部模块/部件的职责划分，没有配合与协作，也可以实现系统功能，但是……

☐具有良好系统构架设计的系统必须……

☐如果既要实现功能，又具有良好的构架设计，满足关键需求，则系统设计将：

☐仔细地划分模块的功能

☐设计良好的模块间连接与关联关系

易用性：

☐架构设计无关：

界面表示直观、操作简便

☐架构设计有关：

☐是否允许取消、撤销操作

☐是否可重用以前输入的数据

☐是否有多层次的输入支持和帮助

系统性能：

☐架构设计无关：

算法的好坏

☐架构设计有关：

☐组件之间通信的瓶颈制约

☐分配给组件的功能的合理性

☐组件完成功能所需要的共享资源的情况

可修改性：

☐架构设计无关：

可读性好的注释和编码规范

☐架构设计有关：

☐逻辑独立

☐接口简单

☐变更涉及面小且清晰

☐回归测试的范围容易控制

4.1.3软件需求分析与架构师的关注点

1、需求分析阶段的工作目标与关键交付物成果：

☐需求分析阶段的任务是面向系统实现（最主要的是面向架构设计，而不是代码）、严格对系统的需求，进行再分析

2、需求分析阶段架构师的关注点：

☐软件产品本身除了用户功能需求以外，可能还存在与用户业务过程没有直接关系的非功能性需求，如：

与硬件、软件环境相关的操作系统和软件平台要求、对软件运行的远端监控要求、异常处理（如通信连接中断等非业务异常）、响应时间和负载能力要求等等。

☐另一方面，组织的或产品的设计约束和限制，也是系统需求必须要考虑的内容。

通常这三部分需求，构成了软件需求的总集。

☐后二个部分是架构师“新增加”的需求。

☐架构师的责任是保证这三部分的需求，能够合适地“糅合”在一起。

从体系结构的观点看ISO/OSI模型：

两种系统架构模式的比较与借鉴

相同点：

✓都是从硬件的构成和连接的基础开始，直到应用服务层

✓系统设计中都考虑了升级、扩展、兼容性，这是基于系统下一层为上层建立了良好服务功能的基础上才能实现的

✓下层的机制简化了上层的实现难度

✓层次结构对于性能追踪和分析，提供了可能

不同点：

✓上层对下层是否可以隔层、直接调用，OS结构限制的不是非常严格，为了提高效率，可以直接与底层建立连接。

ISO/OSI则不可以

软件架构概要设计的任务

✓软件系统概要设计的任务是：

✓将需求分析模型映射为具体的软件架构。

✓在上一章所讨论的软件架构“规划”阶段，这种映射要完成的是宏观和策略层面的“蓝图”，是设想和规划

✓而在本章讨论的，是实际完成的、可以交付编码工程师执行的设计“图纸”。

✓面向结构的系统设计产生的结果是：

✓过程设计、接口设计、架构设计和数据设计

✓采用面向对象方法产生的设计结果是：

✓子系统设计、数据设计、消息设计和方法设计。

1、软件架构（子系统）设计的任务是：

☐定义系统的主要结构元素及相互的关系。

☐结构化方法是从数据流图出发对数据进行分析，得出软件的层次化的模块结构图。

☐面向对象方法是：

通过分析模型（例如：

OMT模型），划分子系统，在考虑通信、并发、部署、复用等问题综合平衡的基础上，建立系统架构。

所以，不论用什么方法，首先确定的是系统的总体架构（主要是逻辑架构）。

2、数据设计（对象设计）的任务是：

☐结构化方法从在分析阶段得到的数据模型和数据字典出发，设计出相应的数据结构。

☐面向对象方法把数据作为类（通常为实体类）的一个属性，设计合适的数据结构，来表示这个属性。

3、过程设计（方法设计）的任务是：

☐将软件架构的结构元素变化为对软件组件的过程性描述。

☐结构化方法采用从分析阶段获得的过程规格说明、控制规格说明和状态图出发，得到系统各个功能的过程化描述。

☐面向对象方法从系统功能模型和行为模型出发，得到各个类的方法以及实现细节的描述。

4、接口设计的任务是：

☐描述系统内部、系统与系统之间以及系统与用户之间如何通信，接口包括了信息交互和特定的行为，因此，数据流和控制是接口设计的基础。

☐面向对象方法的接口设计主要是消息设计，面向对象的系统是以消息和事件为驱动的。

☐一般将软件架构（子系统）设计，归为概要设计，而将后三个部分的设计，纳入详细设计的范围。

五个架构之间的关系以及各自的解释：

子系统所包含的内部组件以及其含义：

子系统是组件的集合，一般子系统可能（但不是必须）具有以下四个内部组件：

☐问题域组件（核心业务逻辑）：

每一个子系统都是为了实现某类需求而存在的，问题域组件反映的是子系统的核心业务逻辑。

问题域组件是最反映用户需求的部件，也是需求分析阶段已经做了深入分析的部分。

☐人机交互组件（界面）：

人机交互的主要对象有二类：

窗口和报表。

窗口：

窗口信息：

系统登录、系统设置、信息的获取交互等；

窗口行为：

引发系统数据对象的建立、维护和删除（数据库记录）、系统管理设置、设备的打开、激活、关闭、系统业务活动等。

报表：

报表信息：

日报表、周报、月报、查询打印等；

报表行为；固定结果、查询结果、数据挖掘分析处理结果等。

☐数据管理组件（永久存储）：

数据管理组件通常有以下两个目的：

（1）用于存储问题域中持久性对象；

（2）用于封装问题域中持久性对象的存储和检索机制，通过这个方法，可以实现当持久性对象的存储和检索机制的具体实现方法改变的时候，只影响数据管理部件中的对象，而不影响到问题域中的对象。

☐系统交互组件（消息）：

系统交互组件主要负责系统与系统的物理设备之间、各子系统之间、系统与其他系统之间的通信和信息交互

面向对象创建型模式：

⏹基本的创建型模式：

●抽象工厂AbstractFactory：

提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类

●生成器Builder：

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示

●工厂方法FactoryMethod：

定义一个用于创建对象的接口，让子类决定实例化哪个类。

FactoryMethod使一个类的实例化延迟到其子类。

●原型Prototype：

用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象

●单件Singleton：

保证一个类仅有一个实例，并提供一个访问它的全局访问点

MVC的定义

模型-视图-控制器（MVC）模式

⏹MVC模式将一个交互式应用程序分成3个部件

●模型（model）：

软件所处理的核心逻辑，包含核心功能和数据

●视图（View）：

向用户显示信息，对相同的信息可以有不同的显示

●控制器（Controller）：

处理用户的输入（如：

鼠标、键盘等），转化成用户对模型或视图的服务请求，并把信息的变化，传递给视图。

用户仅通过控制器与系统交互

行为型模式7：

观察者（Observer）

⏹意图：

●定义对象间的一种一对多的依赖关系，当一个对象的状态发生变化时，所有依赖于他的对象都得到通知并被自动更新。

⏹动机：

●把一个系统分解成一些相互协作的类或者对象，有一个问题，就是如何维护这些相关的类/对象的一致性？

●一致性是协作的需要，但太紧密，又导致紧偶合

●观察者模式的典型应用是MVC结构

⏹这个模式，也称为发布-订阅（publish-subscribe）模式。

目标是通知的发布者，它发出通知时，并不知道谁是订阅者、有多少订阅者、是什么样的订阅者。

⏹发布-订阅（publish-subscribe）模式：

⏹发布：

广而告之

⏹订阅：

只针对订阅者

⏹发布主体：

模型（Model）

⏹消息受众：

●广播读者（推）：

可能没有任何请求、被动接收

●订阅读者（拉）：

点击、主动请求

⏹实现：

变更-传播机制

架构验证的概念：

☐好的策略必须是一再求证、测试、发现瑕疵漏洞，另想途径或方法来弥补策略不足，有时甚至不得不全盘放弃，重新策划。

☐架构原型对功能性需求的实现非常有限，也就是说，架构原型一般不是用来验证功能需求是否满足的。

☐那么“架构验证”要验证什么？

☐答案是：

验证架构对质量属性需求的支持程度，包括运行期质量属性和开发期质量属性。

验证架构的两种方法：

☐原型法：

对于项目型开发，一般常采用“原型法”。

☐框架法：

对于产品型开发，采用“框架法”有更多优点。

架构验证的目标：

（1）目的1——验证架构设计的可行性：

（2）目的2——检查架构设计的遵守程度：

使用VS2010进行层验证

☐当设计好一个应用系统架构后，“架构纪律”的一个基本要求是：

所有的模块信息交互，都必须通过定义好的接口进行，不能让应用程序模块直接调用该接口所属的类或方法。

所以，可以通过LayerDiagram来展示这个架构上的想法。

☐以下将使用一段非常简单的代码，通过现有代码层关系架构逻辑设计分析的基础上进行层验证（LayerValidation）功能

☐主要强调的是代码所代表的概念，而不是代码的细节。

针对架构设计基本要素的架构评审

1、架构设计的基本要素与架构评审：

☐这里所谓的架构设计的“基本要素”，主要是指架构设计的“物理、逻辑、开发、运行、数据”五个方面考虑因素。

即指架构设计在这五个方面限制条件下，是否满足其特定的需求。

显然，这五个要素，是架构设计的最基本考虑因素。

2、针对基本要素的架构评审：

☐针对五个基本素的架构设计评审，架构师应包括分别报告并接受审查以下一些内容：

☐目标系统在这五个方面的具体需求和限制是什么？

☐针对需求和限制的设计决策是什么？

☐实现设计决策的方法是什么？

☐通过一定的形式，例如：

原型法、模拟运行环境、形式化方法等，对采用上述设计方法可能达到的实现效果，进行展示和预期，并接受老师的评审。

3、效果展示与评审方法：

☐在实现方法的效果评审中，应考虑采用按五个方面，进行分解的方法。

如：

根据需求的OMT方法，把用例图转化为静态的类图、动态的行为（状态图、时序图、协作图、活动图），以及反映系统架构的组件图和部署图时，应分别报告：

系统设计和实现，是如何分别满足五个方面的特定需求和限制的。

4、评审的关注点：

☐评审老师应特别关注：

作为系统架构设计的第一步和关键一步，系统一步步被分解为子系统、包、接口、实现类、对象和方法等，其分解的依据是什么？

各逻辑单元的抽取与定义是如何体现对系统架构元素（模块、组件、包、子系统）进行划分和分离的？

分离点在哪里？

理由是什么？

这些分离后的架构元素本身，是否满足：

☐抽象是否与系统目标相一致；

☐是否与作为类的责任相一致；

☐是否满足高内聚、松耦合的原则要求；

☐是否可以委托给其他类；

☐等等。

实践题：

1.4两个简单程序的架构实现与分析

1、计算器程序

。

。

。

。

2、“欢迎”的程序

☐在MFC应用程序向导-步骤1中，向导提问：

你要创建的应用程序类型是？

有三个选项：

单文档界面、多文档界面和基于对话框的应用程序。

选择“单文档”，并选择（打钩）“文档/查看架构支持”，最后单击【完成】。

☐至此，利用MFC向导，完成了应用程序框架的创建。

如果直接编译这个程序，就完全可以运行了。

☐打开工作区的“ResourceView”选项，展开“Menu”和“IDR_MAINFRAME”，就可以看到“欢迎”程序主菜单（此时，还没有添加“欢迎”按钮）。

☐在菜单“帮助”右边的空白处，点击鼠标右键，在弹出的快捷菜单中，选择“属性”，在新出现的“菜单项目-属性”对话框中的“标明”处，填写新菜单项的显示标题——“欢迎”，取消“弹出”钩，在ID栏里，为菜单取一个名字“ID_MENUACCE”，按Enter键，完成新按钮的创建，此时可以看到，已添加了一个“欢迎”按钮。

☐创建消息映射：

在MFC工具栏上，选择【查看】|【建立类向导】，弹出MFCClassWizard对话框，在ObjectIDs处的下拉菜单中，选中刚刚命名的按钮名——ID_MENUACCE，然后，在Messages处，选择COMMAND，点击右边的【AddFunction】按钮，在新出现的“添加消息函数”对话框中，填写新的函数名——“OnMenuacce”。

点击【OK】，完成映射的设置。

☐MFC通过这样的方式，建立了按钮（构件，本质上也是代码）与处理函数构件（代码）之间的连接定义。

实际上，MFC是通过自动在MenuAcceView.h文件中，为按钮消息处理函数OnMenuacce（）定义了如下代码：

☐这一步的意义，是让Windows知道，当按钮被按下的时候，找谁来处理这个按钮事件。

☐从架构角度看，这就是构成架构的第二个要素——建立构件之间的“联系”。

☐Windows的消息机制，是构件之间联系的“连接件”。

☐建立“连接”的方式越来越简单——IDE平台可视化

☐编写处理函数。

在MenuAcceView.cpp文件的相应位置（MFC已经为你留空），编写显示“欢迎”的代码。

☐应用程序到了这一步，可能需要程序员的大量工作，但架构师的任务已经基本完成。

☐最后一步，从架构的角度讲，是完成另一个构件——“处理函数”。

同时，在处理函数模块中，实现架构概念的第三个要素：

构件之间的“交互协议”，交互协议的具体内容，应体现在按钮的内容、传递的消息内容和对应的处理函数三者之中。

以欢迎程序为例，如果换一种按钮，以及相应的按钮功能（如不是显示“欢迎”，而是显示当前时间），那么，在现有的架构下，哪些需要修改，哪些不用修改，为什么？

欢迎与时间调换程序：

1、在MenuAccess程序的基础上，把“欢迎”按钮，改成“时间”按钮，并显示当前时间；

2、把“欢迎”程序的“欢迎”按钮，从系统菜单移到窗口内，用一个按钮控件实现；

3、为“欢迎”程序实现两个“欢迎”按钮，一个是按“模式对话框”，另一个是“非模式对话框”方法实现的。

看看在代码实现（协议）上，有什么不同。

（注：

所谓“模式对话框”是指用户在对当前对话框做出响应、例如，按下当前对话框的【确认】键之前，程序不允许用户进入系统的其他部分。

而“非模式对话框”则没有这个限制，因此，即使没有按下当前对话框的【确认】键，话框没有被关闭的情况下，也允许用户不断打开新的对话框，导致出现多个相同的对话框，甚至进行其他操作，如退出程序。

采用“非模式对话框”将导致相同面临更多的复杂情况）。

4、只有一个“欢迎”按钮，但这个按钮需要根据窗口内的不同情景，决定打开对话框的“种类”。

例如：

当窗口已经出现多于3个对话框的时候，新打开的对话框，只能是“模式对话框”。

否则，则可以打开“非模式对话框”，直到对话框数到达3为止。

当前窗口的状态，必须有按钮构件进行判断，并作为参数，传递给执行对话框创建的构件（假定该构件是外部DLL）。

汽车控制系统的设计

☐p模块划分原则：

用来完成同一个功能、位于同一个硬件中、用于管理相同的资源等系统被划分为：

开关量、速度、模数转换、数模转换、中心控制5个子系统

☐各子系统有自己的问题域、接口、数据存储部分

☐各子系统与控制部分的连接是系统交互部件、即各子系统与控制部件的接口

☐连接关系是：

中断（中断定义、处理约定）

☐在以上基础上，考虑灵活性

五子棋程序

电梯控制

播放器（KTV扩展）