ADD3.0属性驱动设计之基础

1,278 阅读12分钟

在探讨ADD属性驱动设计之前,我们需要先掌握关于架构设计得一些基础性知识和基础,对于架构有一个入门性的认识。

学属性驱动设计之前我们还是得先搞清楚架构设计是什么?

在业界中都有一些通用的说法,这些说法构成了两大理论体系。分别是软件组成理论和架构决策理论。

这里我们使用《Software Architecture in Practice》一书中的定义:

一个系统的软件架构是构成该系统所需结构的组合,他们由软件元素、元素之间的关系以及元素和关系两者的属性组成。国际化标准组织(ISO)和软件工程标准认为,系统的架构是一系列基本概念或者系统在其环境中表现出来的属性,体现在它的元素、关系及设计和发展的原则中。系统架构包括系统元素、基本系统属性、设计和发展原则三个主要方面。

1.系统元素: 架构的系统元素包括模块、组件、接口、子系统等日常开发中的内容。系统元素之间是有关系的,元素加上他们之间的关系构成的基本的系统结构。一般来说,架构师感兴趣的包括静态结构和动态结构。静态结构体现在设计时,描述系统内部设计时元素及其组合方式,动态结构则关注运行时的元素及其交互方式。

2.基本系统属性,包括功能属性和质量属性。功能属性说明系统行为属性,回答系统能做什么,另一个指外部可见的非功能性属性,比如系统的性能、可用、安全性等属性。

  1. 设计和发展原则

架构的设计与发展原则是指能够可以度量的、可测试、可跟踪的,举个例子: 比如用户的操作响应时间、用户信息的加密处理、系统的拓展性,健壮性等。

软件组成理论派往往会先关注系统的构成部分和他们之间的关系,然后逐步挖掘每个部分的细节,以便进一步确定模块、组件、接口等元素,并确保这些元素满足既定的架构设计原则。比如MVC设计模式。

架构决策

关于架构决策理论的典型提倡者是RUP,统一过程。该理论关注架构实践的主体:====人。架构决策的不仅包括软件系统的组织、元素、子系统等等,还会关注许多非功能性需求。当软件架构遇到问题时,架构师需要根据场景不断得到决策不断去解决问题。 这里暂时不深入讨论。

软件架构生命周期

软件架构师一般来说会关注以下的一些点: 架构需求、架构设计、架构分析、架构文档、架构评估、架构实现,可以看下下图:

软件架构中的一些设计

在软件架构设计中,我们需要做出决策把设计目的、需求、约束和架构方面关心的问题转化为结构,然后用这些结构指导项目。

1.架构设计

有这样的一句话,所有的架构都是设计,但不是所有的设计都是架构。如果一个决策有非局部的影响并且会影响架构驱动因子的达成,就说这个是架构的。

2.元素交互设计 3.元素内部设计。

在元素交互设计之后的第三层,就是元素内部设计,在之前设计层次发现的元素内部结构就在这个层次中创建,以满足元素的接口。

架构驱动因子

架构驱动因子,通俗来讲就是,架构考虑要做什么和为什么要这样做的因素就是架构驱动因子。

组成部分

1. 设计目的

首先需要先确定你要实现的设计目的,什么时候要实现这个设计,这时候最关心哪个业务目标。

而且设计的目的也跟设计时的几个场景有关:

1.如果软件架构的设计作为项目提案的一部分来执行,这时候的架构设计不会非常细致,设计目的是了解架构并将其分解的足够详细,来了解工作单元。 2. 如果是把软件架构设计作为创建一个探索原型过程的一部分来执行,这种情况就不是要创建一个可发布可重构的部分,而是探索新的领域,新的技术,或是发现一些质量属性(性能、可拓展性、提高可用性实现的故障转移) 3.如果是开发一个全新的系统或者是开发过程中设计你的架构,这可能是一个全新的系统、作为新系统的一个补充部分或作为现系统被重构或替换的部分。这种情况下,架构设计的目的是要用足够多的设计工作来满足需求,指导系统的建设和工作分配,准备最终的发布。

设计目的在成熟领域的绿地系统和棕地系统都可以得到不同的解释。

列出设计目的,能够帮助架构师明确实现业务目标,因为他们会影响设计的过程和设计的产出。

2. 质量属性

质量属性被定义为一个系统可测量的或者可测试的属性,用来表示系统如何很好的满足利益相关者的需求,在驱动因子中质量属性是最能使架构成形,设计软件架构时,做出的关键选择很大程度取决于系统能否满足驱动质量属性的目标。

我们可以展开质量属性研讨会,把系统最关注的一些质量属性做一个优先级排列,选出系统最关系和最主要的关注的质量属性,这些都将成为最重要的架构驱动因子。。

具体罗列出几点: 性能、可用性、可靠性、安全性

3. 主要功能

主要功能被定义为实现业务目标,促进系统开发关键的功能,有一个法则:你的用例或用户故事里大概10%可能是主要功能。

在设计一个软件时,为什么需要考虑主要功能有两个原因:

  1. 需要思考如何将功能分配到元素(通常是模块)来推进可修改性或可重用性,并计算工作任务。 2.一些质量属性场景直接与系统的主要功能相连。

4. 架构关注点

软件架构的关注点包含一些额外的方面,这些也视为架构设计的一部分,有几种不同类型的关注点:

一般关注点: 这都是一个人在创建软件架构时处理的宽泛的问题,如建立一个完整的系统结构,将功能分配到模块,将模块分配到团队,代码库的组织,启动和关闭,并支持交付、部署和更新。

