浅析系统构架设计考虑

《浅析系统构架设计考虑》由会员分享，可在线阅读，更多相关《浅析系统构架设计考虑（17页珍藏版）》请在金锄头文库上搜索。

1、 系统架构设计考虑 普拉纳信息技术服务中心 http:/www.P 系统架构设计考虑 摘要摘要 本文从程序的运行时结构和源代码的组织结构两个方面探讨了系 统构架设计应考虑的各种因素，列举了系统构架设计文档应考虑的一 些问题。 关键字关键字：系统构架、设计、考虑、因素。 普拉纳信息技术服务中心 http:/ 第 I 页，共 17 页 系统架构设计考虑 目 录 摘要.I 关键字.I 第一章、与构架有关的几个基本概念 1 1.1、模块. 1 1.2、组件. 1 1.3、模式. 1 1.4、构架模式. 1 1.5、层. 2 1.6、系统分层方法. 2 1.7、构架. 2 1.8、构架的描述方式. 3

2、1.9、结构. 3 第二章、构架设计应考虑的因素概揽 4 2.1、程序的运行时结构方面的考虑. 4 2.2、源代码的组织结构方面的考虑. 4 第三章、程序的运行时结构方面的考虑 5 3.1、需求的符合性. 5 3.2、总体性能. 6 3.3、运行可管理性. 6 3.4、系统安全性. 7 3.5、系统可靠性. 7 3.6、业务流程的可调整性. 7 3.7、业务信息的可调整性. 7 3.8、使用方便性. 8 3.9、构架样式的一致性. 8 第四章、源代码的组织结构方面的考虑 9 4.1、开发可管理性. 9 4.2、可维护性. 10 4.3、可扩充性. 10 4.4、可移植性11 4.5、需求的符合

3、性11 第五章、写系统构架设计文档应考虑的问题 12 第六章、总结 13 参考文献 14 普拉纳信息技术服务中心 http:/ 第 II 页，共 17 页 系统架构设计考虑 第一章、第一章、与构架有关的几个基本概念 1.1、模块、模块 模块(module)是一组完成指定功能的语句，包括：输入、输出、逻辑处理功能、 内部信息、运行环境（与功能对应但不是一对一关系） 。 1.2、组件、组件 组件（component）是系统中相当重要的、几乎是独立的可替换部分，它在明 确定义的构架环境中实现确切的功能。 1.3、模式、模式 模式（pattern） ：指经过验证，至少适用于一种实用环境（更多时候是好几

4、种 环境）的解决方案模板（用于结构和行为。在 UML 中：模式由参数化的协作来 表示，但 UML 不直接对模式的其他方面（如使用结果列表、使用示例等，它们 可由文本来表示）进行建模。存在各种范围和抽象程度的模式，例如，构架模式、 分析模式、设计模式和代码模式或实施模式。模式将可以帮助我们抓住重点。构 架也是存在模式的。比如，对于系统结构设计，我们使用层模式；对于分布式系 统，我们使用代理模式（通过使用代理来替代实际的对象，使程序能够控制对该 对象的访问） ；对于交互系统，我们使用 MVC（M 模型(对象)V 视图(输出管理) C 控制器(输入处理)）模式。模式是针对特定问题的解，因此，我们也可

5、以针对 需求的特点采用相应的模式来设计构架。 1.4、构架模式、构架模式 构架模式（architectural pattern） ：表示软件系统的基本结构组织方案。它提供 了一组预定义的子系统、指定它们的职责，并且包括用于组织其间关系的规则和 指导。 普拉纳信息技术服务中心 http:/ 第 1 页，共 17 页 系统架构设计考虑 1.5、层、层 层（layer） ：对模型中同一抽象层次上的包进行分组的一种特定方式。通过分 层，从逻辑上将子系统划分成许多集合，而层间关系的形成要遵循一定的规则。 通过分层，可以限制子系统间的依赖关系，使系统以更松散的方式耦合，从而更 易于维护。 （层是对构架的横

