精华内容
下载资源
问答
  • 2022-01-09 12:19:02

    Q1.什么是软件架构?

    软件架构的定义没有一个统一的标准,各有各的看法。但可以参考来自SEI的定义:

    计算系统的软件架构是解释该系统所需要的结构体的集合,包括软件元素、元素的交互,以及两者各自的属性。

    可以从 2 个维度描述:

    • 静态结构,包括层次、模块划分以及更细节的数据结构体等等,代表一个系统的骨架,就如一幢建筑物的框架;
    • 动态行为,包括模块间的通信、交互机制,代表系统的行为。

    Q2.什么属于架构层面的内容?

    架构一般指的是软件系统宏观层面的设计部分,前面讲到架构是骨架,关注于整体,一般不会关注于细节。

    但同时,如果有一些元素的设计会影响到整体系统的质量属性,那么它也应该被拉进架构设计中讨论。 比如,嵌入式系统当中,实时性是一个很重要的质量属性,那么对于通信协议的技术选型也就是非常重要的。比如,一个汽车软件架构师,你说不你懂CAN协议终归不合适。

    Q3.架构重要吗?

    重要,关系到软件系统的成败。
    有下面的作用:

    • 扮演着系统骨架的角色
    • 影响质量属性
    • 与软件功能正交 决定系统能做什么
    • 更加重要的是决定系统不做什么

    尤其是最后一点非常重要,比如在汽车自动驾驶当中,自动化程度是分等级的,假如你设计一个L2级别自动驾驶系统,你就应该将L3级别以上功能排除在外,通过 ODD 进行准确的界定。

    Q4. 什么时候需要架构?

    可以不需要架构,这个叫大泥球模式。

    说起来也挺尴尬的,很多时候我们发现一个软件团队没有架构师、没有架构也能正常开发并正常实现所有功能。但没有架构设计的系统其实也有架构,它代表一种功能优先设计的模式,就像一个大泥球一样越滚越大。

    当然,正常的开发者都知道很多情况需要架构的,比如:

    • 实现特别难的解决方案
    • 非常容易失败的高度复杂项目
    • 非常难以满足的质量属性的系统
    • 需要统筹的产品线

    无非就 2 点:
    越难的项目越需要架构设计
    产品平台需要架构设计,比如一家自动驾驶企业,如果做L3,也做L4,最理想的状态就是他们的产品基于同一套架构,这样能够避免资源冗余和浪费。

    Q5. 什么是推定架构和参考架构?

    推定架构(presumptive architecture) 是行业占主导地位的架构族,不采用会需要特别做说明的技术。比如你做汽车ECU软件开发,如果你不采用 CP Autosar,你得准备好来自各个方面的质问,你要说明你不选它的逻辑是什么。
    参考架构(reference architecture) 是针对某个问题在架构方面的解决方案。推定架构是事实标准,参考架构想成为事实标准。
    自动驾驶软件架构有一些参考架构,但它只做参考用,比如下面这张图。
    在这里插入图片描述

    Q6. 如何在一个项目中运用架构?

    有几种选择:

    • 不运用任何架构
    • 从0到1严肃的正向设计开发
    • 在原有架构上进行重构与提升

    3 种方式都很普遍。

    Q7. 企业架构师与应用架构师的区别?

    企业架构师是站在企业的角度负责多个应用系统的开发,不负责单个系统的具体功能,专注于打造企业内的软件生态系统,促进每个软件系统为企业贡献力量。
    应用架构师关注于单个软件系统的架构设计。
    我举个例子。智能汽车当中现在有智能网联、智能驾驶、智能座舱 3 大系统。企业架构师的职责就是打造整个智能汽车软件生态。应用架构师可以只负责其中一个系统或者子系统的架构。

    8.康威定律如何描述软件架构?

    任何设计系统的组织…必然会产生以下设计结果,其结构就是该组织沟通结构的写照。

    我比较认同一种说明,架构设计本质就是一种社交行为。和客户、用户、项目经理、产品经理、测试人员、开发人员、其他相关人员

    9.软件架构的另外一个定义?

    前面讲到软件架构没有统一标准,另外一个比较有名的定义来自 Martin Fowler 与 Ralph Jonson 之间的讨论。
    架构是必须在项目早期作出的一组设计决策。

    也被称为“那些在项目后期难以改变的内容”。

    但我个人认为,这种说法只是为了强调架构设计在软件开发过程中应该越早介入越好,是一种理想的状态。

    备注:本文观点大多来自《恰如其分的软件架构》。

    更多相关内容
  • 通过实际软件开发过程中的架构设计实例,为大家在编写架构文档时提供范例!
  • 软件架构文档模板

    2018-04-03 14:44:50
    软件架构设计文档模板,如何做架构设计、系统设计(概要设计、详细设计和数据库设计),以及需要有那些规范和参考模板。
  • 软件架构实践(第三版)林巴斯
  • 软件架构实践 第三版 英文版 Software architecture in practice 3rd
  • 本书描述了一种恰如其分的软件架构设计方法。作者建议根据项目面临的风险来调整架构设计的成本,并从多个视角阐述了软件架构的建模过程和方法,包括用例模型、概念模型、域模型、设计模型和代码模型等。本书不仅介绍...
  • 软件架构设计-软件架构风格、分层架构

    万次阅读 多人点赞 2021-06-12 15:39:23
    一、软件架构设计 软件或计算机系统的软件架构是该系统的一个(或多个)结构,而结构由软件元素、元素的外部可见属性及它们之间的关系组成。 软件系统架构是关于软件系统的 结构、行为和属性 的高级抽象。指定了软件...

    一、软件架构设计

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

    软件系统架构是关于软件系统的 结构、行为和属性 的高级抽象。指定了软件系统的组织结构和拓扑结构

    软件架构是可传递可复用的模型,架构就是体系结构。架构设计介于需求分析和软件设计之间。架构设计就是需求分配,即满足,需求的职责分配到组件上。

    软件架构设计是降低成本、改进质量、按时和按需交付产品的关键因素。架构设计能够满足系统的性能、可维护性等品质;能够使得不同的利益相关人(stakeholders)达成一致的目标;能够支持项目计划和项目管理等活动;能够有效地管理复杂性;等等。然而系统架构的给出必须建立在需求明确的基础上。

    软件架构能够在设计变更相对容易的阶段,考虑系统结构的可选方案,便于技术人员与非技术人员就软件设计进行交互,能够展现软件的结构、属性与内部交互关系。但是软件架构与用户对系统的功能性需求没有直接的对应关系。

    二、架构的模型 4+1视图

    在这里插入图片描述
    逻辑视图:主要支持系统的功能需求,即系统提供给最终用户的服务。(用户关注)

    开发视图:也称为模块(实现)视图,主要侧重于软件模块的组织和管理。(程序员)

    进程视图:侧重于系统的运行特性,主要关注一些非功能性的需求,例如系统的性能和可用性。(并发,集成人员)

    物理视图:主要考虑如何把软件映射到硬件上,它通常要考虑到解决系统拓扑结构、系统安装、通信等问题。(软件到硬件,系统工程人员)

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

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

    三、软件架构风格

    软件架构风格是描述特定软件系统组织方式的惯用模式。组织方式描述了系统的组成构件和这些构件的组织方式;惯用模式则反映众多系统共有的结构和语义特性强调对软件设计的重用

    架构风格定义一个系统家族,即一个架构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型,而这组约束指出系统是如何将这些构件和连接件组合起来的。架构风格反映了领域中众多系统所共有的结构和语义特性,并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件架构风格的研究和实践促进对设计的重用,一些经过实践证实的解决方案也可以可靠地用于解决新的问题。例如,如果某人把系统描述为“客户/服务器”模式,则不必给出设计细节,我们立刻会明白系统是如何组织和工作的。

    1. 数据流风格
    在这里插入图片描述

    1. 批处理序列

      强调数据作为一个整体(数据必须是完整的,以整体的方式传递)

    2. 管道和过滤器

      每个构件都有一组输入和输出,构件读输入的数据流,经过内部处理,然后产生输出数据流. (构件–>过滤器;连接件–>管道) (数据流的形式)

    2. 调用/返回风格

    在这里插入图片描述

    1. 主程序/子程序

      计算构件作为子程序协作工作,由一个主程序顺序地调用这些子程序,构件通过共享存储区交换数据. 曾经作为结构化开发方法的主要选择,具有结构清晰,维护方便的特点,缺点是主子程序划分缺乏标准,较难实现不同设计人员间设计的子程序复用。

    2. 面向对象风格

      面向对象在类的层次实现高度内聚,整个系统通过不同类的组合调用实现不同功能,便于类的复用,只是面向对象是一个通用风格,类的划分不同设计人员设计结果有很大不同,对实际架构设计指导意义不大。

    3. 层次结构风格

      分层结构将整个系统按照抽象层次不同分为多层,每个层次的程序只需要负责与相邻的上下两层打交道,简化了系统中调用关系复杂度。允许每层用不同的方法实现,为软件重用提供了强大的支持。(二层C/S、三层C/S、MVC、MVP、MVVP、RIA富互联网应用)

    3. 独立构件风格
    在这里插入图片描述

    1. 进程通讯

      进程通讯架构将系统建设成一个个独立构件,构件间采用命名的消息传递来实现沟通与协作。

    2. 事件系统子风格(隐式调用 )

      事件驱动架构风格与进程通讯风格类似,也是将系统分各个为独立的构件,不同的是不同构件间通讯不采用命名的消息,而是采用隐式调用的方式,先将一个个构件的过程注册到某个事件中,当这个事件发生时,所有注册到该事件的过程自动被触发执行。这类风格的好处是独立构件间耦合度进一步降低,方便构件修改及替换,缺点是触发事件放弃了对被触发执行程序组的控制。

    4. 虚拟机风格
    在这里插入图片描述

    1. 解释器

      具有运行时系统行为 (自)定义与改变能力 。如专家系统。

    2. 基于规则的系统

      基于规则的系统包括规则集、规则解释器、规则/数据选择器及工作内存。(一般用在人工智能领域和DSS中)

    5. 仓库风格
    在这里插入图片描述
    在仓库风格中,有两种不同的构件:中央数据结构说明当前状态,独立构件在中央数据存储上执行。

    1. 数据库系统

      构件主要有两大类,一个是中央共享数据源,保存当前系统的数据状态,另一个是多个独立处理元素,处理元素对数据元素进行操作。中央数据库管理系统通过自身机制如数据排它锁,共享锁等,实现数据高速访问,数据一致性,数据完整性。同时各独立数据处理单元之间互相不受约束。 (如编译器,传统编译器采用批处理架构,现代编译器采用数据共享架构风格。分析树是共享数据。)

    2. 超文本系统

      主要应用于静态网页。

    3. 黑板风格

      由一个作为全局共享数据的黑板,一个控制单元和多个知识源组成,主要应用与专家问题解决系统。通过专家知识和反馈逐步得到正确结果. (如语音识别)

    6. 闭环控制架构

    1. 过程控制

      工业中的过程控制是指以温度、压力、流量、液位和成分等工艺参数作为被控变量的自动控制。过程控制也称实时控制,是计算机及时的采集检测数据,按最佳值迅速地对控制对象进行自动控制和自动调节,如数控机床和生产流水线的控制等。(比如空调制冷,温度大于设定温度制冷,小于等于时停止,一旦大于继续运作)

    2. C2
      在这里插入图片描述

      通过连接件绑定在一起按照一组规则运作的并行构件。

      1. 构建和连接件都有一个顶部和一个底部
      2. 构建的顶部都要连接连接件的底部,构建的底部都要连接连接件的顶部,构建 之间不允许直连。
      3. 一个连接进行直接连接时,必须有其中一个的底部到另一个的顶部。

    四、分层C/S架构风格演化

    1. 二层 C/S
    在这里插入图片描述

    1. 二层 C/S 结构为单一服务器且以局域网为中心,所以难以扩展至大型企业广域网或Internet;(使用范围)
    2. 软、硬件的组合及集成能力有限;(扩展性)
    3. 服务器的负荷太重,难以管理大量的客户机,系统的性能容易变坏;(性能)
    4. 数据安全性不好。因为客户端程序可以直接访问数据库服务器,那么,在客户端计算机上的其他程序也可想办法访问数据库服务器,从而使数据库的安全性受到威胁。(安全)

    2. 三层C/S架构

    在这里插入图片描述

    1. 表现层(Web层)
      负责接收客户端请求,向客户端响应结果,通常客户端使用http协议请求 web,web层需要接收 http请求,完成http响应。
      表现层包括展示层和控制层:控制层负责接收请求,展示层负责结果的展示。
      表现层依赖业务层,接收到客户端请求一般会调用业务层进行业务处理,并将处理结果响应给客户端。
      表现层的设计一般都使用 MVC 模型。 MVC 是表现层的设计模型,和其他层没有关系。
    2. 业务层 (Service层)
      它负责业务逻辑处理,和我们开发项目的需求息息相关。web层依赖业务层,但是业务层不依赖Web层。
      业务层在业务处理时可能会依赖持久层,如果要对数据持久化需要保证事务一致性。 (事务应该放到业务层来控制)
    3. 持久层 (dao 层)
      负责数据持久化,包括数据层即数据库和数据访问层,数据库是对数据进行持久化的载体,数据访问层是业务层和持久层交互的接口;业务层需要通过数据访问层将数据持久化到数据库中。
      持久层就是和数据库交互,对数据库表进行增删改査的。

    优点:

    (1)允许合理地划分三层结构的功能,使之在逻辑上保持相对独立性,从而使整个系统的逻辑结构更为清晰,能提高系统和软件的可维护性和可扩展性。(逻辑独立清晰, 可维护性/可扩展性)

    (2)允许更灵活有效地选用相应的平台和硬件系统,使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层;并且这些平台和各个组成部分可以具有良好的可升级性和开放性。(可升级性/开放性)

    (3)三层C/S架构中,应用的各层可以并行开发,各层也可以选择各自最适合的开发语言。使之能并行地而且是高效地进行开发,达到较高的性能价格比;对每一层的处理逻辑的开发和维护也会更容易些。(开发维护成本/速度/技术门槛)

    (4)允许充分利用功能层有效地隔离开表示层与数据层,未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层,这就为严格的安全管理奠定了坚实的基础;整个系统的管理层次也更加合理和可控制。(安全)

    3. 三层B/S架构
    在这里插入图片描述

    用户在使用系统时,仅仅需要一个浏览器就可运行全部的模块,真正达到了“零客户端”的功能,很容易在运行时自动升级。(客户端)

    基于B/S架构的软件,系统安装、修改和维护全在服务器端解决。(服务端)

    B/S架构还提供了异种机、异种网、异种应用服务的联机、联网、统一服务的最现实的开放性基础。(开放性)

    缺点:

    1. B/S架构缺乏对动态页面的支持能力,没有集成有效的数据库处理功能。
    2. B/S架构的系统扩展能力差,安全性难以控制。
    3. 采用B/S架构的应用系统,在数据查询等响应速度上,要远远地低于C/S架构。(性能)
    4. B/S架构的数据提交一般以页面为单位,数据的动态交互性不强,不利于OLTP应用.

    五、MVC的架构风格

    在这里插入图片描述

    MVC 全名是 Model ViewController,是模型(model)-视图(view)-控制器(controller)的缩写,它是分层架构风格的一种。主要解决 将与 UI 相关的逻辑都定义在针对视图的相关元素的事件上 的问题。

    MVC 中各个部分的分工与协作:

    1. Model 是对应用状态和业务功能的封装,我们可以将它理解为同时包含数据和行为的领域模型。Model 接受 Controller 的请求并完成相应的业务处理,在状态改变的时候向 View 发出相应的通知。
    2. View 实现可视化界面的呈现并捕捉最终用户的交互操作(例如鼠标和键盘的操作)。
    3. View 捕获到用户交互操作后会直接转发给 Controller,后者完成相应的 UI 逻辑。如果需要涉及业务功能的调用,Controller 会直接调用 Model。在完成 UI 处理后,Controller 会根据需要控制原 View 或者创建新的 View 对用户交互操作予以响应。

    六、MVP 的架构风格

    在这里插入图片描述

    MVP 是从经典的模式 MVC 演变而来,它们的基本思想有相通的地方:Controller/Presenter 负责逻辑的处理,Model 提供数据,View 负责显示。

    当然 MVP 与 MVC 也有一些显著的区别,MVC 模式中元素之间“混乱”的交互主要体现在允许 View 和 Model 直接进行“交流”,这在 MVP 模式中是不允许的。在 MVP 中 View 并不直接使用 Model,它们之间的通信是通过 Presenter (MVC 中的 Controller)来进行的,所有的交互都发生在 Presenter 内部,而在 MVC 中 View 会直接从 Model 中读取数据而不是通过 Controller,从而避免了 View 和 Model 之间的耦合。

    扩展:

    1. MVVM架构

    在这里插入图片描述
    2. 富互联网应用(RIA)

    在这里插入图片描述
    3. 分布式架构

    客户机/服务器系统开发时可以采用不同的分布式计算架构:

    1. 分布式表示架构是将表示层和表示逻辑层迁移到客户机,应用逻辑层、数据处理层和数据层仍保留在服务器上(类似三层CS架构的两层应用);
    2. 分布式数据架构是将数据层和数据处理层放置于服务器,应用逻辑层、表示逻辑层和表示层放置于客户机(类似两层CS架构);
    3. 分布式数据和应用架构数据层和数据处理层放置在数据服务器上,应用逻辑层放置在应用服务器上,表示逻辑层和表示层放置在客户机(类似三层CS架构)。

    4. ANSI

    在ANSI/IEEE 1471-2000标准中,系统是为了达成利益相关人(Stakeholder)的某些使命(Mission),在特定环境(Enviroment)中构建的。每一个系统都有一个架构(Architecture)。架构(Architecture)是对所有利益相关人的关注点(Concern)的响应和回答,通过架构描述(Architecture Description)来说明。每一个利益相关人都有各自的关注点。这些关注点是指对其重要的,与系统的开发、运营或其他方面相关的利益。架构描述(Architecture Description)本质上是多视图的。每一个视图(View)是从一个特定的视角(Viewpoint)来表述架构的某一个独立的方面。试图用一个单一的视图来覆盖所有的关注点当然是最好的,但实际上这种表述方式将很难理解。视角(Viewpoint)的选择,基于要解决哪些利益相关人的哪些关注点。它决定了用来创建视图的语言、符号和模型等,以及任何与创建视图相关的建模方法或者分析技术。一个视图(View)包括一个或者多个架构模型(Model),一个模型也可能参与多个视图。模型较文本的表述的好处在于,可以更容易的可视化、检查、分析、管理和集成。

    5. 需求和架构

    需求和软件架构设计面临的是不同的对象:一个是问题空间;另一个是解空间。保持两者的可追踪性和转换,一直是软件工程领域追求的目标

    6. 架构风格和设计模式的区别

    1. 架构风格往往是从全局的角度来考虑问题,他是一种独立于实际问题的通用组织结构。例如,常用的B/S架构,在很多不同的系统中,都有应用。

    2. 而设计模式着眼于解决某一特定的局部问题,是一种局部解决方案的应用。例如,在很多的软件系统中,创建对象时,希望有统一的机制对这些对象的创建进行管理,所以出现了工厂模式,创建者模式等设计模式。比如java内存垃圾的回收机制也做成了一种设计模式。

    7. 软件架构需求

    软件架构需求是指用户对目标软件系统在功能、行为、性能和设计约束等方面的期望。需求过程主要是获取用户需求,标识系统中所要用到的构件,并进行架构需求评审。其中标识构件又详细分为生成类图、对类图进行分组和将类打包成构件三步。软件架构需求并不应该包括设计构件的过程。

    8. 面向构件的编程(COP)

    面向构件的编程(COP)关注于如何支持建立面向构件的解决方案。一个基于一般 OOP 风格的 COP 定义如下(Szyperski,1995): “面向构件的编程需要下列基本的支持:

    1. 多态性(可替代性);
    2. 模块封装性(高层次信息的隐藏);
    3. 后期的绑定和装载(部署独立性);
    4. 安全性(类型和模块安全性)。”

    系统构件组装分为三个不同的层次:定制( Customization)、集成(Integration)、扩展(Extension)。这三个层次对应于构件组装过程中的不同任务。

    9. OMG接口定义语言IDL

    IDL 是一种接口定义语言,具体的定义会涉及到接口以及相关部分。文件包含的主要元素有:接口描述、模块定义、类型定义、常量定义、异常、值类型。接口描述是IDL文件中最核心的内容。

    由于IDL只是一种接口定义语言,最终还是要落地与语言对接的,所以IDL的数据类型要与实现语言进行映射。以Java为例,IDL接口映射为Java类,而该接口的操作映射为相应的成员函数。模块定义映射为Java 语言中的包 (Package)或C++的namespaces。

    9. 扩展知识

    一个软件的架构设计是随着技术的不断进步而不断变化的。以编译器为例,其主流架构经历了管道-过滤器到数据共享为中心的转变过程。早期的编译器采用管道-过滤器架构风格,以文本形式输入的代码被逐步转化为各种形式,最终生成可执行代码。早期的编译器采用管道-过滤器架构风格,并且大多数编译器在词法分析时创造独立的符号表,在其后的阶段会不断修改符号表,因此符号表并不是程序数据的一部分。现代的编译器采用以数据共享为中心的架构风格,主要关心编译过程中程序的中间表示。现代的编译器采用以数据共享为中心的架构风格,分析树是在语法分析阶段结束后才产生作为语义分析的输入,分析树是数据中心中重要的共享数据,为后续的语义分析提供了帮助。

    展开全文
  • 一、软件架构评估 软件架构评估是在对架构分析、评估的基础上,对架构策略的选取进行决策。它也可以灵活地运用于对软件架构进行评审等工作中。 二、软件架构评估的方法 业界已开发出多种软件架构评估的方法,按基于...

    一、软件架构评估

    软件架构评估是在对架构分析、评估的基础上,对架构策略的选取进行决策。它也可以灵活地运用于对软件架构进行评审等工作中。

    二、软件架构评估的方法

    业界已开发出多种软件架构评估的方法,按基于的技术手段来看,可以分为三类:基于调查问卷或检查表的方式、基于场景的方式和基于度量的方式。以属性作为架构评估的核心概念。

    1. 基于调查问卷或检查表的方式:该方式的关键是要设计好问卷或检查表,它充分利用系统相关人员的经验和知识,获得对架构的评估。其缺点是在很大程度上依赖于评估人员的主观推断。
    2. 基于场景的方式:基于场景的方式由 SEI 首先提出并应用在架构权衡分析法(Architecture Tradeoff Analysis Method,ATAM)和软件架构分析方法(Software Architecture Analysis Method,SAAM)中。它是通过分析软件架构对场景(也就是对系统的使用或修改活动)的支持程度,从而判断该架构对这一场景所代表的质量需求的满足程度。
    3. 基于度量的方式:它是建立在软件架构度量的基础上的,涉及三个基本活动,首先需要建立质量属性和度量之间的映射原则,即确定怎样从度量结果推出系统具有什么样的质量属性;然后从软件架构文档中获取度量信息;最后根据映射原则分析推导出系统的质量属性。它能提供更为客观和量化的质量评估,但它对评估人员及其使用的技术有较高
      的要求。ATAM 中也使用了度量的思想(度量效用)。

    三、软件架构评估的质量属性

    1. 性能是指系统的响应能力,即要经过多长时间才能对某个事件做出响应,或者在某段时间内系统所能处理事件的个数。(优先级队列、资源调度)
    2. 可用性是系统能够正常运行的时间比例。(通过用两次故障之间的时间长度或出现故障时系统能够恢复的速度来表示)(冗余、心跳线(ping/echo))
    3. 可靠性是指软件系统在应用或错误面前,在意外或错误使用的情况下维持软件系统功能特性的基本能力。(冗余、心跳线)
    4. 健壮性是指在处理或环境中,系统能够承受压力或变更的能力。
    5. 安全性是指系统向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。(追踪审计)
    6. 可修改性是指能够快速地以较高的性能价格比对系统进行变更的能力。(包含四个方面:可维护性(maintainability)、可扩展性(extendibility),结构重组(reassemble)、可移植性(portability))
    7. 可变性是指体系结构经扩充或变更成为新体系结构的能力。
    8. 易用性是衡量用户使用一个软件产品完成指定任务的难易程度。
    9. 可测试性是指软件发现故障并隔离、定位其故障的能力特性,以及在一定的时间和成本前提下,进行测试设计、测试执行的能力。(信息隐蔽)
    10. 功能性是系统所能完成所期望工作的能力。
    11. 互操作性是指系统与外界或系统与系统之间的相互作用能力。

    四、关键步骤

    敏感点是实现一个特定质量属性的关键特征,该特征为一个或多个软件构件所共有。系统权衡点会影响一个或多个属性,并对于多个属性来说都是敏感点。

    1. 风险点: 架构设计中潜在的、存在问题的架构决策所带来的隐患。(业务逻辑不明确的地方)

    2. 非风险点:非隐患

    3. 敏感点: 为了实现某种特定的质量属性,一个或多个构件所具有的特征;(修改影响结果)

    4. 权衡点: 影响多个质量属性的特征,是多个质量属性的敏感点(如对两个质量属性特征产生相反的影响,一个好一个坏)(安全与性能)

    通常采用效用树对质量属性的描述进行刻画与排序。在评估过程中,权衡点是一个会影响多个质量属性的架构设计决策

    五、软件架构评估-基于场景的评估 SAAM

    最初用于分析架构可修改性,后扩展到其他质量属性。

    场景:问题描述/需求说明/架构描述。
    在这里插入图片描述
    分析过程:场景开发/架构描述/单个场景评估/场景交互/总体评估。
    在这里插入图片描述
    先评估单个, 再评估多个相互作用。

    六、架构权衡分析法ATAM

    在SAAM的基础上发展起来的,主要针对性能、可用性、安全性和可修改性,在系统开发之前,对这些质量属性进行评价和这种。ATAM 方法不但能够揭示架构如何满足特定的质量需求(例如,性能和可修改性),而且还提供了分析这些质量需求之间交互作用的方法。使用 ATAM 方法评价一个软件架构的目的是理解架构设计满足系统质量需求的结果。该框架主要关注系统的需求说明

    场景包括:场景和需求收集、架构视图和场景实现、属性模型构造和分析、属性模型折中。整个评估过程强调以属性作为架构评估的核心概念
    在这里插入图片描述
    评估过程:
    在这里插入图片描述

    七、产品线及系统演化

    在这里插入图片描述

    软件产品线是指一组软件密集型系统,它们共享一个公共的、可管理的特性集,满足某个特定市场或任务的具体需要,是以规定的方式用公共的核心资产集成开发出来的。
    包含的技术: 软件架构/领域工程/DSSA

    1. 特定领域软件架构(DSSA)

    2. 过程模型

      1. 双生命周期模型:
        在这里插入图片描述

      2. SEI模型

        在这里插入图片描述

      3. 三生命周期模型
        在这里插入图片描述

    3. 组织结构

    在这里插入图片描述

    1. 建立方式

    在这里插入图片描述

    八、架构复用

    软件构件是软件系统中具有一定意义的、相对独立的可重用单元。与对象相比,构件可以基于对象实现,也可以不作为对象实现。构件需要在容器中管理并获取容器提供的服务;客户程序可以在运行状态下利用接口动态确定构件所支持的功能并调用。

    面向构件的编程需要下列基本的支持:多态性(可替代性)、模块封装性(高层次信息的隐藏)、后期的绑定和装载(部署独立性)、安全性(类型和模块安全性)

    构件组装成软件系统的过程可以分为3个层次: 定制/集成/拓展

    1. 商用构件标准规范 CORBA

    三个层次:

    1. 对象请求代理(ORB): 最底层, 规定了分布对象的定义(接口)和语言映射,实现对象间的通信和互操作,是分布对象系统中的“软总线”.

    2. 公共对象服务: 提供诸如并发服务、名字服务、事务(交易)服务、安全服务等各种各样的服务.

    3. 公共设施: 最上层, 定义了构件框架,提供可直接为业务对象使用的服务,规定业务对象有效协作所需的协定规则.

    四种构件

    1. 实体(Entity) 构件需要长期持久化并主要用于事务性行为,由容器管理其持久化。
    2. 加工(Process) 构件同样需要容器管理其持久化,但没有客户端可访问的主键。
    3. 会话(Session) 构件不需要容器管理其持久化,其状态信息必须由构件自己管理。负责完成服务端和客户端的交互。
    4. 服务(Service) 构件是无状态的。

    构件模型

    1. 伺服对象(Servant):CORBA对象的真正实现,负责完成客户端请求。

    2. 对象适配器(Object Adapter):用于屏蔽ORB内核的实现细节,为服务器对象的实现者提供抽象接口,以便他们使用ORB内部的某些功能。

    3. 对象请求代理(Object Request Broker):解释调用并负责查找实现该请求的对象,将参数传给找到的对象,并调用方法返回结果。客户方不需要了解服务对象的位置、通信方式、实现、激活或存储机制。

    2. EJB/J2EE
    支持的5种构件模型:Applet、Servlet、JSP、EJB、Application Client。
    其中,EJB中的BEAN分三种:

    1. session bean会话bean: 负责维护一个短暂的会话;
    2. entity bean 实体bean:负责维护一行稳固持久的数据;
    3. message-driven bean 消息驱动bean:异步接受消息。

    无状态的bean没有成员变量,用单例模式 ;有状态的bean有成员变量,非线程安全,适合用prototype原型模式。

    3. 微软的 COM/DCOM/COM+

    4. 软件重用

    软件重用分垂直式重用与水平式重用,垂直式重用是指局限于某一垂直领域的重用,如只在电力系统中用到的构件;而水平式重用是指通用领域的重用,如标准函数库,任何软件都能用,所以是水平式重用。

    展开全文
  • 要真正通过架构设计来完成业务和技术,需求和实现,软件和硬件,静态和动态,成本和收益等多方面的平衡。 架构设计中有两个重点,一个是分解,一个是集成。 分解最基础的,架构的重点就是要对复杂问题进行...

    一、架构思维概述

    对于架构思维本身仍然是类似系统思维,结构化思维,编程思维等诸多思维模式的一个合集。由于架构的核心作用是在业务现实世界和抽象的IT实现之间建立起一道桥梁,因此架构思维最核心的就是要理解到业务驱动技术,技术为最终的业务服务。

    要真正通过架构设计来完成业务和技术,需求和实现,软件和硬件,静态和动态,成本和收益等多方面的平衡。

    架构设计中有两个重点,一个是分解,一个是集成。

    • 分解最基础的,架构的重点就是要对复杂问题进行分而治之,同时保证分解后的各个部分还能够高内聚,松耦合,最终又集成为一个完整的整体。分解核心是定义问题,因此架构首先仍然需要理解清楚需求。
    • 集成是配合分解完成的动作,最终分解完成的各个组件或子系统,通过合适的接口设计,最终还能够集成为一个完整的整体,分解仅仅是加速开发和降低问题复杂度,如果分解后的内容无法集成在一起,那么分解就没有任何意义。

    分解+集成可以理解为架构最核心的思考方式和方法。

    在分解完成后,一个大的系统已经拆分为了诸多的小模块,或者一个小模块实现本身又分为了多个步骤阶段。那么零散的节点必须向上汇集和归纳,形成一个完整的架构。

    而这个架构的形成要给关键就是要又分层思维。架构分层是谈架构绝对绕不开的一个点,通过架构分层可以更好地全面理解业务系统或功能实现。

    二、云平台三层架构:资源-平台-应用

    在规划大架构的时候,常会参考云计算的标准三层架构,即IaaS层,PaaS层,SaaS层。

    对于IaaS层重点是IT基础设施和虚拟化;PaaS层重点是构建平台层服务能力;而对于SaaS层则是具体的应用。

    对于资源层从物理资源,再到虚拟化逻辑资源,从虚拟机到现在更加轻量的容器资源。而对于平台层原来只谈技术平台,但是当前又进一步拆分出业务平台,也可以理解成当前说得比较多的中台层。

    同时在平台层和应用层之间增加了服务层,实现资源和服务的解耦。

    如果涉及到物联网类应用,一般还会在底层增加网络层和感知层,比如一个智慧城市标准平台和应用的架构图类似如下:

     在平台+应用构建模式下,一般在平台和应用之间还会有一个单独的服务层来实现接口服务对外的能力开放。资源+服务+应用也是我们常说的SOA分层架构模式,因此对于服务层也可以单独拆分出来作为一个小分层。

    问题1:数据库和数据层

    在构建一个完整的总体架构的时候,实际上没有数据层这个概念,数据层是在表达单个应用系统的分层架构实现的时候才会出现的内容。

    在总架构图里面把类似结构化数据库,非结构化数据等全部列出单独一层这个也不对,这个应该是在技术架构里面体现。

    还有一种是单独分出一个数据层,将大的公共基础数据列出,比如上面谈的智慧城市架构图。如果这些基础数据存在共性能力朝上提供,那么可以归纳到PaaS平台层,在PaaS平台层单独分出一个数据平台域来进行体现。

    问题2:服务层和服务

    在构建整体架构的时候可以单独出一个能力开放平台或服务层,但是不用体现具体有哪些业务服务能力。因为单独出业务服务能力本质已经属于应用层内容,即应用又细化拆分为了业务中台和前台应用,中间衔接的服务。我们可以参考网上的另外一个构图,如下:

    这个构图既不像云平台中的分层架构,也不像应用功能实现中的分层架构。实际可以看到如果体现单独的支撑层,支撑层已经类似现在经常说到的业务中台和能力提供。

    那么整个架构应该为 技术平台+中台+应用 方式来进行构图。


    三、SOA分层:组件-服务-流程

    对于SOA架构分层,重点要体现的就是服务,对于组件本身是属于逻辑资源层的概念,而对于服务则是资源对外暴露的能力抽象。

    SOA架构分层重点就是要体现出独立的服务层,注意不是画服务总线,这里可以单独画出具体提供哪些业务服务能力,技术服务能力。在采用SOA架构进行开发的时候,整体业务系统拆分为4个组件,10类服务域,5类流程,那么在构建的时候重点就是将上述组件,服务域和流程类体现出来。

    对于参考SOA架构来进行的构图,参考如下:

    这里的数据层最好改为标准的组件层,更加贴近SOA架构模型。在图中的服务层已经可以看到一个个独立的API服务接口。如果服务接口数据大,一般只会划分到服务域,比如用户中心服务,采购类服务等。在这种方式下构图参考如下:

    在上图中结合了云和SOA两种架构融合在一起,对于上图中的服务层实际可以理解为组件资源层和服务接口层的融合。更好的构图方式应该是拆分为标准的中台资源层-服务层-应用层。

    四、云和SOA架构融合

    注意对于云分层架构重点强调的是基础设施,平台和应用三层架构。而对于SOA架构强调的是资源,服务和应用三层。而对于对于传统的应用系统的构建一般又包括了IT基础设施,技术平台,数据库,中间件和应用。再到应用系统本身的分层架构可能又是标准的三层架构模式等。

    这些架构分层方法都帮助我们进一步融合分层架构模式。

    架构分层有很多方法,包括基础设施层,平台层,组件层,支撑层,服务层,应用层,数据层,展现层等。多种分发导致分层模型反而出现歧义和模糊。

    在这里我们从技术架构和应用架构两个层面来谈,技术架构沿用云计算的三层模型;而对于应用架构则采用eTOM模型标准的资源,服务,应用三层模型。那么两种分层架构模型的融合则是一个完整的云和SOA融合的分层架构模型。

    即云计算的三层中,每一个层次本身又可以进一步拆分为资源,服务和应用三层。

    拿IaaS层来说,最底层的物理资源虚拟机等是属于资源层内容,通过IaaS层资源能力提供API接口作为技术服务进行能力开放,即是服务层;最终基于资源能力,构建了一个公有云的面向公众的运营服务平台,本身又属于应用层的内容。而对于SaaS层,则底层的业务组件是资源,抽象的API接口是服务层,最终的前端业务或流程是应用功能实现。


    五、应用架构分层

    回到单个应用的架构分层,谈得最多的就是常说的三层架构模式。在软件架构中,经典三层架构自顶向下由用户界面层(User Interface Layer)、业务逻辑层(Business Logic Layer)与数据访问层(Data Access Layer)组成。

    在整个实现过程中,可能还会增加独立的Facade层,或独立的API接口服务提供层,统一的DTO数据传输对象层等,但是这些都不影响整体的三层逻辑结构。

    三层架构本身也和一个业务功能实现的完整对应,在数据访问层处理数据获取和持久化操作,在业务逻辑层对业务规则进行处理,在界面展现层进行相应的前端展现和用户交互。而谈到领域建模的时候,又引入了领域模型中的分层架构,如下:

    领域驱动设计在经典三层架构的基础上做了进一步改良,在用户界面层与业务逻辑层之间引入了新的一层,即应用层(Application Layer)。同时,一些层次的命名也发生了变化。将业务逻辑层更名为领域层自然是题中应有之义,而将数据访问层更名为基础设施层(Infrastructure Layer),则突破了之前数据库管理系统的限制,扩大了这个负责封装技术复杂度的基础层次的内涵。

    5.1 领域层和业务逻辑层

    当然,也有融合了领域模型和传统三架构思路后的技术架构如下:

    在领域建模的一个核心是领域模型,领域模型不再是一个个独立的数据库表或数据对象,而是一个业务对象或领域对象。因此领域层是面向领域对象而设计实现,而业务规则能力本身也是属于领域对象对外提供的能力接口。即业务规则本身也是领域对象暴露的能力。

    传统业务逻辑层实现往往是一个数据对象对应一个DAO,一个Service和一个Interface。而领域模型下DAO可以是分开的,但是Service逻辑层往往则更多应该按领域模型思路对DAO层的能力进行组装和聚合。

    5.2 独立应用层拆分

    在我原来理解里面,领域层提供领域模型和领域服务能力接口,而应用层更多的是对领域层多个领域对象模型提供的服务能力进一步进行组装和编排,然后再暴露给前端应用。

    谈到应用层的概念,实际上可以理解为前端应用中存在的共性能力的进一步下沉。即应用本身只是用户业务功能实现的承载,但是这个功能的实现可以通过多种前端展现形式,比如传统的CS桌面应用,BS应用,或手机端APP。

    在电商里面,一个商品订购就是一个独立的应用,用户可以在APP完成,也可以在BS端完成,但是不论在哪里完成最终应用层提供的能力都应该一样。比如完成一个商品订购需要同时和底层的订单,库存,支付多个服务进行交付和协同。那么这个逻辑显然不适合同时在BS端应用和APP端应用中进行重复编写和开发。那么这个内容就应该在应用层实现。

    如果回到微服务和中台架构下,这个应用层拆分更加必要,即通过应用层来下沉共性的服务组合和组装逻辑,这个逻辑和协同不应该属于任何一个前端应用。

    5.3 界面层还是接口层

    在开发一个聚合能力的中台微服务模块的时候,可以看到这个微服务模块本身并没有界面展现层,那么该微服务的最上层仅仅是提供API接口的接口服务层。

    该API接口服务能力既可以提供给APP前端,也可以提供给BS端使用。


    六、软件技术架构分层

    软件技术架构构图,分层仍然可以沿用软件三层分层模型,重点是说明清楚各层用到的关键技术组件或技术服务能力。比如软件开发三层模型的技术架构分层如下:

    如果本身就是一个技术平台,类似大数据平台,那么我们在整体构图的时候仍然需要考虑先进行分层,再详细说明每层里面的技术内容。

    比如对应一个大数据平台,包括了大数据采集,大数据存储,大数据处理,大数据分析和应用,那么这个就是关键的分层,可以基于这个分层再来考虑各层采用的关键技术。

    对于技术栈构图基本也可以参考技术架构构图模式进行。

    技术架构重点需要回答的就是你在进行软件架构设计过程中,究竟会用到哪些关键技术,哪些开源产品或工具等。可以细化到具体的技术产品,也可以仅细化到产品类型。

    比如消息中间件,你可以细化到采用RabbitMQ,也可以在技术架构中只体现采用消息中间件。

    技术架构和软件功能分层架构唯一相同的就是分层,技术架构在各个分层里面都没有具体的业务功能点和实现内容,仅仅是关键技术点说明。


    七、单个应用功能架构

    注意应用功能架构完全是重点描述应用系统具备哪些功能,一个功能究竟是采用什么三层技术架构实现并不用关心。因此功能架构不应该体现数据层,逻辑层,技术点这些内容。

    那么对于一个应用系统的功能如何分层?

    我们可以参考业务分层分类,将业务分为基础支撑层,执行层,决策管理层。这样基本的分层模式就出来了,基于该方式可以完成一个功能架构构图。

    对于单个应用来说一般不会自身有云平台,PaaS平台这类概念。但是单个应用构建一定存在共性技术支撑平台能力,比如有自己的流程管理,各自共性技术功能组件等。因此单应用构建还可以采用基础技术支撑层+应用层+门户层的方式进行构图。

    在应用层再按具体的业务域或业务阶段进行进一步细分。

    7.1 架构图的分层构图逻辑

    在前面基本给出了不同类型的架构图的核心分层逻辑,可以看到在画架构图的时候尽量不要混合使用不同场景下的构图方式,否则就导致整体架构图混乱。

    在画整体架构的时候一般需要重点参考云三层架构,SOA三层架构的构图模式进行构图。而在细化到某一个应用系统的时候,仍然还需要分清是构建技术架构图还是功能架构图,两者本身的分层逻辑也存在很大的差别而不能混用。

    7.2 架构图的构图逻辑

    要完成一个完整的架构图构图,可以先拆分为两边+中间。两边一般是放具体的标准,规范等,比如安全管理,质量管理,技术标准规范,开发运维规范等。

    中间即是重点需要考虑进行分层构建的地方。

    在前面也谈到了中间部分重点参考云计算和SOA的架构分层逻辑。一般来说核心的还是资源层,平台层,应用层,门户层。而对于应用层本身又可以考虑业务域进一步拆分,或者根据价值链或业务生命周期拆分为多个阶段域再展开描述。

    在云和SOA下,更加强调平台+应用构建模式。

    而两者之间一般是服务层,通过SOA平台或API能力开放平台来统一接入和发布服务,以形成一个完整的资源+服务+应用的松耦合架构。同时一个完整的架构本身就是多视角的,如下:

    功能架构往往可以给具体用户和业务人员看,而对于技术架构往往更多是内部团队开发人员研讨使用。而设计到资源和平台的架构图往往又是运维工程人员进行部署架构搭建的重要参考。因此不同维度的架构分层属性本身不能随意融合使用,而导致架构图混乱。

    参考资料:

    1.微信公众号(石杉的架构笔记)-《软件架构设计分层模型和构图思考》

    展开全文
  • 软件架构设计

    千次阅读 2022-02-20 15:23:48
    系统设计是业务处理设计,而架构设计是设计一个机制和方案,让业务处理能够实现和落地。 架构设计填补了用户需求和系统设计之间的鸿沟。
  • 【网站架构】软件架构是什么?

    千次阅读 2022-01-22 14:31:31
    2.软件架构 3.开发规范 1、环境架构 首先,我们来介绍环境架构 环境架构 环境架构指的是软件运行时的环境结构 一般而言,除自身开发以外的软件或硬件都算是环境 环境是一个软件运行的前提 对于环境架构的...
  • 软考之软件架构设计

    千次阅读 2022-01-23 17:15:01
    这里写目录标题架构的本质架构的作用软件架构的概念以下叙述,(D)不是软件架构的主要作用。架构的发展历程架构的"4+1"视图UML的“4+1”视图软件架构风格软件架构风格——数据流风格【数据驱动】批处理和管道-过滤器...
  • 软件架构设计入门学习

    千次阅读 2022-02-21 12:36:07
    本文是笔者做立项时,针对产品规划的需求,梳理各种架构图的过程中学习软件架构相关知识笔记。
  • 软件架构基本概念

    千次阅读 多人点赞 2020-10-11 14:03:22
    软件架构(software architecture) 学习笔记,内容来自网络,橙色为自己总结,如有错误还请指正。 目录 软件架构(software architecture) 一、架构的定义 二、软件架构定义 三、架构的种类 逻辑架构:软件...
  • 软件架构仍在不断发展中,还没有形成一个统一的、公认的定义,这里仅举出几个较为权威的定义。 软件或计算机系统的软件架构是该系统的一个(或多个)结构,而结构由软件元素、元素的外部可见属性及它们之间的关系...
  • 经典软件架构设计模式

    千次阅读 2022-03-17 10:18:32
    分层架构模式是最常见的模式之一。分层模式背后的理念是,具有相同功能的组件将被组织成水平层。因此,每一层在应用程序中都扮演着特定的角色。 在这种模式中,我们对应用程序可以拥有的层数没有限制。在这方面,...
  • 软件架构设计---软件架构概述

    万次阅读 2018-09-17 21:25:54
    像学写文章一样,在学会字、词、句之后,就应上升到段落,...软件架构的研究内容主要涉及软件架构描述、软件架构设计、软件架构风格、软件架构评价和软件架构的形成方法等。 软件设计人员学习软件架构知识旨在站在...
  • 软件架构--MVC介绍(垂直应用架构)

    千次阅读 2022-03-06 18:56:34
    软件架构--MVC介绍(垂直应用架构)1 介绍2 示例3 优势4 缺点参考 1 介绍 MVC(视图/模型结构)把数据和视图组件分离,这使得我们可以在几个不同的试图组件中显示相同的数据,并且实现新类型的视图,并且不改变底层...
  • [软件架构] 软件系统架构 (英文版)

    热门讨论 2013-08-21 19:12:55
    [Addison-Wesley Professional] 软件系统架构 (英文版) [Addison-Wesley Professional] Software Systems Architecture Working With Stakeholders Using Viewpoints and Perspectives (E-Book) ☆ 出版信息:☆ ...
  • 嵌入式软件架构

    千次阅读 2022-02-19 16:19:27
    嵌入式软件架构一 嵌入式软件架构二 嵌入式软件架构三 1、本文通过学习嵌入式系统的分层思想结合自身工作中的经验分享以NB-IoT模块为例的分层思想,一般在系统设计中可将系统按照业务功能分为功能模块,也就是分为子...
  • 第1章 软件架构介绍  1.1 引子  1.2 架构的源起  1.3 系统架构与软件架构  1.4 软件架构的历程  1.5 软件架构的误区  1.6 软件架构生命周期 第2章 企业中的架构师  2.1 软件架构师的定义、分类和职责...
  • 软件架构模式

    2018-01-16 11:27:54
    软件架构软件架构软件架构软件架构软件架构软件架构软件架构软件架构软件架构软件架构软件架构软件架构软件架构软件架构软件架构软件架构软件架构软件架构软件架构软件架构软件架构软件架构软件架构软件架构软件架构...
  • 软件架构的发展及研究现状

    千次阅读 2022-04-11 10:55:44
    软件架构研究现状 软件架构的发展经历了单体架构、分布式架构、SOA架构、微服务架构四个阶段。 1.3.1 单体架构 Web应用程序发展的早期,大部分web工程师将所有的功能集成在一个项目工程中,所有功能打在一个war包中...
  • 解决方案与软件架构

    千次阅读 2022-03-08 19:54:34
    我观察到,经常这样的架构内容并不总是能区分解决方案和软件架构。 本文不是学术论文。在本文中,我介绍了我的经验和想法,以帮助我的同事更好地理解两个相似但不同的架构学科之间的模糊差异。至少,这篇文章可能会...
  • 1.软件架构概述 从需求分析到软件设计之间的过渡过程称为软件架构。只要软件架构设计好了,整个软件就不会出现坍塌性的错误,即不会崩溃。 架构设计就是需求分配,将满足需求的职责分配到组件上。 软件架构为软件...
  • 软考系统架构师-软件架构

    千次阅读 2019-10-18 11:49:44
    软考系统架构师考试基础之软件架构
  • 软件架构设计分层模型和构图思考

    千次阅读 2021-03-20 00:17:33
    点击上方“朱小厮的博客”,选择“设为星标”后台回复"书",获取后台回复“k8s”,可领取k8s资料今天谈下架构设计中的分层思维和分层模型以及基于分层思维下的架构构图逻辑。架...
  • 关键要点 通过创建和维护架构图来提供准确且有价值的内容并非易事。大多数情况下,我们要么创建了太多的文档,...在实践中,大多数利益相关者对详细架构图不感兴趣,但会对一两个反映系统模块和边界的高级架构图...
  • 在网上也看了很多关于架构方面的文章,林林总总,总感觉没有说的太清楚,可能是每个人的理解不一样,我自己也在繁杂的文章中总结一些架构方面的划分,记录一下。 解决方案架构:解决方案架构,顾名思义,解决方案...
  • 嵌入式软件架构设计

    千次阅读 多人点赞 2021-06-01 18:23:39
    一、前言 小生做MCU方面的开发已经很多年了,记得当初开始做项目的时候,实现功能就是我的目标,基本不会关注其它方面,功能的...而我却是一个坑踩了一次又一次,直到实在受不了了,我决定"再也不踩了",于是,软件

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 889,562
精华内容 355,824
关键字:

软件架构