《系统架构设计师教程》

系统分析与设计方法

　　对于架构设计师而言，如何进行系统设计是其“看家本领”，而设计是在对系统进行分析的基础上进行的，否则，设计就是“无米之炊”。

　　从软件开发项目中的角色分配来看，系统架构设计师应该在信息系统项目管理师的协调下，与系统分析师协同工作。

定义问题与归结模型

　　软件系统的目的是为了解决问题，因此在建模之初最重要的步骤是对问题的分析与定义， 并在此基础上归结模型，这样才能够获得切实有效的模型。

　　定义问题的过程包括：理解真实世界中的问题和用户的需要，并提出满足这些需要的解决方案的过程。

问题分析

　　问题分析的目标就是在开发之前对要解决的问题有一个更透彻的理解。

　　为了达到这一目标，通常需要经过在问题定义上达成共识，理解问题的本质，确定项目干系人和用户，定义系统的边界和确定系统实现的约束这五个步骤。

　　1．在问题定义上达成共识

　　2．理解问题的本质

　　　　每一句描述都会夹杂着叙述者的个人理解和判断，因此透过表面深入本质，理解问题背后的问题，是问题分析阶段一个十分关键的任务。

　　　　其中一种技术是“根本原因”分析，这是 一种提示问题或其表象的根本原因的系统化方法。在实际的应用中，常使用因果鱼骨图和帕累托图两种方法。

　　3．确定项目干系人和用户

　　4．定义系统的边界

　　　　系统的边界是指解决方案系统和现实世界之间的边界。

　　　　在系统边界中，信息以输入和输出的形式流入系统并由系统流向系统外的用户，所有和系统的交互都是通过系统和外界的接口进行的。

　　　　在定义系统的边界时，将世界分为两个部分：系统及与系统进行交互的事物。

　　　　要描述系统的边界有两种方法：一种是结构化分析中的“上下文范围图”，另一种则是面向对 象分析中的“用例模型”。

　　5．确定系统实现的约束

　　　　由于各种因素的存在，会对解决方案的选择造成一定的限制，称这种限制为约束。每条 约束都将影响到最后的解决方案的形成，甚至会影响是否能够提出解决方案。

问题定义　

　　通过对问题进行细致周密的分析，就可以对其进行综合的定义。

　　对于一个问题的完整定义，通常应包括目标、功能需求和非功能需求三个方面。　　　

目标

　　目标是指构建系统的原因，它是最高层次的用户需求，是业务上的需要，而功能、性能 需求则必须是以某种形式对该目标做出贡献。

　　在描述目标时，应该注意以下几个方面。

　　　　优势：目标应该不仅仅是解决问题，还要提供业务上的优势；

　　　　度量：不仅要说明业务的优势，而且还必须提供度量这种优势的标准；

　　　　合理性：要确保完成解决方案所需的工作量少于所获得的业务优势，这才是合理的解决方案；

　　　　可行性：要探寻能够满足度量标准的解决方案；

　　　　可达成性：对于组织而言，是否具备获取该系统的技能，构建完成后是否能够操作它。

功能需求

　　功能需求是用来指明系统必须做的事情，只有这些行为的存在，才有系统存在的价值。

　　功能需求应该源于业务需求，它只与问题域相关，与解决方案域无关。

　　也就是说，功能需求 是在与用户或某个业务人员交谈时，他们所描述的内容是为了完成他们某部分的工作而必须 做的事情。

　　而在设计解决方案时，会遇到一些限制条件，这些东西也是“系统需求” 的一 部分，不过应该是设计约束或非功能需求形式指定。

非功能需求

　　非功能需求是系统必须具备的属性，这些属性可以看作是一些使产品具有吸引力、易用、快速或可靠的特征或属性。

　　非功能需求并不改变产品的功能，它是为工作赋予特征的。

　　在识别功能需求和非功能需求时，有一种十分有用的思维模式：功能需求是以动词为特征的，而非功能性需求则是以副词为特征的。

需求分析与软件设计

　　需求分析与软件设计是软件生存期中最重要的两个步骤，需求分析解决的是“做什么” 的问题，系统设计则是解决“怎么做”的问题。

需求分析的任务与过程

　　需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其 他系统元素的接口细节，定义软件的其他有效性需求，细化软件要处理的数据域。

