软件体系结构 整合.docx
《软件体系结构 整合.docx》由会员分享，可在线阅读，更多相关《软件体系结构 整合.docx（31页珍藏版）》请在冰点文库上搜索。
软件体系结构整合
1、三种构件分类法，如何检索构件，各自优缺点
关键字分类法：
是一种最简单的构件库组织方法，其基本思想是：
根据领域分析的结果将应用领域的概念按照从抽象到具体的顺序逐次分解为树形或有向无回路图结构。
优点：
简单，易于实现
缺点：
某些场合没有应用价值，因为用户往往无法用构建库中已有的关键字描述期望的构建功能或行为，对库的浏览也容易使用户迷失方向。
刻面分类法：
主要思想来源于图书馆学，在刻面分类机制中，定义若干用于刻画构建特征的“面”，每个面包含若干概念，这些概念表述构建在面上的特征。
刻面可以描述构建执行的功能，被操作的数据，构建应用的语境或任意其他特征。
优点：
易于实现相思构建的查找
缺点：
查询时比较麻烦。
超文本组织方法：
其主要思想是所有构建必须辅以详尽的功能或行为说明文档；说明中出现的重要概念或构建以网状链接方式相互连接；检索者在阅读文档的过程中可按照人类的联想思维方式任意跳转到包含相关概念或构建的文档；全文检索系统将用户给出的关键字说明文档中的文字进行匹配，实现构建的浏览式检索。
超文本组织方法为构造构件和重用构件提供了友好，直接的多媒体方式。
优点：
由于网状结构比较自由，松散，因此，超文本组织方法比前两种方法更易于修改构件库的结构。
缺点：
在某些情况下用户难以在超文本浏览过程中正确选取构建。
2、什么是web体系结构，与传统的结构相比，有什么好处？
在因特网上有许多系统和平台，在这些系统和平台上又有更多的应用程序。
说得
更明白些就是，存在着许多技术，把客户端连接到服务器，这其中包括DCOM、CORBA
和其它各种技术；而Web服务则是在HTTP、XML和SOAP这样的开放标准上形成的，
它具有更新和更简单的连接类型。
Web服务是基于XML和HTTPS的的一种服务，其通信协议主要基于SOAP，服务的描述通过WSDL，通过UDDI来发现和获得服务的元数据。
平台无关、语言无关。
对于图片的描述：
在Web服务模型的解决方案中，服务提供者定义并实现Web服务，使用服务描述语言（WSDL）描述Web服务，然后将服务描述发布到服务请求者或服务注册中心；服务请求者使用查找操作从本地或服务注册中心检索服务描述，然后使用服务描述与服务提供者进行绑定并调用Web服务。
服务注册中心是整个模型中的可选角色，它是连接服务提供者和服务请求者的纽带；
Web服务的具体特征（优点）：
完好的封装性；松散耦合；使用协议的规范性；使用标准协议规范；高度可集成能力。
Web服务体系结构最重要的优点之一就是允许在不同平台上使用不同编程语言以一种基于标准的技术开发程序，来与其它应用程序通讯；其次具有高度的通用性，易用性和集成性；
第二个答案：
Webservice是基于HTTP和XML的一种服务，其通信协议主要基于SOAP协议，服
务的描述通过WSDL，并通过UDDI来发现和获得服务的元数据。
Web服务就像web上的构件编程，开发人员通过调用web应用编程接口，将web服
务集成进他们的应用程序，就像调用本地服务一样。
Web服务的包括五个逻辑层：
数据层，数据访问层，业务逻辑层，业务面，监听者。
数据层：
保存物理数据。
数据访问层：
为业务层提供数据。
业务逻辑层：
提供业务面使用的服务。
业务面：
到底层业务对象的接口。
监听者：
接收并解析带有请求服务的信息，发送给业务面相应的方法。
Web服务就外部使用者的角度而言，web服务是一种部署在web上的对象/构件，它
具备以下特点：
使用标准协议规范，使用协约的规范性，高度集成能力，完好的封装
性，松散耦合。
Web服务模型
一个完整的web服务包括三种逻辑构件：
服务代理：
起中介作用。
是服务的注册构件；
服务请求者：
可在应用程序中通过服务代理请求服务，调用所需服务；
服务提供者：
提供服务，并进行注册以使服务可用。
相关的操作主要是发布，查找和绑定。
服务提供者向服务代理发布所提供的服务，服务请求者向服务代理发出服务查询请
求，最后服务请求者可以编程实现对服务的远程调用。
Web服务开发生命周期包括构建，部署，运行，管理四个阶段。
Web服务栈包括：
发现服务，UDDI；描述服务WSDL,消息格式SOAP,编码格式XML,
传输协议HTTP等。
Web服务体系结构的优势：
高度的通用性和易用性；完全的平台、语言独立性、高度
的继承性、容易部署和发布。
Web服务的技术核心：
XML可扩展标记语言；解决数据怎么表示的问题。
SOAP简单对象访问协议，解决数据怎么传输的问题。
WSDLweb服务描述语言，解决web服务怎么描述的问题。
UDDI统一描述，发现和集成协议，解决在哪里，怎么获取需要的信息的问题。
3、软件体系结构的引入，相对传统结构，软件开发过程有什么变化,这种变化有什么好处？
①体系结构是风险承担者进行交流的手段
②体系结构是早期设计决策的体现
③软件体系结构是可传递和可重用的模型
目前软件开发的问题日益突出，比如：
软件成本日益增长，开发进度难以控制，软件
质量差，软件维护困难等。
出现这些问题的主要原因有：
用户需求不明确，缺乏正确
的理论指导，软件规模越来越大，软件复杂度越来越高。
大量实践表明，大系统软件
开发中的大部分错误是由需求和软件设计阶段引入的，而且错误在系统中存在的时间
愈长愈难发现，解决这些错误的代价也越高。
软件体系结构的引入，本质上是对软件
需求的一种抽象解决方案，它试图在软件系统的需求与系统设计之间建立一座桥梁，
实现从系统需求到系统设计的平稳过渡。
引入它的好处有很多，包括程序员在内的绝
大多数系统的利益相关人员都借助软件体系结构来进行彼此理解、协商、达成共识
或者相互沟通，软件体系结构的模型可以应用到具有相似质量属性和功能需求的系
统中，并能够促进大规模软件的系统级复用，在很多方面使得软件开发更加人性化。
4、πADL描述一个简单系统
具体回答：
5、画出装饰模式的结构图举例说明各个角色的作用
动态地给一个对象添加一些额外的职责。
优点：
把类有的类。
有效地把类的核心功能和装饰功能区分开了。
中的装饰功能从类中搬移出去，这样可以简化原
已经开发完毕的对象，后期由于业务需要，对旧的对象需要扩展特别多的功能，这时候使用给对象动态地添加新的状态或者行为（即装饰模式）方法，而不是使用子类静态继承。
在装饰模式中的各个角色有：
（1）抽象构件（Component）角色：
给出一个抽象接口，以规范准备接收附加责任的对象。
（2）具体构件（ConcreteComponent）角色：
定义一个将要接收附加责任的类。
（3）装饰（Decorator）角色：
持有一个构件（Component）对象的实例，并实现一个与抽象构件接口一致的接口。
（4）具体装饰（ConcreteDecorator）角色：
负责给构件对象添加上附加的责任。
6、软件复用继承和聚合的优缺点
软件复用的主要思想是，将软件看成是由不同功能部分的“组件”所组成的有机体，每一个组件在设计编写时可以被设计成完成同类工作的通用工具，这样，如果完成各种工作的组件被建立起来以后，编写一特定软件的工作就变成了将各种不同组件组织连接体来的简单问题，这对于软件产品的最终质量和维护工作都有本质性的改变。
聚合：
一个对象拥有另一个对象或对另一个对象负责（即一个对象包含另一个对象或是另一个对象的一部分）并且聚合对象和其所有具有相同的生命周期（即所谓的“同生共死”关系）。
聚合复用优点：
①容器类仅能通过被包含对象的接口来对其进行访问。
②“黑盒”复用，因为被包含对象的内部细节对外是不可见。
③包装性好。
④实现上的相互依赖性比较小。
⑤每一个类只专注于一项任务。
⑥通过获取指定其他的具有相同类型的对象的使用，可以在运行期间动态地定义（对象的）组合。
聚合的缺点：
①导致系统中的对象过多②为了能将多个不同的对象作为组合块来使用，必须仔细地对接口进行定义。
类继承：
是一种通过扩展（一个已有对象的）实现，从而获得新功能的复用方法。
继承的优点：
①容易进行新的实现，因为其大多数可继承而来②易于修改或扩展那些被复用的实现。
继承的缺点：
①破坏了封装性，因为这会将父类的实现细节暴露给子类②“白盒”复用，因为父类的内部细节对于子类而言通常是可见的③当父类的实现更改时，子类也不得不随之更改④从父类继承来的实现将不能在运行期间进行改变。
画出工厂方法模式的结构图。
7、用一种你熟悉的ADL描述系统这种ADL的优缺点
有ACME,C2
ACME特点：
1.用7种基本的设计元素来表示软件体系结构：
2.提供了一种灵活的注释机制，支持把体系结构和用子语言表示的非结构化信息结合起来，这些子语言是外部定义的；
3.提供了一种类型机制，用于抽象出共同的、可重用的体系结构用法和风格；
4.提供了一个开放的语义框架，用于体系结构的描述的推理。
ACME支持从四个不同的方面对软件体系结构进行描述，分别是结构、属性、设计约束、类型和风格。
ACME对简单的C/S体系结构的描述
对图片的描述：
其中client构件只有一个sendRequest端口，server也只有一个receive_Request端口，连接件rpc有两个角色，分别为caller和callee。
该系统的布局（topology）是由与构件端口和连接件角色绑定的attachments定义，其中client的请求端口绑定到rpc的caller角色，server的请求处理端口绑定到rpc的callee端口。
Systemsimple_CS={
Componentclient={PortsendRequest}
Componentserver={PortreceiveRequest}
Connectorrpc={Roles{Roles{caller,callee}}
Attachments:
{
client.sendRequesttorpc.caller;
server.receiveRequesttorpc.caller}
}
C2：
通过连接件绑定在一起的按照一组规则运作的并行构件网络。
C2风格中的系统组织规则如下：
◎系统中的构件和连接件都有一个顶部和一个底部；
◎构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的；
◎一个连接件可以和任意数目的其它构件和连接件连接；
◎当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。
C2特点：
◎系统中的构件可实现应用需求，并能将任意复杂度的功能封装在一起；
◎所有构件之间的通讯是通过以连接件为中介的异步消息交换机制来实现的；
◎构件相对独立，构件之间依赖性较少。
系统中不存在某些构件将在同一地址空间内执行，或某些构件共享特定控制线程之类的相关性假设。
8、为什么要进行软件体系结构的风险评估和分析结合具体项目进行风险评估和分析
主要步骤如下：
1）采用体系结构描述语言ADL对体系结构进行建模；
2）通过模拟方法进行复杂性分析；
3）通过FMEA和模拟运行进行严重性分析；
4）为构件和连接件开发其启发式风险因子；
5）建立用于风险评估的CDG；
6）通过图论中的算法进行风险评估和分析。
结合具体项目：
Step1实际上是画出这个图
Step2实际上是计算构件的动态复杂度cpx；
Step3实际上是计算构件的失效危害程度svrty；
Step4Risk（Ci）表示第i个构件的风险因子。
Step5顺序图是最简单的CDG。
即：
构件一个接着一个的结构。
如下所示：
Step6执行风险评估：
这里的hrfi就是第i个构件的风险因子Risk（Ci）.
9.体系结构的测试是什么，熟悉使用抽象化学机进行测试的方法
体系结构测试着重于仿真系统模型，解决体系结构层的主要问题。
由于测试的抽象层次不同，体系结构测试策略可以分为单元/子系统/集成/验收测试等阶段的测试策略。
在体系结构集成测试阶段，Debra等人提出了一组针对体系结构的测试覆盖标准，PaolaInveradi提出了一种基于CHAM的体系结构语义验证技术。
化学抽象机看PPT
10.SOA
W3C定义：
SOA为一种应用程序体系结构，在这种体系结构中，所有功能都定义为独立的服务，这些服务带有定义明确的可调用接口，可以以定义好的顺序调用这些服务来形成业务流程。
服务:
是提供者完成一组工作，为服务使用者交付所需的最终结果。
SOA本质上是服务的集合，服务间彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动，服务间需要某些方法进行连接。
SOA为客户端/服务器的软件设计方法，一项应用有软件服务和软件服务使用者足证，着重强调软件构建的松散耦合，并使用独立的标准接口。
11.详细了解所讲过的设计模式.
代理模式
定义：
为其他对象提供一种代理以控制对这个对象的访问。
在某些情况下，一个对象不适合或者不能直接引用另一个对象，而代理对象可以在客户端和目标对象之间起到中介的作用。
代理模式的思想是为了提供额外的处理或者不同的操作而在实际对象与调用者之间插入一个代理对象。
这些额外的操作通常需要与实际对象进行通信。
优点
（1）.职责清晰
真实的角色就是实现实际的业务逻辑，不用关心其他非本职责的事务，通过后期的代理完成一件完成事务，附带的结果就是编程简洁清晰。
（2）.代理对象可以在客户端和目标对象之间起到中介的作用，这样起到了的作用和保护了目标对象的作用。
（3）.高扩展性
模式结构
一个是真正的你要访问的对象（目标类），一个是代理对象,真正对象与代理对象实现同一个接口,先访问代理类再访问真正要访问的对象。
应用场景
例如：
假设有一组对象都实现同一个接口，实现同样的方法，但这组对象中有一部分对象需要有单独的方法，传统的笨办法是在每一个应用端都加上这个单独的方法，但是代码重用性低，耦合性高。
如果用代理的方法则很好的解决了这个问题。
责任链模式
定义：
使多个对象都有机会处理请求，从而避免了请求的发送者和接收者之间的耦合关系。
将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。
类型：
行为类模式
类图：
责任连模式的结构
责任连模式的类图非常简单，它由一个抽象地处理类和它的一组实现类组成：
抽象处理类：
抽象处理类中主要包含一个指向下一处理类的成员变量nextHandler和一个处理请求的方法handRequest，handRequest方法的主要主要思想是，如果满足处理的条件，则有本处理类来进行处理，否则由nextHandler来处理。
具体处理类：
具体处理类主要是对具体的处理逻辑和处理的适用条件进行实现。
责任链模式的优缺点
责任链模式与if…else…相比，他的耦合性要低一些，因为它把条件判定都分散到了各个处理类中，并且这些处理类的优先处理顺序可以随意设定。
责任链模式也有缺点，这与if…else…语句的缺点是一样的，那就是在找到正确的处理类之前，所有的判定条件都要被执行一遍，当责任链比较长时，性能问题比较严重。
责任链模式的适用场景
就像开始的例子那样，假如使用if…else…语句来组织一个责任链时感到力不从心，代码看上去很糟糕时，就可以使用责任链模式来进行重构。
总结
责任链模式其实就是一个灵活版的if…else…语句，它就是将这些判定条件的语句放到了各个处理类中，这样做的优点是比较灵活了，但同样也带来了风险，比如设置处理类前后关系时，一定要特别仔细，搞对处理类前后逻辑的条件判断关系，并且注意不要在链中出现循环引用的问题。
观察者模式
定义：
定义对象间一种一对多的依赖关系，使得当每一个对象改变状态，则所有依赖于它的对象都会得到通知并自动更新。
类型：
行为类模式
类图
在软件系统中经常会有这样的需求：
如果一个对象的状态发生改变，某些与它相关的对象也要随之做出相应的变化。
比如，我们要设计一个右键菜单的功能，只要在软件的有效区域内点击鼠标右键，就会弹出一个菜单；再比如，我们要设计一个自动部署的功能，就像eclipse开发时，只要修改了文件，eclipse就会自动将修改的文件部署到服务器中。
这两个功能有一个相似的地方，那就是一个对象要时刻监听着另一个对象，只要它的状态一发生改变，自己随之要做出相应的行动。
其实，能够实现这一点的方案很多，但是，无疑使用观察者模式是一个主流的选择。
观察者模式的结构
在最基础的观察者模式中，包括以下四个角色：
被观察者：
从类图中可以看到，类中有一个用来存放观察者对象的Vector容器（之所以使用Vector而不使用List，是因为多线程操作时，Vector在是安全的，而List则是不安全的），这个Vector容器是被观察者类的核心，另外还有三个方法：
attach方法是向这个容器中添加观察者对象；detach方法是从容器中移除观察者对象；notify方法是依次调用观察者对象的对应方法。
这个角色可以是接口，也可以是抽象类或者具体的类，因为很多情况下会与其他的模式混用，所以使用抽象类的情况比较多。
观察者：
观察者角色一般是一个接口，它只有一个update方法，在被观察者状态发生变化时，这个方法就会被触发调用。
具体的被观察者：
使用这个角色是为了便于扩展，可以在此角色中定义具体的业务逻辑。
具体的观察者：
观察者接口的具体实现，在这个角色中，将定义被观察者对象状态发生变化时所要处理的逻辑。
观察者模式的优点
观察者与被观察者之间是属于轻度的关联关系，并且是抽象耦合的，这样，对于两者来说都比较容易进行扩展。
观察者模式是一种常用的触发机制，它形成一条触发链，依次对各个观察者的方法进行处理。
但同时，这也算是观察者模式一个缺点，由于是链式触发，当观察者比较多的时候，性能问题是比较令人担忧的。
并且，在链式结构中，比较容易出现循环引用的错误，造成系统假死。
模板方法模式
定义：
定义一个操作中算法的框架，而将一些步骤延迟到子类中，使得子类可以不改变算法的结构即可重定义该算法中的某些特定步骤。
类型：
行为类模式
类图：
模版方法模式的结构
模版方法模式由一个抽象类和一个（或一组）实现类通过继承结构组成，抽象类中的方法分为三种：
抽象方法：
父类中只声明但不加以实现，而是定义好规范，然后由它的子类去实现。
模版方法：
由抽象类声明并加以实现。
一般来说，模版方法调用抽象方法来完成主要的逻辑功能，并且，模版方法大多会定义为final类型，指明主要的逻辑功能在子类中不能被重写。
钩子方法：
由抽象类声明并加以实现。
但是子类可以去扩展，子类可以通过扩展钩子方法来影响模版方法的逻辑。
抽象类的任务是搭建逻辑的框架，通常由经验丰富的人员编写，因为抽象类的好坏直接决定了程序是否稳定性。
实现类用来实现细节。
抽象类中的模版方法正是通过实现类扩展的方法来完成业务逻辑。
只要实现类中的扩展方法通过了单元测试，在模版方法正确的前提下，整体功能一般不会出现大的错误。
模版方法的优点及适用场景
容易扩展。
一般来说，抽象类中的模版方法是不易反生改变的部分，而抽象方法是容易反生变化的部分，因此通过增加实现类一般可以很容易实现功能的扩展，符合开闭原则。
便于维护。
对于模版方法模式来说，正是由于他们的主要逻辑相同，才使用了模版方法，假如不使用模版方法，任由这些相同的代码散乱的分布在不同的类中，维护起来是非常不方便的。
比较灵活。
因为有钩子方法，因此，子类的实现也可以影响父类中主逻辑的运行。
但是，在灵活的同时，由于子类影响到了父类，违反了里氏替换原则，也会给程序带来风险。
这就对抽象类的设计有了更高的要求。
在多个子类拥有相同的方法，并且这些方法逻辑相同时，可以考虑使用模版方法模式。
在程序的主框架相同，细节不同的场合下，也比较适合使用这种模式。
命令模式
定义：
将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。
类型：
行为类模式
类图：
命令模式的结构
顾名思义，命令模式就是对命令的封装，首先来看一下命令模式类图中的基本结构：
Command类：
是一个抽象类，类中对需要执行的命令进行声明，一般来说要对外公布一个execute方法用来执行命令。
ConcreteCommand类：
Command类的实现类，对抽象类中声明的方法进行实现。
Client类：
最终的客户端调用类。
以上三个类的作用应该是比较好理解的，下面我们重点说一下Invoker类和Recevier类。
Invoker类：
调用者，负责调用命令。
Receiver类：
接收者，负责接收命令并且执行命令。
所谓对命令的封装，说白了，无非就是把一系列的操作写到一个方法中，然后供客户端调用就行了，反映到类图上，只需要一个ConcreteCommand类和Client类就可以完成对命令的封装，即使再进一步，为了增加灵活性，可以再增加一个Command类进行适当地抽象，这个调用者和接收者到底是什么作用呢？
其实大家可以换一个角度去想：
假如仅仅是简单地把一些操作封装起来作为一条命令供别人调用，怎么能称为一种模式呢？
命令模式作为一种行为类模式，首先要做到低耦合，耦合度低了才能提高灵活性，而加入调用者和接收者两个角色的目的也正是为此。
执行的时序首先是调用者类，然后是命令类，最后是接收者类。
也就是说一条命令的执行被分成了三步，它的耦合度要比把所有的操作都封装到一个类中要低的多，而这也正是命令模式的精髓所在：
把命令的调用者与执行者分开，使双方不必关心对方是如何操作的。
命令模式的优缺点
首先，命令模式的封装性很好：
每个命令都被封装起来，对于客户端来说，需要什么功能就去调用相应的命令，而无需知道命令具体是怎么执行的。
比如有一组文件操作的命令：
新建文件、复制文件、删除文件。
如果把这三个操作都封装成一个命令类，客户端只需要知道有这三个命令类即可，至于命令类中封装好的逻辑，客户端则无需知道。
其次，命令模式的扩展性很好，在命令模式中，在接收者类中一般会对操作进行最基本的封装，命令类则通过对这些基本的操作进行二次封装，当增加新命令的时候，对命令类的编写一般不是从零开始的，有大量的接收者类可供调用，也有大量的命令类可供调用，代码的复用性很好。
比如，文件的操作中，我们需要增加一个剪切文件的命令，则只需要把复制文件和删除文件这两个命令组合一下就行了，非常方便。
最后说一下命令模式的缺点，那就是命令如果很多，开发起来就要头疼了。
特别是很多简单的命令，实现起来就几行代码的事，而使用命令模式的话，不用管命令多简单，都需要写一个命令类来封装。
命令模式的适用场景
对于大多数请求-响应模式的功能，比较适合使用命令模式，正如命令模式定义说的那样，命令模式对实现记录日志、撤销操作等功能比较方便。
迭代器模式
定义：
提供一种方法访问一个容器对象中各个元素，而又不暴露该对象的内部细节。
类型：
行为类模式
类图：
迭代器模式的结构
抽象容器：
一般是一个接口，提供一个iterator（）方法，
升级会员 