精华内容
下载资源
问答
  • 本书系统介绍了软件体系结构的基本原理、方法和实践,全面反映了软件体系结构研究和应用的最新进展。既讨论了软件体系结构的基本理论知识,又介绍了软件体系结构设计和工业界应用实例,强调理论实践相结合。 ...
  • 引入软件体系结构技术,将软件分析设计过程细分为需求分析体系结构设计系统设计3 个阶段,并 提出了基于体系结构的软件分析设计过程(SADPBA) 模型,该模型是一种采用迭代增量方法将功能设计空 间映射到结构设计空间...
  • 软件工程设计概念与体系结构设计

    千次阅读 2020-04-15 11:46:39
    设计软件的时候,首要需求必须是被分析和被具体指定了。 在软件设计的过程中,设计工程是设计软件的概念之一。在开始软件设计时,需求应该被分析和建模。这个模型能够保证质量和在编码生成时能够进行改进。 在一个...

    软件工程第四次作业

    11.1 当你编写程序时是否会设计软件?软件设计和编码有什么不同?

    • 我在编写程序是并不会设计软件,编写程序和设计软件是不同的概念。当软件质量被确定好时才会设计软件。在设计软件的时候,首要需求必须是被分析和被具体指定了。
    • 在软件设计的过程中,设计工程是设计软件的概念之一。在开始软件设计时,需求应该被分析和建模。这个模型能够保证质量和在编码生成时能够进行改进。
    • 在一个软件工程的内容中,首先需要的是改进项目的模型,而并不是项目本身。

    软件设计和编码的不同

    • 首先非常明确的是,软件设计不是编码,编码也不是软件设计。他们是项目不同组件所产生的。
    • 设计是用来解决问题的逻辑的描述。
    • 编码是实现设计的语言规范,他是运行在电脑上并提供预期结果的

    11.17 简要描述设计模型的四个元素。

    1. 数据设计元素

      • 在数据设计元素中,创建了在高抽象级上表示的数据模型和信息模型。数据结构通常是软件设计的重要部分。在数据设计元素中可以存放类图,分析包,CRC模型,协作图,数据流图,控制流图,处理过程说明等。

      • 在体系结构级,数据设计关注文件或数据库,在构件级,数据设计考虑实现局部数据对象所需的数据结构

    2. 体系结构设计元素

      • 软件的体系结构设计等效于房屋的平面图。软件体系结构设计元素提供了整个软件的整体视图。

      • 体系结构模型从以下三个来源导出:1. 关于将要构建的软件的应用域信息。 2. 特定的需求模型元素,如数据流图或分析类,现有问题中他们的关系和协作。 3. 可获得的体系结构风格和模式

      • 体系结构设计元素通常被描述成一组相互联系的子系统,且常常从需求模型的分析包中派生出来。

    3. 接口设计元素

      • 软件的接口相当于一组房屋的门,窗和外部设施的详细绘图。软件接口设计元素描述了信息如何流入和流出系统,以及被定义为体系结构一部分的构件之间是如何通信的。

      • 接口设计有三个重要元素:1. 用户界面(User Interface) 2. 和其他系统、设备、网络、信息生成者或使用者的外部接口。3. 各种设计构件之间的内部接口。能够使软件进行外部通信,还能使软件体系结构中的构件之间进行内部的通信和协作。这些接口设计元素能够使软件进行外部通信,还能使软件体系结构中的构件之间进行内部通信和协作。

      • UI设计使软件工程中的主要活动,包含美学元素,人机工程元素,技术元素等。

      • 外部接口设计需要发送和接收信息实体的确定信息

      • 内部接口设计和构件级设计紧密相关。

    4. 构建级设计元素

      • 软件的构件级设计相当于一个房屋中的每个房间的一组详图(规格说明)软件的构件级设计完整地描述了每个软件构件的内部细节。为此,构件级设计为所有局部数据对象定义数据结构,为所有在构件内发生的处理定义算法细节,并定义允许访问所有构件操作的接口。
      • 在面向对象的软件工程中,使用UML图表现的一个构件。能够反应整个构件图的整体规划。

    12.2 举出2-3个例子,说明12.3.1节中提到的每一种体系结构风格的应用。

    1. 以数据为中心的体系结构:

      数据存储位于这种体系结构的中心,其他构件会经常访问该数据存储,并对存储中的数据进行更新,增加,删除,或者修改。

      例子:

      图书目录查询系统:这里涉及到许多数据的管理,数据库的构建,存储等

      线上购书系统: 购书记录也是需要不断对数据进行访问删除存储。

      剪贴板:剪贴板是一个用来进行短时间的数据存储,并在文档/应用之间进行数据传递和交换的软件程序

    2. 数据流体系结构:

      当输入数据经过一系列计算构件和操作构件的变换形成输出数据时,可以应用这种体系结构。

      例子:

      工程软件: 这里涉及到许多构件的前后关系,要经过一系列计算构件

      科学软件

      Unix 的Shell程序

    3. 调用和返回体系结构:

      这种体系结构风格能设计出一个相对易于修改和扩展的程序结构。

      例子:

      任何I-O-P 申请。

      C语言或C++语言中所用到的使用函数时的结构

    4. 面向对象体系结构

      系统的构件封装了数据和必须用于控制该数据的操作,构件间通过信息传递进行通信与合作

      例子:

      所有面向对象的程序,C++,Java中的面向对象的程序的内容

      基于GUI的应用程序,用来显示画面

    5. 层次体系结构

      层次体系结构中定义了一系列不同的层次,每个层次各自完成操作,这些操作逐渐接近机器的指令集。

      例子:

      客户端服务器软件一般来说都是分层的

      一些应用功能要从底层操作系统分离的应用程序。

    12.7 使用本章描述的设计方法开发PHTRS的软件体系结构。

    PHTRS系统是城市公共工程部门开发路面坑洼跟踪和修补系统。

    PHTRS采用的是以数据为中心的体系结构。数据中心是包含有坑洼信息,报告信息,修补信息的数据库。

    体系结构基本上分为4个层次:

    1. 用户界面层:是由网站和在用户桌面上的用户界面程序组成的。市民通过网站去登录并且报告一个坑洼信息。施工人员会用软件登录数据库并去生成工作顺序和损失报告。工程承包商用相同的软件去根据修补信息,比如修补员工的基本信息,特长,材料使用,修补时长等数据来更新坑洼情况。

    2. 业务层:业务层是业务逻辑存在的地方。它包括业务组件,所有业务实体和定义了管理业务工作流的规则。

    3. 数据访问层:这一层提供了更多的清晰性和数据安全性。数据只能够被类中定义的去访问数据库,并进行增删改。

    4. 最后是数据库。 是设计中的最后一层

    展开全文
  • 【《软件设计模式与体系结构》学习笔记】软件设计模式的概念软件设计模式是对软件设计经验的总结,是对软件设计中反复出现的设计问题的已被验证的成功解决之道。大量的软件设计模式都是之前从事软件设计开发的前人...

    【《软件设计模式与体系结构》学习笔记】

    软件设计模式的概念


    软件设计模式是对软件设计经验的总结,是对软件设计中反复出现的设计问题的已被验证的成功解决之道。大量的软件设计模式都是之前从事软件设计开发的前人经过大量的实践而摸索出来的,用于帮助后来者快速高效且高质从事软件开发的。

    软件设计模式的要素


    软件设计模式一般会包含四个基本要素:

    • 模式名称:此种设计模式的名字;
    • 问题:是设计者所面临的设计场景,也就是此种设计模式所适用的情况;
    • 解决方案:描述设计细节,通常会采取UML等图示的方式来进行设计模式的详细描述;
    • 效果:描述适用此设计模式的优势与劣势,包括面向软件的质量属性等。

    软件设计模式的分层


    软件设计模式根据问题的规模可以分为三个层次
    架构模式 -> 设计模式 -> 习惯用法

    1. 架构模式:描述系统级的结构组成、相互关系及相关约束,如MVC模式;
    2. 设计模式:针对系统局部设计问题给出的解决方案,一般情况下,设计模式指的就是这一层次的;
    3. 习惯用法:与具体编程语言相关的一种底层模式。

    软件设计模式的分类


    《软件设计模式与体系结构》一书中将设计模式归类如下:

    面向对象分布式计算企业应用软件面向服务的体系结构(SOA)
    创建型模式从混沌到结构领域逻辑模式服务设计模式
    结构型模式分布式基础设施数据源结构模式服务库设计模式
    行为型模式事件分离与分发对象——关系行为模式服务组合设计模式
    接口划分对象——关系结构模式
    组件划分对象——关系元数据映射模式
    应用控制Web表现模式
    并发分布模式
    同步离线并发模式
    对象交互会话状态模式
    适配与扩展基本模式
    模态行为
    资源管理
    数据库访问

    感悟

    在我们日常学习中,有些时候不知不觉的应用到某些设计模式,但我们很难意识到这可以抽象为一种思想方法,并且是可以被他人当为一种模式的设计方法。所以,在以后我们又碰到类似问题时,又会重新将以前的思路再来一次,等到脑中的设计思想快成型的时候,才会恍然大悟,一拍脑门道:“哦,这个东西我好像上一次做过。”

    设计模式是前人经过验证的成功的解决方案,我们应该要善于学习,学会运用,别辜负了前辈们的心血。站在巨人的肩膀上,我们会看得更远。

    展开全文
  • 软件体系结构与设计模式笔记

    千次阅读 2012-12-26 22:35:35
    软件体系结构与设计模式笔记 第1章软件体系结构概述 ü SEI软件体系结构讨论群定义如下:一个程序/系统构件的结构,它们之间的相互关系,以及在设计和交付的整个过程中的原则和指导方针。 ü Mary Shaw和David ...

    软件体系结构与设计模式笔记

    第1章软件体系结构概述

    ü  SEI软件体系结构讨论群定义如下:一个程序/系统构件的结构,它们之间的相互关系,以及在设计和交付的整个过程中的原则和指导方针。

    ü  Mary Shaw和David Garlan认为软件体系结构包括构成系统的设计元素的描述,设计元素的交互,设计元素组合的模式,以及在这些模式中的约束。

    ü  软件体系结构包括构件(Component)、连接件(Connector)和约束(Constrain)或配置(Configuration)三大要素。

    ü  国内普遍接受的定义:软件体系结构包括构件、连接件和约束,它是可预制和可重构的软件框架结构。

    ü 构件是可预制和可重用的软件部件,是组成体系结构的基本计算单元或数据存储单元

    ü 连接件也是可预制和可重用的软件部件,是构件之间的连接单元

    ü 构件和连接件之间的关系用约束来描述

    ü  软件体系结构 = 构件 + 连接件 + 约束

    软件体系结构的优势容易理解、重用、控制成本、可分析性

    第2章软件体系结构风格

    w  软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。

    w  体系结构风格定义了一个系统家族,即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型,而这组约束指出系统是如何将这些构件和连接件组合起来的。

    w  体系结构风格反映了领域中众多系统所共有的结构和语义特性,并指导如何将各个模块和子系统有效地组织成一个完整的系统。

    w  数据流风格: 批处理序列; 管道/过滤器。

    w  调用/返回风格:主程序/子程序;面向对象风格;层次结构。

    w  独立构件风格:进程通讯;事件系统。

    w  虚拟机风格:解释器;基于规则的系统。

    w  仓库风格:数据库系统;超文本系统;黑板系统。

    w  过程控制环路

    C/S风格体系结构有三个主要组成部分:数据库服务器、客户应用程序和网络。

    B/S风格浏览器/Web服务器/数据库服务器。

    优点:C/S体系结构具有强大的数据操作和事务处理能力,模型思想简单,易于人们理解和接受。将大的应用处理任务分布到许多通过网络连接的低成本计算机上,以节约大量费用。

    缺点:开发成本较高、客户端程序设计复杂、信息内容和形式单一、用户界面风格不一,使用繁杂不利于推广使用、软件移植困难、软件维护和升级困难、新技术不能轻易应用

    优点:基于B/S体系结构的软件,系统安装、修改和维护全在服务器端解决。

    缺点:B/S体系结构缺乏对动态页面的支持能力,没有集成有效的数据库处理功能。

    B/S体系结构的系统扩展能力差,安全性难以控制。

    采用B/S体系结构的应用系统,在数据查询等响应速度上,要远远低于C/S体系结构。

    B/S体系结构的数据提交一般以页面为单位,数据的动态交互性不强,不利于在线事务处理(OLTP)应用。

    第3章软件需求与架构

    w  需求的基本概念

    ü  IEEE (1997)

    Ø (1)  用户解决问题或达到目标所需的条件或能力

    Ø (2)  系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力

    Ø (3)  一种反映上面(1)或(2)所描述的条件或能力的文档说明

    w  业务需求

    ü  反映组织机构或客户对系统、产品高层次的目标要求,通常问题定义本身就是业务需求

    w  用户需求

    ü  描述用户使用产品必须要完成什么任务,怎么完成的需求,通常是在问题定义的基础上进用户访谈、调查,对用户使用的场景进行整理,从而建立从用户角度的需求。

    w  系统需求

    ü  从系统的角度来说明软件的需求,包括用特性说明的功能需求、质量属性,以及其他非功能需求,还有设计约束等。

    w  非功能需求

    ü  指产品必须具备的属性或品质,如正确性、可靠性、性能、容错性和可扩展性等。

    w  功能需求

    ü  需求的主体,需求的本质

    ü  功能需求定义:系统必须完成的那些事,即为了向它的用户提供有用的功能,产品必须执行的动作

    w  设计约束

    获取需求的方法

    ü  面谈(访谈)

    ü  问卷调查

    ü  会议(需求讨论会、重点问题讨论会、业务专题讨论会、设计专题讨论会)

    ü  文档研究

    ü  任务示范(观察)

    ü  用例与角色扮演

    ü  原型设计(小规模试验)研究类似公司

    需求的层次化

    ü  业务级需求:包含客户或出资者要达到的业务目标、预期投资、工期要求,以及要符合哪些标准、对哪些遗留系统进行整合等约束条件。

    ü  用户级需求:用户使用系统来辅助完成哪些工作?对质量有何要求?用户群及所处的使用环境方面有何特殊要求?

    ü  开发级需求:开发人员需要实现什么?开发期间、维护期间有何质量考虑?开发团队的哪些情况会反过来影响架构?

    需求分类

    ü  功能需求:更多体现各级直接目标要求

    ü  质量属性:运行期质量 + 开发期质量

    ü  约束需求:业务环境因素 +使用环境因素 + 构建环境因素+ 技术环境因素

    ü  功能模型——如UC

    ü  业务流程模型——如DFD

    ü  数据建模模型——如ER

    w  用例建模(Use CaseModeling)是使用用例的方法来描述系统的功能需求的过程,用例建模促进并鼓励了用户参与,这是确保项目成功的关键因素之一。

    粒度原则:

           用例要有路径,路径要有步骤。而这一切都是“可观测”的。

    ü  需求跟踪的目的是建立与维护“需求-设计-编程-测试”之间的一致性,确保所有的工作成果符合用户需求。

    w  外部质量对于用户而言是可见的包括正确性、健壮性、可靠性、性能、安全性、易用性、兼容性等。

    w  内部质量只有开发人员关心它们可以帮助开发人员实现外部质量包括易理解性、可测试性、可维护性、可扩展性、可移植性、可复用性等

    ü  依赖注入

    w 构造注入(Constructor Injection):通过构造函数注入实例变量。

    w 设值注入(Setter Injection):通过Setter方法注入实例变量。

    w 接口注入(Interface Injection):通过接口方法注入实例变量。

    1.        用例文档

    用例编号

    用例名

    执行者

    前置条件

    后置条件

    涉众利益

    基本路径      

    ü  1…..××××

    ü  2……××××

    ü  3…..××××

    2.        需求规格说明书

     

    第1章_统一建模语言基础知识

    a)        视图(View)

                            i.             用户视图:以用户的观点表示系统的目标,它是所有视图的核心,该视图描述系统的需求。

                          ii.             结构视图:表示系统的静态行为,描述系统的静态元素,如包、类与对象,以及它们之间的关系。

                         iii.             行为视图:表示系统的动态行为,描述系统的组成元素如对象在系统运行时的交互关系。

                         iv.             实现视图:表示系统中逻辑元素的分布,描述系统中物理文件以及它们之间的关系。

                          v.             环境视图:表示系统中物理元素的分布,描述系统中硬件设备以及它们之间的关系。

    用例图(Use Case Diagram): 又称为用况图,对应于用户视图。在用例图中,使用用例来表示系统的功能需求,用例图用于表示多个外部执行者与系统用例之间以及用例与用例之间的关系。用例图与用例说明文档(Use Case Specification)是常用的需求建模工具,也称之为用例建模。

    类图(Class Diagram):对应于结构视图。类图使用类来描述系统的静态结构,类图包含类和它们之间的关系,它描述系统内所声明的类,但它没有描述系统运行时类的行为。

    w  类之间的关系

    ü  关联关系

    •      关联关系(Association)是类与类之间最常用的一种关系,它是一种结构化关系,用于表示一类对象与另一类对象之间有联系。

    •      双向关联

    •      单向关联

    •      自关联

    •      重数性关联

    ü  聚合关系

    •      聚合关系(Aggregation)表示一个整体与部分的关系。通常在定义一个整体类后,再去分析这个整体类的组成结构,从而找出一些成员类,该整体类和成员类之间就形成了聚合关系。

    ü  组合关系

    •      组合关系(Composition)也表示类之间整体和部分的关系,但是组合关系中部分和整体具有统一的生存期。一旦整体对象不存在,部分对象也将不存在,部分对象与整体对象之间具有同生共死的关系。

    ü  依赖关系

    •      依赖关系(Dependency)是一种使用关系,特定事物的改变有可能会影响到使用该事物的其他事物,在需要表示一个事物使用另一个事物时使用依赖关系。大多数情况下,依赖关系体现在某个类的方法使用另一个类的对象作为参数。

    ü  泛化关系

    •      泛化关系(Generalization)也就是继承关系,也称为“is-a-kind-of”关系,泛化关系用于描述父类与子类之间的关系,父类又称作基类或超类,子类又称作派生类。在UML中,泛化关系用带空心三角形的直线来表示。

    ü  接口与实现关系

    •      接口之间也可以有与类之间关系类似的继承关系和依赖关系,但是接口和类之间还存在一种实现关系(Realization),在这种关系中,类实现了接口,类中的操作实现了接口中所声明的操作。在UML中,类与接口之间的实现关系用带空心三角形的虚线来表示。

    w  顺序图定义

    ü  顺序图(SequenceDiagram)是一种强调对象间消息传递次序的交互图,又称为时序图或序列图。

    w  状态图定义

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

     

    第2章_面向对象设计原则

    w  单一职责原则要求在软件系统中,一个类只负责一个功能领域中的相应职责。

    w  开闭原则要求一个软件实体应当对扩展开放,对修改关闭,即在不修改源代码的基础上扩展一个系统的行为。

    w  里氏代换原则可以通俗表述为在软件中如果能够使用基类对象,那么一定能够使用其子类对象。

    w  依赖倒转原则要求抽象不应该依赖于细节,细节应该依赖于抽象;要针对接口编程,不要针对实现编程。

    w  接口隔离原则要求客户端不应该依赖那些它不需要的接口,即将一些大的接口细化成一些小的接口供客户端使用。

    w  合成复用原则要求复用时尽量使用对象组合,而不使用继承。

    w  迪米特法则要求一个软件实体应当尽可能少的与其他实体发生相互作用。

    第3章_设计模式概述

    w  设计模式的定义

    ü  设计模式(DesignPattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结,使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。

    ü  设计模式一般有如下几个基本要素:模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式,其中的关键元素包括以下四个方面:

    w 模式名称(Pattern name)

    w 问题(Problem)

    w 解决方案(Solution)

    w 效果(Consequences)

     

    范围\目的

    创建型模式

    结构型模式

    行为型模式

    类模式

    工厂方法模式

    (类)适配器模式

    解释器模式

    模板方法模式

    对象模式

    抽象工厂模式

    建造者模式

    原型模式

    单例模式

    (对象)适配器模式

    桥接模式

    组合模式

    装饰模式

    外观模式

    享元模式

    代理模式

    职责链模式

    命令模式

    迭代器模式

    中介者模式

    备忘录模式

    观察者模式

    状态模式

    策略模式

    访问者模式

     

     

    第4章_简单工厂模式

    ü  简单工厂模式(SimpleFactory Pattern):又称为静态工厂方法(Static Factory Method)模式,它属于类创建型模式。在简单工厂模式中,可以根据参数的不同返回不同类的实例。简单工厂模式专门定义一个类来负责创建其他类的实例,被创建的实例通常都具有共同的父类。

    ü  重构后的代码:

    public abstract class AbstractPay

    {

      public abstract void pay();

    }

    public class CashPay extends AbstractPay

    {

       public void pay()

        {

           //现金支付处理代码

        }

    }

    public class PayMethodFactory

    {

       public static AbstractPay getPayMethod(String type)

        {

           if(type.equalsIgnoreCase("cash"))

           {

               return new CashPay();       //根据参数创建具体产品

            }

            elseif(type.equalsIgnoreCase("creditcard"))

           {

               return new CreditcardPay();   //根据参数创建具体产品

           }

           ……

        }

    }

    ü  简单工厂模式最大的缺点是当有新产品要加入到系统中时,必须修改工厂类,加入必要的处理逻辑,这违背了“开闭原则”。

    ü  简单工厂模式最大的优点在于实现对象的创建和对象的使用分离,将对象的创建交给专门的工厂类负责,但是其最大的缺点在于工厂类不够灵活,增加新的具体产品需要修改工厂类的判断逻辑代码,而且产品较多时,工厂方法代码将会非常复杂。

    ü  简单工厂模式适用情况包括:工厂类负责创建的对象比较少;客户端只知道传入工厂类的参数,对于如何创建对象不关心。

     

    第5章_工厂方法模式

    ü  工厂方法模式(FactoryMethod Pattern)又称为工厂模式,也叫虚拟构造器(Virtual Constructor)模式或者多态工厂(PolymorphicFactory)模式,它属于类创建型模式。在工厂方法模式中,工厂父类负责定义创建产品对象的公共接口,而工厂子类则负责生成具体的产品对象,这样做的目的是将产品类的实例化操作延迟到工厂子类中完成,即通过工厂子类来确定究竟应该实例化哪一个具体产品类。

    ü  抽象工厂类代码:

    public abstract class PayMethodFactory

    {

       public abstract AbstractPay getPayMethod();

    }

    ü  具体工厂类代码:

    public class CashPayFactory extendsPayMethodFactory

    {

       public AbstractPay getPayMethod()

        {

           return new CashPay();

        }

    }

    ü  客户类代码片段:

    PayMethodFactory factory;

    AbstractPay payMethod;

    factory=new CashPayFactory();

    payMethod =factory.getPayMethod();

    payMethod.pay();

    ü  工厂方法模式的主要优点是增加新的产品类时无须修改现有系统,并封装了产品对象的创建细节,系统具有良好的灵活性和可扩展性;其缺点在于增加新产品的同时需要增加新的工厂,导致系统类的个数成对增加,在一定程度上增加了系统的复杂性。符合开闭原则。

    ü  工厂方法模式适用情况包括:一个类不知道它所需要的对象的类;一个类通过其子类来指定创建哪个对象;将创建对象的任务委托给多个工厂子类中的某一个,客户端在使用时可以无须关心是哪一个工厂子类创建产品子类,需要时再动态指定。

     

    第6章_抽象工厂模式

    ü  抽象工厂模式(AbstractFactory Pattern):提供一个创建一系列相关或相互依赖对象的接口,而无须指定它们具体的类。抽象工厂模式又称为Kit模式,属于对象创建型模式。

    ü  具体工厂类的典型代码如下:

    public class ConcreteFactory1 extendsAbstractFactory

    {

       public AbstractProductA createProductA()

        {

           return new ConcreteProductA1();

        }

       public AbstractProductB createProductB()

        {

           return new ConcreteProductB1();

        }

    }

    ü  抽象工厂模式的主要优点是隔离了具体类的生成,使得客户并不需要知道什么被创建,而且每次可以通过具体工厂类创建一个产品族中的多个对象,增加或者替换产品族比较方便,增加新的具体工厂和产品族很方便;主要缺点在于增加新的产品等级结构很复杂,需要修改抽象工厂和所有的具体工厂类,对“开闭原则”的支持呈现倾斜性。

    ü  抽象工厂模式适用情况包括:一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节;系统中有多于一个的产品族,而每次只使用其中某一产品族;属于同一个产品族的产品将在一起使用;系统提供一个产品类的库,所有的产品以同样的接口出现,从而使客户端不依赖于具体实现。

     

    第9章_单例模式

    ü  单例模式(SingletonPattern):单例模式确保某一个类只有一个实例,而且自行实例化并向整个系统提供这个实例,这个类称为单例类,它提供全局访问的方法。

    ü  单例模式的要点有三个:一是某个类只能有一个实例;二是它必须自行创建这个实例;三是它必须自行向整个系统提供这个实例。单例模式是一种对象创建型模式。单例模式又名单件模式或单态模式。

     

    ü  单例模式的实现代码如下所示:

    public class Singleton

    {

             privatestatic Singleton instance=null;  //静态私有成员变量

             //私有构造函数

             privateSingleton()

             {       

             }

            

          //静态公有工厂方法,返回唯一实例

             publicstatic Singleton getInstance()

             {

                       if(instance==null)

                           instance=new Singleton();      

                       returninstance;

             }

    }

    ü  单例模式的主要优点在于提供了对唯一实例的受控访问并可以节约系统资源;其主要缺点在于因为缺少抽象层而难以扩展,且单例类职责过重。

    ü  单例模式适用情况包括:系统只需要一个实例对象;客户调用类的单个实例只允许使用一个公共访问点。

    ü  饿汉式单例与懒汉式单例类比较

    ü 饿汉式单例类在自己被加载时就将自己实例化。单从资源利用效率角度来讲,这个比懒汉式单例类稍差些。从速度和反应时间角度来讲,则比懒汉式单例类稍好些。

    ü 懒汉式单例类在实例化时,必须处理好在多个线程同时首次引用此类时的访问限制问题,特别是当单例类作为资源控制器,在实例化时必然涉及资源初始化,而资源初始化很有可能耗费大量时间,这意味着出现多线程同时首次引用此类的机率变得较大,需要通过同步化机制进行控制。

     

     

    第10章_适配器模式

    ü  适配器模式(AdapterPattern) :将一个接口转换成客户希望的另一个接口,适配器模式使接口不兼容的那些类可以一起工作,其别名为包装器(Wrapper)。适配器模式既可以作为类结构型模式,也可以作为对象结构型模式。

    ü  典型的类适配器代码:

    public class Adapter extendsAdaptee implements Target

    {

             publicvoid request()

             {

                       specificRequest();

             }

    }

    ü  典型的对象适配器代码:

    public class Adapter extends Target

    {

             privateAdaptee adaptee;

            

             publicAdapter(Adaptee adaptee)

             {

                       this.adaptee=adaptee;

             }

            

             publicvoid request()

             {

                       adaptee.specificRequest();

             }

    }

    类适配器

    对象适配器

    ü  适配器模式的主要优点是将目标类和适配者类解耦,增加了类的透明性和复用性,同时系统的灵活性和扩展性都非常好,更换适配器或者增加新的适配器都非常方便,符合“开闭原则”;类适配器模式的缺点是适配器类在很多编程语言中不能同时适配多个适配者类,对象适配器模式的缺点是很难置换适配者类的方法。

    ü  适配器模式适用情况包括:系统需要使用现有的类,而这些类的接口不符合系统的需要;想要建立一个可以重复使用的类,用于与一些彼此之间没有太大关联的一些类一起工作。

     

    第14章_外观模式

    ü  外观模式(FacadePattern):外部与一个子系统的通信必须通过一个统一的外观对象进行,为子系统中的一组接口提供一个一致的界面,外观模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。外观模式又称为门面模式,它是一种对象结构型模式。

    外观模式也是“迪米特法则”

    ü  典型的外观角色代码:

    public class Facade

    {

        private SubSystemA obj1 =new SubSystemA();

        private SubSystemB obj2 =new SubSystemB();

        private SubSystemC obj3 =new SubSystemC();

        public void method()

        {

            obj1.method();

            obj2.method();

            obj3.method();

        }

    }

    w  外观模式主要优点在于对客户屏蔽子系统组件,减少了客户处理的对象数目并使得子系统使用起来更加容易,它实现了子系统与客户之间的松耦合关系,并降低了大型软件系统中的编译依赖性,简化了系统在不同平台之间的移植过程;其缺点在于不能很好地限制客户使用子系统类,而且在不引入抽象外观类的情况下,增加新的子系统可能需要修改外观类或客户端的源代码,违背了“开闭原则”。

    w  外观模式适用情况包括:要为一个复杂子系统提供一个简单接口;客户程序与多个子系统之间存在很大的依赖性;在层次化结构中,需要定义系统中每一层的入口,使得层与层之间不直接产生联系。

     

    第16章_代理模式

    ü  代理模式(ProxyPattern) :给某一个对象提供一个代理,并由代理对象控制对原对象的引用。代理模式的英文叫做Proxy或Surrogate,它是一种对象结构型模式。

     

    ü  典型的代理类实现代码:

    public class Proxy implements Subject

    {

        private RealSubjectrealSubject = new RealSubject();

        public void preRequest()

        {…...}

        public void request()

        {

            preRequest();

            realSubject.request();

            postRequest();

        }

        public void postRequest()

        {……}

    }

    ü  代理模式的优点在于能够协调调用者和被调用者,在一定程度上降低了系统的耦合度;其缺点在于由于在客户端和真实主题之间增加了代理对象,因此有些类型的代理模式可能会造成请求的处理速度变慢,并且实现代理模式需要额外的工作,有些代理模式的实现非常复杂。

    ü  模式适用环境

    ü  根据代理模式的使用目的,代理模式有以下几种类型(续):

    ü 保护(Protect or Access)代理:控制对一个对象的访问,可以给不同的用户提供不同级别的使用权限。

    ü 缓冲(Cache)代理:为某一个目标操作的结果提供临时的存储空间,以便多个客户端可以共享这些结果。

    ü 防火墙(Firewall)代理:保护目标不让恶意用户接近。

    ü 同步化(Synchronization)代理:使几个用户能够同时使用一个对象而没有冲突。

    ü 智能引用(Smart Reference)代理:当一个对象被引用时,提供一些额外的操作,如将此对象被调用的次数记录下来等。

     

    第23章_观察者模式

    ü  观察者模式(ObserverPattern):定义对象间的一种一对多依赖关系,使得每当一个对象状态发生改变时,其相关依赖对象皆得到通知并被自动更新。观察者模式又叫做发布-订阅(Publish/Subscribe)模式、模型-视图(Model/View)模式、源-监听器(Source/Listener)模式或从属者(Dependents)模式。观察者模式是一种对象行为型模式。

     

    ü  典型的抽象目标类代码如下所示:

    import java.util.*;

    public abstract class Subject

    {

        protectedArrayList observers = new ArrayList();

             publicabstract void attach(Observer observer);

             publicabstract void detach(Observer observer);

             publicabstract void notify();

    }

    ü  典型的具体目标类代码如下所示:

    public class ConcreteSubject extendsSubject

    {

             publicvoid attach(Observer observer)

             {

                       observers.add(observer);

             }

            

             publicvoid detach(Observer observer)

             {

                       observers.remove(observer);

             }

            

             publicvoid notify()

             {

                       for(Objectobs:observers)

                       {

                                ((Observer)obs).update();

                       }

             }       

    }

    ü  典型的抽象观察者代码如下所示:

    public interface Observer

    {

             publicvoid update();

    }

    ü  典型的具体观察者代码如下所示:

    public class ConcreteObserver implementsObserver

    {

             publicvoid update()

             {

                       //具体更新代码

             }

    }

    ü  客户端代码片段如下所示:

    Subject subject = new ConcreteSubject();

    Observer observer = new ConcreteObserver();

    subject.attach(observer);

    subject.notify();

    w  观察者模式的主要优点在于可以实现表示层和数据逻辑层的分离,并在观察目标和观察者之间建立一个抽象的耦合,支持广播通信;其主要缺点在于如果一个观察目标对象有很多直接和间接的观察者的话,将所有的观察者都通知到会花费很多时间,而且如果在观察者和观察目标之间有循环依赖的话,观察目标会触发它们之间进行循环调用,可能导致系统崩溃。

    w  观察者模式适用情况包括:一个抽象模型有两个方面,其中一个方面依赖于另一个方面;一个对象的改变将导致其他一个或多个对象也发生改变,而不知道具体有多少对象将发生改变;一个对象必须通知其他对象,而并不知道这些对象是谁;需要在系统中创建一个触发链。

     

     

    ü  组合模式(CompositePattern):组合多个对象形成树形结构以表示“整体-部分”的结构层次。组合模式对单个对象(即叶子对象)和组合对象(即容器对象)的使用具有一致性。

    ü  Composite Pattern: Compose objects into tree structures to representpart-whole hierarchies. Composite lets clients treat individual objects andcompositions of objects uniformly.

    ü  组合模式的主要优点在于可以方便地对层次结构进行控制,客户端调用简单,客户端可以一致的使用组合结构或其中单个对象,用户就不必关心自己处理的是单个对象还是整个组合结构,简化了客户端代码;其缺点在于使设计变得更加抽象,且增加新构件时可能会产生一些问题,而且很难对容器中的构件类型进行限制。

    ü  组合模式适用情况包括:需要表示一个对象整体或部分层次;让客户能够忽略不同对象层次的变化,客户端可以针对抽象构件编程,无须关心对象层次结构的细节;对象的结构是动态的并且复杂程度不一样,但客户需要一致地处理它们。

    ü  命令模式(CommandPattern):将一个请求封装为一个对象,从而使我们可用不同的请求对客户进行参数化;对请求排队或者记录请求日志,以及支持可撤销的操作。命令模式是一种对象行为型模式,其别名为动作(Action)模式或事务(Transaction)模式。

    ü  Command Pattern: Encapsulate a request as an object, thereby lettingyou parameterize clients with different requests, queue or log requests, andsupport undoable operations.

    ü  命令模式的主要优点在于降低系统的耦合度,增加新的命令很方便,而且可以比较容易地设计一个命令队列和宏命令,并方便地实现对请求的撤销和恢复;其主要缺点在于可能会导致某些系统有过多的具体命令类。

    ü  命令模式适用情况包括:需要将请求调用者和请求接收者解耦,使得调用者和接收者不直接交互;需要在不同的时间指定请求、将请求排队和执行请求;需要支持命令的撤销操作和恢复操作;需要将一组操作组合在一起,即支持宏命令。

     

    ü  迭代器模式(IteratorPattern) :提供一种方法来访问聚合对象,而不用暴露这个对象的内部表示,其别名为游标(Cursor)。迭代器模式是一种对象行为型模式。

    ü  Iterator Pattern: Provide a way to access the elements of an aggregateobject sequentially without exposing its underlying representation.

    ü  迭代器模式的主要优点在于它支持以不同的方式遍历一个聚合对象,还简化了聚合类,而且在同一个聚合上可以有多个遍历;其缺点在于增加新的聚合类需要对应增加新的迭代器类,类的个数成对增加,这在一定程度上增加了系统的复杂性。

    ü  迭代器模式适用情况包括:访问一个聚合对象的内容而无须暴露它的内部表示;需要为聚合对象提供多种遍历方式;为遍历不同的聚合结构提供一个统一的接口。

     

    ü  模板方法模式(TemplateMethod Pattern):定义一个操作中算法的骨架,而将一些步骤延迟到子类中,模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。模板方法是一种类行为型模式。

    ü  Template Method Pattern: Define the skeleton of an algorithm in anoperation, deferring some steps to subclasses. Template Method lets subclassesredefine certain steps of an algorithm without changing the algorithm'sstructure.

    ü  模板方法模式的优点在于在子类定义详细的处理算法时不会改变算法的结构,实现了代码的复用,通过对子类的扩展可以增加新的行为,符合“开闭原则”;其缺点在于需要为每个不同的实现都定义一个子类,这会导致类的个数增加,系统更加庞大,设计也更加抽象

    ü  模板方法模式适用情况包括:一次性实现一个算法的不变的部分,并将可变的行为留给子类来实现;各子类中公共的行为应被提取出来并集中到一个公共父类中以避免代码重复;对一些复杂的算法进行分割,将其算法中固定不变的部分设计为模板方法,而一些可以改变的细节由其子类来实现;通过模板方法模式还可以控制子类的扩展。

    ü  桥接模式(BridgePattern):将抽象部分与它的实现部分分离,使它们都可以独立地变化。它是一种对象结构型模式,又称为柄体(Handle and Body)模式或接口(Interface)模式。

    ü  Bridge Pattern: Decouple an abstraction from its implementation sothat the two can vary independently.

    ü  桥接模式的主要优点是分离抽象接口及其实现部分,是比多继承方案更好的解决方法,桥接模式还提高了系统的可扩充性,在两个变化维度中任意扩展一个维度,都不需要修改原有系统,实现细节对客户透明,可以对用户隐藏实现细节;其主要缺点是增加系统的理解与设计难度,且识别出系统中两个独立变化的维度并不是一件容易的事情。

    ü  桥接模式适用情况包括:需要在构件的抽象化角色和具体化角色之间增加更多的灵活性,避免在两个层次之间建立静态的继承联系;抽象化角色和实现化角色可以以继承的方式独立扩展而互不影响;一个类存在两个独立变化的维度,且这两个维度都需要进行扩展;设计要求需要独立管理抽象化角色和具体化角色;不希望使用继承或因为多层次继承导致系统类的个数急剧增加的系统。

     

    展开全文
  • 本书的内容对多方面的读者都是很重要的,包括计算机体系结构系统软件和应用领域工作的研究人员、学生和工程技术人员。
  • 软件工程》第6章体系结构设计

    千次阅读 2020-06-02 09:33:24
    体系结构设计关注理解一个软件系统应当如何组织,以及设计该系统的整体结构。体系结构设计是设计和需求工程之间的关键性衔接环节,因为它会确定组成一个系统的主要结构构件以及它们之间的关系。体系结构设计过程的...

        体系结构设计关注理解一个软件系统应当如何组织,以及设计该系统的整体结构。体系结构设计是设计和需求工程之间的关键性衔接环节,因为它会确定组成一个系统的主要结构构件以及它们之间的关系。体系结构设计过程的输出是一个体系结构模型,该模型描述系统如何被组织为一组相互通信的构件。

        在敏捷过程中,得到广泛认同的一点是,一个敏捷开发过程的早期阶段应该关注设计一个整体的系统体系结构。体系结构的增量开发通常都不会成功。根据变化重构构件通常相对容易。然而,重构体系结构却很昂贵,因为可能需要修改大部分系统构件以使它们能够适应体系结构的变化。

        在实践中,需求工程过程和体系结构设计过程之间存在显著的重叠。理想情况下,系统规格说明不应当包含任何设计信息。然而,这个设想是不现实的;因此,作为需求工程过程的一部分,要提出一个抽象的系统体系结构,其中将一组组的系统功能或特征与大规模的构件或子系统关联起来。

        可以在两个抽象层次上设计软件体系结构,分别称为小体系结构和大体系结构。

        1.小体系结构关注单个程序的体系结构。在这个层次上,我们关注单个的程序是如何被分解为构件的。

        2.大体系结构关注包括其他系统、程序和程序构件的复杂企业系统体系结构。这些企业系统可以分布在不同的计算机上,这些计算机可以由不同的公司拥有和管理。

        软件体系结构很重要,因为它会影响一个系统的性能、健壮性、分布性和可维护性。明确地设计并描述软件体系结构有以下3个好处:

        1.利益相关者交流。体系结构是一种可以作为许多不同利益相关者讨论的焦点的系统的高层表示。

        2.系统分析。在系统开发早期阶段明确系统的体系结构要求进行一些分析。

        3.大范围复用。体系结构模型是关于系统如何组织以及构件如何互操作的一个紧凑、可管理的描述。

        系统体系结构经常使用简单的框图进行非正式的建模。可以使用UML的构造型和构件图进行绘制,其中每一个方框表示一个构件。方框中的方框表示该构件被分解子构件。箭头表示数据和控制信号按照箭头的方向从一个构件传到另一个构件。

        程序的体系结构模型有如下两种不同的使用方式:

        1.作为一种鼓励对系统设计进行讨论的方式。一个系统的高层体系结构视图对于与系统利益相关者进行交流以及项目计划都很有用,利益相关者可以接受这种表示并理解系统的抽象视图。体系结构模型识别出了要开发的关键构件,从而使管理者可以开始分配人员规划这些系统的开发。

        2.作为一种文档化已经设计好的体系结构的方式。目的是产生一个显示系统中不同的构件、它们的接口以及连接关系的完整的系统模型,这样一种详细的体系结构描述使得对系统的理解和演化可以更容易。

        对于很多项目,框图是唯一的体系结构描述。理想情况下,如果要详细描述一个系统的体系结构,最好能使用一种更严格的软件体系结构描述的方法。显然,一个更加详细和完整的描述意味着对体系结构构件之间关系误解的可能性会降低,然而其相应的成本就会大大增加,在实践中无法判断待开发的系统使用严格定义体系结构的方法是否合算。

    §6.1体系结构设计决策

        体系结构设计是一个创造性的过程,在这个过程中你会设计一个满足系统功能性和非功能性需求的系统组织结构。具体的体系结构设计过程取决于所开发的系统的类型、系统架构师的背景和经验,以及系统的特定需求,因此也并不存在公式化、形式化的体系结构设计过程。

        在体系结构设计过程中,系统架构师必须做出一系列深刻影响系统及其开发过程的结构决策:

        1.是否存在一个通用的应用体系结构可以用作所设计的系统的模板?

        2.系统将如何分布到各个硬件核或处理器上?

        3.可以使用什么体系结构模式或风格?

        4.用来组织系统的基本方法是什么?

        5.用什么样的策略来控制系统中的构件的运行?

        6.系统中的结构构件将如何分解为子构件?

        7.什么样的体系结构组织是实现系统的非功能性需求的最佳选择?

        8.系统的体系结构应当如何文档化?

        虽然每个软件系统都是独特的,但是同一个应用领域中的系统经常具有相似的、反映领域的基本概念的体系结构。当设计一个系统体系结构时,你必须确定你的系统和更广阔的应用类型有什么共性,确定来自这些应用体系结构中的知识有多少可以复用。

        对于嵌入式系统以及针对个人电脑和移动设备设计的应用,不需要为系统设计一个分布式体系结构。然而,大多数大型系统是分布式系统,其中系统软件分布在许多不同的计算机上。

        一个软件系统的体系结构可以基于特定的体系结构模式或风格。体系结构模式捕捉了一个在不同的软件系统中使用的体系结构的本质特性。在进行体系结构设计时,应当了解通用的模式、这些模式的适用场合、它们的优势和弱点。

        由于非功能性系统特性和软件体系结构的密切关系,体系结构风格和结构的选择应当根据系统的非功能性需求来确定。

       1.性能。如果性能是一个关键性需求,那么体系结构设计应当将关键性操作局部化到少量的构件中,尽量让这些构件部署在同一台计算机上而不要分布在网络上。

       2.信息安全。如果信息安全是一个关键性需求,那么应该使用一种层次化的体系结构组织,把最关键的资产放在最内层进行保护,并对这些层应用高级的信息安全确认。

       3.安全性。如果安全性是一个关键性需求,那么体系结构设计应该让安全性相关的操作集中在单个构件或少量构件中。

       4.可用性。如果可用性是一个关键性需求,那么体系结构设计应该包含冗余的构件以便在不停止系统的情况下可以更换或更新构件。

       5.可维护性。如果可维护性是一个关键性需求,那么系统体系结构设计应当使用容易改变的细粒度、自包含的构件。

       显然,上面这些体系结构之间存在潜在的冲突,在具体的系统体系结构设计时就必须要进行权衡折中:有时可以通过在系统的不同部分使用不同的体系结构模式或风格来实现权衡。

        评价一个体系结构很难,因为真正的体系结构评判标准是,系统在使用时能够在多大程度上满足它的功能性和非功能性需求。

    §6.2体系结构视图

       此外,体系结构模型也可以用于设计的文档化,这样,体系结构可以作为更加详细的系统设计以及实现的基础。在单个图中表示出与一个系统的体系结构相关的所有信息是不可能的,因为一个图形化模型只能显示一个系统视图或视角。通常来说,需要从多个不同的视图来呈现软件体系结构。

        1.逻辑视图。这个视图将系统中的关键抽象显示为对象或对象类。

        2.进程视图。这个视图显示系统在运行时如何通过相互交互的进程来构成。

        3.开发视图。这个视图显示软件如何面向开发任务进行分解;也就是说,该视图显示了软件如何分解为由单个开发者或开发团队实现的构件。

        4.物理视图。这个视图显示系统硬件以及软件构件如何分布在系统中的处理器上。

        在实践中,一个系统体系结构的概念视图几乎总是在设计过程中开发。这些概念视图用于向利益相关者解释系统体系结构以及告知体系结构设计决策。在设计过程中,其他一些视图也可以在讨论系统的不同方面的时候进行开发,但是一般都不需要从所有的视角出发开发一个完整的描述。

        当使用UML描述一个软件系统的体系结构时,通常都是以一种非正式的方式进行应用的。而另有一些人提出,应使用更加专业化的体系结构描述语言(Architectural Description Language, ADL)来描述系统体系结构。体系结构描述语言的基本元素是构件和连接器,并且包含面向结构良好的体系结构的规则和指南。然而,由于体系结构描述语言是专家语言,领域和应用专家感觉很难理解和使用体系结构描述语言。

        与之对比的是敏捷方法的使用者,他们认为详细的设计文档通常都是没有用的,即开发这种文档是浪费时间。

    §6.3体系结构模式

        将模式作为一种表示、分享、复用软件系统相关知识的思想已经在软件工程中的一系列领域中得到了采用。

        体系结构模式是在20世纪90年代提出的,最初被称为“体系结构风格”。可以将体系结构模式理解为对好的实践的一种风格化、抽象化的描述,这些实践已经在不同的系统和环境中进行了尝试和测试。因此,一个体系结构模式应当描述一种已经在此前的系统中得到成功应用的系统的组织。它应当包含何时适合以及何时不适合使用该模式,还应包含关于该模式的优缺点的详细描述等信息。

    【例】模型—视图—控制器(MVC)模式

    名称MVC(模型—视图—控制器)
    描述将呈现和交互从系统数据中分离出来。系统被组织为3个相互交互的逻辑构件。模型(Model)构件管理系统数据以及相关的对这些数据的操作。视图(View)构件定义并管理数据呈现给用户的方式。控制器(Controller)构件管理用户界面(例如按键、鼠标点击等)并将这些交互传递给视图和模型。
    例子显示了一个使用MVC模式进行组织的基于Web的应用系统的体系结构
    何时使用当存在多种查看数据以及数据交互的方式时使用。也可在未来关于数据的交互和呈现的需求未知时使用
    优点允许数据独立于它的呈现方式进行变更,反之亦然。支持以不同的方式呈现同样的数据,在某一呈现方式中进行的修改可以在所有呈现方式中显示
    缺点

    当数据模型和交互比较简单时,可能包含额外的代码以及代码复杂性

    这是该体系结构模式的“型”

        上表和上图所示是模型—视图—控制器的体系结构模式。该模式是许多基于Web的系统中交互管理的基础,并且得到了大多数语言框架的支持。这种风格化的描述包括一个模式名称、一段简要描述、一个图形化模型,以及一个使用了这种模式的系统的例子。(见下图)其中还应当包含关于该模式应该在何种情况下使用以及模式的优缺点的信息。

    这是该体系结构模式的“值”

        6.3.1分层体系结构

        分离和独立性的思想是体系结构设计的基础,因为这可以使变更被局部化。分层体系结构模式是另一种实现分离和独立性的方式。系统功能被组织为多个分离的层次,每个层次只依赖于紧邻的下一层所提供的设施和服务。

        这一分层的方法支持系统的增量开发。一个层次开发好之后,该层次所提供的一些服务可以提供给用户。该体系结构也是可变化和可前移的。如果接口不变,那么一个功能进行了扩展的新层可以在不影响系统的其他部分的情况下取代一个已有的层。而且,当一个层次的接口发生变化或者增加了新的设施时,只有相邻的层次受到影响。由于分层的系统将机器的依赖局部化了,这使提供一个应用系统的多平台实现变得更容易了。只需将与机器有依赖关系的层重新实现,便可以适应不同的操作系统或数据库的设施。

    分层体系结构
    名称多层体系结构
    描述将系统组织为多个层次,每个层次与一些相关的功能相联系。每个层次向其上的一层提供服务,因此那些最低层次表示很可能在整个系统中使用的核心服务
    例子一个数字化学习系统的分层模型支持学校中所有科目的学习
    何时使用当在已有系统之上构建新的设施时使用;当开发涉及多个团队,每个团队负责一个层次上的功能时使用;当存在多个层次上的信息安全需求时使用
    优点只要接口保持不变,允许对整个层进行替换。可以在每个层次上提供冗余设施以增加系统的可依赖性
    缺点在实践中,将各层之间干净地分离经常很难做到,较高层次上的层可能不得不与较低层次上的层直接交互,而不是通过紧邻着的下一层。性能可能是一个问题,因为当一个服务请求在各个层次上进行处理时需要经过多层的解析

        6.3.2知识库体系结构

        知识库模式,则描述了一组相互交互的构件如何共享数据。大多数使用大量数据的系统都是围绕一个共享数据库或知识库组成的。因此,这个模型适合于数据由一个构件生成同时由另一个构件使用的应用。

    知识库模式
    名称知识库
    描述一个系统中的所有数据在所有系统构件都能访问的中心知识库中进行管理。构件相互之间并不直接交互,仅通过知识库进行交互
    例子下图是一个集成开发环境(IDE)的例子,其中构件使用系统设计信息的知识库。每个软件工具生成的信息都会提供给其他工具使用
    何时使用当系统生成大量需要长时间保存的信息时应当使用这个模式。还可以在数据驱动的系统中使用,这类系统中的知识库中增加新数据时会触发一个动作或工具
    优点构件可以保持独立,它们不需要知道其他构件的存在;一个构件进行的修改可以被传播到所有构件;所有数据都可以一致地进行管理(例如同时进行备份),因为这些数据都位于一个地方
    缺点知识库可能存在单点失效问题,因此知识库中的问题会影响整个系统;通过知识库组织所有的通信可能效率不高;将知识库分布到多台计算机上可能比较困难
    面向集成开发环境(IDE)的知识库体系结构

        围绕一个知识库组织工具是一个共享大量数据的有效方法。不需要显式地从一个构件向另一个构件传输数据。然而,构件必须围绕一个达成共识的知识库数据模型运转。这其中不可避免地要对每个工具的特定需要进行权衡,而且如果一个新构件与数据模型不相符,那么就可能很难甚至无法集成了。在实践中,可能很难将知识库分布到多台不同的机器上。虽然有可能实现一个逻辑上的集中知识库的分布式部署,这其中会涉及维护数据的多份拷贝。保证这些拷贝的一致性以及及时更新给系统增加了更多的额外负担。

        6.3.3客户-服务器体系结构

        知识库模式关注系统的静态结构,没有显示系统的运行时组织。【例】客户-服务器模式,描述了一种常用的分布式系统运行时的组织方式。一个遵循客户-服务器模式的系统被组织为一组服务和相关联的服务器,以及访问并使用服务的客户端。该模型的主要构件包括以下这些:

        1.一组向其他构件提供服务的服务器。服务器的例子包括:提供打印服务的打印服务器,提供文件管理服务的文件服务器,提供编程语言编译服务的编译服务器。服务器是软件构件,多个服务器可能运行在同一台计算机上。

        2.一组调用服务器提供的服务的客户端。通常会有一个客户端程序的多个实例并行运行在多台计算机上。

        3.一个允许客户端访问这些服务的网络。客户-服务器系统通常实现为分布式系统,使用互联网协议连接。

    客户-服务器模式
    名称客户-服务器
    描述在客户-服务器体系结构中,系统被呈现为一组服务,其中每个服务都由一个独立的服务器提供。客户端是这些服务的用户,通过访问服务器来利用这些服务
    例子下图是一个组织成客户-服务器系统的电影和视频/DVD库的例子
    何时使用当一个共享数据库中的数据必须从一系列不同的位置进行访问时使用。因为服务器可以复制,因此也可以在一个系统的负载多变的情况下使用
    优点这种模型的主要优点是服务器可以分布在网络上。通用的功能(例如一个打印服务)可以向所有客户端开放使用,不需要由所有服务实现
    缺点每个服务都存在单点失效问题,因此容易受到拒绝服务攻击或服务器失效的影响;性能可能不可预测,因为这取决于网络以及系统;如果服务器属于不同的组织,那么还可能会出现管理问题

        客户-服务器体系结构通常被认为是分布式系统体系结构,但是运行在不同的服务器上的独立服务的逻辑模型可以被实现在单台计算机上。这里的一个重要优势仍然是分离和独立性。服务和服务器可以在不影响系统的其他部分的情况下被修改。

        客户端可能必须知道可用的服务器以及它们所提供的服务的名称。然而,服务器不需要知道客户端的身份或者有多少客户端正在访问它们的服务。客户端通过使用请求-应答协议的远程过程调用访问一个服务器提供的服务,其中客户端向一个服务器发出请求,并且一直等待直到收到来自服务器的应答。

        下图是一个基于客户-服务器模型的系统的例子,这是一个提供电影和照片库的多用户、基于Web的系统。

    一个电影库的客户—服务器体系结构

        客户-服务器模型最重要的优势在于它是一个分布式体系结构。带有很多分布式处理器的网络化系统可以获得有效的使用。很容易增加一个新的服务器并将其与系统的剩余部分相集成,或者在不影响系统其他部分的情况下透明地升级服务器。

        6.3.4管道和过滤器体系结构

        这是一个通用体系结构的模型,其中功能性的变换处理输入并产生输出。数据从一个构件流动到另一个构件,在流经这个序列时进行变换。每个处理步骤被实现为一个变换。输入数据流经这些变换直到被转换为输出。这些变换可以串行或并行执行。每个变换可以一项项地处理数据,也可以在单个批次中一次性处理。

    管道和过滤器模式
    名称管道和过滤器
    描述系统中的数据处理通过组织,每个处理构件(过滤器)可以分离开来并执行一种数据转换。数据从一个构件流动(就像在管道中一样)到另一个构件进行处理
    例子下图是一个用于处理发货单的管道和过滤器系统的例子
    何时使用在数据处理应用(无论是批处理还是基于事务)中得到了广泛应用,这类应用中输入在多个分离的阶段中进行处理,并最终生成相关的输出
    优点容易理解并且支持变换的复用;这种工作流风格与许多业务过程的结构相匹配;通过增加变换来进行演化是非常直观的;可以被实现为一个顺序系统或一个并发系统
    缺点针对数据转换的格式必须在相互通信的多个变换之间达成一致;每个变换必须解析它的输入,并将输出转换成所约定的形式,增加了系统的负担,同时可能意味着无法复用使用不兼容的数据结构的体系结构构件
    一个管道和过滤器体系结构的例子

        【例】一个管道和过滤器体系结构的例子

        管道和过滤器最适合于用户交互很少的批处理系统和嵌入式系统。交互式系统很难使用管道和过滤器模型实现,因为管道和过滤器模型需要处理数据流。虽然简单的文本输入和输出可以用这种方式建模,但是对于图形化的用户界面、更复杂的输入/输出格式以及基于事件的控制策略,很难将这些实现为一种符合管道和过滤器模型的顺序流。

    §6.4应用体系结构

        应用系统的目的是满足一个企业或者一个组织的需要。所有的企业都有很多共性:它们都需要雇人、开发货单、保存账户等。同属一个行业的企业使用通用的行业特定的应用。因此,与通用的企业功能一样,所有的电话公司都需要系统来连接呼叫和计费、管理他们的网络、向客户发出账单。因此,这些企业使用的应用系统同样有很多共性。

        这些共性促使人们去开发描述特定类型软件系统的结构合组织的软件体系结构。应用体系结构封装了一类系统的主要特性。应用体系结构可以在开发系统时重新实现,应用体系结构复用是隐式的。这一点在广泛使用的企业资源规划(Enterprise Resource Planning, ERP)系统以及可配置的成品应用系统中可以看到。这些系统有一个标准的体系结构以及相关的构件。这些构件可以通过配置和适应性调整来创建一个特定的企业应用。

        一个软件设计者可以通过以下这些不同的方式使用应用体系结构模型:

        1.作为体系结构设计过程的起点。如果你不熟悉你正在开发的应用类型,你可以将你的初始设计建立在一个通用的应用体系结构基础上。

        2.作为一个设计检查表。如果你已经为一个应用系统开发了一个体系结构设计,那么你可以将它与通用的应用体系结构相比较,检查你的设计是否与通用体系结构相一致。

        3.作为组织开发团队工作的一种方式。应用体系结构识别出了系统体系结构中稳定的结构特征,而且这些结构单元很多时候可以并行开发。

        4.作为评价构件复用的一种方式。如果你有一些可复用的构件,可以将它们与通用结构相比较,以确定应用体系结构中是否有与之相当的构件。

        5.作为谈论应用时的一种词汇表。如果你正在讨论一个特定的应用或者试图比较不同的应用,那么你可以使用通用体系结构中所识别的概念来讨论这些应用。

        存在许多类型的应用系统,有时候它们可能看上去很不一样。然而,表面上不一样的应用可能有很多共性,因此可以共享一个抽象应用体系结构。

    【例】

        1.事务处理应用。事务处理应用是以数据库为中心的应用,处理用户的信息请求并且更新数据库中的信息。

        2.语言处理系统。语言处理系统中用户的意图用形式化语言来表达。

        6.4.1事务处理系统

        事务处理系统被设计用于处理用户获取数据库中信息的请求或者更新数据库的请求。从技术上看,一个数据库事务包含一个操作序列并且该序列作为整体处理。一个事物中的所有操作必须在数据库修改被持久化之前完成。这保证了一个事务中失败的操作不会导致数据库中的不一致。

        从用户的角度看,一个事务是任何满足一个目标的内聚的操作序列。如果用户事务不需要对数据库进行修改,那么不一定要将其作为一个技术上的数据库事务。

        事务处理系统通常是交互式系统,其中发出的异步的服务请求。下图描述了事务处理应用的概念体系结构。首先,用户通过一个输入/输出处理构件向系统发出请求。该请求由一些应用特定的逻辑进行处理。一个事务被创建并传递给事务管理器(通常嵌入在数据库管理系统中)。事务管理器在保证事务被正确完成后,再通知应用处理已完成。

    事务处理应用的结构

        可将事务处理系统组织为含有负责输入、处理、输出的系统构件的“管道和过滤器”体系结构。

        6.4.2信息系统

        所有包含与一个共享数据库交互的系统都可以认为是基于事务的信息系统。一个信息系统允许对一个很大的信息库的受控访问。信息系统几乎都是基于Web的系统,其中用户界面在一个Web浏览器中实现。

        下图展示了一个非常通用的信息系统模型。系统使用层次化的方法进行建模,其中最顶层支持用户界面,最底层是系统数据库。用户通信层处理来自用户界面的所有输入和输出,信息检索包括特定应用的数据库访问和更新逻辑。这个模型中的各个层可以直接映射到一个分布式基于互联网的系统中的服务器上。

    分层的信息系统体系结构

        可以通过识别支持用户通信以及信息检索和访问的构件,向这个模型的每一层都增加了一些细节。信息和资源管理系统有时候也是事务处理系统。这些系统中的服务器通常反映了上图所示的4层通用模型。这些系统经常实现为带有多层客户端/服务器体系结构的分布式系统。

        1.Web服务器负责所有的用户通信,并带有使用Web浏览器实现的用户界面。

        2.应用服务器负责实现特定应用逻辑以及信息存储和检索请求。

        3.数据库服务器将信息移动到数据库,从数据库中获取数据,同时处理事务管理

        使用多个服务器可以实现高吞吐量,使每分钟处理完成千上万的事务成为可能。随着请求量的增长,每个层次都可以增加服务器以应对所需要的额外处理能力。

        6.4.3语言处理系统

        语言处理系统将一种语言翻译为该语言的另一种表示方式,对于编程语言还可以执行所产生的代码。编译器将一种编程语言翻译为机器代码。其他语言处理系统可以将XML数据描述为数据库查询命令或者另一种XML表示形式。自然语言处理系统可以将一种自然语言翻译为另一种语言。

        一个面向编程语言的语言处理系统体系结构如下图所示。源语言指令定义了要执行的程序,一个翻译器将这些转换为面向抽象机器的指令。这些指令接着被另一个构件解析,该构件取出执行指令并且使用来自环境的数据执行这些指令。该过程的输出是解析输入数据中的指令的结果。

        对于许多编译器,解析器是处理机器指令的系统硬件,而抽象机器是真实的处理器。然而,对于动态类型语言,解析器是一个软件构件。

        作为更通用的编程环境的一部分的编程语言编译器具有一个通用体系结构,其中包括以下这些构件:

        1.一个词法分析器,读入输入语言标记符号,并将其砖混为一种内部形式。

        2.一个符号表,包含与所翻译的文本中使用的实体(变量、类名、对象名等)名称相关的信息。

        3.一个语法分析器,检查所翻译的语言的语法。它使用该语言所定义的语法,并且构造一个语法树。

        4.语法树,这是所编译的程序的一种内部表示结构。

        5.语义分析器,使用来自语法树的信息以及符号表来检查输入语言文本的语义正确性。

        6.代码生成器,遍历语法树并且生成抽象的机器代码。

        还可以包含其他对语法树进行分析和转换以提高效率并从所生成的机器代码中消除冗余的构件。在其他类型的语言处理系统中,还有一些附加的构件,例如字典。系统的输出是对输入文本的翻译。

        【例】下图描述了一个语言处理系统如何作为一个集成的编程支持工具集的一部分。

        其他体系结构模式也可以用于语言处理系统。编译器的实现可以将知识库模型和管道过滤器模型结合起来使用。在一个编译器体系结构中,符号表是一个共享数据的知识库。词法、语法和语义分析阶段以顺序化的方式进行组织,并且通过共享的符号表进行通信。

        这一语言编译的管道和过滤模型在批处理环境中很有效,其中程序的编译和执行都不需要与用户交互。然而,当一个编辑器与其他语言处理工具相集成时,该模型就没那么有效了。在这种情况下,更好的办法是围绕一个知识库来组织系统。

    展开全文
  • 设计设计软件系统的整体结构、划分功能模块、确定每个模块的实现算法以及编写具体的代码,形成软件的具体设计方案,强调的是软件的具体实现。 面向对象的分析与设计的优势 以人类对世界的认识为原型,将程序的...
  • 软件体系结构基础

    千次阅读 2020-12-27 12:57:33
    体系结构的模式选择设计模式做阐述,风格选择典型的三种体系结构风格做阐述,框架选择MVC、J2EE、PCMEFPCBMER框架做阐述,同时也对特定领域的软件体系结构的类属模型、参考模型,分布式系统结构的多处理机结构、...
  • 软件体系结构》第三章 软件体系结构风格

    万次阅读 多人点赞 2018-07-01 13:56:42
    1. 软件体系结构设计的一个核心问题是能否使用重复的体系结构模式,即能够达到体系结构级的复用。 2. 软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。体系结构风格定义了一个系统家族,即一个...
  • 软件体系结构

    千次阅读 2014-10-30 20:28:50
    软件体系结构笔记 L1.pdf 课程简介源起... 现状系统分析员遇到的困境解决之道 基于软件体系结构的开发 示意图软件体系结构的生命周期 体系结构的非形式化描述 通常使用自然语言描述概念和...
  • MVC设计模式 模型层: 数据对象封装 model.bean/domain 数据库操作类 model.dao 数据库 model.db 视图层: 相关工具类 view.utils 自定义view view.ui 控制层 应用界面相关 controller.activity ...
  • 通过使用软件体系结构,可以有效地分析用户需求,方便系统的修改,以及减小程序构造风险。 随着软件规模不断地增大和复杂程度日益增高,系统框架架构的设计变得越来越关键。软件框架设计的核心问题是能否复用已经...
  • 比如,我们要做一个web学生作业在线管理系统,它的系统结构(软件体系结构软件架构)设计是什么?我们老师要求做这一部分的PPT讲解,我不知道这一块怎么写。求助。不是功能图吧?功能图我已经分析并做好了
  •  研究软件体系结构的首要问题是如何表示软件体系结构,即如何对软件体系结构建模。可以将软件体系结构的模型分为5种:结构模型、框架模型、动态模型、过程模型、功能模型。 一、4+1视图模型 1.定义 “4+1”视图...
  • 有效性(efficiency):有效性是指软件系统能最有效地利用计算机的时间资源和空间资源,一般将系统的时/空开销作为衡量软件质量的一项重要技术指标.牺牲时间效率换取空间有效性或牺牲空间效率换取时间有效
  • 软件体系结构建模

    千次阅读 2019-06-11 12:37:16
    文章目录软件体系结构建模的种类结构模型框架模型功能模型动态模型过程模型体系结构的核心模型“4+1”视图模型逻辑视图表示法开发视图表示法进程视图表示法物理视图表示法场景总结体系结构的生命周期模型 软件体系...
  • 体系结构设计风格

    千次阅读 2016-04-05 17:28:07
    一、常用的软件体系结构风格数据流风格:批处理和管道/过滤器 调用/返回风格:主程序/子程序、层次结构,客户机/服务器,面向对象风格 独立部件风格:进程通讯、事件驱动 虚拟机风格:解释器、基于规则的系统 ...
  • 软件体系结构风格

    千次阅读 2013-05-22 15:04:32
     软件体系结构设计的一个核心问题是能否使用重复的体系结构模式,即能否达到体系结构级的软件重用。也就是说,能否在不同的软件系统中,使用同一体系结构。基于这个目的,学者们开始研究和实践软件体系结构的风格和...
  • 软件体系结构期末复习总结

    千次阅读 多人点赞 2020-08-18 21:14:41
    软件体系结构是具有一定形式的结构化元素,抽象的讲,软件体系结构包括构成系统设计元素的描述,设计元素的交互,设计元素组合的模式,以及在这些模式中的约束。具体的讲,体系结构 = 组件+连接件+约束 组件:...
  • 软件体系结构风格整理

    万次阅读 多人点赞 2019-01-06 15:17:36
    软件体系结构风格(Architectural Styles)是描述特定系统组织方式的惯用范例,强调了软件系统中通用的组织结构。 风格这个词是个模糊的概念,不同的人有不同的理解,这有时候就让人很困惑。这时候为了明确这个概念...
  • 开始复习《软件体系结构》,虽然为了考试要背诵的内容比较多,但是从软件工程到软件测试,我发现这样的课程,总可以增强自己的理解能力,更重要的是对于“软件工程”的认识。天气炎热,能静下心来复习也是一件美好的...
  • 系统体系结构用于描述系统各部分的结构,接口以及用于通信的机制,包括软件系统体系结构模型和硬件系统体系结构模型。而软件体系结构模型对系统的用例,类,对象,接口以及相互之间的交互和协作进行描述;硬件系统...
  • 软件体系结构期末考试总结

    千次阅读 多人点赞 2019-12-30 23:19:35
    对了我们的教材是《软件工程体系结构原理、方法实践(第2版)》张友生 编著的 第一章 1. 软件危机的表现: 软件成本日益增长。开发进度难以控制。软件质量差。软件维护困难 2. 软件危机的原因: 用户需求不明确。...
  • 设计模式与软件体系结构【期末全整理答案】

    万次阅读 多人点赞 2020-07-13 19:01:19
    若本文对你有帮助,请点赞、关注我呦! 期末试题基本出自这些题,请提前复制黏贴到word文档里,方便考试时直接查找。 单选题汇总 ...2、常用的基本设计模式可分为(A)。 A.创建型、结构型和行为型 ...
  • 系统分析与设计方法---需求分析与软件设计

    万次阅读 多人点赞 2018-09-14 20:22:35
    需求分析软件生命周期中相当重要的一个阶段。根据 Standish Group 对 23000 个项目进行的研究结果表明,28%的项目彻底失败,46%的项目超出经费预算或者超出工期,只有约 26%的项目获得成功。需求分析工作在...
  • 章五 软件体系结构集成开发环境的设计与实现一、软件体系结构描述语言1、目前出现了许多针对特定领域的软件体系结构描述语言,有:Aesop、ArTek、C2、Darwin、LILEANNA、MetaH、UniCon、Weaves、Wright等。2、对软件...
  • 题目:任选一个大型的软件分析它的体系结构 我选的软件是爱奇艺。 我搜索到的资料链接: 技术相关 https://blog.csdn.net/zhlei12345/article/details/78795946爱奇艺推荐系统架构实践 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 124,862
精华内容 49,944
关键字:

软件系统分析与体系结构设计