软件系统的架构设计

软件系统架构(Software Architecture)是关于软件系统的结构、行为、属性、组成要素及其之间交互关系的高级抽象。任何软件开发项目,都会经历需求获取、系统分析、系统设计、编码研发、系统运维等常规阶段,软件系统架构设计就位于系统分析和系统设计之间。做好软件系统架构,可以为软件系统提供稳定可靠的体系结构支撑平台,还可以支持最大粒度的软件复用,降低开发运维成本。如何做好软件系统的架构设计呢?笔者就这一问题做如下探讨分析。

软件系统架构设计方法步骤

  基于体系架构的软件设计模型把软件过程划分为体系架构需求、设计、文档化、复审、实现和演化6个子过程,现逐一简要概述如下。

  体系架构需求。即将用户对软件系统功能、性能、界面、设计约束等方面的期望(即“需求”)进行获取、分析、加工,并将每一个需求项目抽象定义为构件(类的集合)。

  体系架构设计。即采用迭代的方法首先选择一个合适的软件体系架构风格(如C/S、B/S、N层、管道过滤器风格、C2风格等)作为架构模型,然后将需求阶段标识的构件映射到模型中,分析构件间的相互作用关系,最后形成量身订做的软件体系架构。

  体系架构文档化。即生成用户和研发人员能够阅读的体系架构规格说明书和体系架构设计说明书。

  体系架构复审。即及早发现体系架构设计中存在的缺陷和错误,及时予以标记和排除。

  体系架构实现。即设计人员开发出系统构件,按照体系架构设计规格说明书进行构件的关联、合成、组装和测试。

  体系架构演化。如果用户需求发生了变化,则需相应地修改完善优化、调整软件体系结构,以适应新的变化了的软件需求。

  以上6个子过程是软件系统架构设计的通用方法步骤。但由于软件需求、现实情况的变化是难以预测的,这6个子过程往往是螺旋式向前推进。

软件系统架构设计常用模式

  目前软件领域广泛使用的软件系统架构模式,主要有层次化架构设计、企业集成架构设计、嵌入式架构设计和面向服务的架构设计模式。

  层次化架构设计模式。分层设计是一种最为常见的架构设计方案,能有效地使系统结构清晰、设计简化。MVC模式是当今最为流行的多层设计模式。该模式把一个应用的输入、处理、输出流程进行分离并抽象为控制器(Controller)、模型(Model)、视图(View)三个模块,实现了业务逻辑层、数据库访问层和用户界面层之间在彼此分离的同时仍保持松散的耦合关系,增加了灵活性和可扩展性。我们常见的C/S架构、B/S架构、N层架构都是层次化架构设计的表现形式。

  企业集成架构设计模式。该模式不仅为企业在异构分布式环境下(操作系统、网络、数据库)的业务应用提供了一致的信息访问和交互手段,而且为各类业务应用提供了有效的通信、信息集成、应用集成、维护开发、运行管理等服务。目前最著名的企业集成架构设计包括:CORBA、COM+、J2EE、WebService等。

  嵌入式架构设计模式。该模式具备良好的可配置性、可管理性、可扩展性、时效性等性能指标。目前业界主流的嵌入式操作系统都是特定领域专用的,其中包括:WinCE、Linux、ECOS、EPOC、LynxOS、VxWorks等。

  面向服务的架构设计模式。该模式将业务应用按照一定的粒度和原则划分成为统一标准和统一格式的服务,使企业可以按照模块化的方式添加新服务或更新现有服务,有助于打破信息孤岛,促进企业系统集成、资源共享。该模式包括服务注册表模式和企业服务总线模式两类。

软件系统架构设计实践

  软件系统架构设计是一项非常复杂的工作任务。如何才能做好软件系统架构设计呢?笔者认为需要做好以下几项工作:

  树立软件系统架构的意识。设计人员不能局限在算法和数据结构上,而是要树立和不断强化软件系统整体架构的意识,学会运用多层架构的视角和观念去分析设计软件。在多层架构的实践上,通过MVC模式实现软件多层结构,层和层之间要做到职责清晰、互相独立、耦合关系松散;在模块设计原则上,要尽量体现“高内聚、低耦合”的思想。

  高度重视软件设计模式。软件设计模式是设计人员在长期开发实践中总结出来的,其他设计人员可借助这些模式加快软件设计进程,降低开发风险。所以,设计人员应高度重视设计模式思想,切勿滞留在编码的层面,应不断总结经验,积极尝试运用软件设计模式的思想去提出问题、分析问题、解决问题,提高自身开发软件的水平。

  形成自身的软件架构风格。软件系统架构设计的核心目标是实现体系架构级别的软件复用。这就需要设计人员一方面不断学习钻研不同应用领域中软件架构的惯用模式、思维、风格;另一方面要借鉴吸收先进理念,积极探索实践,最终形成自身独特的软件架构风格。

  充分了解用户需求,做好全局架构设计。要做好软件系统的架构设计,不能急于求成,首先,要全面准确地收集到用户需求,对整个系统功能形成清晰完整的认识;其次,针对整个软件系统做好全局架构设计工作,从而避免因考虑不周或片面理解带来的失误。

时间: 2024-10-05 01:50:07

软件系统的架构设计的相关文章

如何进行软件系统架构设计?

