您好,欢迎访问三七文档
当前位置:首页 > 商业/管理/HR > 公司方案 > 架构设计指南架构设计指南
在完成需求分析之后,下一步是系统分析设计。系统分析设计的输入是需求分析所提供的《需求规格说明书》,输出是《概要设计说明书》和《详细设计说明书》。在一般情况下,《概要设计说明书》由系统设计师负责。《详细设计说明书》则由高级程序员负责。这两种设计说明书的差异是:《概要设计说明书》既要覆盖《需求规格说明书》的全部内容,又是要作为指导详细设计的依据。因此,它注重于框架上的设计,包括软件系统的总体结构设计、全局数据库(包括数据结构)设计、外部接口设计、功能部件分配设计、部件之间的内部接口设计,它要覆盖需求规格说明书中的功能点列表、性能点列表、接口列表。若为C/S或B/A/S结构设计,则要说明部件运行在网络中的哪一个节点上。《详细设计说明书》既要覆盖《概要设计说明书》的全部内容,又要作为指导程序设计和编码的依据。因此,它注重于微观上和框架内的设计,包括各子系统的公用部件实现设计、专用部件实现设计、存储过程实现设计、触发器实现设计、外部接口实现设计、部门角色授权设计、其他详细设计等部件。其他设计包括:登录注册模块设计、信息发布模块设计、菜单模块设计、录入修改模块设计、查询统计模块设计、业务逻辑处理模块设计、报表输出模块设计、前台网站模块设计、后台数据处理模块设计、数据传输与接收模块设计等。对于简单或熟悉的系统,概要设计和详细设计可以合二而一,形成一份文档(称为设计说明书),进行一次评审,实现一个里程碑,确立一条基线。对于复杂或生疏的系统,概要设计和详细设计必须分开,形成两份文档,进行两次评审,实现两个里程碑,确立两条基线。4.1软件架构设计(软件概要设计)当对象、类、构件、组件等概念出现并成熟之后,传统意义上的软件概要设计(又叫软件总体设计或软件系统设计),就逐渐改名为软件架构设计。所以说,软件架构设计就是软件概要设计。软件架构设计工作由架构师来完成,架构师是主导系统全局分析设计和实施、负责软件构架和关键技术决策的角色,他的具体职责为:领导与协调整个项目中的技术活动(分析、设计入实施等)推动主要的技术决策,并最终表达为软件构架描述确定和文档化系统中对构架而言意义重大的方面,包括系统的需求、设计、实施和部署等“视图”确定设计元素的划分以及这些主要分组之间的接口为技术决策提供规则,平衡各类涉众的不同关注点,化解技术风险,并保证相关决定被有效传达和贯彻理解、评价并接收系统需求评价和确认软件架构的实现4.1.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性能、可伸缩性、吞吐量类图交互图、状态图、活动图线程、进程实施视图ImplementationView构件、文件构件图交互图、状态图、活动图配置、发布部署视图DeploymentView构件的发布、交付、安装实施图交互图、状态图、活动图拓扑结构的节点4.1.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),而它们之间的关系则表达为如何组合构件、连接器的约束条件。传统的软件构架风格可概括为以下几种:1、DataflowSystems数据流系统:---BatchSequential批处理---Pipesandfilters管道过滤器2、Call—and---ReturnSystems调用与返回系统:---MainProgramandsubroutine主程序与子程序---00System对象系统---Hierarchicallayers分层体系系统3、Independentcomponents独立的构件:---CommunicatingProcesses通讯交互的进程---Eventsystems事件(驱动)系统---Capsule—Port—Protocol实时系统在eGov电子政务系统概要设计中,我们使用分层架构模式。分层模式是一种将系统的行为或功能以层为首要的组织单位来进行分配(划分)的结构模式。—层内的元素只信赖于当前层和之下的相邻层中的其它元素(注意这并非绝对的要求)1、逻辑层次Layer—通常在逻辑上进行垂直的层次Layer划分--关注的是如何将软件构件组织成一种合理的结构,以减少依赖,从而便于管理(支持协同开发)--逻辑层次划分的标准基于包的设计原则2、物理Tier—在物理上则进行水平的层级Tier划分--关注软件运行时刻的性能及其伸缩性,还有系统级的操作需求(OperationalRequirement)----管理、安全等---物理层划分的目标在于确定若干能够满足不同类型软件运行时对系统资源要求的标准配置,各构件部署在这些配置下将获得最优的性能。我们将eGov电子政务系统应用在职责上至少能被分成4层:表示层(PresentationLayer)、持久层(PersistenceLayer)、业务层(BusinessLayser)和域模块层(domainmodelLayer)。每个层在功能上都应该是十分明确的,而不应该与其他层混合。每个层要相互独立,通过接口而相互联系。3、利用可重用资产任何软件架构设计都不会从头开始,我们要尽量利用可重用资产。资产类型包括:领域模型,需求规格,构件、模式、webservices、框架、模板等。我们首先必须理解对这些资产进行考察的上下文,即项目需求、系统的范围、普遍的功能和性能等,之后可以从组织级的资产库、或业界资源中搜寻相关的资产,甚至是相似的产品或项目。在eGov电子政务系统中,我们使用了设计模式和框架。(1)设计模式(DesignPatterns)1)设计模式概念如果要问起近10年来在计算机软件工程领域所取得的重大成就,那么就不能不提到设计模式(DesignPattern)了。什么是模式(Pattern)呢?并没有一个很严格的定义。一般说来,模式是指一种从一个一再出现的问题背景中抽象出来的解决问题的固定方案,而这个问题背景不应该是绝对的,或者说是不固定的。很多时候看来不相关的问题,会有相同的问题背景,从而需要应用相同的模式来解决。模式的概念最开始的时候是出现在城市建筑领域的。Alexander的一本关于建筑的书中明确的给出了模式的概念,用来解决在建筑中的一些问题。后来,这个概念逐渐的被计算机科学所采纳,并在一本广为接受的经典书籍的推动下而流行起来的。这本书就是:DesignPatterns:ElementsofReusableObject-OrientedSoftware(设计模式:可复用面向对象软件元素),是由四位软件大师合写的(很多有时候我们直接用GoF来意指这四位作者,Gof的意思是GangsofFour,四人帮)。设计模式指的是在软件的建模和设计的过程中运用到的模式。设计模式中很多种方法其实很早就出现了,并且应用的也比较多。但是直到GoF的书出来之前,并没有一种统一的认识。或者说,那时候并没有对模式形成一个概念。这些方法还仅仅是处在经验阶段,并没有能
本文标题:架构设计指南架构设计指南
链接地址:https://www.777doc.com/doc-5239294 .html