火龙果架构设计指南架构设计指南标题.docVIP

在完成需求分析之后，下一步是系统分析设计。系统分析设计的输入是需求分析所提供的《需求规格说明书》，输出是《概要设计说明书》和《详细设计说明书》。在一般情况下，《概要设计说明书》由系统设计师负责。《详细设计说明书》则由高级程序员负责。 这两种设计说明书的差异是： 《概要设计说明书》既要覆盖《需求规格说明书》的全部内容，又是要作为指导详细设计的依据。因此，它注重于框架上的设计，包括软件系统的总体结构设计、全局数据库（包括数据结构）设计、外部接口设计、功能部件分配设计、部件之间的内部接口设计，它要覆盖需求规格说明书中的功能点列表、性能点列表、接口列表。若为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-1 RUP的4+1视图 . 表4-1 RUP的4+1视图 视图名称 视图内容 静态表现 动态表现 观察角度 用例视图 Use Case View 系统行为、动力 用况图 交互图、状态图、活动图 用户、分析员、测试员 逻辑视图 Logic View 问题及其解决