软件架构设计_软件架构设计说明书 - CSDN
精华内容
参与话题
  • 软件架构设计教程(非常全)

    千次下载 热门讨论 2020-07-30 23:30:51
    非常完整的软件架构设计教程。共分10章 269页!!!!!!!!!!!!!!!!!!!!!!!!!
  • 软件架构详解(附图)

    万次阅读 多人点赞 2016-05-24 15:31:21
    软件架构(software architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地...


    软件架构(software architecture)

    软件架构(software architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。在面向对象领域中,组件之间的连接通常用接口_(计算机科学)来实现。

    软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标,作为绘图员画图的基础一样,一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。从和目的、主题、材料和结构的联系上来说,软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来实施和管理软件产品的高级设计。软件架构师定义和设计软件的模块化,模块之间的交互,用户界面风格,对外接口方法,创新的设计特性,以及高层事物的对象操作、逻辑和流程。



    架构是在组件,彼此间和与环境间的关系,引导设计发展原则中体现的系统的基本结构。

    软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标,作为绘图员画图的基础一样,一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。

    软件构架是一个容易理解的概念,多数工程师(尤其是经验不多的工程师)会从直觉上来认识它,但要给出精确的定义很困难。特别是,很难明确地区分设计和构架:构架属于设计的一方面,它集中于某些具体的特征。

    软件架构是指在一定的设计原则基础上,从不同角度对组成系统的各部分进行搭配和安排,形成系统的多个结构而组成架构,它包括该系统的各个组件,组件的外部可见属性及组件之间的相互关系。组件的外部可见属性是指其他组件对该组件所做的假设。

    在“软件构架简介”中,David GArlan和 Mary Shaw认为软件构架是有关如下问题的设计层次:“在计算的算法和数据结构之外,设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构;通信、同步和数据访问的协议;设计元素的功能分配;物理分布;设计元素的组成;定标与性能;备选设计的选择。”

    但构架不仅是结构;IEEEWorking Group on Architecture 把其定义为“系统在其环境中的最高层概念”。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑,而且还在系统的用户环境和开发环境中对系统进行整体考虑,即同时注重对外部的考虑。

    在 Rational Unified ProcESs 中,软件系统的构架(在某一给定点)是指系统重要构件的组织或结构,这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。

    从和目的、主题、材料和结构的联系上来说,软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来实施和管理软件产品的高级设计。软件架构师定义和设计软件的模块化,模块之间的交互,用户界面风格,对外接口方法,创新的设计特性,以及高层事物的对象操作、逻辑和流程。

    一般而言,软件系统的架构(ArchitECture)有两个要素:

    1.它是一个软件系统从整体到部分的最高层次的划分。

    2.一个系统通常是由元件组成的,而这些元件如何形成、相互之间如何发生作用,则是关于这个系统本身结构的重要信息。

    详细地说,就是要包括架构元件(Architecture Component)、联结器(Connector)、任务流(TASk-flow)。所谓架构元素,也就是组成系统的核心"砖瓦",而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果,任务流则描述系统如何使用这些元件和联结器完成某一项需求。

    建造一个系统所作出的最高层次的、以后难以更改的,商业的和技术的决定。

    在建造一个系统之前会有很多的重要决定需要事先作出,而一旦系统开始进行详细设计甚至建造,这些决定就很难更改甚至无法更改。显然,这样的决定必定是有关系统设计成败的最重要决定,必须经过非常慎重的研究和考察。

     


    根据我们关注的角度不同,可以将架构分成三种:

    1.逻辑架构

    软件系统中元件之间的关系,比如用户界面,数据库,外部系统接口,商业逻辑元件,等等。

    从上面这张图中可以看出,此系统被划分成三个逻辑层次,即表象层次,商业层次和数据持久层次。每一个层次都含有多个逻辑元件。比如WEB服务器层次中有HTML服务元件、Session服务元件、安全服务元件、系统管理元件等。

    2.物理架构

    软件元件是怎样放到硬件上的。

    比如下面这张物理架构图,图中所有的元件都是物理设备,包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器、主机等等。

    3.系统架构

    系统的非功能性特征,如可扩展性、可靠性、强壮性、灵活性、性能等。

    系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识,这一工作无疑是架构设计工作中最为困难的工作。

    此外,从每一个角度上看,都可以看到架构的两要素:元件划分和设计决定。

    首先,一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上,以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献,是非常重要的信息。

    其次,进行软件设计需要做出的决定中,必然会包括逻辑结构、物理结构,以及它们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出,就很难更改的。

    根据作者的经验,一个基于数据库的系统架构,有多少个数据表,就会有多少页的架构设计文档。比如一个中等的数据库应用系统通常含有一百个左右的数据表,这样的一个系统设计通常需要有一百页左右的架构设计文档。

     

    我们决定以多种构架视图来表示软件构架。每种构架视图针对于开发流程中的涉众(例如最终用户、设计人员、管理人员、系统工程师、维护人员等)所关注的特定方面。

    构架视图显示了软件构架如何分解为构件,以及构件如何由连接器连接来产生有用的形式 [PW92],由此记录主要的结构设计决策。这些设计决策必须基于需求以及功能、补充和其他方面的约束。而这些决策又会在较低层次上为需求和将来的设计决策施加进一步的约束。

    构架由许多不同的构架视图来表示,这些视图本质上是以图形方式来摘要说明“在构架方面具有重要意义”的模型元素。在 Rational Unified Process 中,您将从一个典型的视图集开始,该视图集称为“4+1 视图模型”[KRU95]。它包括:

    1.用例视图:包括用例和场景,这些用例和场景包括在构架方面具有重要意义的行为、类或技术风险。它是用例模型的子集。

    2.逻辑视图:包括最重要的设计类、从这些设计类到包和子系统的组织形式,以及从这些包和子系统到层的组织形式。它还包括一些用例实现。它是设计模型的子集。

    3.实施视图:包括实施模型及其从模块到包和层的组织形式的概览。 同时还描述了将逻辑视图中的包和类向实施视图中的包和模块分配的情况。它是实施模型的子集。

    4.进程视图:包括所涉及任务(进程和线程)的描述,它们的交互和配置,以及将设计对象和类向任务的分配情况。只有在系统具有很高程度的并行时,才需要该视图。在 Rational Unified Process 中,它是设计模型的子集。

    5.部署视图:包括对最典型的平台配置的各种物理节点的描述以及将任务(来自进程视图)向物理节点分配的情况。只有在分布式系统中才需要该视图。它是部署模型的一个子集。构架视图记录在软件构架文档中。您可以构建其他视图来表达需要特别关注的不同方面:用户界面视图、安全视图、数据视图等等。对于简单系统,可以省略 4+1 视图模型中的一些视图。

     

    早在1960年代,诸如E·W·戴克斯特拉就已经涉及软件架构这个概念了。自1990年代以来,部分由于在 Rational Software Corporation 和Microsoft内部的相关活动,软件架构这个概念开始越来越流行起来。

    卡内基梅隆大学和加州大学埃尔文分校在这个领域作了很多研究。卡内基·梅隆大学的Mary Shaw和David Garlan于1996年写了一本叫做 Software Architecture perspective on an emerging DIscipline的书,提出了软件架构中的很多概念,例如软件组件、连接器、风格等等。加州大学埃尔文分校的软件研究院所做的工作则主要集中于架构风格、架构描述语言以及动态架构。

    计算机软件的历史开始于五十年代,历史非常短暂,而相比之下建筑工程则从石器时代就开始了,人类在几千年的建筑设计实践中积累了大量的经验和教训。建筑设计基本上包含两点,一是建筑风格,二是建筑模式。独特的建筑风格和恰当选择的建筑模式,可以使得一个建筑独一无二。

    软件与人类的关系是架构师必须面对的核心问题,也是自从软件进入历史舞台之后就出现的问题。与此类似地,自从有了建筑以来,建筑与人类的关系就一直是建筑设计师必须面对的核心问题。英国首相丘吉尔说,我们构造建筑物,然后建筑物构造我们(We shape our buildings, and afterwaRDS our buildings shape us)。英国下议院的会议厅较狭窄,无法使所有的下议院议员面向同一个方向入座,而必须分成两侧入座。丘吉尔认为,议员们入座的时候自然会选择与自己政见相同的人同时入座,而这就是英国政党制的起源。Party这个词的原意就是"方"、"面"。政党起源的关键就是建筑物对人的影响。

    在软件设计界曾经有很多人认为功能是最为重要的,形式必须服从功能。与此类似地,在建筑学界,现代主义建筑流派的开创人之一Louis Sullivan也认为形式应当服从于功能(FORMs follows function)。

    几乎所有的软件设计理念都可以在浩如烟海的建筑学历史中找到更为遥远的历史回响。最为著名的,当然就是模式理论和XP理论。

    正如同软件本身有其要达到的目标一样,架构设计要达到的目标是什么呢?一般而言,软件架构设计要达到如下的目标:

    1.可靠性(Reliable)。软件系统对于用户的商业经营和管理来说极为重要,因此软件系统必须非常可靠。

    2.安全性(Secure)。软件系统所承担的交易的商业价值极高,系统的安全性非常重要。

    3.可扩展性(SCAlable)。软件必须能够在用户的使用率、用户的数目增加很快的情况下,保持合理的性能。只有这样,才能适应用户的市场扩展得可能性。

    4.可定制化(CuSTomizable)。同样的一套软件,可以根据客户群的不同和市场需求的变化进行调整。

    5.可扩展性(Extensible)。在新技术出现的时候,一个软件系统应当允许导入新技术,从而对现有系统进行功能和性能的扩展。

    6.可维护性(MAIntainable)。软件系统的维护包括两方面,一是排除现有的错误,二是将新的软件需求反映到现有系统中去。一个易于维护系统可以有效地降低技术支持的花费。

    7.客户体验(Customer Experience)。软件系统必须易于使用。

    8.市场时机(Time to Market)。软件用户要面临同业竞争,软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。

     



    虽然以上视图可以表示系统的整体设计,但构架只同以下几个具体方面相关:

    模型的结构,即组织模式,例如分层。基本元素,即关键用例、主类、常用机制等,它们与模型中的各元素相对。几个关键场景,它们表示了整个系统的主要控制流程。记录模块度、可选特征、产品线状况的服务。

    构架视图在本质上是整体设计的抽象或简化,它们通过舍弃具体细节来突出重要的特征。在考虑以下方面时,这些特征非常重要。

    系统演进,即进入下一个开发周期。在产品线环境下复用构架或构架的一部分。评估补充质量,例如性能、可用性、可移植性和安全性。向团队或分包商分配开发工作。决定是否包括市售构件。插入范围更广的系统。

     


    构架模式是解决复杂构架问题的现成形式。构架框架或构架基础设施(中间件)是可以在其上构建某种构架的构件集。许多主要的构架困难应在框架或基础设施中进行解决,而且通常针对于特定的领域:命令和控制、MIS、控制系统等等。

    构架模式示例

    [BUS96] 根据构架模式最适用的系统的特征将其分类,其中一个类别处理更普遍的结构问题。下表显示了 [BUS96] 中所提供的类别和这些类别所包含的模式。

    类别 模式结构 层管道和过滤器黑板分布式系统代理交互系统 模型-视图-控制器表示-抽象-控制自适应系统反射微核

    在“软件构架简介”中,David Garlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次:“在计算的算法和数据结构之外,设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构;通信、同步和数据访问的协议;设计元素的功能分配;物理分布;设计元素的组成;定标与性能;备选设计的选择。”[GS93]

    但构架不仅是结构;IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”[IEEE98]。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑,而且还在系统的用户环境和开发环境中对系统进行整体考虑,即同时注重对外部的考虑。

    在Rational Unified Process 中,软件系统的构架(在某一给定点)是指系统重要构件的组织或结构,这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。

    为阐明其含义,下面将详述其中的两个;完整说明请参见 [BUS96]。模式以下列广泛使用的形式来表示:

    模式名环境问题影响,描述应考虑的不同问题方面解决方案基本原理结果环境示例模式名层

    环境需要进行结构分解的大系统。

    问题必须处理不同抽象层次的问题的系统。例如:硬件控制问题、常见服务问题和针对于不同领域的问题。最好不要编写垂直构件来处理所有抽象层次的问题。否则要在不同的构件中多次处理相同的问题(可能会不一致)。

    影响

    系统的某些部分应当是可替换的构件中的变化不应波动相似的责任应归为一组构件大小 -- 复杂构件可能要进行分解解决办法将系统分成构件组,并使构件组形成层叠结构。使上层只使用下层(决不使用上层)提供的服务。尽量不使用非紧邻下层提供的服务(不跳层使用服务,除非中间层只添加通过构件)。

    示例:

    1. 通用层

    严格的分层构架规定设计元素(类、构件、包、子系统)只能使用下层提供的服务, 服务可以包括事件处理、错误处理、数据库访问等等。 相对于记录在底层的原始操作系统级调用,它包括更明显的机制。

    2. 业务系统层

    上图显示了另一个分层示例,其中有垂直特定应用层、水平层和基础设施层。注意:此处的目标是采用非常短的业务“烟囱”并实现各种应用程序间的通用性。 否则,就可能有多个人解决同一问题,从而导致潜在的分歧。

    有关该模式的深入讨论,请参见指南:分层。

    模式名黑板

    环境没有解决问题的确定方法(算法)或方法不可行的领域。例如 AI 系统、语音识别和监视系统。

    问题多个问题解决顾问(知识顾问)必须通过协作来解决他们无法单独解决的问题。各顾问的工作结果必须可以供所有其他顾问访问,使他们可以评估自己是否可以参与解决方案的查找并发布其工作结果。

    影响

    知识顾问参与解决问题的顺序不是确定的,这可能取决于问题解决策略

    不同顾问的输入(结果或部分解决方案)可能有不同的表示方式

    各顾问并不直接知道对方的存在,但可以评估对方发布的工作

    解决办法多名知识顾问都可访问一个称为“黑板”的共享数据库。黑板提供监测和更新其内容的接口。控制模块/对象激活遵循某种策略的顾问。激活后,顾问查看黑板,以确定它是否能参与解决问题。如果顾问决定它可以参与,控制对象就可以允许顾问将其部分(或最终)解决方案放置于黑板上。

    示例:

    以上显示了使用 UML 建模的结构或静态视图。 它将成为参数化协作的一部分,然后会绑定到实参上对模式进行实例化。

    构架风格软件构架(或仅是构架视图)可以具有名为构架风格的属性,该属性减少了可选的形式,并使构架具有一定程度的一致性。样式可以通过一组模式或通过选择特定构件或连接器作为基本构件来定义。对给定系统,某些样式可作为构架描述的一部分记录在构架风格指南(Rational Unified Process 中设计指南文档的一部分)中。样式在构架的可理解性与完整性方面起着主要的作用。

    逻辑视图:类图、状态机和对象图。进程视图:类图与对象图(包括任务 - 进程与线程)。实施视图:构件图。部署视图:配置图。

     

    架构描述语言(ADL)用于描述软件的体系架构。已有多种架构描述语言,如Wright (由卡内基梅隆大学开发),Acme (由卡内基梅隆大学开发),C2 (由UCI开发), Darwin (由伦敦帝国学院开发)。ADL的基本构成包括组件、连接器和配置。

     


    构架

    构架视图的图形描述称为构架设计图。对于以上描述的各种视图,设计图由以下统一建模语言图组成 [UML99]:

    1.逻辑视图:类图、状态机和对象图。

    2.进程视图:类图与对象图(包括任务 - 进程与线程)。

    3.实施视图:构件图。

    4.部署视图:配置图。

    5.用例视图:用例图描述用例、主角和普通设计类;顺序图描述设计对象及其协作关系。

    构架设计流程

    在 Rational Unified Process 中,构架主要是分析设计工作流程的结果。当项目再次进行此工作流程时,构架将在一次又一次迭代中不断演化、改进、精炼。由于每次迭代都包括集成和测试,所以在交付产品时,构架就相当强壮了。构架是精化阶段各次迭代的重点,构架的基线通常会在此阶段结束时确定。

    架构师

    软件设计师中有一些技术水平较高、经验较为丰富的人,他们需要承担软件系统的架构设计,也就是需要设计系统的元件如何划分、元件之间如何发生相互作用,以及系统中逻辑的、物理的、系统的重要决定的作出。

    这样的人就是所谓的架构师(Architect)。在很多公司中,架构师不是一个专门的和正式的职务。通常在一个开发小组中,最有经验的程序员会负责一些架构方面的工作。在一个部门中,最有经验的项目经理会负责一些架构方面的工作。

    但是,越来越多的公司体会到架构工作的重要性,并且在不同的组织层次上设置专门的架构师位置,由他们负责不同层次上的逻辑架构、物理架构、系统架构的设计、配置、维护等工作。

     


    软件架构是对软件系统运行时元素的抽象,软件系统可能有很多层抽象,或由多重业务流程所组成,每层抽象或每个业务流程都有自己的软件架构。

    软件架构是平衡的艺术。

    参考:

    http://www.uml.org.cn/zjjs/zjjs-bk.asp

    展开全文
  • 绪论本文打算探讨一下软件架构设计的一些设计原则与经过实践验证的设计模式。 前端(MVC模式)和后端(接口层-业务层-助手层)的分层设计经过了几十年大量软件的证明。分层的思想,就是每一个层次专注做一件事情。每...

    #绪论 #

    本文打算探讨一下软件架构设计的一些设计原则与经过实践验证的设计模式。这些软件架构设计的原则和模式已经有几十年的历史了。

    #分层架构设计#

    软件,应该根据其职能分成多个层次。分层架构设计思想,有很多成功的例子。如网络设计上,OSI七层网络模型,就把网络应用软件,按照功能分成了职能各异的七个层次。实际网络中使用的TCP/IP协议,也遵循OSI七层网络模型,只是把OSI的应用层,表示层和会话层全部糅合在应用层内而已。

    可以说,按照功能进行分层,是一个经过实践检验、行之有效的软件设计方案。

    ##前端和后台##

    从大的范围来分,软件可以分为两个层次:前端和后台。这两个概念大家应该都很熟悉。很多程序员招聘广告,都区分前端工程师和后台工程师。

    前端

    前端,也常称为UI。是用户界面应用程序。用户界面应用程序,是直接和用户进行交互的软件。常见的前端应用有:命令行程序,Web应用,桌面应用(包括移动设备应用)。除了命令行程序外,都是图形化界面。本文只介绍图形化界面的前端程序。

    前端程序,负责与用户进行交互。负责接收和校验用户输入,并向用户反馈输出。其业务操作是委托给后台来实现的。

    前端程序,必用的设计模式,是20世纪80年代发现的MVC模式。所有成功的前端应用,都使用了MVC模式或者它的一些变体。

    MVC模式,MVC全名是Model View Controller,是模型(model)-视图(view)-控制器(controller)的缩写。它是Gof设计模式一书中介绍的第一种设计模式,是设计模式之母。

    MVC模式,就是用控制器来管理用户输入、输出和图形界面。数据来自模型部分。模型Model实际上集中管理了业务数据。这使对同一种业务数据展现多种图形界面成为了可能。MVC模式,分离了显示逻辑和业务逻辑。

    应用MVC模式的前端应用中,模型Model是通向后台系统的通道。

    ##后台##

    前端应用负责提供与用户交互的软件。后台则向前端提供业务服务。所有业务相关的操作和服务应该由后台来实现。

    前端和后台,可以是在同一个进程中的,也可以是分属不同进程的。

    一般,较简单或者小型的单机系统,前端和后台都在同一个进程中。也就是都属于图形应用程序(或者命令行应用程序)。这种应用程序,前端部分代码,通过API调用直接调用后台提供的业务服务。如Office软件就是单机系统。

    复杂或者分布式系统,前端和后台属于不同的进程,前端通过进程间调用机制来调用后台提供的业务服务接口。目前常用的进程间调用机制有:WebService、REST、基于TCP自己实现的通讯协议,编程语言自己定义的通讯协议,操作系统自己定义的通讯协议等。如,现在很多企业级应用软件,Web应用,互联网应用等。

    后台系统本身,也需要分为多个层次,包括:接口层,业务层,助手层。分别对应于大家应该都很熟悉的JavaEE中的表现层,业务层,持久化层。

    ###接口层###

    接口层,在JavaEE中称为表现层。就是后台系统对外的接口层,用于实现跨进程调用。接口层的代码,和你使用的进程间调用机制有关。如,你使用WebService,那么接口层就是用来处理WebService请求的代码;你使用Rest,那么接口层就是处理Http请求和返回Http响应的相关代码;你使用的是RMI这样的语言定义的通讯协议,接口层就是用RMI协议接收和发送数据的相关代码。

    接口层,应用了Gof设计模式中的Façade门面模式。它向前端(客户端)提供了一个简洁一致的接口,隐藏了系统的复杂性。只要保证接口不变,那么后台的业务层和助手层代码再怎样变化,对前端(客户端)程序都是透明的。

    JavaEE中称之为表现层,意为和Web图形界面有关。这是因为当时JavaEE提出这种分层时,Struts等JavaWeb前端框架正大行其道。Struts等会把html页面返回给浏览器,具备呈现图形界面的功能。

    但目前,前端和后台完全分离的应用很多,并已经成为一种趋势。如,前端是桌面应用或者移动应用,显然只需要和后台交换业务数据,不需要后台返回图形界面。Web开发中,目前也流行Html页面上嵌入JavaScript代码通过AJAX向后台交换业务数据,而不是要求后台返回html页面。接口层不再需要返回html页面,只需要返回数据。

    因此这里我命名为接口层而不是表现层,更为贴切。

    另外,对于前端和后台在一个进程中的软件,无需定义接口层。前端部分直接通过API调用后台部分的业务代码即可。

    ###业务层###

    业务层,负责定义领域对象,完成业务逻辑的处理。它向前台提供后台需要的所有服务。

    每一个应用程序,都有其需要解决的问题。针对其问题域,需要划定问题范围,进行数学建模,识别领域对象,并定义各个领域对象之间的关系。

    数学建模和识别领域对象的方法有多种。下面分享一下我一直使用的一种方法:

    1,请需求方描述清楚问题是什么,想要得到什么结果。

    2,描述自己的解决方案,能够做到什么,寻求需求方的确认。

    3,对解决方案文字化。找出其中所有名词和动词。名词就是领域对象的候选对象。动词是领域对象的方法的候选对象。寻找名词之间的制约关系。

    4,确定领域对象的关系。我使用关系数据库的设计方法,确定对象之间是一对一关系,多对一关系还是多对多关系。

    关系数据库实际上和面向对象系统是完全等价的。这可以从很多O-R mapping框架上看出来。

    我对关系数据库设计非常熟悉,因此我总是使用这种方法识别和定义领域对象。即使在一些应用场景中,领域对象根本不需要持久化,我还是用这种方式来考察领域对象。

    5,根据识别出的领域对象,及其相互之间的关系,需要实现的方法,用面向对象的思维编码。用面向对象的思维编码,不意味着必须使用类。用C这样的过程式编程语言也可以用面向对象的思维编码。只是你心中要放着对象这个概念即可。如,我用Python编码时,很少使用类,经常是直接使用函数。但心中还是存着“对象”的理念的,这样写出的代码才不会乱。

    ###助手层###

    业务层代码,会需要使用一些第三方软件提供的服务或者其他更低层级的自己开发的软件服务,才能实现其业务逻辑。这些不属于接口层,也不属于业务层的代码,我们称其属于助手层。助手层代码是为了协助业务层代码实现功能而存在的。

    助手层,在JavaEE中称为持久化层。因为JavaEE是一个企业级软件架构设计方案。其针对的是企业的信息系统。其业务逻辑一般就是操作数据库。

    数据库的读写访问,是与具体业务逻辑无关的,是帮助实现业务逻辑的。因此JavaEE称为持久化层。但这个定义也不全面。因为还是存在很多系统,其除了访问数据库外,还需要其他服务才能实现业务逻辑。如,一个视频网站,它可能需要对上传的视频文件进行格式转换,进行文件切分等;OpenStack,除了访问数据库,还需要访问各个Hypervisor的管理软件来管理虚拟机,需要访问网络部分代码,管理虚拟网络,需要访问存储部分代码,访问块设备和文件等。

    因此,我认为称之为助手层比持久化层更具普适性。

    假设我们的应用是一个类似美团这样的优惠券应用,需要操作地图的功能。对优惠券应用来说,自己的领域对象包括商户、优惠券、用户等。操作地图的功能,不属于领域对象,也就不属于业务层的范围。它是为服务层服务的。因此操作地图的功能,在优惠券应用中就属于助手层。助手层使用的地图API,实际上可能是调用百度地图服务。

    对于百度地图服务来说,它相当于一个后端系统,其也由接口层、服务层和助手层构成。地图的位置信息、兴趣点等是它的服务。

    因此,服务层和助手层的区别,实际上是逻辑概念上的区别。一个系统的服务层,对于其他系统可能就是助手层。

    比如,一个企业信息化应用,需要处理一些时间、字符串、集合等相关的函数。这些函数在这个应用中就属于助手层。因为时间,字符串,集合都属于我的系统的领域对象,它们是为业务服务的。是更低一个层级的。

    总之,后台部分中,不属于接口层和业务层的所有代码,都属于助手层。

    ###业务层和助手层的区别###

    我们以openstack为例具体说明业务层和助手层的区别。

    openstack的业务层,包括其定义的server,也就是虚拟机。

    而虚拟机的业务逻辑代码,需要调用hypervisor 管理工具。如果使用KVM这个hypervisor,就需要使用libvirt的客户端库。libvirt客户端在openstack中就是助手层代码。

    而libvirt客户端库又会通过网络调用libvirt后台。在libvirt后台系统中,也包括了接口层,业务层,助手层这样的层次。

    libvirt内部定义了虚拟机这样的领域对象,对其的操作,需要使用qemu命令行程序。qemu命令行程序在libvirt中就属于助手层。

    这就像是剥洋葱,剥开一层里面还有一层。你在剥哪层,哪层就是业务层,其内部的层次就属于助手层。

    让我们上升到哲学的高度。这种分层的研究方法,就是形而上学的方法,是用孤立、静止、片面的观点观察和研究世界的思维方式。一次聚焦和处理软件系统的一个层面的逻辑。不采用这种方法,眉毛胡子一把抓是做不好软件的。

    #小结#

    分层的软件设计思想已经存在很多个年头了,在计算机科学的各个领域都证明了它的成功。前端(MVC模式)和后端(接口层-业务层-助手层)的分层设计也经过了几十年大量软件的证明。

    分层的思想,就是每一个层次专注做一件事情。每一个层次都为上层提供服务。每一个层次对于其上层来说,都是可以复用的。

    如,助手层的代码,时间、字符串等函数,换一个应用也可以用上。后端部分,可以为多个前端应用提供服务。前端一开始可能是桌面应用,后面变成Web应用,之后可能再开发移动应用,后端都不需要改变。一个框架的服务层代码,在另一个应用中,可以成为助手层代码。一个应用的整个后台,也可能成为另一个应用的助手层。

    分层设计的软件,结构清晰,代码各司其职,能够最大限度地重用代码。

    PS:后面打算再找时间谈一下海量规模的软件架构的设计原则和模式。

    致有志于终身学习的通才

    展开全文
  • 软件架构设计的一些总结和理解

    万次阅读 多人点赞 2019-05-06 18:16:01
    1. 软件架构设计的What & Why ● 啥是软件架构(Software Architecture)? 软件架构是指在一定的设计原则基础上,从不同角度对组成系统的各部分进行搭配和安排,形成系统的多个结构而组成架构,它包括该系统...

    1. 软件架构设计的What & Why

    ● 啥是软件架构(Software Architecture)?

    软件架构是指在一定的设计原则基础上,从不同角度对组成系统的各部分进行搭配和安排,形成系统的多个结构而组成架构,它包括该系统的各个组件,组件的外部可见属性及组件之间的相互关系。组件的外部可见属性是指其他组件对该组件所做的假设。

    软件架构设计就是从宏观上说明一套软件系统的组成与特性。

    软件架构设计是一系列有层次的决策 ,比如:功能与展现的决策;技术架构的决策;自主研发还是合作;商业软件还是开源软件 。

     

     

    为啥要进行软件架构设计?

    业务需求层出不穷;软件系统越来越复杂;参与的人越来越多;共性和特殊性的问题越来越多;技术发展日异月新;……

     

    2. 软件架构师

     

    2.1. 软件架构师是干什么的

     

    介于需求与开发的中间人     良好的沟通能力
    能够统领全局的大牛 良好的大局观
    能够将需求转换为技术     洞悉前沿与市场嗅觉
    能够为软件研发提供指导     见多识广的大牛
    需要全面思考软件系统方方面面的问题     缜密地思考问题
    能够攻关和搞定重要技术难题     公司可信赖的支柱

     

    2.2. 架构师的素质

     

    全局思维  

    从业务、市场,到技术实现;

    从软件的过去、现在,到将来;

    从外部客户,到内部研发;

    从软件研发,到硬件部署;

    从功能实现,到运行效率  

    战略思维  

    在所在行业的发展战略;

    在业务领域的发展战略;

    在技术方向的发展战略;

    在潜在市场的发展战略。

    前瞻思维  

    市场趋势的发展动向;

    前沿技术的发展动向;

    竞争对手的发展动向;

    合作伙伴的发展动向。

    抽象思维  

    各项业务需求:抽象成功能模块;

    各项功能的实现:抽象成软件架构。 

    逆向思维

    假如不实现会怎样?

    假如没搞定会怎样?

    假如没有它会怎样?

    假如被延期会怎样?

     

    2.3.  架构师的分类

    随着行业和社会的发展,架构师的定义和分类越来越广泛和细分,广泛和细分其实并不矛盾,如果“广泛”是x轴,“细分”是y轴,则二维坐标系x和y轴中间的任一点就是一种架构师类别。但总体来说,或目前来说,集合业界的大致认知,总结如下:

     

    No. 分类 描述
    1 解决方案架构师 与客户探讨业务需求,将业务、市场,与技术、产品结合起来,为客户提供解决他们需求的方案。
    2 系统架构师 也称应用架构师。最终确认和评估系统需求,并将业务转换为技术,为研发人员制订核心框架与技术规范 为研发工作澄清技术细节并扫清技术障碍 。
    3 平台架构师 这里的平台其实包括两个平台,一个是系统平台,也就是负责搭建多个系统整合的系统应用平台;另外一个其实是基础平台,是专门负责搭建基础技术平台;两者其 实区别蛮大,也经常容易被从业人员混乱。举个简单例子,金蝶有平台架构师一职,但是金蝶BOSS应用和金蝶中间件两者招聘的对象和技术要求是截然不同的。
    4 业务架构师 业务架构其实已经开始脱离技术层面了,但是它要求架构师有跨越多系统的大局观,去整合和组织不同系统的技术平台与交互模式。其实这个职位的未来也就是CIO了。
    5 网络架构师 过去,我们可能听的最多的是网络工程师。不错,一个优秀的网络架构师必须有足够的网络技术基底,并且它的关注点也是系统的基础架构。比如说如果搭建并优化集群环境,如果构建基于云计算的系统应用与部署等等。它对于像淘宝、腾讯这样的互联网公司是极其重要的。
    6 移动架构师 移动互联网的迅猛发展横向和纵向都细分出了很多新的职责和岗位,移动架构师的职责和作用日益重要,既要整体和全局考虑整个前后端的软件系统架构,又要重点深入移动客户端的架构设计的方方面面,既要有跨平台思维,又要拿捏好原生和混合开发的尺度,另外移动应用的特点,导致移动架构师必须要比传统系统架构师更加注重非功能性的质量属性。
    7 前端架构师

    这也是互联网的迅猛发展而细分出来的新的职责和岗位,这里的前端特指Web开发中的前端,主要考虑前端呈现层的设计(HTML/CSS/JS/AJAX/RIA/…),跨浏览器设计,性能优化等等。

    注:这些年,在很多互联网一线大厂,Web前端和移动客户端有融合为大前端的趋势和内在需求,所以,大前端架构师的知识领域和职责范围也有不同的涵盖和侧重。

    8 ... ...

     

    3.  软件需求

    软件架构设计中常说需求驱动架构设计,可见需求在整个架构设计中起到了关键指引和方向的作用,如果以目标导向为原则,则需求的满足和实现就是架构设计的终极目标。
    OK,在进行架构设计之前,我们先看下软件需求。

    3.1.  软件需求怎么来的(软件需求的过程)

     

    阶段

    需求阶段

    说明

    什么人做什么事

    可能产生的文档

    客户方

    实施方

    客户方

    实施方

    1

    业务需求

    高纬度抽象的需求,也是来自客户的原始需求,背景描述,业务诉求和期望目标。

    项目负责人或接口人描述需求或提供客户方需求文档。

    销售或售前接触客户,听取和记录需求。

    工作说明书(SOW),或邀标书

    售前的方案建议书

    2

    用户需求

    通常是在问题定义的基础上进行用户访谈、调查,对用户使用的场景进行整理,从而建立从用户角度的需求。

    项目负责人或接口人接受访谈和调研。

    需求分析师或项目经理等进行需求调研。

     

    调研计划、用户需求调研提问库、调研日志、用户需求说明书

    3

    软件需求

    从系统实现的角度描述的需求。开发人员(设计和分析人员)在业务需求、用户需求的基础上形成的。

     

    需求分析师或项目经理、架构师等讨论和细化需求,编写需求文档

     

    SRS(Software Requirement Specification)软件需求规格说明书

     

    3.2.  软件需求的分类:

     

    另外,也有McCall软件质量模型:

    注:在架构设计中,对非功能性需求的重视程度,也会影响架构设计的好与劣;但也要平衡过渡设计和适可而止的关系。

     

    4.  软件架构的过程

    业界软件架构设计的方法论很多,各有各自的应用场景和特点,下文结合ADMEMS(Architecture Design Method has been Extended to Method System)架构设计方法论说明软件架构的过程:

     

    架构阶段

    目标

    方式方法

    现实工作场景

    预架构阶段

    全面理解需求;需求结构化,摒弃“需求列表”,建立二维需求观(ADMEMS矩阵)。

    使用ADMEMS矩阵方法,捋清需求间关系和发现衍生需求。

    1、与人:与项目经理、需求分析师等内部需求人员了解需求;与客户了解需求(不建议架构师做需求分析师角色)。
    2、与物:了解《需求规格说明书》等需求文档。"
    3、对需求有什么问题,反馈给售前或销售,可能会参与拜访客户或电话会议。
    4、销售或售前有时会要求提供一个大致的工作量,以便他们初步评估项目可行性。

    概念架构

    高层组件及其关系

    1、初步设计,基于关键功能,借助鲁棒图进行以发现职责为目的的初步设计(不是必须)。
    2、高层分割,将复杂系统切分为多个二级系统或多个子系统。
    3、考虑非功能需求,采用ADMEMS推荐的目标-场景-决策表。

    1、参与内部讨论:项目可行性分析、讨论,从需求、技术、人力、风险等角度提供建议。
    2、项目投标准备:参与投标团队的技术方案编写,编写系统架构章节,解决招标书上技术问题的问答。
    3、参与项目讲标:作为讲标团队成员参与项目讲标,负责技术问答环节的应对。

    细化架构

     

    5视图法

    在项目概要设计阶段,进行架构设计,制定规范和约定,为详细设计提供指导。

    实现

    详细设计
    编码实现

    架构设计形成详细设计文档

    在项目实现阶段,对开发人员提供规范指引和技术支持。

     

    注:架构设计的过程和内容的不是固定不变的,现实中,比如售前提供解决方案中,很多时候需要架构师提供细化架构中才会深思的逻辑架构、物理架构等,这时候,架构师就需要有螺旋思维和跳跃思维的方式,就像武功中,招式是死的,人是活的,要学会灵活运用。

     

     

    5.  软件架构设计的方式方法

     

    5.1.  多视图法


    多视图方法是业界广泛认同的一种架构设计思路,包括:
    ● SEI的3视图法:
    模块视图、组件-连接器视图、分配视图。
    ● 西门子的4视图法:
    概念视图、模块视图、代码视图、执行视图。
    ● RUP的4+1视图法:
    用例视图、逻辑视图、开发视图、进程视图、物理视图。
    ● 联邦企业架构框架:
    技术架构视图、信息架构视图、应用架构视图、业务架构视图。
    ● ……

    5.2.  5视图法

    5视图法分析的意义:

    ● 全面分析软件系统方方面面的问题
    ● 尽早地发现和排除项目风险与不确定因素
    ● 从不同角度去展现要设计的软件系统
    ● 为项目进行中不同的干系人提供指导:
        -- 逻辑架构描述系统功能,并指导系统测试
        -- 开发架构规范软件的层次及代码风格
        -- 数据架构指导数据库的设计
        -- 运行架构定义了一些关键过程的设计
        -- 物理架构明确软件如何部署与实施

    5.3.  5视图法设计步骤

    两种观念:

     

    观念

    设计步骤

    观念一

    顺序进行:

    1、逻辑架构。

    2、开发架构

    3、数据架构

    4、运行架构

    5、物理架构

    观念二

    5个视图是穿插进行设计的,对复杂系统而言,根本不可能将逻辑视图设计完了后再考虑其它视图。

    笔者观念

    观念一和观念二的情况在现实状况中都可能存在,要根据具体情况具体分析,但总体而言,5视图穿插进行思考更有利于思考的全局性和完整性。

     

    5.4.  如何进行5视图法的设计

     

    以下5视图表格中的工具和方法每个架构师或略有差异,以下仅为参考。

    5.4.1.  逻辑架构

    逻辑架构的重点是考虑软件功能性需求。

     

    No.

    考虑的方面

    产出物

    工具

    说明

    1

    系统功能划分为几个子系统与功能模块?

    系统功能树

    树型结构图

     

    2

    向什么用户提供什么样的功能?

    用例模型

    UML用例图

    体现用户和行为

    3

    每个功能都是怎样的操作流程与分支?

    用例描述

    用例描述表

     

    含输入输出、事件流分析;

    不要有界面描述

    UML活动图

    进行业务流程分析,包括泳道图

    4

    如何通过界面与用户交互?怎样交互?

    鲁棒分析

    鲁棒图

    通过对“用例描述表”进行原文分析法拣出名词和动词

    5

    应当设计哪些类与界面?怎样设计?

    领域模型

    UML类图

     

    6

    与哪些外部系统接口?怎样接口?

    接口描述

    UML类图

     

     

    5.4.2.  开发架构

     

    开发架构重点关注的是开发编码实现方面的问题。

     

    No.

    考虑的方面

    产出物

    工具

    说明

    1

    分层结构设计

    分层架构图(开发架构图)

    各种绘图工具

    好的分层结构支持自动化测试

    2

    开发技术选项

    开发语言

    开发框架

    开发工具

     

    考虑商用产品、开源框架、自研框架

    3

    模块划分

    源码工程;Project目录结构;

    分包(分库)

     

     

    4

    开发规范

    开发/编码规范文档;

     

     

    5

    软件质量属性

    分析和决策结果

     

    考虑运行期和开发期软件质量属性,并权衡利弊进行决策。

     

    5.4.3.  数据架构

     

    数据架构不仅仅要考虑开发中涉及到的数据库,实体模型,也要考虑物理架构中数据存储的设计。

    No.

    考虑的方面

    产出物

    工具

    说明

    1

    数据是集中还是分布存储的?如何考虑分布式存储?

    数据架构图

     

     

    2

    领域模型到数据库表的转换?表结构关系的设计?

    逻辑模型

    物理模型

    ER图

    Power Designer

    Visio

     

    3

    实体如何设计?充血模型和贫血模型?

    UML类图

     

     

    4

    使用什么数据库?关系型还是非关系型?

    选型结果

     

     

     

     

     

    关系型数据库

    非关系型数据库(NoSQL)

    Oracle(首次发行:1980年)

    MySQL(首次发行:1995)

    MS SQL Server(首次发行:1989)

    PostgreSQL(首次发行:1989)

    IBM DB2(首次发行:1983)

    Microsoft Access(首次发行:1992)

    Sybase ASE(首次发行:1987)

    SQLite(首次发行:2000)

    …… 

    MongoDB(首次发行:2009)

    Cassandra(首次发行:2008)

    Apache CouchDB

    Hbase

    Redis

    db4o

    BaseX

    …… 

     

     

     

    5.4.4.  运行架构

     

    运行架构关注的不再是全局而是局部,着重关注那些关键点与难点,常常需要技术攻关与预研。主要考虑控制流、通讯机制、资源争用、锁机制、同步异步、并发、串行,同时也要考虑质量属性。

    No.

    考虑的方面

    产出物

    工具

    说明

    1

    运行:同步vs.异步;并发vs.串行

    考虑开发架构中代码的实现。

     

     

    2

    交互:对象间交互;状态转换

    考虑开发架构的合理性,到类、到接口、到代码。

     

     

    3

    质量:安全;可靠;可伸缩

    考虑开发架构的合理性

     

     

    4

    性能:响应时间;吞吐量

    估算:

    在线人数、并发人数;

    每秒事务量;

    响应时间。

     

     

     

     

     

    5.4.5.  物理架构

     

    物理架构主要考虑硬件选择和拓扑结构,软件到硬件的映射,软硬件的相互影响。

     

    考虑的方面

    产出物

    工具

    说明

    1

    网络方面:网络拓扑;网络设备;安全机制

    拓扑图

    安全规范

     

     

    2

    性能方面:可靠性、可伸缩性

    需要什么样设备性能

     

     

    3

    部署方面:集中式还是分布式;组件部署

    部署图

     

     

     

     

     

     

    6.  一个思考,谁驱动了架构设计?

     

    需求驱动了架构设计?

    质量属性了驱动了架构设计(ADD)?

    领域驱动了架构设计(DDD)?

    风险驱动了架构设计?

    质疑驱动了架构设计?

    ……

    到底是谁驱动了架构设计?我们以船舶设计建造为例,来看这些问题:

    目标和结果

    问题

    回答

    小结

    设计和制造一艘远洋货轮,能经历数月海上颠簸和长途跋涉,并保证货物的安全和完整,最后能顺利抵达目标港口。

    我们为什么要设计和制造这样的大船?

    市场有这个需求;

    获利很丰厚;

    解决就业;

    ……

    不管是外部需求还是内部的需求,都是需求。不正是需求驱动吗?

    如何保证货船能长途航行并经受波涛和风雨?

    船要造的结实;

    鲁棒性

    这些不正是质量属性驱动设计吗?

    引擎设计的强劲;

    性能

    船的燃料充足;

    持续可用性

    装备卫星电话、GPS、雷达等设备

    互操作性

    货物和人员要安全

    安全性

    船舶设计师怎么设计这样的船舶?

    现在都会通过计算机进行船舶的CAD和3D模型设计。

    是不是佷似领域模型驱动了设计?

    造船一定有很多风险吧?

    那是,比如订货方客户有时提出改装船舶的意见(需求变化的风险);有时某些工艺成品率不稳定(质量风险);等等。

    所有可能的风险点在设计时都要考虑到,做好预案,才能保证架构设计的可行性和灵活性,风险驱动了架构设计。

    上面怎么提了那么多问题,其实还有很多问题,比如……

    嗯,你现在有不少疑问了。

    不断的质疑架构设计中可能存在各种问题,有质疑才有思考,才有解决方案,从而推动架构设计的不断完善。

     

    总结:

     

    以上几个方面都能驱动架构设计,并不是零和的规则,而是一个立方体从不同方向看的问题。以上方面有些是指导思想,有些是行动方式,有的兼而有之,阐述方式看似不同,终极目标还是造出大船(实现需求),造出好船(质量属性),怎么造(领域模型),造的顺利(风险控制),挑不出毛病(架构师自己先质疑问题并解决了)。

     

     

    7.  软件架构设计的误区

     

    ● 高开高走落不到实处

    ● 理想与现实需要折中

    ● 遗漏关键性约束与非功能需求

    ● 为虚无的未来埋单而过度设计

    ● 过早做出关键性决策

    ● 客户说啥就是啥成为酱油哥

    ● 埋头干活儿缺乏前瞻性

    ● 架构设计还要考虑系统可测性

    ● 架构设计不要企图一步到位

     

     

    8.  部分参考资料

     

    温昱的《一线架构师实践指南》

     


    注:有网友问:这是自己总结,还是看书总结呢?
    我的回答是:看书是学习的过程,概念是不变真理,架构是工作内容,经验是多年积累,教训是切身体会,内容是自己总结,文章是自己码字,^_^。

    展开全文
  • 软件架构设计---软件架构概述

    万次阅读 2018-09-17 21:25:54
    通俗地讲,软件架构设计就是软件系统的“布局谋篇”。  人们在软件工程实践中,逐步认识到了软件架构的重要性,从而开辟了一个崭新的研究领域。软件架构的研究内容主要涉及软件架构描述、软件架构设计、软件架构...

         像学写文章一样,在学会字、词、句之后,就应上升到段落,就应追求文章的“布局谋篇”,这就是架构。通俗地讲,软件架构设计就是软件系统的“布局谋篇”。

        人们在软件工程实践中,逐步认识到了软件架构的重要性,从而开辟了一个崭新的研究领域。软件架构的研究内容主要涉及软件架构描述、软件架构设计、软件架构风格、软件架构评价和软件架构的形成方法等。

        软件设计人员学习软件架构知识旨在站在较高的层面上整体地解决好软件的设计、复用、质量和维护等方面的实际问题。

       1 软件架构概述 

        软件架构是软件抽象发展到一定阶段的产物,从编程的角度,可以清晰地看到软件抽象层次和表达工具的发展历史。

    • 20 世纪 60 年代是子程序的年代:出现了原始的软件架构,即子程序,并以程序间的调用为连接关系。

    • 20 世纪 70 年代是模块化的年代:出现了数据流分析、实体—关系图(E-R 图)、信息隐藏等工具和方法,软件的抽象层次发展到了模块级。

    • 20 世纪 80 年代是面向对象的年代:基于模块化的编程语言进一步发展成面向对象的语言,继承性地增加了一种新元素之间的连接关系。

    • 20 世纪 90 年代是框架的年代:标准的基于对象的架构以框架的形式出现了。如电子数据表、文档、图形图像、音频剪辑等可互换的黑箱对象,可以相互嵌入。

    • 当前(最近 10 年来):中间件和 IT 架构作为标准平台出现,用可购买可复用的元素来构建系统,同时,基于架构的开发方法和理论不断成熟。

    1  软件架构的定义 

        软件架构仍在不断发展中,还没有形成一个统一的、公认的定义,这里仅举出几个较权威的定义。

        定义 1:软件或计算机系统的软件架构是该系统的一个(或多个)结构,而结构由软件元素、元素的外部可见属性及它们之间的关系组成。

        定义 2:软件架构为软件系统提供了一个结构、行为和属性的高级抽象,由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式及这些模式的约束组成。

        定义 3:软件架构是指一个系统的基础组织,它具体体现在:系统的构件,构件之间、构件与环境之间的关系,以及指导其设计和演化的原则上。(IEEE1471- 2000)

       前两个定义都是按“元素—结构—架构”这一抽象层次来描述的,它们的基本意义相同,其中定义 1 较通俗,因此,本章采用这一定义。该定义中的“软件元素”是指比“构件”更一般的抽象,元素的“外部可见属性”是指其他元素对该元素所做的假设,如它所提供的服务、性能特征等。

        为了更好地理解软件架构的定义,特作如下说明:

        (1)架构是对系统的抽象,它通过描述元素、元素的外部可见属性及元素之间的关系来反映这种抽象。因此,仅与内部具体实现有关的细节是不属于架构的,即定义强调元素的“外部可见”属性。

        (2)架构由多个结构组成,结构是从功能角度来描述元素之间的关系的,具体的结构传达了架构某方面的信息,但是个别结构一般不能代表大型软件架构。

        (3)任何软件都存在架构,但不一定有对该架构的具体表述文档。即架构可以独立于架构的描述而存在。如文档已过时,则该文档不能反映架构。

        (4)元素及其行为的集合构成架构的内容。体现系统由哪些元素组成,这些元素各有哪些功能(外部可见),以及这些元素间如何连接与互动。即在两个方面进行抽象:在静态方面,关注系统的大粒度(宏观)总体结构(如分层);在动态方面,关注系统内关键行为的共同特征。

        (5)架构具有“基础”性:它通常涉及解决各类关键的重复问题的通用方案(复用性),以及系统设计中影响深远(架构敏感)的各项重要决策(一旦贯彻,更改的代价昂贵)。

        (6)架构隐含有“决策”,即架构是由架构设计师根据关键的功能和非功能性需求(质量属性及项目相关的约束)进行设计与决策的结果。不同的架构设计师设计出来的架构是不一样的,为避免架构设计师考虑不周,重大决策应经过评审。特别是架构设计师自身的水平是一种约束,不断学习和积累经验才是摆脱这种约束走向自由王国的必经之路。

        在设计软件架构时也必须考虑硬件特性和网络特性,因此,软件架构与系统架构二者间的区别其实不大。但是,在大多情况下,架构设计师在软件方面的选择性较之硬件方面,其自由度大得多。因此,使用“软件架构”这一术语,也表明了一个观点:架构设计师通常将架构的重点放在软件部分。

        将软件架构置于商业背景中进行观察,可以发现软件架构对企业非常重要。

        (1)影响架构的因素。软件系统的项目干系人(客户、用户、项目经理、程序员、测试人员、市场人员等)对软件系统有不同的要求开发组织(项目组)有不同的人员知识结构、架构设计师的素质与经验、当前的技术环境等方面都是影响架构的因素。

    这些因素通过功能性需求、非功能性需求、约束条件及相互冲突的要求,影响架构设计师的决策,从而影响架构。

        (2)架构对上述诸因素具有反作用,例如,影响开发组织的结构。架构描述了系统的大粒度(宏观)总体结构,因此可以按架构进行分工,将项目组为几个工作组,从而使开发有序;影响开发组织的目标,即成功的架构为开发组织提供了新的商机,这归功于:系统的示范性、架构的可复用性及团队开发经验的提升,同时,成功的系统将影响客户对下一个系统的要求等。这种反馈机制构成了架构的商业周期。

    2 软件架构的重要性 

        从技术角度看,软件架构的重要性表现为如下几方面。

        (1)项目关系人之间交流的平台。软件系统的项目关系人分别关注系统的不同特性,而这些特性都由架构所决定,因此,架构提供了一个共同语言(公共的参考点),项目关系人以此作为彼此理解、协商、达成共识或相互沟通的基础。架构分析既依赖于又促进了这个层次上的交流。

        (2)早期设计决策。从软件生命周期来看,软件架构是所开发系统的最早设计决策的体现,主要表现为:

    • 架构明确了对系统实现的约束条件:架构是架构设计师对系统实现的各方面进行权衡的结果,是总体设计的体现,因此,在具体实现时必须按架构的设计进行。

    • 架构影响着系统的质量属性:要保证系统的高质量,具有完美的架构是必要的(虽然不充分)。

    • 架构可以用来预测系统的质量,例如,可以根据经验对该架构的质量(如性能)作定性的判断。

    • 架构为维护的决策提供根据。在架构层次上能为日后的更改决策提供推理、判断的依据。一个富有生命力的架构,应该是在最有可能更改的地方有所考虑(架构的柔性),使其在此点最容易进行更改。

    • 架构有助于原型开发。可以按架构构造一个骨架系统(原型),例如,在早期实现一个可执行的特例,确定潜在的性能问题。

    • 借助于架构进行成本与进度的估计。

        (3)在较高层面上实现软件复用。软件架构作为系统的抽象模型,可以在多个系统间传递(复用),特别是比较容易地应用到具有相似质量属性和功能需求的系统中。产品线通常共享一个架构。产品线的架构是开发组织的核心资产之一,利用架构及其范例进行多系统的开发,在开发时间、成本、生产率和产品质量方面具有极大的回报。基于架构的开发强调对各元素的组合或装配。系统开发还可以使用其他组织开发的元素,例如购买商业构件。

        (4)架构对开发的指导与规范意义不容忽略。架构作为系统的总体设计,它指导后续的详细设计和编码。架构使基于模板的开发成为可能,有利于开发的规范化和一致性,减少开发与维护成本。架构可以作为培训的基础,有利于培养开发团队和培训相关人员。

       从软件开发过程来看,如果采用传统的软件开发模型(生命周期模型),则软件架构的建立应位于概要设计之前,需求分析之后。

        基于架构的软件开发模型则明确地把整个软件过程划分为架构需求、设计、文档化、评审(评估)、实现、演化等 6 个子过程。本章各节将分别对这些子过程进行讨论。

    3 架构的模型

        软件架构作为一个有机的整体,可以分解成多个侧面来认识,每个侧面强调它的不同方面的特征,从而使架构设计师能整体地把握它的重点。我们可以将软件架构归纳成 5 种模型:结构模型、框架模型、动态模型、过程模型和功能模型。最常用的是结构模型和动态模型。

        (1)结构模型。这是一个最直观、最普遍的建模方法。这种方法以架构的构件、连接件和其他概念来刻画结构,并力图通过结构来反映系统的重要语义内容,包括系统的配置、约束、隐含的假设条件、风格、性质。研究结构模型的核心是架构描述语言。

        (2)框架模型。框架模型与结构模型类似,但它不太侧重描述结构的细节而更侧重于整体的结构。框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构。

        (3)动态模型。动态模型是对结构或框架模型的补充,研究系统“大颗粒”的行为性质。例如,描述系统的重新配置或演化。动态可能指系统总体结构的配置、建立或拆除通信通道或计算的过程。

        (4)过程模型。过程模型研究构造系统的步骤和过程。因而结构是遵循某些过程脚本的结果。

        (5)功能模型。该模型认为架构由一组功能构件按层次组成,且下层向上层提供服务。它可以看作是一种特殊的框架模型。

        这 5 种模型各有所长,也许将 5 种模型有机地统一在一起,形成一个完整的模型来刻画软件架构更合适。即将软件架构视为这些模型的统一体,通过这些模型的表述(文档)来完整反映软件架构。例如,Kruchten 在 1995 年提出了一个“4+1”的视图模型。“4+1” 视图模型从 5 个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件架构。每一个视图只关心系统的一个侧面,5 个视图结合在一起才能反映系统的软件架构的全部内容。“4+1”视图模型如图 9-1 所示。

        (1)逻辑视图:主要支持系统的功能需求,即系统提供给最终用户的服务。在逻辑视图中,系统分解成一系列的功能抽象,这些抽象主要来自问题领域。这种分解不但可以用来进行功能分析,而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。在面向对象技术中,通过抽象、封装和继承,可以用对象模型来代表逻辑视图,用类图来描述逻辑视图。逻辑视图中使用的风格为面向对象的风格,逻辑视图设计中要注意的主要问题是要保持一个单一的、内聚的对象模型贯穿整个系统。

        (2)开发视图:也称为模块视图,主要侧重于软件模块的组织和管理。软件可通过程序库或子系统进行组织,这样,对于一个软件系统,就可以由不同的人进行开发。开发视图要考虑软件内部的需求,如软件开发的容易性、软件的重用和软件的通用性,要充分考虑由于具体开发工具的不同而带来的局限性。开发视图通过系统输入输出关系的模型图和子系统图来描述。可以在确定了软件包含的所有元素之后描述完整的开发角度,也可以在确定每个元素之前,列出开发视图原则。

        (3)进程视图:侧重于系统的运行特性,主要关注一些非功能性的需求,例如系统的性能和可用性。进程视图强调并发性、分布性、系统集成性和容错能力,以及逻辑视图中的主要抽象的进程结构。它也定义逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。进程视图可以描述成多层抽象,每个级别分别关注不同的方面。

        (4)物理视图:主要考虑如何把软件映射到硬件上,它通常要考虑到解决系统拓扑结构、系统安装、通信等问题。当软件运行于不同的节点上时,各视图中的构件都直接或间接地对应于系统的不同节点上。因此,从软件到节点的映射要有较高的灵活性,当环境改变时,对系统其他视图的影响最小。

        (5)场景:可以看作是那些重要系统活动的抽象,它使四个视图有机地联系起来,从某种意义上说,场景是最重要的需求抽象。在开发架构时,它可以帮助设计者找到架构的构件和它们之间的作用关系。同时,也可以用场景来分析一个特定的视图,或描述不同视图构件间是如何相互作用的。场景可以用文本表示,也可以用图形表示。

        希赛教育专家提示:逻辑视图和开发视图描述系统的静态结构,而进程视图和物理视图描述系统的动态结构。对于不同的软件系统来说,侧重的角度也有所不同。例如,对于管理信息系统来说,比较侧重于从逻辑视图和开发视图来描述系统,而对于实时控制系统来说,则比较注重于从进程视图和物理视图来描述系统。

    展开全文
  • 软件架构设计---架构设计

    千次阅读 2018-09-17 21:46:29
    实现软件质量属性的战术,这些战术可以看做设计的基本“构建块”,通过这些构建块,就可以精心设计系统的软件架构了。  架构模式也称为架构风格,它是适当地选取战术的结果,这些固定的结果(模式)在高层抽象层次...
  •  软件属性包括功能属性和质量属性,但是,软件架构(及软件架构设计师)重点关注的是质量属性。因为,在大量的可能结构中,可以使用不同的结构来实现同样的功能性,即功能性在很大程度上是独立于结构的,架构设计师...
  • 软件架构设计---软件架构视图

    万次阅读 2018-09-18 07:38:21
    软件架构视图  从软件架构本身的特点出发讨论了架构建模及与特定应用领域密切相关的架构风格。本节将从对架构编档的角度对软件架构视图及其风格进行讨论。 1 软件视图的分类   现代软件系统非常复杂,通常在...
  • 软件架构设计---层次系统架构风格

    万次阅读 2018-09-17 21:38:22
    1 二层及三层 C/S 架构风格 ... C/S 软件架构具有强大的数据操作和事务处理能力,模型思想简单,易于人们理解和接受。但随着企业规模的日益扩大,软件的复杂程度不断提高,传统的二层 C/S 结...
  • 软件架构设计---软件架构风格

    千次阅读 2018-09-17 21:33:52
     软件架构设计的一个核心问题是能否使用重复的软件架构模式,即能否达到架构级别的软件重用。也就是说,能否在不同的软件系统中,使用同一架构。基于这个目的,学者们开始研究和实践软件架构的风格和类型问题。  ...
  • 好的软件架构设计

    万次阅读 2013-12-17 16:53:27
    什么是软件架构 前言:软体设计师中有一些技术水平较高、经验较为丰富的人,他们需要承担软件系统的架构设计,也就是需要设计系统的元件如何划分、元件之间如何发生相互作用,以及系统中逻辑的、物理的、系统的...
  • 软件架构设计经典书籍有哪些?

    万次阅读 2011-12-03 11:51:51
    1.软件架构设计 作者: 温昱 内容简介:本书紧紧围绕“软件架构设计”这一主题,立足实践解析了软件架构的概念、阐述了切实可行的软件架构设计方法、提供了可操作性极强的完整的架构设计过程。另外,本书从思维...
  • 软件架构设计之工具实践篇

    千次阅读 2019-05-16 06:35:43
    前面写了两篇软件架构设计的文章,思想篇和理论篇,今天Relax君想跟大家聊一聊如何通过具体的工具去画出软件架构设计中的那些图,这其实也正是上篇文章《这个公众号后面会写些什么》中写到的,Relax君会给大家分享...
  • 软件架构设计经典书籍有哪些

    千次阅读 2015-12-03 14:10:45
    内容简介:本书紧紧围绕“软件架构设计”这一主题,立足实践解析了软件架构的概念、阐述了切实可行的软件架构设计方法、提供了可操作性极强的完整的架构设计过程。另外,本书从思维方式的突破、面向对象设计、UML...
  • 软件架构设计的一般过程

    千次阅读 2014-09-24 19:15:15
    在一个以软件架构为中心的...软件架构设计阶段依赖于分析阶段并以软件需求规约为主要输入。那么是不是软件架构工程师必须等到软件需求规约评审通过后才开始工作呢?前面讲到软件架构的策略时讲到全面认识需求与关键需求
  • 1. 软件架构设计的What & Why● 啥是软件架构(Software Architecture)?软件架构是指在一定的设计原则基础上,从不同角度对组成系统的各部分进行搭配和安排,形成系统的多个结构而组成架构,它包括该系统...
  • 嵌入式应用软件架构设计

    千次阅读 2018-07-07 17:15:32
    转自:https://blog.csdn.net/qq8864/article/details/17961375嵌入式应用软件架构设计要做到嵌入式应用的代码逻辑清晰,且避免重复的造轮子,没有好的应用架构怎么行。如果没有好的架构,移植将会是一件很痛苦的...
  • 前面写了两篇软件架构设计的文章,今天Relax想跟大家聊一聊如何通过具体的工具去画出软件架构设计中的那些图,那么今天主要给大家分享的是一个好用的架构设计画图工具——Enterprise Architect(后面都简称EA)。...
  • 微服务架构设计实践 目 次1 序言2 微服务3 软件架构设计思想4 微服务架构设计实践4.1 项目概述4.2 架构准备阶段4.3 概念架构阶段4.4 细化架构阶段4.4.1 业务架构4.4.2 数据架构4.4.3 应用架构4.4.4 技术架构4.4.5 ...
  • 软件架构设计的几点理解

    千次阅读 2018-09-23 22:09:41
    与建筑师设定建筑项目的设计原则和目标,作为绘图员画图的基础一样,一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。从和目的、主题、材料和结构的联系上来说,软件架构...
1 2 3 4 5 ... 20
收藏数 432,688
精华内容 173,075
关键字:

软件架构设计