基于体系架构的软件设计模型把软件过程划分为体系架构需求.设计.文档化.复审.实现和演化6个子过程,现逐一简要概述如下. 1.体系架构需求.即将用户对软件系统功能.性能.界面.设计约束等方面的期望(即“需求”)进行获取.分析.加工,并将每一个需求项目抽象定义为构件(类的集合). 2.体系架构设计.即采用迭代的方法首先选择一个合适的软件体系架构风格(如C/S.B/S.N层.管道过滤器风格.C2风格等)作为架构模型,然后将需求阶段标识的构件映射到模型中,分析构件间的相互作用关系,最后形成量身订做的软件

架构设计实践二:需求分析

1.1 三个问题 掌握好需求分析,需要掌握三个问题的解决方式. 需求如何获得?需求开发=愿景分析+需求分析 如何判断需求全不全?功能.质量.约束三类需求 如何从需求转换为设计?功能.质量.约束对架构产生不同的影响. 1.2 软件研发与交付过程总图 其中概念化阶段一般都要完成愿景分析.风险评估.可行性分析及项目进度和成本的粗略估算,输出<愿景与范围文档>:需求分析阶段则完成需求捕获.需求分析,得到<软件需求规格说明书>,一个关键的思路是需求捕获与需求分析是迭代着进行的,完成需求捕获之

架构设计--逻辑层 vs 物理层

如果你对项目管理.系统架构有兴趣,请加微信订阅号"softjg",加入这个PM.架构师的大家庭 Layer 和Tier都是层,但是他们所表现的含义不同,Tier指的是软件系统中物理上的软件和硬件,具体指部署在某服务器上,而Layer(逻辑层)指软件系统中完成特定功能的逻辑模块,逻辑概念. Layer是逻辑上 组织代码的形式.比如逻辑分层中表现层,服务层,业务层,领域层,他们是软件功能来划分的.并不指代部署在那台具体的服务器上或者,物理位置. Tier这指代码运行部署的具体位置,是一个物

小钢的架构思考:架构设计

原创文章,转载请注明:转载自Keegan小钢并标明原文链接:http://keeganlee.me/post/architecture/20160621微信订阅号:keeganlee_me写于2016-06-21 小钢的架构思考:什么是架构小钢的架构思考:架构规划小钢的架构思考:架构设计 最近一个多月因为忙于工作上的项目重构,所以文章一直没能更新.现在,重构终于暂时告一段落,于是,赶紧抽时间把文章写完更新发布.下面进入正文. 当架构规划的结果,整理出一堆不同优先级的需求,尤其是质量需求之后,接下

恰如其分的架构设计

设计恰如其分的架构 远在2009年,Martin Fowler与Rebecca Parsons在QCon SF做了一次题为Agilists and Architects: Allies not Adversaries Presentation的演讲.演讲主要讨论了在敏捷方法中的架构活动.相似的话题,Neal Ford则提出了紧急设计的概念,并发表了名为Evelutionary Architecture and Emergent Design(演进架构与紧急设计)的系列文章.这是很棒的一个讲解演进

架构/设计

随笔分类 -架构/设计 软件架构设计模式简述 2014-03-25 20:33 by 破狼, 2465 阅读, 收藏, 编辑 在软件开发设计中我们经常会面对业务分析,提取领域问题,从而实现软件架构设计.关于 软件架构设计Martin Fowler在2004出版的<企业应用架构模式>中 概括了四种方式的架构模式.它们分别为事务性脚本,表驱动模式,活动记录模式,领域驱动设计.前两者事务性脚本,表驱动模式作为 面向过程方式架构设计,后两者为面向对象架构设计.它们适合于不同的业务场景,它们也各有长短.

MySQL性能调优与架构设计——第1章 MySQL 基本介绍

MySQL性能调优与架构设计——第1章 MySQL 基本介绍 前言:作为最为流行的开源数据库软件之一, MySQL 数据库软件已经是广为人知了. 但是为了照顾对MySQL还不熟悉的读者,这章我们将对 MySQL 做一个简单的介绍.主要内容包括MySQL 各功能模块组成,各模块协同工作原理, Query 处理的流程等. 1.1 MySQLServer 简介 1.1.1 什么是 MySQLMySQL 是由MySQL AB公司(目前已经被SUN公司收归麾下,SUN已经被Oracle收购)自主研发的,目

架构设计:系统间通信(43)——自己动手设计ESB(4)

============================== 接上文<架构设计:系统间通信(42)--自己动手设计ESB(3)> 5.Borker Server选择 在本文之前的三篇文章中,我们介绍了自行设计的ESB中间件的顶层设计.介绍了主控服务如何对多个ESB-Brokers动态节点进行日志采集和监控.还介绍了ESB-Broker节点如何进行动态路由定义的加载管理.这篇文章我们主要讨论关于ESB-Client的一些关键设计. 在我们自行设计的ESB中间件中为了保证ESB服务不会成为整个软件

(转)互联网保险O2O平台微服务架构设计

关于架构,笔者认为并不是越复杂越好,而是相反,简单就是硬道理也提现在这里.这也是微服务能够流行的原因,看看市场上曾经出现的服务架构:EJB.SCA.Dubbo等等,都比微服务先进,都比微服务功能完善,但它们都没有微服务这么深入民心,就是因为他们过于复杂.简单就是高科技,苹果手机据说专门有个团队研究如何能让用户更加简单的操作.大公司都是由小公司发展起来的,如果小公司在开始技术选型时感觉某个框架费时费力就不会选择,而小公司发展到大公司的过程,一般也伴随着系统不断优化的过程,而不断优化往往不会重新选择