软件架构设计指南.docx
《软件架构设计指南.docx》由会员分享，可在线阅读，更多相关《软件架构设计指南.docx（21页珍藏版）》请在冰豆网上搜索。
软件架构设计指南
软件架构设计指南
1.概要设计和详细设计
在完成需求分析之后，下一步是系统分析设计。
系统分析设计的输入是需求分析所提供的《需求规格说明书》，输出是《概要设计说明书》和《详细设计说明书》。
在一般情况下，《概要设计说明书》由系统设计师负责。
《详细设计说明书》则由高级程序员负责。
这两种设计说明书的差异是:
《概要设计说明书》既要覆盖《需求规格说明书》的全部内容，又是要作为指导详细设计的依据。
因此，它注重于框架上的设计，包括软件系统的总体结构设计、全局数据库（包括数据结构）设计、外部接口设计、功能部件分配设计、部件之间的内部接口设计，它要覆盖需求规格说明书中的功能点列表、性能点列表、接口列表。
若为C/S或B/A/S结构设计，则要说明部件运行在网络中的哪一个节点上。
《详细设计说明书》既要覆盖《概要设计说明书》的全部内容，又要作为指导程序设计和编码的依据。
因此，它注重于微观上和框架内的设计，包括各子系统的公用部件实现设计、专用部件实现设计、存储过程实现设计、触发器实现设计、外部接口实现设计、部门角色授权设计、其他详细设计等部件。
其他设计包括:
登录注册模块设计、信息发布模块设计、菜单模块设计、录入修改模块设计、查询统计模块设计、业务逻辑处理模块设计、报表输出模块设计、前台网站模块设计、后台数据处理模块设计、数据传输与接收模块设计等。
对于简单或熟悉的系统，概要设计和详细设计可以合二而一，形成一份文档（称为设计说明书），进行一次评审，实现一个里程碑，确立一条基线。
对于复杂或生疏的系统，概要设计和详细设计必须分开，形成两份文档，进行两次评审，实现两个里程碑，确立两条基线。
2.软件架构设计（软件概要设计）
当对象、类、构件、组件等概念出现并成熟之后，传统意义上的软件概要设计（又叫软件总体设计或软件系统设计），就逐渐改名为软件架构设计。
所以说，软件架构设计就是软件概要设计。
软件架构设计工作由架构师来完成，架构师是主导系统全局分析设计和实施、负责软件构架和关键技术决策的角色，他的具体职责为:
（1）领导与协调整个项目中的技术活动（分析、设计入实施等）
（2）推动主要的技术决策，并最终表达为软件构架描述
（3）确定和文档化系统中对构架而言意义重大的方面，包括系统的需求、设计、实施和部署等“视图”
（4）确定设计元素的划分以及这些主要分组之间的接口
（5）为技术决策提供规则，平衡各类涉众的不同关注点，化解技术风险，并保证相关决定被有效传达和贯彻
（6）理解、评价并接收系统需求
（7）评价和确认软件架构的实现
2.1.软件架构设计基本概念
1、软件架构定义
系统是部件的集合，完成一个特定的功能或完成一个功能集合。
架构是系统的基本组织形式，描述系统中部件间及部件与环境音质相互关系。
架构是指导系统设计和深化的原则。
系统架构是实体、实体属性以及实体关系的集合。
软件架构是软件部件、部件属性以及客观存在们之间相互作用的集合，描述软件系统的基本属性和限制条件。
2、软件架构建模
软件架构建模是与软件架构的定义和管理相关的分析、设计、文档化、评审及其他活动。
软件架构建模的目的:
（1）捕获早期的设计决策。
软件架构是最早的设计决策，它将影响到后续设计、开发和部署，对后期维护和演变也有很大的影响。
（2）捕获软件运行时的环境。
（3）为底层实现提供限制条件。
（4）为开发团队的结构组成提供依据。
（5）设计系统满足可靠性、可维护性以及性能等方面的要求。
（6）方便开发团队之间的交流。
各种角色的人员都可以使用架构，如项目经理、开发经理、技术总监、系统架构师、测试人员以及开发人员。
针对不同角色的人员，架构应提供适当的信息，其详细程度也不同。
软件架构的构建是软件设计的基础，它关心的是软件系统中大的方面，台子系统和部件，而不是类和对象。
软件架构应描述以下问题:
（1）软件系统中包含了哪些子系统和部件。
（2）每个子系统和部件都完成哪些功能。
（3）子系统和部件对外提供或使用外部的哪些
（4）子系统和部件间的依赖关系，以及对实现和测试的影响。
（5）系统是如何部署的。
软件架构不包括硬件、网格以及物理平台的设计。
软件架构只描述创建软件所需要的各种环境，而不是详细描述整个系统。
3、软件架构视图
架构视图是指从一个特定的视角对系统或系统的一部分进行的描述。
架构可以用不同的架构视图进行描述，如逻辑视图用于描述系统功能，进程视图用于描述系统并发，物理视图用于描述系统部署。
架构视点包含名称、涉众、关注点、建模分析规则等信息，描述如何创建和使用架构视图。
架构视图概念见下图和下表
图4-1RUP的4+1视图
.
表4-1RUP的4+1视图
视图名称视图内容静态表现动态表现观察角度
系统行为、动力用况图交互图、状态图、用户、分析员、用例视图
活动图测试员
UseCaseView
问题及其解决方类图、对象图交互图、状态图、类、接口、协作逻辑视图
案的术语词汇活动图LogicView
性能、可伸缩性、类图交互图、状态图、线程、进程进程视图
吞吐量活动图ProcessView
构件、文件构件图交互图、状态图、配置、发布实施视图
活动图Implementation
View
构件的发布、交实施图交互图、状态图、拓扑结构的节点部署视图
付、安装活动图Deployment
View
2.2.软件架构设计步骤
1、确定影响整体技术方案的因素:
（1）考察用户界面复杂度
用户界面的复杂度可概括为以下几种:
简单数据输入simpledatainput（例如登入界面）
数据的表态静态视图staticview（例如商品报价列表）可定制视图customizableview（例如可自定义查询报告界面）数据的动态视图dynamicview（例如实时运行监控视窗）交互式图形（例如CAD系统）
（2）考察用户界面部署约束
用户界面的部署约束可概括为以下几种:
-经常要离线工作的移动电脑
-手持设备（例如PDA、java手机）
-支持Interner网上的任何一种浏览器（包括低速的拨号上网方式和老版本浏览器）-支持Internet网上的较新版本浏览器
-支持内部网上的较新版本浏览器
-支持内部网上的特定浏览器
-内部网上的专用工作站（传统C/S架构的客户端软件）
（3）考察用户的数量和类型
用户的数量和类型可概括为以下几种:
--少数的专业用户:
关注功能强大，期望量身定制，乐于学习新特性，例如图形制作系统的用户
--组织内的日常使用者:
主流用户，关注便利和易用，例如考勤系统用户--大量的爱好者:
对系统的功能有执着的兴趣，有意愿克服使用时遇到的的各种困难，包括软件本身的缺陷，例如游戏软件的用户。
--数量巨大的消费型用户:
关注速度和服务感受，例如商业网站的用户（4）考察系统接口类型
系统接口类型可概括为以下几种:
--数据传输:
仅仅为了满足系统间交换数据的需要，例如电子数据交换EDI接口、数据库同步等
--通过协议提供服务:
系统依照协议向外提供特定的服务，例如http协议、soap（webservice）协议等
--直接访问系统服务:
按照类似于系统内部调用的方式，直接使用系统的方法，例如RPC远程调用/RMI/Corba等
（5）考察性能和可伸缩性
性能和可伸缩性方面可概括为以下几种:
---只读:
只有对数据浏览和查询操作，例如股票行情分析系统
---独立的数据更新:
有对数据的修改操作，但各用户的修改完全隔离，相互间不存在任何潜在的冲突，例如网上商店各顾客对自己帐单的管理
---并发的数据更新:
并发用户对数据的修改将相互影响，或者就是更改了同一数据，例如多个用户同时使用航班预定系统预定同一航班的座位
对于eGov电子政务系统,它的主要特性如下:
用户界面的复杂度:
数据的静态显示/可定制视图（customizableview）用户界面的部署约束:
基于独立的桌面电脑或专用工作站的浏览器用户的数量和类型:
组织内的日常使用者，总共几百人
系统接口类型:
通过HTTP协议提供服务，未来可以使用SOAP的SOA技术性能:
主要是独立的数据更新，有少量并发处理
2、选择软件构架样式（风格）
所谓软件构架样式（风格），是指关于一组软件元素及其关系的元模型（meta-model）,那些元素及其关系将基于不同的风格（被元模型所定义）被用来描述目标系统本身。
上述这些元素通常表示为构件（component）和连接器（connection）,而它们之间的关系则表达为如何组合构件、连接器的约束条件。
传统的软件构架风格可概括为以下几种:
DataflowSystems数据流系统:
---BatchSequential批处理
---Pipesandfilters管道过滤器
Call—and---ReturnSystems调用与返回系统:
---MainProgramandsubroutine主程序与子程序
---00System对象系统
---Hierarchicallayers分层体系系统
Independentcomponents独立的构件:
---CommunicatingProcesses通讯交互的进程
---Eventsystems事件（驱动）系统
---Capsule—Port—Protocol实时系统
在eGov电子政务系统概要设计中，我们使用分层架构模式。
分层模式是一种将系统的行为或功能以层为首要的组织单位来进行分配（划分）的结构模式。
—层内的元素只信赖于当前层和之下的相邻层中的其它元素（注意这并非绝对的要求）逻辑层次Layer
—通常在逻辑上进行垂直的层次Layer划分
--关注的是如何将软件构件组织成一种合理的结构，以减少依赖，从而便于管理（支持协同开发）
--逻辑层次划分的标准基于包的设计原则
2、物理Tier
—在物理上则进行水平的层级Tier划分
--关注软件运行时刻的性能及其伸缩性，还有系统级的操作需求（OperationalRequirement）
----管理、安全等
---物理层划分的目标在于确定若干能够满足不同类型软件运行时对系统资源要求的标准配置，各构件部署在这些配置下将获得最优的性能。
我们将eGov电子政务系统应用在职责上至少能被分成4层:
表示层（PresentationLayer）、持久层（PersistenceLayer）、业务层（BusinessLayser）和域模块层（domainmodelLayer）。
每个层在功能上都应该是十分明确的，而不应该与其他层混合。
每个层要相互独立，通过接口而相互联系。
3、利用可重用资产
任何软件架构设计都不会从头开始，我们要尽量利用可重用资产。
资产类型包括:
领域模型，需求规格，构件、模式、webservices、框架、模板等。
我们首先必须理解对这些资产进行考察的上下文，即项目需求、系统的范围、普遍的功能和性能等，之后可以从组织级的资产库、或业界资源中搜寻相关的资产，甚至是相似的产品或项目。
在eGov电子政务系统中，我们使用了设计模式和框架。
4、设计模式（DesignPatterns）
1）设计模式概念
如果要问起近10年来在计算机软件工程领域所取得的重大成就，那么就不能不提到设计模式（DesignPattern）了。
什么是模式（Pattern）呢,并没有一个很严格的定义。
一般说来，模式是指一种从一个一再出现的问题背景中抽象出来的解决问题的固定方案，而这个问题背景不应该是绝对的，或者说是不固定的。
很多时候看来不相关的问题，会有相同的问题背景，从而需要应用相同的模式来解决。
模式的概念最开始的时候是出现在城市建筑领域的。
Alexander的一本关于建筑的书中明确的给出了模式的概念，用来解决在建筑中的一些问题。
后来，这个概念逐渐的被计算机科学所采纳，并在一本广为接受的经典书籍的推动下而流行起来的。
这本书就是:
DesignPatterns:
ElementsofReusableObject-OrientedSoftware
（设计模式:
可复用面向对象软件元素），是由四位软件大师合写的（很多有时候我们直接用GoF来意指这四位作者，Gof的意思是GangsofFour，四人帮）。
设计模式指的是在软件的建模和设计的过程中运用到的模式。
设计模式中很多种方法其实很早就出现了，并且应用的也比较多。
但是直到GoF的书出来之前，并没有一种统一的认识。
或者说，那时候并没有对模式形成一个概念。
这些方法还仅仅是处在经验阶段，并没有能够被系统的整理，形成一种理论。
每一个设计模式都系统的命名，解释和评价了面向对象系统中的一个重要的和重复出现的设计。
这样，我们只要搞清楚这些设计模式，就可以完全或者说很大程度上吸收了那些蕴含在模式中的宝贵的经验，对面向对象的系统能够有更为完善的了解。
更为重要的是，这些模式都可以直接用来指导面向对象系统中至关重要的对象建模问题。
如果有相同的问题背景，那么很简单，直接套用这些模式就可以了。
这可以省去你很多的工作。
2）常用设计模式:
在设计模式一书中涉及到23个模式，被分类为创建型模式，结构型模式和行为模式，分别从对象的创建，对象和对象间的结构组合以及对象交互这三个方面为面向对象系统建模方法给予了解析和指导，几乎可以说的上包罗万象了.之后，有很多模式陆续出现，比如分析模式，体系结构模式等等。
主要的23个设计模式概述如下:
AbstractFractory
提供一个创建一系列相关或相互依赖对象的接口，而无需制定它们具体的类（Adapter
将一个类的接口转换成客户希望的另外一个接口。
Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作
Bridge
将抽象部分与它的实现部分分离，使它们都可以独立地变化。
Builder
S将一个复杂对象的构建与它的表示分离，使得同样的构件过程可以创建不同的表示ChainofResponsibility
解除请求的发送者和接收者之间的耦合，从而使多个对象都有机会处理这个请求。
将这些对象连接成一条链来传递该请求，直到有一个对象处理它。
Command
将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化;对请求排队或者记录请求日志，以及支持取消操作
Composite
将对象组合成树形结构以表示“部分-整体”的层次结构。
Composite使得客户对单个对象和复合对象的使用具有一致性。
Decorator
动态地给一个对象添加一些额外的职责。
Façade
为子系统中的一组接口提供一个一致的界面。
FactoryMethod
定义一个用于创建对象的接口，让子类决定将哪个类实例化。
Flyweight
运用共享技术有效地支持大量细粒度（finegrained）的对象。
Interpreter
给定一个语言，定义它的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子
Iterator
提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露该对象的内部表示。
Mediator
用一个中介对象来封装一系列的对象交互。
Memento
在不破坏封装性的前提下，捕捉一个对象的内部状态，并在该对象之外保存这个状态。
Observer
定义对象间的一种一对多的依赖关系，以便当一个对象的状态发生改变时，所有依赖它
的对象都得到通知并自动刷新。
Prototype
用原型实例指定创建对象的种类，并且通过拷贝这个原型来创建新的对象。
Proxy
为其他对象提供一个代理以控制对这个对象的访问。
Singleton
保证一个类仅有一个实例，并提供一个访问它的全局访问点。
State
允许一个对象在其内部状态改变时改变它的行为。
Strategy
定义以系列算法，把它们一个个封装起来，并且使它们可相互替换。
TemplateMethod
定义一个操作中的算法框架，而将一些步骤延迟到子类中。
Visitor
表示一个作用于某对象结构中的各元素的操作。
我们重点介绍常用的三个设计模式:
a（Factory工厂模式
1）简介
工厂模式是我们最常用的模式之一，它在Java程序系统中可以说是随处可见。
为什么工厂模式是如此常用,因为工厂模式就相当于创建实例对象的new，我们经常要根据类Class生成实例对象，如Aa=newA（）工厂模式也是用来创建实例对象的，所以以后new时就要多个考虑，是否可以考虑实用工厂模式，虽然这样做，可能多做一些工作，但会给你系统带来更大的可扩展性和尽量少的修改量。
我们以类Sample为例，如果我们要创建Sample的实例对象:
Samplesample=newSample（）;
可是，实际情况是，通常我们都要在创建sample实例时做点初始化的工作,比如赋值、查询数据库等。
首先，我们想到的是，可以使用Sample的构造函数，这样生成实例就写成:
Samplesample=newSample（参数）;
但是，如果创建sample实例时所做的初始化工作不是象赋值这样简单的事，可能是很长一段代码，如果也写入构造函数中，那你的代码很难看了。
为什么说代码很难看，初学者可能没有这种感觉，我们分析一下，初始化工作如果是很长一段代码，说明要做的工作很多，将很多工作装入一个方法中是很危险的，这也是有背于Java面向对象的原则，面向对象的封装（Encapsulation）和分派（Delegation）告诉我们，尽量将长的代码分派“切割”成每段，将每段再“封装”起来（减少段和段之间耦合联系性），这样，就会将风险分散，以后如果需要修改，只要更改每段，不会再发生牵一动百的事情。
在本例中，我们首先需要将创建实例的工作与使用实例的工作分开,也就是说，让创建实例所需要的大量初始化工作从Sample的构造函数中分离出去。
这时我们就需要Factory工厂模式来生成对象了，不能再用上面简单的newSample（参数）。
还有,如果Sample有个子类如MySample,按照面向接口编程,我们需要将Sample抽象成一个接口.现在Sample是接口,有两个子类MySample和HisSample.我们要实例化他们时,如下:
Samplemysample=newMySample（）;Samplehissample=newHisSample（）;
随着项目的深入,Sample可能还会生出很多子类,那么我们要对这些子类一个个实例化,更糟糕的是,可能还要对以前的代码进行修改，以便加入后来子类的实例.这在传统
程序中是无法避免的.
但如果你一开始就有意识使用了工厂模式,这些麻烦就没有了.
2）工厂模式分类:
工厂模式中有:
工厂方法（FactoryMethod）和抽象工厂（AbstractFactory）.
（1）工厂方法
你会建立一个专门生产Sample实例的工厂:
publicclassFactory{
publicstaticSamplecreator（intwhich）{
//getClass产生Sample一般可使用动态类装载装入类。
if（which==1）
returnnewSampleA（）;
elseif（which==2）
returnnewSampleB（）;
}
}
那么在你的程序中,如果要实例化Sample时.就使用
SamplesampleA=Factory.creator
（1）;这样,在整个就不涉及到Sample的具体子类,达到封装效果,也就减少错误修改的机会.
（2）抽象工厂
它与工厂方法的区别在于需要创建对象的复杂程度上。
如果我们创建对象的方法变得复杂了,如上面工厂方法中是创建一个对象Sample,如果我们还有新的产品接口Sample2.
这里假设:
Sample有两个具体（concrete）类SampleA和SamleB，而Sample2也有两个concrete类Sample2A和Sample2B
那么，我们就将上例中Factory变成抽象类,将共同部分封装在抽象类中,不同部分使用子类实现，下面就是将上例中的Factory拓展成抽象工厂:
publicabstractclassFactory{
publicabstractSamplecreator（）;
publicabstractSample2creator（Stringname）;
}
publicclassSimpleFactoryextendsFactory{
publicSamplecreator（）{
.........
returnnewSampleA（）;
}
publicSample2creator（Stringname）{
.........
returnnewSample2A（）;
}
}
publicclassTestFactoryextendsFactory{
publicSamplecreator（）{
......
returnnewSampleB（）;
}
publicSample2creator（Stringname）{
......
returnnewSample2B（）;
}
}
从上面看到两个工厂各自生产出一套Sample和Sample2,也许你会疑问，为什么我不可以使用两个工厂方法来分别生产Sample和Sample2?
这是因为抽象工厂还有另外一个关键要点，在SimpleFactory内，生产Sample和生产Sample2的方法之间有一定联系，所以才要将这两个方法捆绑在一个类中，这个工厂类有其本身特征，也许制造过程是统一的，比如制造工作比较简单，所以名称叫SimpleFactory。
b（Singleton（单态/单点/单例）模式
1）定义:
Singleton模式主要作用是保证在Java应用程序中，一个类Class只有一个实例存
在很多操作中，比如建立目录、数据库连接都需要这样的单线程操作。
在。
还有,singleton能够被状态化;这样，多个单态类在一起就可以作为一个状态仓库一样向外提供服务，比如，你要论坛中的帖子计数器，每次浏览一次需要计数，单态类能否保持住这个计数，并且能synchronize的安全自动加1，如果你要把这个数字永久保存到数据库，你可以在不修改单态接口的情况下方便的做到。
另一方面，Singleton也能够被无状态化，提供工具性质的功能。
Singleton模式就为我们提供了这样实现的可能。
使用Singleton的好处还在于可以节省内存，因为它限制了实例的个数，有利于Java垃圾回收（garbagecollection）。
我们常常看到工厂模式中类装入器（classloader）中也用Singleton模式实现的,因为被装入的类实际也属于资源。
2）如何使用?
一般Single
升级会员 