系统概要设计中的构架设计2.docx
《系统概要设计中的构架设计2.docx》由会员分享，可在线阅读，更多相关《系统概要设计中的构架设计2.docx（25页珍藏版）》请在冰点文库上搜索。
系统概要设计中的构架设计2
3.2软件架构设计
3.2.1软件架构及架构设计
1．什么是架构
在IT业，软件的系统架构是指通过某种特定的技术平台，完成软件系统整体功能的开发过程。
也可以通俗地理解为：
总体设计和总体结构布局。
（1）架构
架构普遍指通过某种特定的平台，而达到完成整体软件的功能。
也即软件体系结构通常被称为架构，指可以预制和可重构的软件框架结构。
并最终产生出本软件系统的《体系结构设计报告》的开发过程。
（2）架构的英文Architecture。
其英文的本意来源于建筑行业的建筑艺术、建筑风格和结构。
下面是摘录1EEE-Std-1471-2000RecommendedPracticeforArchitecturalDescriptionofSoftware-IntensiveSystems中有关Architecture一词的解释。
Architecture：
Thefundamentalorganizationofasystemembodiedinitscomponents，theirrelationshipstoeachother，andtotheenvironment，andtheprinciplesguidingitsdesignandevolution．[IEEEStd1471．2000]（Architecture是一个系统的基本组织，它蕴含于系统的组件、组件之间的相互关系、组件与环境的相互关系中，以及呈现于其设计和演进的原则中）。
软件架构可以有多种定义，不管对软件架构如何定义和说明，所有的定义都有一个共同的主题，那就是必须考虑软件系统中诸如技术方向、开发平台的选择、组件的构建、设计风格的确定、设计模式的具体应用、系统中各个模块职责的划分、协作、连接等问题。
2．架构是一组有关软件系统要素的重要决策
（1）决定软件系统的组织结构。
·构成系统的结构化元素的选择，实现对目标软件系统从整体到部分的最高层次的划分。
·接口和它们相互协作行为的选择。
·将结构化元素和行为元素再次组合成粒度更大的子系统方式的选择。
（2）指导这一组织结构（元素及其接口、协作和组合方式）架构风格的选择。
即选择包括架构中的组成组件、组件之间的联结器等组成元素，同时还要决定建造本应用系统采用的具体技术。
（3）软件开发中的架构既可以是名词，也可以是动词。
软件系统的架构实际上应该是两个层面的事情。
将架构作为名词来理解时，是指为软件系统设计并提供一个统一的共享框架（Framework），这种架构事实上是系统的一个层；而将架构作为动词来理解时，则是指设计构造系统或者是框架（Architecture）。
3．软件架构重要性的体现
强调软件架构最主要的目的是希望本软件项目能够实现可重用——因为开发者希望系统能够重用以前的代码和系统设计，从而提高本次项目开发的效率，这也是分析设计人员在进行架构实践时应该把握的原则：
另一个目的则是希望能够实现可扩展——同样开发者还希望在系统保持结构稳定的前提下，能够很容易地扩充系统的功能和性能t这可以通过合理地应用其他比较成熟的框架。
好的架构一定易于理解，易于学习，易于维护，开发者希望通过一个简洁的架构来把握系统。
因为一个复杂的架构不论是测试还是维护都很困难，所以开发者希望架构能够在满足目标的前提下尽可能地简单明了。
（1）软件架构是软件各相关方联系的载体。
·软件系统开发涉及许多相关人员。
它们包括软件系统的使用者、项目管理人员、分析和设计人员、编码人员、测试人员、维护人员等。
由于各类人员都有自己的独特见解和思想，要求和技术水平也不同，因此他们一般都会从自己的视角来了解和理解所要开发的软件系统。
导致不同层次和不同角色的人员对软件系统的了解和技术理解是不同的，这将给以后再开发过程中的沟通、交流带来一定的困难。
·软件架构是沟通和联系各类人员的特殊载体。
在各种要求和理解存在矛盾的情况下，软件架构又成为协调和沟通各相关方人员的共同语言。
因为各个方面的人员，都应该围绕系统架构开展各自的工作。
（2）软件架构代表了软件系统设计早期阶段中一系列重要的决策。
·软件架构提供了如何满足软件系统各项功能的要求，并为各个部件的设计和其相互
关系提供了必须遵守的约束。
软件架构为后面的详细设计工作和系统维护工作的组织、实施提供了一定的依据。
·软件架构应该提出软件系统应该实现的质量目标和性能指标，根据这些质量目标，开发者也能够预测出软件系统的某些质量属性和等级。
·软件架构为开发人员的技术培训提供了基础，因为，当开发人员在对系统架构中应用的技术或者应用的某种形式的框架不熟悉的情况下，技术培训是一个比较快捷的方法。
（3）一个成熟的软件架构可以为今后开发类似的软件产品或者软件项目提供一定的参照。
4．软件系统架构的主要工作内容
（1）架构调研（架构分析）。
面向对象的设计并不只是简单地把需求分析中的领域分析模型转换成软件系统的设计模型，系统架构师在进行软件系统的架构设计之前，还必须从需求分析的结果中获取架构因素。
架构调研的本质是识别出可能会影响系统架构的各种因素，并了解它们的易变性和优先级，最终解决这些问题。
架构调研是对系统的重大设计决策有特别影响的需求进行分析，从而识别出对系统存在或可能存在重大影响的功能性或非功能性需求（特别是非功能性需求），例如市场趋势、系统性能、开发的成本、维护和系统演进等方面的内容。
其主要的重点在于应该了解提出了什么问题，并权衡这些问题，和掌握解决影响架构重要因素的众多方法。
（2）架构设计。
架构设计主要包括体系结构设计和各个层中的模块设计，是指对软件、硬件、网络、运营、政策等软件设计中的需求和要素进行决策。
在统一过程中，架构调研和架构设计统称为架构分析。
5．统—过程（RUP）中的架构视图（ArchitectureView）
（1）4+1View模型。
1995年，PhilippeKruchten在IEEESoftware上发表了题为The4+1ViewModelofArchitecture的论文，引起了业界的极大关注，并最终被RUP（RationalUnifiedProcess）采纳。
逻辑视图、实现视图、进程视图、部署视图，再加上用例视图，这些视图在RUP中被称为架构视图（ArchitectureView）．即通过这几种视图可以完整地展示系统的架构。
软件系统中的架构结果同样也可以组织成各种不同的视图，并且需要从不同的视角来了解系统。
图3.6所示为RationalRose2003支持的各种视图。
图3.6RationalRose2003支持的各种视图
逻辑架构主要描述系统中的各个层、包、主要框架、类、接口和子系统的概念组织方式：
而部署架构则描述系统的进程如何分配给处理单元和网络配置。
同时不同的视图面对的人员也不同，如分析设计人员一般比较关注逻辑视图，而程序员则更多地关注实现视图。
（2）用例视图。
用例视图描述系统应该交付的功能，也就是外部参与者所看到的功能：
用例视图的使用者是客户、设计人员、开发人员以及测试人员。
（3）逻辑视图。
逻辑视图描述如何实现用例视图中提出的系统功能，它的使用者主要是设计人员和开发人员。
与用例视图相比，逻辑视图关注系统的内部，它既描述系统的静态结构（类、对象以及它们之间的关系），也描述系统内部的动态协作关系。
这种协作发生在实现既定功能的各对象之间进行消息传递时。
（4）组件（实现）视图。
组件视图描述系统的实现模块以及它们之间的依赖关系。
它的使用者主要是开发人员。
（5）进程（并发）视图。
并发视图将系统划分为进程和处理器。
这是系统的非功能特性，该视图主要考虑资源的有效利用、代码的并行执行以及系统环境中异步事件的处理。
除了将系统划分为并发执行的控制线程以外，并发视图还必须处理这些线程之间的通信和同步。
并发视图的使用者是开发人员和系统集成人员，并且该视图由动态图（状态图、协作图，以及活动图）和实现图（组件图和部署图）组成。
（6）部署视图。
部署视图显示系统的物理部署，例如计算机和设备（节点），以及它们之间是如何连接的。
部署视图的使用者是开发人员、系统集成人员和测试人员。
（7）对系统的架构设计要采用多视图来表达。
由于系统的架构涵盖的内容和决策太多，并且还涉及不同方面的内容，不能采用某一种单一形式的图来描述，而且也不能表达完整的内涵。
因此系统的架构设计需要从不同的层次和不同的视角分别设计：
同时，由于在系统开发过程中还将涉及不同方面的开发人员，多视图表达也为开发人员之间的交流提供了方便。
应用架构视图的核心问题是要展示应用系统中重要的设计元素，而屏蔽次要的设计元素。
因此，统一过程的架构视图给系统的开发者提供了这样的设计原则：
“选择一小组有意义的设计元素来传达主要的设计思想”。
6．系统架构设计应明确的问题
（1）何时开展架构设计工作。
架构设计一般应该在应用系统的需求分析和域建模完成后开展。
当然，这需要项目经理以具体的经验来判断是否合适开始构建软件架构的工作。
（2）架构设计工作不仅要依据静态的系统目标，还要考虑动态的开发过程。
·静态的系统目标：
一般为系统的功能性青求、非功能性需求和变化的用例等。
·动态的开发过程：
一般为如人力资源的情况，开发进度的要求，开发环境的满足。
（3）没有统一的“万能”系统架构。
由于软件的系统架构设计是和千差万别的具体软件系统的功能要求、应用的技术和具体的开发平台等实现因素密切相关的，因此没有通用的系统架构设计解决方案；尽管存在上述的原因，但在一般系统架构设计中还是会有一些共性的内容可以参考，以及需要考虑因素的说明。
对于每个因素的设计策略和具体的解决方法还需要软件系统的架构设计师在具体开发实践中灵活把握。
但要注意的是，不同的因素之间有时是相互矛盾的，架构设计师需要根据具体情况进行平衡和统筹协调。
7．架构设计的基本依据
（1）架构设计的主要依据首先是应用系统中的需求。
应用系统的设计人员主要根据需求规格说明书中的功能性需求和非功能性需求来进行系统的架构设计工作。
比如在系统的体系架构设计中为什么要应用B/S体系架构，为什么要应用轻量级的J2EE框架而不应用重量级的框架，在每一层中为什么要用这种技术实现以及各种设计模式等策略的考虑。
设计人员对于这些问题的思考，其实都是为了能够更好地满足应用系统中的“需求”，同时也是为了很好地实现需求和适应今后的需求变化；另外，系统的架构设计不仅要满足功能性的需求，还应该满足非功能性的需求，如性能等方面的要求：
还应该权衡各种性能指标的优先级别，否则系统架构设计的结果也会很复杂，系统实现的总体代价将会很高。
（2）其次，在进行架构设计的同时还应该遵循J2EE平台中倡导的两个主要设计原则多层架构、松耦合。
采用分层设计方案后，系统中各个模块的功能相互独立并被封装，同时层与层之间的关联性也大大地减弱了，并能够保持松耦合的关联；另外系统的稳定性也得到进一步提高，也便于系统今后的扩展和维护管理。
通过系统架构可以把一个复杂的系统划分为一些简单的子系统，这些子系统之间又能够保持相互独立，并与整个系统保持一致。
8．如何验证系统架构设计的正确性
很多看似完美的架构，往往会在实现时出现问题。
通过写代码来验证，还是开发出原型来验证？
在影响系统性能的各种因素中，架构是否合理是最重要的一个因素；糟糕的架构设计几乎无法通过代码优化或者其他的方式得以根本性的改进，软件系统的开发者需要首先证明现在的系统架构是否合理。
对于系统架构是否合理这一问题，开发者可以首先采用设计评审的方式由同行专家认证，然后再通过开发原型来验证系统架构是否满足功能性的需求和通过写代码（测试用例）来验证系统架构是否满足非功能性的需求。
（1）在具体实施系统开发（编程）之前，邀请一些专家和有相关经验的人员对设计进行评审。
针对可能出现的问题，对该项目的架构设计进行讨论和分析，就能够发现架构设计的问题，以避免问题进一步扩大。
（2）应用原型开发方法。
原型开发能够在需求不明确的条件下，根据现有的需求，在短时间内开发出一个原型，以这个原型作为确定进一步需求的依据，用户可以根据开发方构造出的原型来检查开发方是否能提供用户想要的软件产品，以及开发方的原型和用户需求的差距程度。
原型必须用快速的方法来开发，在一些情况下，这个原型只是概念性的，在后面的开发中将被抛弃。
根据运用原型的目的和方式的不同，原型可分为废弃型和追加型两种。
·前者先构造出一个功能简单并且质量要求不高的模型系统，针对这个模型系统反复进行分析修改，形成比较好的设计思想，系统构造完成后，原来的模型系统就被废弃；
·后者也先构造一个功能简单且质量要求不高的模型系统，作为最终系统的核心，然后对其进行不断地扩充修改并逐步追加新的功能，最后发展成为最终的系统。
目前大多数的Web动态网站开发，都是在客户初步需求的基础上，先制作出一个能表现功能的静态网站，然后让客户根据这个静态网站提出进一步的详细需求，开发方便按照这个详细需求来开发。
图3.7所示为某个BBS论坛系统中添加新闻信息的用户界面。
图3.7某个BBS论坛系统中添加新闻信息的用户界面
依据快速原型法的特点，它特别适合于开发探索型、实验型的软件。
原型法的主要优点在于它是一种支持用户的方法，使得用户在系统生存周期的设计阶段起到了积极的作用；它能减少系统开发的风险，特别是在大型项目的开发中，应用原型法效果更为明显。
（3）利用代码对架构进行验证是一种比较实用的手段。
代码验证是保证架构设计优秀的一种方法，它的核心思想是测试，特别是单元测试。
利用代码能够很好地验证架构设计中的非功能性需求是否满足，同时也能够了解系统某些技术在应用时的可行性，以及系统的设计是否能达到既定的性能指标等。
为了对架构进行验证，编程实现的代码应该面向接口编程。
对接口进行验证和测试的基本思路是保证接口的可测试性。
因此，用代码来验证架构是一种有效的做法。
如何进行代码验证？
一般在开发阶段实施之前进行验证性的测试。
因为随着开发工作的进展，在编码过程中，有可能暴露出一些架构设计上的问题和漏洞，比如发现当前架构对某个需求不能够很好地解决，这时再完善架构设计将会造成大量返工：
对于性能等方面的指标是否满足，一般应用一些压力和负载测试工具来模拟实际的访问状态，以找出性能方面的问题。
3.2.2软件系统的架构师
1．什么是软件系统架构师（Architecture）
（1）架构师是软件行业中的一种新兴职业。
软件系统的架构师通俗地说就是软件系统的设计师、结构设计者，或者按照现有的国内企业的技术职称来对照，应该是“总工程师”的角色。
比如人们常说BillGates是微软公司的系统构架师。
（2）谁能够胜任软件架构师的工作职责。
软体开发中有一些技术水平较高、行业经验较为丰富的人，这些人可以承担软件系统的架构设计工作。
从而保证开发出的软件系统项目或者软件产品符合客户的要求。
（3）架构师主要的工作内容。
软件系统的架构师需要设计软件系统中的各个部件（逻辑的、物理的部件），这包括如何划分软件系统的总体结构，系统中的各个模块组件之间如何相互作用，如何使应用系统满足性能等方面的要求。
2．架构师的主要工作职责
架构师的主要工作职责是保证在一个软件项目开发的过程中，能够将客户的各种需求转换为规范的开发计划及相关的文档；并制定这个项目的总体架构设计方案，同时还要指导整个开发团队完成对这个设计方案的具体实现。
尽管对软件架构师的角色有这样或那样的定义或描述，但大体上下列几个职责是架构师必须要承担的。
（1）技术方向的决定、技术风险的承担，具体解决方案的提供者或者建议者。
（2）与项目经理紧密合作，共同制定出本项目的开发计划和过程控制，决定项目中的成员，组织项目开发团队。
（3）最终保证软件项目能够按时、按质地顺利完成。
3．软件架构师的主要任务
（1）首先需要明确的是“自己不做什么，而不是考虑做什么”。
架构师的主要任务和工作的内容不是从事具体软件程序的编写，也不是承担繁琐的行政管理等方面的工作，更不是像有些国营企业的总工程师，大部分时间都在忙于应酬和请客吃饭。
而应该从事更高层次的有关技术方向的制定、技术难题的攻关、系统开发和架构工作，架构师不是程序员，也不应该成为行政领导。
（2）不应该只从纯技术的角度来考虑整个软件项目的实施。
架构设计工作不仅应该考虑技术方面的问题，还应该考虑如何选择技术与本企业的发展方向相匹配。
并通过本次项目的开发为企业培养和储备人才。
（3）预见客户的技术走向，以便在早期决定技术研发的方向和积累技术经验。
架构师必须对本软件系统涉及的相关开发技术非常了解，同时还应该对系统涉及的业务规则比较熟悉；并且需要有一定的组织管理能力。
因此，一个系统架构师工作能力的高低会影响整个软件开发项目的成败和软件的总体质量。
（4）在架构设计的实践工作中，最好不要过分地追求新技术的应用。
不要使用时髦但还不成熟、不可靠的技术，因为这样会增加项目实现过程中的技术风险。
同时架构师还必须关注软件系统的需求，并参与系统需求的分析活动。
4．努力把自己培养和锻炼成为软件架构师
（1）软件架构师初始的职业为程序员。
软件架构师首先必须技术过硬，这可以通过在程序员的职业阶段积累和丰富自己的技术能力。
在此阶段中应该把握的是，在实际的软件开发中不断积累的应该是对问题的分析能力、对错误的诊断能力、对软件系统结构的设计能力，而不应该仅停留在编写代码的能力方面。
（2）从程序员逐步成为高级程序员。
不是所有的程序员都能够成长为系统架构师，架构师应该是对技术有自己的独特理解和掌握能力的程序员，同时在技术方面应该有比较广的知识面。
在开发团队中，逐步体现出自己对项目中遇到的实际问题的解决能力，并不断地加以提高，慢慢成长为高级程序员。
（3）从程序员提升为设计师。
软件系统架构师和程序员（Coding）在职业范畴和工作性质、工作内容、解决问题的思路等方面是有差别的，同时对两者的技术能力要求也是不同的。
优秀的程序员经过多个实际项目的锻炼，将逐步对项目的设计工作有一定的感悟，能够成长为企业应用系统的设计师。
对设计工作初步涉及和参与，并不断积累系统设计方面的经验。
（4）系统架构师应该是高级设计师的角色。
系统架构师应该有一定的系统整体观念，这主要体现在分析问题的能力、把握抽象的能力、综合应用知识解决问题的能力等方面；同时还应该有一定的沟通能力t比如与客户的沟通、与项目组中其他成员的沟通；在知识面方面应该有一定的广度和深度，不仅要把握本行业的技术发展、流行的趋势，同时还应该掌握与系统架构相关的知识和拥有相应的行业经验：
最后还应该具有很强的自学能力、分析能力、解决问题的能力。
“程序员→高级程序员→项目实施工程师→IT咨询专家→资深IT专家”的发展过程是系统架构师培养的路线。
同时软件架构设计也是一个非常严肃、细致、敏感而且技术困难的工作，必须实实在在地积累经验，尤其是在失败中积累经验。
5．软件架构师与系统分析师的区别
（1）软件项目开发团队中的人员组成。
在一个较大规模的软件开发团队中，一般应该有项目管理师（项目经理）、软件架构师、系统分析师、软件设计师、测试工程师、数据库工程师、程序员、过程改进、质量保证等不同角色的人员。
（2）系统分析师的主要工作内容。
系统分析师的主要工作内容包括对系统中涉及的业务需求进行分析、可行性分析以及系统建模，其工作的特点和性质更多地是与行业领域专家、用户沟通，以及与项目经理（项目管理师）、软件架构师、企业的负责人进行交流，分析项目的特点、成本、风险等因素。
（3）软件架构师的主要工作内容。
本节在前面介绍了软件架构师的主要工作内容，现在再归纳一下：
软件架构师的工作内容是在系统需求比较清晰的条件下进行软件系统总体的架构设计和技术的方向性把握，项目中技术难题的解决。
当然它也可能涵盖一些系统分析师和软件设计师的工作内容，但其特点是做出技术决定或者技术决策，力求为软件系统找到或架构出一个最优的软件系统模型。
6．有关软件架构设计工作中的几个观点
（1）要承认软件系统本身是不完美的。
任何人对问题的理解和把握都是一个循序渐进的过程。
必然导致对问题的解决也是不断地完善和丰富的过程，否则软件系统就没有升级和改进版本的必要。
但这并不意味着对本次设计和开发实现，可以掉以轻心。
（2）要承认软件的需求是不完全的、动态地变化的。
正是由于软件系统本身的需求是动态地变化的，软件系统的架构设计工作才会出现许多的矛盾和不确定因素。
如何开展软件系统的架构和设计工作呢?
关键是要学会“拥抱变化、适应变化”，因为软件开发不可能等到系统的需求不再变化时再开展架构设计工作。
（3）在衡量软件系统的各种性能标准中，什么是架构师最需要关注的呢？
首先应该关注的是系统的稳定性、安全性和可扩展性；其次是系统采用技术的先进性。
因此，技术并不是第一位的。
技术是用来解决问题的，但不是系统的根本。
因为用户摄终需要的是一个能够满足其业务需要的稳定、可靠的应用系统。
（4）架构师最重要的处理和解决问题的素质。
架构师最重要的处理和解决问题的素质应该是把握解决问题的重点。
另外，在进行系统架构设计时不能仅考虑技术本身，项目的管理和风险控制有时比技术更应该多关注。
3.2.3软件架构设计的目的
1．与架构相关的框架（Framework）概念
（1）框架是从技术的横切面去解决实际应用问题的。
很多框架一般表现为中间件技术，并且是从技术的角度来解决同类型问题的。
比如ApacheStruts框架解决J2EEWeb层的开发和实现，而Spring框架则解决了J2EE平台中类的对象管理，Hibernate框架则为应用系统解决了数据访问和O/RMapping的开发和实现。
（2）框架是具体化的架构。
它也是根据应用框架的需求制定的纯技术方面的实现支持，主要用于细化整个架构或某一组成部分。
例如ApacheStruts框架定义Web层的框架，Spring框架定义应用层的框架，Hibernate框架定义数据访问层的框架。
（3）框架应当更多地体现重用。
框架应当更多地体现出重用，也就是框架应当包含设计重用（其设计方案能够被重用）和代码重用（其代码能够被重用）两层意思，并且是架构在某一问题域的具体化实现方案，更关注的是可重用性。
·框架中的设计重用
框架中的设计重用一般借助于设计模式来体现。
如在ApacheStruts框架中就应用了MVC架构模式、J2EE前端控制器模式等，而Spring框架中则提供了控制反转（IoC）和依赖注入（DI）模式。
·框架中的代码重用
框架中的代码重用一般通过提供基础组件和对应的API（包括类和接口），并通过模板模式回调框架使用者的具体实现代码来体现。
如Struts框架中的ActionServlet、Actionform和Action等组件类。
2．与架构相关的设计模式（DesignPattern）概念
设计模式主要侧重于思想和方法（如MVC模式、桥模式、命令模式、工厂模式等），不像框架那样明确地提供了组件。
因为在处理大量问题时，在很多不同的问题中经常会重复出现相同的解决方法，但细节不会重复的内容。
模式化过程是把问题抽象化，在忽略不重要的细节后发现问题的一般性本质，并找到使用普遍方法去解决的过程。
因此，设计模式是一套被反复使用、多数人知晓的、经过分类编目的代码设计经验的总结。
并且是在大量的实践总结和理论化之后优选的代码结构、编程风格，及解决问题的思考方式。
3．架构设计的目标之一是希望能够最大化地重用
（1）在系统架构设计中灵活地使用各种共享的，特别是开源的框架技术。
当架构师成功地实施了某个系统的架构后，应该概括和总结出本项目中一些共性的和经验性的内容，并
升级会员 