　　用一句话 概括就是：需求分析主要是确定待开发软件的功能、性能、数据、界面等要求。

　　需求分析的实现步骤通常包括：获取当前系统的物理模型，抽象出当前系统的逻辑模型，建立目标系统的逻辑模型三个部分。

　　具体来说，需求分析阶段的工作可以分成 4 个方面：

　　（1）问题识别　　（2）分析与综合　　（3）编制需求分析的文档　　（4）需求分析与评审

如何进行系统设计

　　当设计者拿到一个需求，他如何开展系统设计呢？

　　许多想进入系统分析与设计的年轻人 以为自己知道了面向对象、统一建模语言、设计模式等新鲜深奥的名词就可以进行设计了， 可是掌握工具和技能绝不是成为优秀设计者的充分条件，甚至也不是必要条件。

　　遗憾的是这里没有捷径，只有设计者在实践中不断学习和总结。而在实践中，系统设计与其说是在设计，不如说是在选择和妥协。

软件设计的任务与活动　　

　　软件设计是一个把软件需求变换成软件表示的过程。最初这种表示只是描绘出软件的总体框架，然后再进一步细化，并在此框架中填入细节。

　　1.软件设计的两个阶段从工程管理角度，软件设计可以分为两个步骤：

　　　　（1）概要设计：也称为高层设计，将软件需求转化为数据结构和软件的系统结构。例如，如果采用结构化设计，则将从宏观的角度将软件划分成各个组成模块，并确定模块的功 能及模块之间的调用关系。

　　　　（2）详细设计：也称为低层设计，将对结构表示进行细化，得到详细的数据结构与算法。同样的，如果采用结构化设计，则详细设计的任务就是为每个模块进行设计。

　　2．主要的设计方法比较

　　　　而近年来，面向对象技术凭借其对数据的高效封装及良好的消息机制，实现了高内聚、低耦 合的系统设计，成了现代软件设计的主流方法学。

结构化分析与设计

　　结构化分析与设计方法是一种面向数据流的需求分析和设计方法，它适用于分析和设计大型数据处理系统，是一种简单、实用的方法，曾获得广泛的应用。

结构化分析

　　结构化分析方法的基本思想是自顶向下逐层分解。

　　分解和抽象是人们控制问题复杂性的两种基本手段。

　　　　对于一个复杂的问题，人们很难一下子考虑问题的所有方面和全部细节，通常可以把一个大问题分解成若干个小问题，每个小问题再分解成若干个更小的问题，

　　　　经过多次逐层分解，每个最底层的问题都是足够简单、容易解决的，于是复杂的问题也就迎刃而解 了。这个过程就是分解过程。

面向对象的分析与设计

　　面向对象方法是一种非常实用的软件开发方法，它一出现就受到软件技术人员的青睐， 现已成为计算机科学研究的一个重要领域，并逐渐成为软件开发的一种主要方法。

　　面向对象方法以客观世界中的对象为中心，其分析和设计思想符合人们的思维方式，分析和设计的结构与客观世界的实际比较接近，容易被人们接受。

　　在面向对象方法中，分析和设计的界面并不明显，它们采用相同的符号表示，能够方便地从分析阶段平滑地过渡到设计阶段。

　　此外， 在现实生活中，用户的需求经常会发生变化，但客观世界的对象及对象间的关系比较稳定， 因此用面向对象方法分析和设计的结构也相对比较稳定。　

软件架构设计

设计模式

　　面向对象技术为软件技术带来新的发展。人们运用面向对象的思想分析系统、为系统建模并设计系统，最后使用面向对象的程序语言来实现系统。

　　但是面向对象的设计并不是一件 很简单的事情，尤其是要设计出架构良好的软件系统更不容易。

　　为了提高系统的复用性，需 要进行一些“额外”的设计（这里的额外并不是无用的，而是指业务领域之外），定义类的接口、规划类的继承结构、建立类与类之间的关系。

　　毋庸置疑，良好的设计可以让系统更容 易地被复用、被移植和维护，而如何快速进行良好的设计则是设计模式要讨论的问题。设计 模式是软件架构设计师的必修课，设计模式中蕴含的思想是架构设计师必须掌握的。　

设计模式概述