6、向划分，分区是对构架的纵向划分） 。 1.6、系统分层方法、系统分层方法 1） 常用三层服务：用户层、业务逻辑层、数据层； 2） 多层结构的技术组成模型：表现层、中间层、数据层； 3） 网络系统常用三层结构：核心层、汇聚层和接入层； 4） RUP 典型分层方法：应用层、专业业务层、中间件层、系统软件层； 5） 基于 Java 的 B/S 模式系统结构：浏览器端、服务器端、请求接收层、请 求处理层； 6） 某六层结构：功能层（用户界面） 、模块层、组装层（软件总线） 、服务 层（数据处理） 、数据层、核心层； 1.7、构架、构架 构架 （Architecture） ， 愿意为建筑学设计和建筑物建

7、造的艺术与科学） : 在 RUP 中的定义：软件系统的构架（在某一给定点）是指系统重要构件的组织或结构， 这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互； 软件构 架实践中的定义：某个软件或者计算系统的软件构架即组成该系统的一个或者 多个结构，他们组成软件的各个部分，形成这些组件的外部可见属性及相互间的 联系；IEEE 1471-2000 中的定义：the fundamental organization of a system emboided in its components,their relationships to each other,and to the env

8、iroment and the principles guiding its design and evolution，构架是系统在其所处环境中的最高层次 的概念。软件系统的构架是通过接口交互的重要构件（在特定时间点）的组织或 结构，这些构件又由一些更小的构件和接口组成。 （ “构架”可以作为名词，也可 作为动词，作为动词的“构架”相当于“构架设计” ） 。 普拉纳信息技术服务中心 http:/ 第 2 页，共 17 页 系统架构设计考虑 1.8、构架的描述方式、构架的描述方式 “41”视图（用例视图、设计视图、实现视图、过程视图、配置视图）是 一个被广为使用的构架描述的模型；RUP 过程的构

9、架描述模板在“41”视图的 基础上增加了可选的数据视图（从永久性数据存储方面来对系统进行说明） ；HP 公司的软件描述模板也是基于“41”视图。 1.9、结构、结构 软件构架是多种结构的体现，结构是系统构架从不同角度观察所产生的视图。 就像建筑物的结构会随着观察动机和出发点的不同而有多种含义一样，软件构架 也表现为多种结构。常见的软件结构有：模块结构、逻辑或概念结构、进程或协 调结构、物理结构、使用结构、调用结构、数据流、控制流、类结构等等。 普拉纳信息技术服务中心 http:/ 第 3 页，共 17 页 系统架构设计考虑 第二章、构架设计应考虑的因素概揽第二章、构架设计应考虑的因素概揽 模块

10、构架设计可以从程序的运行时结构和源代码的组织结构方面考虑。 2.1、程序的运行时结构方面的考虑、程序的运行时结构方面的考虑 1） 需求的符合性：正确性、完整性；功能性需求、非功能性需求； 2） 总体性能（内存管理、数据库组织和内容、非数据库信息、任务并行性、 网络多人操作、关键算法、与网络、硬件和其他系统接口对性能的影响） ； 3） 运行可管理性：便于控制系统运行、监视系统状态、错误处理；模块间 通信的简单性；与可维护性不同； 4） 与其他系统接口兼容性； 5） 与网络、硬件接口兼容性及性能； 6） 系统安全性； 7） 系统可靠性； 8） 业务流程的可调整性； 9） 业务信息的可调整性 10）

11、 使用方便性 11） 构架样式的一致性 注：运行时负载均衡可以从系统性能、系统可靠性方面考虑。 2.2、源代码的组织结构方面的考虑、源代码的组织结构方面的考虑 1） 开发可管理性：便于人员分工（模块独立性、开发工作的负载均衡、进 度安排优化、预防人员流动对开发的影响） 、利于配置管理、大小的合理性与适度 复杂性； 2） 可维护性：与运行可管理性不同； 3） 可扩充性：系统方案的升级、扩容、扩充性能； 4） 可移植性：不同客户端、应用服务器、数据库管理系统； 5） 需求的符合性（源代码的组织结构方面的考虑） 普拉纳信息技术服务中心 http:/ 第 4 页，共 17 页 系统架构设计考虑 第三章

