[从需求分析走向概要设计.docVIP

从需求分析走向概要设计 王青 2007-07-28 在软件过程中，需求分析和概要设计是两个极其重要的阶段。需求分析是概要设计的依据，而设计则是需求自然的逻辑延续。从需求分析走向概要设计，就是我们从待解决问题的领域走向解决方案的领域，也就是我们从客观的现实世界走向主观的计算机待建系统世界的过程。为了使得大家对这一过程的目的、原则和具体工作有较为清楚的认识，特阐述以下内容与大家讨论。凡以下之内容，均系一家之言，不妥之处，敬请指正。 软件工程的方法学 方法学是指导我们解决问题的原则，它是我们对于具体问题解决方案的哲学基础，是我们思考问题，解决问题的方式方法。下面的一些方法学是软件工程的理论基础和逻辑起点，它们在软件工程的具体方法、规则和关键活动域中都有体现。了解这些方法论，有助于我们加深对软件工程的理解；同时在我们优化软件工程的活动中，对它们的了解和应用更会使我们的工作事半功倍。 分治法：将大的问题分解为小的问题，从而缩小问题的规模，降低问题的复杂度，减少风险。 逻辑完整性：所有的活动和所有的制品，都有其逻辑上的起点和支撑点；同时，也都有其逻辑上相应的结果。 可管理：所有的活动和制品都应当能够被控制和调整。 文档化（documented）：将不可见的活动和思维成果外化为具体的文档。 敏捷与MDA：敏捷的原则在于够用就好；而MDA立足于用模型取代部分文档，增强设计的可追溯性与可重构性。 软件工程的这些方法学于实践当中体现为软件过程，而软件过程的实施则依靠管理和组织的保障，在此限于篇幅不再赘述。 需求分析的制品 需求分析的过程是对现实世界中的待解决问题的建模过程，同时也是深入剖析待建系统的过程。它的成果通常包括： 一组Use Case：通过对前置条件、后置条件和事件流的描述来清楚的界定系统使用者对于系统的功能性需求。 Domain Model：明确待建系统中的业务实体以及它们之间的关系 SRS/ARS （Software/Application Requirements Specification）：综述待建系统的目的、功能性需求、接口/界面需求、约束以及非功能性需求。 概要设计的制品 概要设计就是在需求分析成果的基础之上，运用软件设计的原则、模式、惯例和经验，提出问题的解决方案，并明确界定待建系统的结构、接口和界面。在概要设计结束时，待建系统的技术架构、部署图、组件的划分、各个组件的外部接口、用户界面（静态原型）、持久化方案等设计要点都已经确定，系统的表示层，业务逻辑层和数据层的解决方案也已经明确。我们通常用下面的这些制品来描述我们概要设计的结果： 全局制品 Physical Architecture Diagram 系统的物理结构，包括网络环境和服务器分布： 图表 1 系统物理架构图 Technical Architecture Diagram 系统的层次结构，以及各层次所使用的具体技术： 图表 2 系统技术架构图 Installation Package Directory 系统安装包的目录结构： 图表 3 系统安装包目录结构 Deployment Diagram 系统中的各个模块的部署情况： 图表 4 系统模块部署图 表示层制品（针对Web Application） Sitemap 图示待建系统界面由哪些页面构成，以及它们间的层次与导航关系： 图表 8 Sitemap Static- Prototype 一组静态html页面用以说明定义待建系统的最终用户界面，参考附件：prototype.zip 其它 虽然表示层的技术相对简单，但是如果用户有RIA（Rich Internet Application）方面的需求，则通常需要在客户端实现一些较为复杂的逻辑（表示逻辑不是业务逻辑！）；此时我们应该对这些需求进行设计，用到的制品类似于在下面的业务逻辑层和数据层中罗列的制品；但是，必须注意到客户端技术的特殊性，例如：脚本语言和沙箱模式。 业务逻辑层制品 Components Diagram 系统中各个包中所有的公有类 图表 5 组件图 Component Interface Diagram 系统中每个包的对外接口 图表 6 组件接口图 Component Requirements Specification 组件需求规格说明书，用以明确每一个组件的设计需求，作为下阶段详细设计的一个重要输入，参见附件：CRS_example.doc Sequence Diagrams 时序图，针对每个用例，图示系统如何实现这个用例，满足用户的需求 图表 7 系统时序图 数据层制品 Entity Relationship Diagram 数据库设计的ER图： 图表 9 数据库设计ER图 DDL Script 数据