面向对象的系统分析及设计过程.pptVIP

面向对象的系统分析和设计过程 什么是分析和设计？ 分析 对问题和需求进行描述，回答“要做什么”的问题。 强调将功能性需求翻译成软件的概念，即用软件的概念来解释系统所要求的功能。 设计 对问题的逻辑解决方案及系统如何满足需求和约束进行高层描述和具体说明，回答“该怎么做”的问题。 强调问题的逻辑解决方案，即系统怎样才能满足需求。 什么是面向对象的分析和设计 面向对象的分析和设计的精髓是按照对象（事物、概念、实体）的观点考虑问题域和逻辑解决方案。 面对对象的分析（object-oriented analysis） 重点在于发现并描述问题域中的对象 面对对象的设计（object-oriented design） 重点在于定义那些能最终用面对对象程序设计语言实现的逻辑软件对象，这些对象具有属性和方法。 说明 本次的重点在于分析和设计过程，而不是面对对象的分析设计本身，以下的设计法则不会被讨论： 优先使用组合，而不是继承； 针对接口编程，而不是实现； 开、闭法则； 李氏替换原则； 分析和设计的必要性和粒度 类比：软件开发和建筑、系统分析设计和建筑图纸； 系统的复杂度决定了分析和设计的必要性： 需要进行分析和设计的系统特点：问题领域复杂、技术实现难度高、需要多人协作、需要长期持续维护、未来可能扩展； 系统的复杂度和开发模式决定了分析和设计的粒度； 分析和设计的前提：清晰、准确的需求 用例规约（功能性需求）、补充规约（非功能性需求）、数据规格说明、词汇表、界面原型等 面向对象的分析和设计过程 借鉴Rational统一开发过程（RUP），以UseCase驱动、体系架构为核心的迭代化的面向对象的分析和设计过程。 用UseCase作为划分问题的组织单元，分析和设计活动的局部粒度都遵照这一划分原则； 高内聚、低耦合的架构； 基于风险前驱的原则，渐进的展开分析、设计及其相关活动。 模型的划分 业务模型（UseCaseView－用例图）：表述业务过程 需求模型（UseCaseView－用例图）： 表述系统需求 数据模型（LogicalView－DataModel）：表述数据库设计 分析模型（ LogicalView－用例图、时序图、类图） 设计模型（ LogicalView－用例图、时序图、类图） 实现模型（ LogicalView）：按包结构组织实现元素 物理模型（ComponentView－组件图、DeploymentView－部属图） 面向对象的分析和设计过程 角色和分工 系统架构师 领导和协调整个项目的技术活动； 负责全局分析、全局设计； 系统分析师 负责局部性的分析和设计问题以及细节性的设计问题； 全局分析 角色 系统架构师 依据 软件需求，包括用例规约（功能性需求）、补充规约（非功能性需求）、数据规格说明、词汇表、界面原型等 既往经验 活动 选用架构模式 建立概念模型 标识分析机制 选定分析局部 结果 架构模式 概念模型 分析机制 选定的分析局部 全局分析—选用架构模式 概念 架构是指系统重要设计内容的逻辑组织和结构 结果：架构模式 层次架构 表示层 业务逻辑层 持久层 MVC架构 模型 视图 控制 全局分析—建立概念模型 概念： 业务需求和软件需求中通常会揭示系统必须处理的核心概念，这些概念同样将成为设计模型中的核心要素，也将是部分分析类的前身和雏形； 概念模型包括：一组概念、概念之间的关联、概念的属性； 依据 软件需求：用例规约、词汇表、数据规格说明； 领域经验； 步骤 寻找并列出概念； 根据词汇表（术语表）寻找概念； 根据用例规约中的名词性短语寻找概念； 添加关联； 添加属性； 结果 概念类图 全局分析—标识分析机制 概念： “构架机制”表述常见问题的通用解决模式，“分析机制”是构架机制的概念层面表述，即“构架机制”在全局分析阶段的表现形式； 常见的分析机制如：持久化、安全性、分布式处理、树形目录、分页显示、多语言支持等等； 分析机制→设计机制→实现机制 持久化→关系型数据库→Hibernate 依据 补充规约（非功能性需求）、界面原型； 既往经验； 步骤 确定分析机制； 简述分析机制； 结果 分析机制列表 全局分析—选定分析局部 概念： 风险前驱的迭代化开发策略 并非所有的UseCase都会影响系统架构的关键部分，不同的UseCase对设计方案的影响力并不均衡，在某些方面，多个UseCase对设计方案的影响力相互重叠； 根据UseCase所蕴含的风险来评判其优先级，先做优先级高的部分； 依据 分析机制、用例规约、开发进度计划； 既往经验； 步骤 识别风险； 根据分析机制定义技术风险； 根据开发进度计划和用例规约定义业务风险； 建立风险和UseCase的对应关系矩阵； 选定当前的待分析局部； 覆盖至少80％的风险 覆盖前50％优先级内