　　在 20 世纪 70 年代，Christopher Alexander 提出了城市建筑的模式，他认为：模式就是描述一个不断发生的问题和该问题的解决方案。

　　随后，Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 写了一本著名的参考书《设计模式：可复用面向对象软件的基础》。

　　后人也因为这本书称这四个人为四人组，将这本书中描述的模式称为 GoF（Gang of Four） 设计模式。

　　在这本书中，四人组将设计模式定义为：对被用来在特定场景下解决一般设计问题的类和互相通信的对象的描述。通俗地说，可以把设计模式理解为对某一类问题的通用解决方案。

设计模式的概念

　　首先，设计模式解决的是一类问题，例如工厂模式就是为了解决类创建的问题，而适配器模式则是为了解决类接口不匹配的问题。

　　如果把解决 A 问题的设计模式使用在 B 问题 上，结果肯定是张冠李戴了。所以在描述设计模式前，首先要描述这个设计模式究竟要解决什么样的问题。

　　其次，设计模式是一种通用的解决方案，而不是具体的，也不是唯一的。在 GoF 的书 中对设计描述主要着重于思想的描述。

　　需要指出的是，虽然在 GoF 的著作中第一次提出了软件的设计模式，但设计模式并非这四人所创，它来源于很多项目中的成功设计，并将这些优雅的设计方式进行抽象、总结、 归纳出来。

　　在学习设计模式时需要注意以下两点：

　　　　（1）学习这些模式是一个方面，另一方面更要了解模式中的思想。

　　　　设计模式本身是为了提高软件架构的质量，学习设计模式的目的也是为了提高架构设计的水平。

　　　　虽然设计模式 中描述的大多是面向对象的低层设计方案，但其中包含的却是软件设计的思想，同软件架构风格是一致的。

　　　　例如，MVC 既可以看作一种设计模式也可以看作一种架构风格。掌握这种 设计思想是非常有意义的。

　　　　（2）设计模式虽然可以使设计变得更精妙，但滥用设计模式会适得其反。

　　　　在软件设计中使用设计模式，可以优化设计，提高架构质量。但是，首先，设计模式有其应用的场合， 不相宜的场合乱用设计模式有害无益；

　　　　其次，设计模式主要解决对象之间相互通信、相互依赖的结构关系，架构设计师需要把握好使用设计模式的力度，过度的使用设计模式不但不会 提高软件的复用性，反而会让架构变得混乱而难以维护。

设计模式的组成

　　一般的，在描述一个设计模式时，至少需要包含四个方面：模式名称（Pattern name）、 问题（Problem）、解决方案（Solution）、效果（Consequence）。

　　这四个方面就是设计模式的四要素。

　　名不正则言不顺，每种设计模式都有自己的名字，也就是模式名称；

　　设计模式都有其应用的场合，即该设计模式意图解决的问题，超出了这个问题就不应该再应用这种模式，所以问题是设计模式的第二要素；

　　设计模式的目的就是解决问题，所以在描述设计模式时当然要有解决问题的方法描述，这就是设计模式的另外一个要素——解决方案；

　　虽然架构设计师知道应用设计模式可以提高架构质量，提高软件的复用性，但对于每一种设计模式而言， 还有其更具体的效果描述，所以设计模式的最后一个要素就是效果。

设计模式分类　

　　可以说，设计模式是面向问题的，即每一种设计模式都是为了解决一种特定类型的问题。

　　因此，根据设计模式要解决的问题将设计模式分为三类，分别为创建型、结构型和行为型。

　　事实上，面向对象的设计中，需要解决的就是：如何管理系统中的对象、如何组织系统 中的类与对象、系统中的类与对象如何相互通信。

　　这三类设计模式分别解决了这三个方面的 问题。 创建型设计模式主要解决对象创建的问题。

　　在最简单的情况下，在程序中定义类，在使用时创建一个对象实例。但在实际开发中，对象的创建会变得复杂很多，这时就需要使用创建型设计模式解决创建对象的问题。　

 

　　随着开发系统的不断扩张，系统功能更加丰富，模块之间的复用越来越多，系统中类与对象的结构变得更加复杂。如果缺乏良好的设计，这些类之间的关系将会变得非常混乱。结构型设计模式就是为了解决这些问题的。