具体关注点: 这些是一些更细节的系统问题,如异常管理,依赖管理,配置管理,日志记录,身份验证、授权、缓存等等。在多数应用程序都很常见,一些具体关注点可以在参考架构提到,其他的是自己系统独有的。

内部需求: 内部需求可能涉及到系统的开发、部署、运行或维护的几个方面。

问题: 这些是分析活动如涉及审查的结果,所以可能不会再最初出现。

根据之前的经验,聪明的架构师通常会注意与特定类型的系统相关的关注点和做出设计决策来处理他们的需求。架构关注点也会导致导入新的质量属性场景,例如,“支持日志记录”,需要更具体地描述,太模糊了。

5. 约束条件

需要将开发中地一些约束作为架构设计的一部分来分类,这些限制条件可能表现为强制性技术。

比如你的系统需要与之前的系统进行相互操作或者整合其他系统,必须遵守的法律和开发标准、旧版本的兼容,必须遵守的法律。。。约束是架构师很少或根本无法控制的决策。

设计概念

讨论设计概念之前,我们要明确设计不是随意的,而是有计划的、目的性的、有针对性的.设计的开始是很艰巨的,当任何设计活动开始面对空白时,各种可能性会显得非常巨大和复杂。以下是一些软件架构在十几年过程中创造并发展出来的一些能够被普遍接受的设计原则,可以参考并且进行指导设计。

例如一些详细记录的设计原则是面向实现具体质量属性的:

帮助实现高度的可修改性,目标是优秀的模块化,高内聚低耦合。 帮助实现高可用性,避免单点故障。 帮助实现可拓展性,避免关键资源的硬编码限制。 帮助实现安全性,限制对关键资源的访问。 帮助实现可测性,具体化状态。

这些原则已经在不同情况下的实践中处理了这些质量属性发展了几十年,此外也已经在设计中并最终在代码演化了这些抽象方法的实现,我们将其称为可重用实现的设计概念,他们是构成软件架构的结构的基石。

不同类型的设计概念是存在的,我们会谈论一些常用的。

参考架构、部署模式、架构模式、战术、外部开发的组件。

1.参考架构

这是一个蓝图,为特定类型的应用程序提供一个整体的逻辑结构。参考架构是一个映射到一个或多个架构模式的参考模型。

看参考图,这个参考架构创建了这类应用的主层--界面层、业务层和数据层,层内的元素类型和这些元素的职责,如UI组件、业务组件、数据访问组件此外还提供了一些需要加以解决的横向关注点,如安全和通信。

2.架构的设计模式

设计模式是概念性的解决方案,他重现一个已定义内容中存在的设计问题,设计模式起初关注的是对象规模方面的决策,包括实例化、结构化以及行为。然而现有的模式在多个粒度层中寻找决策,还有特定的模式去寻找诸如安全或者集成这类的质量属性。

下图就展示了一个架构的设计模式,这个模式有利于结构化系统,叫做分层模式,选择这样的模式时,需要决定设计的系统需要多少层。

还有一个展示了支持并发的一个模式:半同步半异步模式:

与参考体系架构相比,参考体系架构也可能被认为是模式的一种类型,一个参考体系架构通常即包含了其他模式,同时也约束着这些模式。比如上面参考架构的图,可以看到包含了分层模式,但也约束了最多设计几层。参考体系架构模式也包含了其他模式,如应用外观模式和数据访问组件模式。

3.部署模式

我们还需要考虑的一种模式类型是部署模式,这类模式对于在物理上构建系统来部署该系统提供了模型。比如

4.策略

软件架构师能够利用基础设计技术的集合,来实现对特定质量属性的响应。我们称这些架构设计为基本类型策略。

策略是会影响质量属性响应控制的设计策略。例如,如果想要设计一个低延迟或者高吞吐量的系统,可以定制一组设计决策,充当即将到来的事件(服务),产生的反应带有时间约束条件。

比起模式,策略更简单和原始,他们专注于在单个质量属性所响应的控制上。模式相比之下,更在于平衡多个力量。多个质量属性目标。

策略提供了一种自顶向下的设计思维。一个策略类别目录始于和一个质量属性完成相关的一套设计目标。并呈现给架构师选择一套以从中选择策略,随着这些选项通过一些模式组合、框架和编码,进一步被实例化。

在下图中,性能设计对象是“控制资源需求”和“管理资源”。想要创建“优秀”性能设计,软件架构师需要选择一个或者多个选项。也就是说软件架构师需要决定,控制资源的需求是否可行,管理资源是否可行。

在管理资源的范畴,软件架构师可以选择增加资源、引起并发、保留多份运算、多份数据等等,这些这些策略需要被实例化。

5.外部开发组件

我们通常会把技术作为外部开发组件。比如以下几种:

一、技术家庭组: 比如全栈开发: vue+spring+ElementUI+mybatis+springmvc

比如分布式的一套: dubbo\Spring boot、springcloud

二、应用框架

三、平台

关于架构设计决策

设计是一个做决策的过程,因此我们在面对设计时,通常会有一套备选决策,从一套决策中,选出最佳方案,然后进行实例化。

大概把以上这些关于ADD属性驱动设计的基本理念介绍完了,感兴趣的朋友可以接着看我的这篇文章,属性驱动设计的设计过程。 ADD3.0属性驱动设计总结

后面会专门出一系列关于架构设计相关的文章,慢慢的更新架构设计相关的理论和实践性知识。