信息系统的规划和设计.ppt

* * * * * 30 * 30 * * * * * * * * * * * * * * * * * 基于软件架构的开发 以构架为中心的软件开发模式，是近几年来软件界大力推崇的一项最佳实践，它较好地解决了软件开发中以往难于克服的多个难题，如需求的变更问题、系统功能扩展的困难、系统的设计基础脆弱的问题等等。 软件构架与系统的软件需求往往不是一一对应的关系，通常软件构架的设计应当基于超出当前软件需求定义的边界之外、更为广泛的需求超集，这个需求超集通常而言就是业务领域模型。 真正健壮的软件构架应当面向整个业务领域，因为系统的软件需求不管如何变化，其内容仍然处于原有业务领域的范围之内，这样软件构架将毫不费力地适应这些新的需求变更。 软件架构——对领域知识的高度抽象 不同的应用系统，每个应用系统向最终用户提供一组相关的服务 特定业务层支持特定应用领域或组织的特定业务逻辑功能，成为业务构件 更细化的业务操作 与平台无关的分布式计算和数据访问处理 特定平台的接口 软件架构——对领域知识的高度抽象 应用系统 出纳服务 ATM服务 储蓄柜面 会计柜面 客户管理 现金管理 帐户管理 票证管理 业务逻辑 联机事务处理中间件 数据库访问 系统安全控制 数据访问 数据库 数据库 软件构架的具体技术，我们在系统设计部分进行介绍 构架的重要性： 1、构架是开始把需求转换到解决方案的第一个设计产品 2、系统的属性（性能、可修改性、可用性）在很大程度上是由构架决定的。如果构架不好，不能适应这些属性的要求，系统将永远不可能获得这些属性 3、构架决定了开发项目和最终系统的结构和管理，项目组的成立、资源的分配，都是围绕着构架进行的 4、要了解系统、只能从构架开始 5、正确的构架是保证系统稳定的前提 4.3.1 构架定义和评估 构架的需求： 一个成功的构架，有时可能要考虑以下需求： 在构架的生命周期范围内，支持新功能和新外设之间的柔性集成 因添加新外设而进行的系统扩展，不需要升级所有的软件模块 一个有效的测试方法是，避免对系统所有配置进行测试 支持在不同地点的开发，然后在一个平台上生成产品 在新版本发布的间隔期间，做出对市场和用户的必要的响应 同时提供对内部变更和外部变更的支持 4.3.1 构架定义和评估 构架方法： 自顶向下；从需求出发，通过一系列细化来定义构架、并随着开发的进展，验证、修改，获得构架的一致性和完备性。 在功能设计之前，先考虑系统的基础结构。基础构架是系统执行应用程序必不可少的部分。操作系统、通信协议、中间件、系统专用的支持功能，都是基础构架的组成部分。 在功能开发的过程中，抽取基础结构，建立构架。 构架风格： 构架不是从零开始的，构架的风格，就是行业知识体系的存在形式，也是构架的设计模式 构架风格定义了一组组件类型、指定了相互间连接的拓扑模式、运行时的交互作用。风格与业务模型紧密关联 4.3.1 构架定义和评估 组件接口： 组件接口当然首先应能说明：组件名称、指定参数的类型和数量。 组件与一般程序调用不同的是，它还要说明其操作等 接口通常采用规格说明的方式说明 规格说明规定了组件内部属性： 静态：服务的前置和后置条件、变量定义、服务交互的约束条件 动态：状态机描述、时序逻辑（时间处理顺序、间隔）等的约束条件 组件的外部属性： 性能（负载能力、吞吐量） 可靠性 4.3.1 构架定义和评估 组件应用： 过程调用是组件最古老、最普遍的应用 在现代分布式应用系统中，常用到的组件有： 远程过程调用 通信协议 ……. 以上这些方法，就是所谓“中间件”技术 在现今市场上，最主要的中间件技术有： 公共对象请求代理构架（CORBA） 分布式对象组件模型（DCOM） JaveBeans 4.3.1 构架定义和评估 构架评估： 系统构架是系统最早的设计决策 是系统质量目标（安全性、可靠性、可用性、可更改性、实用性能满足性）等的基础 是系统开发、管理、维护、用户、测试、市场、产品人员工作的公共平台 对构架的依赖越来越高，风险也越来越大 评估的方法，与软件评审方法类似，时机应该在系统概要设计完成，详细设计开始之前进行 必须有详细和明确的评估准则，例如： 一个业务系统的特定功能目标，导致的特殊行为需求和质量属性目标，与构架支持范围的矛盾和平衡 4.3.1 构架定义和评估 软件组件：在一个软件构架下，根据某些规定的接口、内部连接方法和其他组件集成，实现具有明显的上下文依赖性的指定功能的单元。 组件的远祖是子程序，而现代组件的规模更大、更复杂、能应用于更高的领域、具有比子程序调用更加复杂的交互机制。但其中的概念和原理，是相同的。 组件开发的目的，就是将开发人员的注意力，从程序细节，转到构