文档介绍：在完成需求分析之后,下一步是系统分析设计。系统分析设计的输入是需求分析所提供的《需求规格说明书》,输出是《概要设计说明书》和《详细设计说明书》。在一般情况下,《概要设计说明书》由系统设计师负责。《详细设计说明书》则由高级程序员负责。
这两种设计说明书的差异是:
《概要设计说明书》既要覆盖《需求规格说明书》的全部内容,又是要作为指导详细设计的依据。因此,它注重于框架上的设计,包括软件系统的总体结构设计、全局数据库(包括数据结构)设计、外部接口设计、功能部件分配设计、部件之间的内部接口设计,它要覆盖需求规格说明书中的功能点列表、性能点列表、接口列表。若为C/S或B/A/S结构设计,则要说明部件运行在网络中的哪一个节点上。
《详细设计说明书》既要覆盖《概要设计说明书》的全部内容,又要作为指导程序设计和编码的依据。因此,它注重于微观上和框架内的设计,包括各子系统的公用部件实现设计、专用部件实现设计、存储过程实现设计、触发器实现设计、外部接口实现设计、部门角色授权设计、其他详细设计等部件。其他设计包括:登录注册模块设计、信息发布模块设计、菜单模块设计、录入修改模块设计、查询统计模块设计、业务逻辑处理模块设计、报表输出模块设计、前台网站模块设计、后台数据处理模块设计、数据传输与接收模块设计等。
对于简单或熟悉的系统,概要设计和详细设计可以合二而一,形成一份文档(称为设计说明书),进行一次评审,实现一个里程碑,确立一条基线。对于复杂或生疏的系统,概要设计和详细设计必须分开,形成两份文档,进行两次评审,实现两个里程碑,确立两条基线。
(软件概要设计)
当对象、类、构件、组件等概念出现并成熟之后,传统意义上的软件概要设计(又叫软件总体设计或软件系统设计),就逐渐改名为软件架构设计。所以说,软件架构设计就是软件概要设计。软件架构设计工作由架构师来完成,架构师是主导系统全局分析设计和实施、负责软件构架和关键技术决策的角色,他的具体职责为:
领导与协调整个项目中的技术活动(分析、设计入实施等)
推动主要的技术决策,并最终表达为软件构架描述
确定和文档化系统中对构架而言意义重大的方面,包括系统的需求、设计、实施和部署等“视图”
确定设计元素的划分以及这些主要分组之间的接口
为技术决策提供规则,平衡各类涉众的不同关注点,化解技术风险,并保证相关决定被有效传达和贯彻
理解、评价并接收系统需求
评价和确认软件架构的实现
、软件架构设计基本概念
1、软件架构定义
系统是部件的集合,完成一个特定的功能或完成一个功能集合。架构是系统的基本组织形式,描述系统中部件间及部件与环境音质相互关系。架构是指导系统设计和深化的原则。
系统架构是实体、实体属性以及实体关系的集合。
软件架构是软件部件、部件属性以及客观存在们之间相互作用的集合,描述软件系统的基本属性和限制条件。
2、软件架构建模
软件架构建模是与软件架构的定义和管理相关的分析、设计、文档化、评审及其他活动。
软件架构建模的目的:
(1)捕获早期的设计决策。软件架构是最早的设计决策,它将影响到后续设计、开发和部署,对后期维护和演变也有很大的影响。
(2)捕获软件运行时的环境。
(3)为底层实现提供限制条件。
(4)为开发团队的结构组成提供依据。
(5)设计系统满足可靠性、可维护性以及性能等方面的要求。
(6)方便开发团队之间的交流。
各种角色的人员都可以使用架构,如项目经理、开发经理、技术总监、系统架构师、测试人员以及开发人员。针对不同角色的人员,架构应提供适当的信息,其详细程度也不同。
软件架构的构建是软件设计的基础,它关心的是软件系统中大的方面,台子系统和部件,而不是类和对象。
软件架构应描述以下问题:
(1)软件系统中包含了哪些子系统和部件。
(2)每个子系统和部件都完成哪些功能。
(3)子系统和部件对外提供或使用外部的哪些
(4)子系统和部件间的依赖关系,以及对实现和测试的影响。
(5)系统是如何部署的。
软件架构不包括硬件、网格以及物理平台的设计。软件架构只描述创建软件所需要的各种环境,而不是详细描述整个系统。
3、软件架构视图
架构视图是指从一个特定的视角对系统或系统的一部分进行的描述。架构可以用不同的架构视图进行描述,如逻辑视图用于描述系统功能,进程视图用于描述系统并发,物理视图用于描述系统部署。
架构视点包含名称、涉众、关注点、建模分析规则等信息,描述如何创建和使用架构视图。架构视图概念见下图和下表
图4-1 RUP的4+1视图
.
表4-1 RUP的4+1视图
视图名称
视图内容
静态表现
动态表现
观察角度
用例视图
Use Case View
系统行为、动力
用况