软件架构与设计简介
系统的架构描述了它的主要组件、它们的关系(结构)以及它们如何相互作用。软件架构和设计包括几个影响因素,例如业务策略、质量属性、人员动态、设计和 IT 环境。
我们可以将软件架构和设计分为两个不同的阶段:软件架构和软件设计。在架构中,非功能性决策是由功能性需求决定和分离的。在设计中,功能需求得以实现。
软件架构
架构充当系统的蓝图。它提供了一个抽象来管理系统复杂性并在组件之间建立通信和协调机制。
它定义了一个结构化解决方案,以满足所有技术和操作要求,同时优化性能和安全性等常见质量属性。
此外,它还涉及与软件开发相关的组织的一系列重要决策,其中每个决策都可能对最终产品的质量、可维护性、性能和整体成功产生相当大的影响。这些决定包括 -
选择组成系统的结构元素及其接口。
这些元素之间的协作中指定的Behave。
将这些结构和Behave元素组合成大型子系统。
架构决策与业务目标保持一致。
架构风格指导组织。
软件设计
软件设计提供了一个设计计划,该计划描述了系统的元素、它们如何配合以及如何协同工作来满足系统的要求。制定设计计划的目标如下:
与客户、营销和管理人员协商系统要求并设定期望。
在开发过程中充当蓝图。
指导实施任务,包括详细设计、编码、集成和测试。
它发生在详细设计、编码、集成和测试之前,领域分析、需求分析和风险分析之后。
建筑的目标
架构的主要目标是确定影响应用程序结构的需求。精心设计的架构可以降低与构建技术解决方案相关的业务风险,并在业务和技术需求之间架起一座桥梁。
一些其他目标如下 -
暴露系统的结构,但隐藏其实现细节。
实现所有用例和场景。
尝试满足不同利益相关者的要求。
处理功能和质量要求。
减少所有权目标并提高组织的市场地位。
提高系统提供的质量和功能。
提高外部对组织或系统的信心。
局限性
软件架构仍然是软件工程中的一个新兴学科。它有以下限制 -
缺乏表示架构的工具和标准化方法。
缺乏分析方法来预测架构是否会产生满足要求的实现。
缺乏对架构设计对软件开发重要性的认识。
对软件架构师的角色缺乏了解,利益相关者之间的沟通不畅。
缺乏对设计流程的了解、设计经验和设计评价。
软件架构师的角色
软件架构师提供技术团队可以为整个应用程序创建和设计的解决方案。软件架构师应具备以下领域的专业知识 -
设计专长
软件设计专家,包括面向对象设计、事件驱动设计等多种方法和途径。
领导开发团队并协调开发工作以确保设计的完整性。
应该能够审查设计方案和它们之间的权衡。
领域专业知识
正在开发的系统和软件发展规划方面的专家。
协助需求调查过程,确保完整性和一致性。
协调正在开发的系统的领域模型的定义。
技术专长
有助于系统实施的可用技术专家。
协调编程语言、框架、平台、数据库等的选择。
方法论专业知识
SDLC(软件开发生命周期)期间可能采用的软件开发方法方面的专家。
选择对整个团队有帮助的适当的开发方法。
软件架构师的隐藏角色
促进团队成员之间的技术工作并加强团队中的信任关系。
分享知识并拥有丰富经验的信息专家。
保护团队成员免受外部力量的影响,这些外部力量会分散他们的注意力并给项目带来更少的价值。
建筑师的交付成果
一套清晰、完整、一致且可实现的功能目标
系统的功能描述,至少有两层分解
系统的概念
系统形式的设计,至少有两层分解
时间安排、操作员属性以及实施和操作计划的概念
确保遵循功能分解并控制接口形式的文档或流程
质量属性
质量是对卓越性或没有缺陷或缺陷的状态的衡量。质量属性是独立于系统功能的系统属性。
实施质量属性可以更轻松地区分好系统和坏系统。属性是影响运行时Behave、系统设计和用户体验的总体因素。
它们可以分类为 -
静态质量属性
反映系统和组织的结构,与架构、设计和源代码直接相关。它们对最终用户来说是不可见的,但会影响开发和维护成本,例如:模块化、可测试性、可维护性等。
动态质量属性
反映系统在执行过程中的Behave。它们与系统的架构、设计、源代码、配置、部署参数、环境和平台直接相关。
它们对最终用户可见并在运行时存在,例如吞吐量、鲁棒性、可扩展性等。
质量场景
质量场景指定如何防止故障变成故障。根据其属性规格,它们可以分为六个部分 -
源- 产生刺激的内部或外部实体,例如人员、硬件、软件或物理基础设施。
刺激- 当它到达系统时需要考虑的条件。
环境- 刺激发生在某些条件下。
工件- 整个系统或其中的某些部分,例如处理器、通信通道、持久存储、进程等。
响应- 刺激到达后进行的活动,例如检测故障、从故障中恢复、禁用事件源等。
响应措施- 应测量发生的响应,以便测试需求。
通用质量属性
下表列出了软件架构必须具有的常见质量属性 -
类别 | 质量属性 | 描述 |
---|---|---|
设计品质 | 概念完整性 | 定义整体设计的一致性和连贯性。这包括组件或模块的设计方式。 |
可维护性 | 系统能够在一定程度上轻松地进行更改。 | |
可重复使用性 | 定义组件和子系统适合在其他应用程序中使用的功能。 | |
运行时质量 | 互操作性 | 一个系统或不同系统通过与外部方编写和运行的其他外部系统进行通信和交换信息来成功运行的能力。 |
可管理性 | 定义系统管理员管理应用程序的难易程度。 | |
可靠性 | 系统随着时间的推移保持运行的能力。 | |
可扩展性 | 系统在不影响系统性能的情况下处理负载增加的能力或易于扩展的能力。 | |
安全 | 系统防止超出设计用途的恶意或意外操作的能力。 | |
表现 | 指示系统在给定时间间隔内执行任何操作的响应能力。 | |
可用性 | 定义系统正常运行的时间比例。它可以以预定义时间段内总系统停机时间的百分比来衡量。 | |
系统质量 | 支持性 | 系统在无法正常工作时提供有助于识别和解决问题的信息的能力。 |
可测试性 | 衡量为系统及其组件创建测试标准的难易程度。 | |
用户素质 | 可用性 | 定义应用程序通过直观满足用户和消费者需求的程度。 |
建筑质量 | 正确性 | 满足系统所有要求的责任。 |
非运行时质量 | 可移植性 | 系统在不同计算环境下运行的能力。 |
完整性 | 能够使单独开发的系统组件正确地协同工作。 | |
可修改性 | 每个软件系统都可以轻松地适应其软件的更改。 | |
业务质量属性 | 成本和时间表 | 系统成本与上市时间、预期项目寿命和遗留资源的利用有关。 |
适销性 | 使用与市场竞争相关的系统。 |