系统架构设计(一)

软件系统的架构

软件系统的架构

构架设计

模块构架设计可以从程序的运行时结构和源代码的组织结构方面考虑

 程序的运行时结构

运行时负载均衡可以从系统性能、系统可靠性方面考虑。

  需求的符合性

正确性、完整性；功能性需求、非功能性需求

  总体性能

内存管理、数据库组织和内容、非数据库信息、任务并行性、网络多人操作、关键算法、与网络、硬件和其他系统接口对性能的影响

 

性能其实也是客户需求的一部分，当然可能是明确的，也有很多是隐含的，这里把它单独列出来在说明一次。性能是设计方案的重要标准，性能应考虑的不是单台客户端的性能，而是应该考虑系统总的综合性能；

性能设计应从以下几个方面考虑：内存管理、数据库组织和内容、非数据库信息、任务并行性、网络多人操作、关键算法、与网络、硬件和其他系统接口对性能的影响；

几点提示：算法优化及负载均衡是性能优化的方向。经常要调用的模块要特别注意优化。占用内存较多的变量在不用时要及时清理掉。需要下载的网页主题文件过大时应当分解为若干部分，让用户先把主要部分显示出来

  运行可管理性

便于控制系统运行、监视系统状态、错误处理；模块间通信的简单性；与可维护性不同

 

合理的系统构架规划系统运行资源，便于控制系统运行、监视系统状态、进行有效的错误处理；为了实现上述目标，模块间通信应当尽可能简单，同时建立合理详尽的系统运行日志，系统通过自动审计运行日志，了解系统运行状态、进行有效的错误处理

  与其他系统接口兼容性

  与网络、硬件接口兼容性及性能

  系统安全性,可靠性

  业务流程的可调整性

  业务信息的可调整性

  方便性

  构架样式的一致性

 源代码的组织结构

  开发可管理性

   模块独立性、层次性

   开发工作的负载均衡

   进度安排优化

   预防员工人员流动对开发的影响

   配置管理（独立性、层次性）

   大小合理性与适度复杂性

   可维护性

便于在系统出现故障时及时方便地找到产生故障的原因和源代码位置，并能方便地进行局部修改、切割；（可维护性与运行可管理性不同）

  可扩充性

：系统方案的升级、扩容、扩充性能

系统在建成后会有一段很长的运行周期，在该周期内，应用在不断增加，应用的层次在不断升级，因此采用的构架设计等方案因充分考虑升级、扩容、扩充的可行性和便利

  可移植性

不同客户端、应用服务器、数据库管理系统

 系统架构设计文档

成功构架的一个重要特色，在于标明最可能变更的领域，应当列出程序中最可能变更的部分，说明构架的其他部分如何应变

 

构架应重点考虑对于细节全面影响的设计决策，深入这些决策领域：外部软件接口（兼容性、通信方式、传递数据结构）、用户接口（用户接口和系统层次划分）、数据库组织和内容、非数据库信息、关键算法、内存管理（配置策略）、并行性、安全性、可移植性、网络多人操作、错误处理。

要保证需求的可追踪性，即保证每个需求功能都有相应模块去实现。

 方法学

  目标

   重用

   透明

   高效

   安全

  规则

为了达到上述的目的，我们通常需要对架构设计制定一些简单的规则

  功能分解

  解耦(根据实际情况决定不同类间的耦合度)

  够用就好

  应用模式

  抽象

抽象：业务抽象和技术抽象。架构是现实世界的一个模型，所以我们首先需要对现实世界有一个很深的了解，然后我们还要能够熟练的应用技术来实现现实世界到模型的映射

  架构设计的过程模式

  敏捷方法

敏捷代表着有效和灵活;较低的管理成本和高质量的产出

  简单设计

  迭代设计

   单次的迭代

   迭代的交错

   迭代频率

  组合使用模式

  架构愿景

架构愿景的形成的源头是需求，需要特别指出的是，这里的需求主要是那些针对系统基本面的需求。比如说，系统的特点是一个交互式系统，还是一个分布式系统。这些需求将会影响到架构愿景的设计。在收集影响架构愿景的各项需求之后，按照需求的重要性来设计架构愿景。

架构愿景的设计并不需要很复杂的过程，也不需要花费很多的时间。我们已经提过，架构远景的主要目的就是为了能够在开发团队中传播设计思路，因此，架构愿景包括基本的设计思路和基本的设计原则。

元件（Architecture Component）

联结器（Connector）

任务流（Task-flow）

基本概念

一组完成指定功能的语句，包括：输入、输出、逻辑处理功能、内部信息、运行环境（与功能对应但不是一对一关系）

组件

系统中相当重要的、几乎是独立的可替换部分，它在明确定义的构架环境中实现确切的功能。

模式

构架模式、分析模式、设计模式和代码模式或实施模式

构架模式

表示软件系统的基本结构组织方案。它提供了一组预定义的子系统、指定它们的职责，并且包括用于组织其间关系的规则和指导。常见的软件结构有：模块结构、逻辑或概念结构、进程或协调结构、物理结构、使用结构、调用结构、数据流、控制流、类结构等等

层

对模型中同一抽象层次上的包进行分组的一种特定方式。通过分层，从逻辑上将子系统划分成许多集合，而层间关系的形成要遵循一定的规则。通过分层，可以限制子系统间的依赖关系，使系统以更松散的方式耦合，从而更易于维护。（层是对构架的横向划分，分区是对构架的纵向划分）

 常用三层服务(用户层、业务逻辑层、数据层)

 多层结构的技术组成模型(表现层、中间层、数据层)

 网络系统常用三层结构(核心层、汇聚层和接入层)

 RUP典型分层方法(应用层、专业业务层、中间件层、系统软件层)

 基于Java的B/S模式系统结构(浏览器端、服务器端、请求接收层、请求处理层),(功能层（用户界面）、模块层、组装层（软件总线）、服务层（数据处理）、数据层、核心层)

自由主题

转载于:https://www.cnblogs.com/tx720/p/7677382.html