- 浏览: 958685 次
- 性别:
- 来自: 魔都
文章分类
- 全部博客 (745)
- MultiThread (19)
- My Plan (118)
- JavaBasic (61)
- MyInterview (104)
- InternetTechnique (5)
- ProjectConclusion (1)
- Maven (5)
- MogoDb (5)
- Hadoop (11)
- Memcached (6)
- TechniqueCollect (1)
- Ibaits (1)
- Android (34)
- ItLife (40)
- Tree (2)
- ProjectArchitect (7)
- Open Source (3)
- liunx (5)
- socket (8)
- Spring (27)
- DesginPattern (35)
- WebBasic (13)
- English (13)
- structs (1)
- structs2 (2)
- Oracle (17)
- Hibernate (2)
- JavaScript (4)
- Jdbc (1)
- Jvm (15)
- Ibatis (1)
- DataStructures (13)
- Https/Socket/Tcp/Ip (3)
- Linux (4)
- Webservice (7)
- Io (2)
- Svn (1)
- Css (1)
- Ajax (1)
- ExtJs (1)
- UML (2)
- DataBase (6)
- BankTechnique (3)
- SpringMvc (3)
- Nio (3)
- Load Balancing/Cluster (3)
- Tools (1)
- javaPerformanceOptimization (8)
- Lucene(SEO) (1)
- My Think (80)
- NodeJs (1)
- Quartz (1)
- Distributed-java (1)
- MySql (7)
- Project (4)
- junit (4)
- framework (1)
- enCache (1)
- git (2)
- SCJP (1)
- sd (1)
最新评论
-
lkjxshi:
你都这水平了还考这个证干嘛
SCJP 认证考试指南 -
钟逸华:
问的真多
百度java开发面试题(转) -
zuimeitulip:
觉得我就是这样的,从小阅读量就很少,导致现在的读的速度非常慢, ...
让读书成为一种习惯 -
DDT_123456:
我觉得你是不符合要求。问你hashmap的那个问题,你那样回答 ...
阿里面试2(转) -
jingjing0907:
刚刚写了很多读过此博客的感受,竟然没有发上去,以为我注册账号还 ...
让读书成为一种习惯
软件架构设计的目的
对于外包业务类型的项目,软件架构设计的目的与产品类型的项目有所不同,在这里主要讨论外包类型项目的软件架构设计目的。
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
发表评论
-
《30岁前每一天》 读书心得体会
2015-01-20 14:06 1074在某社交网站上看到很 ... -
神回复
2014-05-22 12:31 8161、为什么平胸妹子一般都是吃货?神回复:因为穷胸极饿!2、别人 ... -
别堕落,你没资格
2014-03-19 23:15 821是不是经常迷茫,是不 ... -
马云、李嘉诚、周立波这样骂不上进的人(转)
2014-03-10 23:36 688马云、李嘉诚、周立波这样骂不上进的人。一、周立波的话年轻人,你 ... -
感悟生活(转)
2014-02-28 23:24 915人的受教育程度,一定程度上决定着人的生存和生活方式,接 ... -
程序员的生活
2013-06-26 23:14 7711、总结自己一 ... -
学习是一个反复的过程!
2012-08-22 22:47 9172号在三合班听米老师讲关于如何学习,几个小时下来让我受益 ... -
给年轻程序员的几句话
2012-08-19 21:53 742文章链接:http://zhengfuxinq.iteye.c ... -
不当IT民工 让你拿高薪的10个技能
2012-08-13 22:49 1094文章链接:http://yingchifei.iteye.co ... -
怎样看待这两个词语---天赋、踏实
2012-07-27 09:34 971偶然有机会看到在 ... -
年薪15万的80后小本科:只要6分钟,告诉你少走6年弯路
2012-07-18 23:46 2002这个社会是很残酷的, ... -
IT行业!今天你跳了吗?
2012-05-04 23:59 1013我是2012年2月份来这个公司,其实经历了好几次跳槽。 一、跳 ... -
IT从业人员知识的学习方法以及学习技巧
2012-03-29 09:30 958腾讯搜搜优秀开发人员 ... -
为什么借助开源学习是最有效的?
2012-03-23 23:40 942为什么借助开源学习是 ... -
程序员怎样看书
2012-03-20 10:09 1242对学习编程者的忠告: 眼过千遍不如手过一遍! 书看千行不如手敲 ... -
分享8年开发经验,浅谈程序员职业规划
2012-03-20 09:24 918在中国有很多人都认为I ... -
程序员的经历
2012-03-19 10:17 9361.在岁23-28岁时:经常写 ... -
任正非:卓越领导者的“三气”
2012-02-26 18:47 1019卓越的领导者无不具有“三气”:正气、才气、霸气。 正气者,德 ... -
一点一滴培养你的领导气质
2012-02-26 18:41 881一:沉稳 (1)不要随便显露你的情绪。 (2)不要逢人就诉 ... -
程序员必读经典书籍
2012-02-12 12:10 1377前面几本书来源请看 ...
相关推荐
因此,软件架构设计的知识点非常广泛和复杂,本文将从多个方面对软件架构设计的知识点进行详细的介绍。 一、软件架构设计的基础知识 软件架构设计是软件开发的高层次设计,涉及到软件的整体架构、技术架构、业务...
本文档旨在为产品经理、项目经理、系统工程师、架构师及软件开发人员提供一个清晰、全面的软件架构设计模板,以帮助他们理解和执行项目的架构设计,确保后续开发工作的顺利进行,并为网站后续版本的架构提供参考。...
比较全面的阐述嵌入式系统软件架构设计的资料,pdf版本,文字版,完整无广告。 本课程是针对嵌入式软件开发的特点,讨论架构设计的思路和方法。试图给大家提供一种思想,启发大家的思维。框架,自动化代码生成和...
05_设计模式与软件架构设计.pdf 06_AOP开发实践.pdf 07_软件架构通用服务.pdf ................ ............. .............. ................. .............. 09_基于SOA架构设计.pdf 10_企业软件架构.pdf 11_...
嵌入式系统软件架构设计是构建高效、稳定且适应性强的嵌入式系统的基石。它涉及到如何合理组织软件组件,确保系统性能、可靠性和可维护性。本文将深入探讨决定架构的因素、嵌入式环境下的特点以及软件框架的设计。 ...
标题《软件架构设计》所蕴含的知识点极为广泛,它关联到软件工程的核心概念,包括软件架构的基本原则、设计模式、架构风格、方法论以及实现工具和环境等。下面将从不同角度展开详细解读。 首先,软件架构设计是软件...
软件架构设计说明书是指在软件开发过程中,对软件系统的整体架构进行设计和描述的文档。该文档旨在为软件开发团队提供一个统一的架构蓝图,以指导软件的设计、开发和测试工作。软件架构设计说明书通常包括软件架构的...
在进行软件架构设计时,有几个关键要素需要特别关注: - **模块化**:通过将系统划分为多个独立的模块来提高系统的可维护性和可扩展性。 - **松耦合**:减少不同模块之间的依赖程度,使得每个模块都能够独立地进行...
在IT行业中,软件架构设计是开发高质量软件的关键环节。它涉及到如何组织和构建软件系统,以便满足功能需求、性能指标、可维护性、扩展性和可重用性等多方面的要求。下面将根据“软件架构设计 ppt”这个主题,详细...
作者在这部博士论文中详细阐述了如何基于网络进行软件架构设计,这对于开发者、架构师和项目经理来说都是宝贵的参考资料。他们可以从中学习到如何设计出符合REST原则的服务,如何优化系统性能,以及如何通过模块化...
"软件架构设计文档ADMEMS模板v2" 软件架构设计文档是软件开发过程中的重要文档,旨在描述软件系统的架构设计,包括软件系统的总体架构、组件之间的关系、数据流向、接口定义等。下面是基于ADMEMS模板v2的软件架构...
《架构风格与基于网络的软件架构设计》这篇论文深入探讨了软件架构的重要性和在现代网络环境中如何有效地进行架构设计。架构设计是软件开发的核心环节,它决定了系统的整体结构、组件间的关系以及通信机制,对软件的...
软件架构设计师不仅是技术专家,还需要具备良好的沟通技巧,能有效地与项目经理、开发人员、测试人员和其他利益相关者进行交流,以确保架构设计符合项目需求和目标。 通过《软件架构设计师考试大纲.xmind》这样的...
本书紧紧围绕“软件架构设计”这一主题,立足实践解析了软件架构的概念、阐述了切实可行的软件架构设计方法、提供了可操作性极强的完整的架构设计过程。另外,本书从思维方式的突破、面向对象设计、UML建模、过程与...
软件架构设计是软件工程领域中一个至关重要的方面,它涉及到软件系统的高层次结构和组件的组织方式。在这个案例分析中,我们从多个维度来探讨软件架构设计的细节和实践。 首先,软件架构是一个系统的抽象。它定义了...
《图书杂志采购和借阅系统》的软件架构设计说明书详细阐述了系统的设计和构建过程,旨在为项目相关人员提供全面的理解和指导。以下是该文档的主要内容摘要: 一、简介 这部分明确了文档的编写目的,旨在记录系统...