`
lvwenwen
  • 浏览: 926294 次
  • 性别: Icon_minigender_1
  • 来自: 魔都
社区版块
存档分类
最新评论

如何进行软件架构设计?

阅读更多

软件架构设计的目的
对于外包业务类型的项目,软件架构设计的目的与产品类型的项目有所不同,在这里主要讨论外包类型项目的软件架构设计目的。
1、为大规模开发提供基础和规范,并提供可重用的资产,软件系统的大规模开发,必须要有一定的基础和遵循一定的规范,这既是软件工程本身的要求,也是客户的要求。架构设计的过程中可以将一些公共部分抽象提取出来,形成公共类和工具类,以达到重用的目的。
2、一定程度上缩短项目的周期,利用软件架构提供的框架或重用组件,缩短项目开发的周期。
3、降低开发和维护的成本,大量的重用和抽象,可以提取出一些开发人员不用关心的公共部分,这样便可以使开发人员仅仅关注于业务逻辑的实现,从而减少了很多工作量,提高了开发效率。
4、提高产品的质量,好的软件架构设计是产品质量的保证,特别是对于客户常常提出的非功能性需求的满足。
软件架构设计的原则
软件架构设计必须遵循以下原则:
1、满足功能性需求和非功能需求。这是一个软件系统最基本的要求,也是架构设计时应该遵循的最基本的原则。
2、实用性原则,就像每一个软件系统交付给用户使用时必须实用,能解决用户的问题一样,架构设计也必须实用,否则就会“高来高去”或“过度设计”。
3、满足复用的要求,最大程度的提高开发人员的工作效率。
软件架构设计的几种视图
我们常常在讨论架构设计该做些什么的时候,或是在架构设计评审的会议上,会提出各种各样的问题,例如开发人员该如何记录Log,事务如何控制?怎样才能提高我们的开发人员的工作效率,即在单位时间内更有品质的完成更多的功能?怎样满足客户的非功能性需求?怎样让生产环境的平台管理人员更好的维护系统?
上面这些问题,实际上是软件系统的不同的干系人站在不同的角度上提出的问题,要回答上面这些问题,我们就得从不同的视角来看待软件架构设计这项工作。
1、逻辑架构视角,从系统用户的角度考虑问题,设计出来的软件架构能够满足业务逻辑的需求,能够处理现在越来越复杂的业务逻辑需求。
2、开发架构视角,从系统开发人员的角度来考虑问题,设计的架构要易于理解,易于开发,易于单元测试,最好做到让开发人员可以用最少的代码行数完成功能的开发。
3、运行架构视角,从系统运行时的质量需求考虑问题,特别关注于系统的非功能需求,客户常常都会要求我们系统的功能画面的最长响应时间不超过4秒,能满足2000个用户同时在线使用,基于角色的系统资源的安全控制等。
4、物理架构视角,关注系统安装和部署在什么样的环境上,例如现在最流行的企业应用服务解决方案IBM Http Server + WebSphere Application Server + DB2,WebLogic + Oracle等。
5、数据架构视角,如今我们开发的各类系统,如MIS,ERP,SAP,基本上都是对各类数据的操作,把一堆不太好懂的数据展现成用户容易看懂的数据,自动处理各类数据的运算等,所以数据的持久化是十分重要的一件事情。
1
1、分析需求和理解业务模型(或领域建模),并选定关键Use case。
软件的需求,可以分为从用户视角和开发人员视角来看,从用户的角度看,又可以分为功能性和非功能性需求,我们必须从不同的视角和级别去全面的认识需求并分析需求,理解业务模型。实践表明,常常被我们忽视的非功能性需求常常会导致整个项目失败。
理解业务需求最好的方式莫过于进行领域建模,领域建模与需求分析往往是交替穿叉进行的,领域建模主要有以下三个方面的作用:
◆探索复杂问题,弄清领域知识。Martin Fowler曾经说过,他采用面向对象方法最大的好处就是它有助于解决更为复杂的问题。领域建模本身作为辅助思维的工具,帮助我们将注意力始终保持在最为重要的业务概念及其关系上,使我们能够不断深入地,系统的对需求进行分析和认识。领域建模往往是一个从模糊到清晰,从零散到系统的过程。
◆决定功能范围,影响可扩展性。任何模型都是对现实世界某种程序的抽象,这种抽象就会忽略某一些东西,例如忽略对象的属性和对象间的关系,而这些忽略往往都是带有一定的目的性的,这种忽略就决定了功能的范围。模型揭示了各种功能背后的结构,如果说定义功能相当于“拍照片”的话,那么领域建模就相当于“做透视”,更加关注问题领域的内在结构,相当于对问题领域进行了一定的抽象,良好的领域模型不仅能很好的支持现有的功能,而且还可以在一定程度上支持未来可能出现的新需求,体现良好的可扩展性。
◆提供交流基础,促进有效沟通。领域建模通常会使用UML图作为呈现的方式,这样为我们的沟通提供了方便。当然,有时候文字在描述某些特定领域的问题时可能更适合,可以灵活运用。
在我们公司的实际软件开发流程中,往往领域建模缺少这一环节,这可能是在以后的工作中需要进一步提高之处。
虽然我们总是期望架构设计师能全面掌握需求,但由于时间和精力的限制,摆在我们面前的现实就是架构设计师没有时间对所有需求进行深入分析,所以我们的策略就是“把好钢用在刀刃上”,即把大部分时间和精力花在对决定架构最重要的关键需求上。在选择关键需求时要注意:高优先级的需求往往是从用户的角度来看的,可能并不是真正的关键需求。在《RUP实践者指南》一书中向我们讲述了如何确定关键功能需求?A.作为应用程序的核心或实现了系统的主要接口的功能,B.必须被实现的功能,即如果这些功能不被实现,则开发出来的软件就失去了价值,C.覆盖了系统架构的一些方面,但没有被其他重要的Use case覆盖到的功能。
2、分别从各个视角来考虑软件架构的方方面面。
软件的架构设计必须考虑到各方面,根据前期工作确立的领域模型,关键需求,系统约束等进行设计,必须从系统用户,开发人员,系统管理员,部署管理员,数据管理员等人员的角度去分析并解决问题。比如说,如果我们的运行架构采用Cluster方式时,就必须小心Cache和Session等的使用;如果我们的业务逻辑要求我们要操作多个数据库时,就要考虑采用支持二阶段事务提交的方式。
只有将这些方方面面的问题都考虑到了,这样的架构设计才是完整的。至于每一个视图中,我们应该设计到什么细节这一问题,实际上与整个项目的过程定义有关。例如,如果我们有专门安排数据库概要设计的活动,那我们在架构设计的过程中就可以只需要关注更高层次的数据库特性及数据库之间的关系,而每一张表的数据字典可以在后续的相关活动中进行设计,但如果没有这样的活动,那我们就要细化到每一张表的每一个栏位,以及表之间的关系。
3、解决技术面的重点问题和难题
在软件架构设计的过程中,我们往往会需要攻克一些技术面的重点问题和难题,这完全是一项极其需要扎实的理论知识和丰富的实践经验支撑的工作。例如,我们如何提高整个系统的性能?如何能很好的导出极其复杂的“中国式报表”(一般比西方国家产出的报表要复杂很多,而且很多开源的BI类的框架并不能完全解决问题)?
当遇到确实是很困难的问题,可以去百度一下或Google一下,也可以去请教公司的资深技术人员或专家,或者召开小范围的技术专题讨论会议,采用脑力激荡的方法试着找找答案,这样才能提高工作的效率。
4、召开架构设计评审会议进行同行评审。
架构设计评审是极其重要的一环,我曾将其形容为“七种武器”中的离别钩,就是因为在会议上,同行们可能会提很多问题或意见,而且很多意见很尖锐,所以一定要虚心接受,并做好记录,正所谓“良药苦口利于病,忠言逆耳利于行”。
在评审会议之前,我们要完成很多准备工作,最好是能准备一份简明扼要的电子简报,把最重要的问题列出来,这样在进行评审会议时,就不会漫无目的,在会议前就将这些资料发给与会人员,请他们抽空先了解一下,在会议进行时,要学会控制会议的进度,提高会议的效率。
5、针对关键Use case在设计的架构上实现功能来验证架构。
对于架构设计的验证也是一项十分重要的工作,其验证技术有很多种,在我们公司通常会采用Sample的形式,即XP中所说的迭代0,RUP中所说的切片。这样做的好处是既可以从实际的产品角度出发来有效的验证架构是否满足要求,又可以比抛弃型原型验证技术节省成本。
这个Sample绝不是我们在解决架构设计中的问题时拿来做实验的一些代码的拼凑,而是完整的实现某一关键Use case的符合架构设计和一系列规范的可交付的代码及相关文档。同时,这个Sample可以作为你在给大家讲解或培训架构时的教材,也可以作为开发人员使用此架构进行开发的蓝本,甚至是只需要复制粘贴,加上简单的修改即可。
6、交付给客户Review。
这一环节,在很多公司可能并不存在,因为他们的软件架构并不一定需要客户Review,但像我们这种做服务的公司,最重要的就是客尊,落实到软件架构设计这一活动,就是让客户理解并接受你的架构设计方案,同时,客户也会起到帮你验证架构的作用。通常,我们的架构得到客户的认可后,便可进入大规模的开发。
在交付给客户Review时,通常可能会以会议的形式进行Review,所以我们可以参照评审会议时好的做法来召开会议,在这里就不再冗述。
1
软件架构设计的常见误区及解决办法
1、架构设计的常常会“高来高去”。所谓高来高去,实际上就是我们的架构设计仅停留在模型阶段,但也绝不是产生第一支样例程式。
2、架构设计时常常会在某些方面过度设计(Over engineering)。为了一些根本不会发生的变化而进行一系列复杂的设计,这样的设计就叫过度设计,往往会带来资源的浪费并且会增加开发的工作量或难度。虽然我们必须考虑到系统的扩展性,可维护性等,但切忌过度设计。有时候或许你并不能判断出哪些设计是过度设计,此时你可以请教你的PM,让他站在整个项目的高度来帮你决策一下。
3、架构(Architecture)不是框架(Framework),也不是简单的将几种框架或技术的组合,框架本身也是有架构的。框架一般是针对于某一方面或领域的重用性和可扩展性非常好的半成品,我们可以用一句较为经典的话来总结:框架是软件,架构不是软件,框架是一种特殊的软件。我们在工作中通过将许多方面的可重用的工具类,公共类,基础类等抽象出来,即可形成一些可重用的框架。
4、架构设计绝不是新技术展示平台,合适的技术才是对于项目有利的技术,必须考虑到开发人员的能力和维护人员的能力。作为一名架构设计师应该更多的考虑如何平衡业务需求,织织运作(主要指团队中的协作)和技术三者的关系,而不仅仅是去关注那些技术细节。
5、架构设计的成功与否决定着系统品质的好坏,因为架构设计不好而导致交付的系统Bug过多,无法满足客户非功能性需求等问题,从而导致项目取消的案例时有发生。架构设计不是架构设计师一个人的事情,也不是几天就能完成的一项工作,必须是架构设计师付出大量辛勤劳动后的成果,其成败往往与组织、主管、项目经理的支持有着密切的关系。
关于架构设计的一点通用技巧
1、分层(Layer)规则。这里的层是指逻辑上的层次(Layer),并非指物理上的层次(Tier)。目前的绝大多数的企业级应用系统中都分为三层,即表现层,领域层和数据层。在对各层次进行划分时,主要可以从以下几个方面来考虑:A、每一层是一个相对独立的部分,可以作为一个整体,无需对其它层了解;B、将层次间的依赖性降到最低,即降低耦合;C、可以从某种程度上替换掉某一层,而对其它层不会产生过多的影响;D,层次并不能封闭所有的东西,假如用户界面上增加了一个栏位,那么领域层就要增加一个数据域,数据层就要增加一个相应的字段。同时,过多的分层可能会对性能造成一定的影响。
2、包(package)之间不要产生循环依赖。通常包的划分会先按不同的逻辑层来划分,在层的包下面再按功能来划分。避免包间的循环依赖是一个比较通用的规则,这样的规则一定有其存在的价值和道理,之所以这样主要是出于以下原因:A、循环依赖会使分层失去意义;B、循环依赖会带来许多潜在的风险,如可能会产生嵌套事务(nested transaction,JavaEE标准中并不支持这种事务)的现象,我就曾遇到过这样的问题,在一个项目中,事务放在业务逻辑层统一控制,但由于开发人员忽视了架构中这样的原则,在持久层调用了展现层的公用类,形成了回圈的现象,导致了嵌套事务的发生。
3、设计模式的应用。在很多人的观念里,提供设计模式就等同于GOF的设计模式,其实设计模式是个广泛的概念,比如需求模式、领域模式、反模式等都属于设计模式。模式其实是一门工具,是人们对于过去解决某一类问题的经验总结,所以我们可以在设计活动中应用各种设计模式,但是在应用这些模式之前一定要先分析清楚问题,否则就可能出现“牛头不对马嘴”的现象。
成功的项目总有相似之处,失败的项目却各有各的失败之处。好的软件架构设计必定是成功项目的相似之处,我们有什么理由不把软件架构设计做好了?

出自:http://www.cnblogs.com/kongzheng/articles/1370165.html
分享到:
评论

相关推荐

    产品技术开发项目-软件架构设计模板

    目的:软件架构设计,可以帮我们直观的熟悉整个架构的设计和拓展实现。 本文档作为产品的架构设计说明书,对系统整体进行了架构设计,指导后续的设计与开发。并为网站后续版本的架构参考。 本文内容面向产品经理,...

    嵌入式系统软件架构设计.pdf

    比较全面的阐述嵌入式系统软件架构设计的资料,pdf版本,文字版,完整无广告。 本课程是针对嵌入式软件开发的特点,讨论架构设计的思路和方法。试图给大家提供一种思想,启发大家的思维。框架,自动化代码生成和...

    如何进行软件架构设计

    如何进行软件架构设计

    《软件架构设计》

    《软件架构设计》《软件架构设计》《软件架构设计》《软件架构设计》

    温昱--软件架构设计

    本书紧紧围绕“软件架构设计”这一主题,立足实践解析了软件架构的概念、阐述了切实可行的软件架构设计方法、提供了可操作性极强的完整的架构设计过程。另外,本书从思维方式的突破、面向对象设计、UML建模、过程与...

    架构实战——软件架构设计的过程[汇编].pdf

    架构实战——软件架构设计的过程[汇编].pdf

    软件架构设计说明书.docx

    本文档记录并表述了系统架构的设计人员对系统构架方面做出的重要决策。 项目经理将根据构架定义的构件结构制定项目的开发计划;程序设计员将据此进行各构件的详细设计;测试设计员按照构架设计系统的总体测试框架;...

    LabVIEW软件架构设计

    LabVIEW软件架构设计LabVIEW软件架构设计LabVIEW软件架构设计LabVIEW软件架构设计LabVIEW软件架构设计

    软件架构设计培训

    软件架构设计理论,软件架构设计实践,分析与应用技术,软件架构设计思想

    面向对象软件架构设计.ppt

    第一单元:软件生命周期与软件架构介绍 2 第二单元:技术架构视图─面向对象程序设计原则与模式 59 用GRASP模式指导设计 62 领域模型 96 面向对象设计的基本原则 132 第三单元:用UML辅助系统...

    高级软件架构设计(软件架构师参考)

    介绍关于软件架构的基础知识,对于想往软件架构方面发展的同学有一定帮助。

    逻辑架构和物理架构在架构设计中的应用

    在不同的架构设计方法中出现的软件... 图1 区分物理视角与逻辑视角同样,在软件架构设计过程中,也可以通过区分软件的逻辑架构和物理架构,分别从不同的角度设计和描述软件架构。所谓软件架构视图,是指设计和看待

    论文:架构风格与基于网络的软件架构设计(PDF)

    论文:架构风格与基于网络的软件架构设计(PDF)

    软件架构之软件架构设计

    软件架构之软件架构设计电子书下载 由于[GOF95]是论述软件模式的著作的第一本,也是OO设计理论著作中最流行的一本,因此有些人常常使用设计模式(Design Pattern)一词来指所有直接处理软件的架构、设计、程序实现的...

    架构实战 : 软件架构设计的过程

    本书从基本原理入手,介绍软件架构设计过程中涉及的一些概念、流程、方法、用到的工作产品及可重用的资源,从第6章开始,通过介绍一个具体的案例来阐述如 何定义需求、创建逻辑架构、创建物理架构。在第10章“进阶”...

    高级软件架构设计

    本书为讲解如何设计实现高级软件架构设计,是软件工程师向软件架构师转变学习书籍。

    面向对象软件架构设计

    第一单元:软件生命周期与软件架构介绍 2 第二单元:技术架构视图─面向对象程序设计原则与模式 59 用GRASP模式指导设计 62 领域模型 96 面向对象设计的基本原则 132 第三单元:用UML辅助系统分析与设计 177 UML简介...

    架构风格与基于网络的软件架构设计(Restful API)-中英文

    这篇论文定义了一个框架,致力于通过架构风格来理解软件架构,并且展示如何使用风格来指导基于网络的应用的架构设计。本文使用了一个对基于网络的应用的架构风格的调查,根据不同的风格在分布式超媒体的架构中所导致...

    软件架构设计师考试大纲_软件架构设计师_

    软件架构设计师 考试大纲软考高级 软件架构设计师 考试大纲 学习指导

Global site tag (gtag.js) - Google Analytics