12、、程序的运行时结构方面的考虑第三章、程序的运行时结构方面的考虑 3.1、需求的符合性、需求的符合性 正确性、完整性；功能性需求、非功能性需求软件项目最主要的目标是满足 客户需求。在进行构架设计的时候，大家考虑更多的是使用哪个运行平 台、编成 语言、开发环境、数据库管理系统等问题，对于和客户需求相关的问题考虑不足、 不够系统。如果无论怎么好的构架都无法满足客户明确的某个功能性需求 或非功 能性需求，就应该与客户协调在项目范围和需求规格说明书中删除这一需求。否 则， 架构设计应以满足客户所有明确需求为最基本目标， 尽量满足其隐含的需 求。 （客户的非功能性需求可能包括接口、系统安全性、可靠性、移植

13、性、扩展性等 等，在其他小节中细述） 。 一般来说，功能需求决定业务构 架、非功能需求决定技术构架，变化案例决 定构架的范围。需求方面的知识告诉我们，功能需求定义了软件能够做些什么。 我们需要根据业务上的需求来设计业务构 架，以使得未来的软件能够满足客户的 需要。非功能需求定义了一些性能、效率上的一些约束、规则。而我们的技术构 架要能够满足这些约束和规则。变化案例是对 未来可能发生的变化的一个估计， 结合功能需求和非功能需求，我们就可以确定一个需求的范围，进而确定一个构 架的范围。 这里讲一个前几年因客户某些需求错误造成构架设计问题而引起系统性能和 可靠性问题的小小的例子：此系统的需求本身是比

14、较简单的，就是将某城市的某 业务的 全部历史档案卡片扫描存储起来，以便可以按照姓名进行查询。需求阶段 客户说卡片大约有 20 万张，需求调研者出于对客户的信任没有对数据的总量进行 查证。由 于是中小型数据量，并且今后数据不会增加，经过计算 20 万张卡片总 体容量之后，决定使用一种可以单机使用也可以联网的中小型数据库管理系统。 等到系统完成 开始录入数据时，才发现数据至少有 60 万，这样使用那种中小型 数据库管理系统不但会造成系统性能的问题，而且其可靠性是非常脆弱的，不得 不对系统进行重新 设计。从这个小小的教训可以看出，需求阶段不仅对客户的功 普拉纳信息技术服务中心 http:/ 第 5

15、页，共 17 页 系统架构设计考虑 能需求要调查清楚，对于一些隐含非功能需求的一些数据也应当调查清楚，并作 为构架设计的依据。 对于功能需求的正确性，在构架设计文档中可能不好验证（需要人工、费力） 。 对于功能需求完整性，就应当使用需求功能与对应模块对照表来跟踪追溯。对于 非功能需求正确性和完整性，可以使用需求非功能与对应设计策略对照表来跟踪 追溯评估。 “软件设计工作只有基于用户需求，立足于可行的技术才有可能成功。” 3.2、总体性能、总体性能 性能其实也是客户需求的一部分，当然可能是明确的，也有很多是隐含的， 这里把它单独列出来在说明一次。性能是设计方案的重要标准，性能应考虑的不 是单台客户端的性能，而是应该考虑系统总的综合性能； 性能设计应从以下几个方面考虑：内存管理、数据库组织和内容、非数据库 信息、任务并行性、网络多人操作、关键算法、与网络、硬件和其他系统接口对 性能的影响； 几点提示：算法优化及负载均衡是性能优化的方向。经常要调用的模块要特 别注意优化。占用内存较多的变量在不用时要及时清理掉。需要下载的网页主题 文件过大时应当分解为若干部分，让用户先把主要部分显示出来。 3.3、运行可管理性、运行可管理性 系统的构架设计应当为了使系统可以预测系统故障，防患于未然。现在的系 统正逐步向复杂化、大型化发展，单靠一个人或几个人来管理已显得