面向对象的系统分析和设计过程什么是分析和设计？ 分析 对问题和需求进行描述，回答“要做什么”的问题。 强调将功能性需求翻译成软件的概念，即用软件的概 念来解释系统所要求的功能。 设计 对问题的逻辑解决方案及系统如何满足需求和约束进 行高层描述和具体说明，回答“该怎么做”的问题。 强调问题的逻辑解决方案，即系统怎样才能满足需求 。什么是面向对象的分析和设计 面向对象的分析和设计的精髓是按照对象（事物 、概念、实体）的观点考虑问题域和逻辑解决方 案。 面对对象的分析（object-oriented analysis） 重点在于发现并描述问题域中的对象 面对对象的设计（object-oriented design） 重点在于定义那些能最终用面对对象程序设计语言实 现的逻辑软件对象，这些对象具有属性和方法。说明 本次的重点在于分析和设计过程，而不是面对对象的分析 设计本身，以下的设计法则不会被讨论： 优先使用组合，而不是继承； 针对接口编程，而不是实现； 开、闭法则； 李氏替换原则； 分析和设计的必要性和粒度 类比：软件开发和建筑、系统分析设计和建筑图纸； 系统的复杂度决定了分析和设计的必要性： 需要进行分析和设计的系统特点：问题领域复杂、技术实现难度高、 需要多人协作、需要长期持续维护、未来可能扩展； 系统的复杂度和开发模式决定了分析和设计的粒度； 分析和设计的前提：清晰、准确的需求 用例规约（功能性需求）、补充规约（非功能性需求）、数据规 格说明、词汇表、界面原型等面向对象的分析和设计过程借鉴Rational统一开发过程（RUP），以UseCase驱动、体系架构为核 心的迭代化的面向对象的分析和设计过程。 用UseCase作为划分问题的组织单元，分析和设计活动的局部粒度都遵照 这一划分原则； 高内聚、低耦合的架构； 基于风险前驱的原则，渐进的展开分析、设计及其相关活动。 模型的划分 业务模型（UseCaseView用例图）：表述业务过程 需求模型（UseCaseView用例图）： 表述系统需求 数据模型（LogicalViewDataModel）：表述数据库设计 分析模型（ LogicalView用例图、时序图、类图） 设计模型（ LogicalView用例图、时序图、类图） 实现模型（ LogicalView）：按包结构组织实现元素 物理模型（ComponentView组件图、DeploymentView部属图）面向对象的分析和设计过程 角色和分工 系统架构师 领导和协调整个项目的技术活动； 负责全局分析、全局设计； 系统分析师 负责局部性的分析和设计问题以及细节性的设计问题；全局分析角色 系统架构师 依据 软件需求，包括用例规约（功能性需求）、补充规约（非功能性需求） 、数据规格说明、词汇表、界面原型等 既往经验 活动 选用架构模式 建立概念模型 标识分析机制 选定分析局部 结果 架构模式 概念模型 分析机制 选定的分析局部全局分析选用架构模式 概念 架构是指系统重要设计内容的逻辑组织和结构 结果：架构模式 层次架构 表示层 业务逻辑层 持久层 MVC架构 模型 视图 控制全局分析建立概念模型概念： 业务需求和软件需求中通常会揭示系统必须处理的核心概念，这些概 念同样将成为设计模型中的核心要素，也将是部分分析类的前身和雏 形； 概念模型包括：一组概念、概念之间的关联、概念的属性； 依据 软件需求：用例规约、词汇表、数据规格说明； 领域经验； 步骤 寻找并列出概念； 根据词汇表（术语表）寻找概念； 根据用例规约中的名词性短语寻找概念； 添加关联； 添加属性； 结果 概念类图全局分析标识分析机制概念： “构架机制”表述常见问题的通用解决模式，“分析机制”是构架机制的概念 层面表述，即“构架机制”在全局分析阶段的表现形式； 常见的分析机制如：持久化、安全性、分布式处理、树形目录、分页显 示、多语言支持等等； 分析机制设计机制实现机制 持久化关系型数据库Hibernate 依据 补充规约（非功能性需求）、界面原型； 既往经验； 步骤 确定分析机制； 简述分析机制； 结果 分析机制列表全局分析选定分析局部概念： 风险前驱的迭代化开发策略 并非所有的UseCase都会影响系统架构的关键部分，不同的UseCase对设计方案的影响力 并不均衡，在某些方面，多个UseCase对设计方案的影响力相互重叠； 根据UseCase所蕴含的风险来评判其优先级，先做优先级高的部分； 依据 分析机制、用例规约、开发进度计划； 既往经验； 步骤 识别风险； 根据分析机制定义技术风险； 根据开发进度计划和用例规约定义业务风险； 建立风险和UseCase的对应关系矩阵； 选定当前的待分析局部； 覆盖至少80的风险 覆盖前50优先级内的全部风险； 结果 选定的分析局部局部分析角色 系统分析师 依据 用例规约 概念模型 活动 提取分析类并描述需求场景 整理分析类 结果 层次构架 场景描述图（时序图） 参与类图局部分析提取分析类并转述需求场景 概念： 分析类是指能够协作完成UseCase行为的分析元素，用于描述系统 中较高层次的对象； 影响系统的变化因素的三个维度和分析类的类型划分： 系统和外部元素之间交互的边界：边界类（界面和外部系统接口）； 系统要记录和维护的信息：实体类（需要留存的实体信息）； 系统运行中的控制逻辑：控制类（业务逻辑）； 需求阶段的UseCase可能被细化成为分析阶段的UseCase； 描述需求场景的时序图； 将用例规约中用文字描述的需求场景用UML时序图的方式转述； 需求场景：用户系统，系统被视为一个黑盒子； UML时序图：用户界面（边界类）业务逻辑（控制类）持久 （实体类）、外部系统接口（边界类）；局部分析提取分析类并转述需求场景依据 用例规约、界面原型； 概念模型； 步骤 细化UseCase，定义UseCase实现； 提取分析类； 根据界面原型提取部分边界类； 根据概念模型提取部分实体类； 根据用例规约提取控制类和其他边界类、实体类； 绘制时序图转述需求场景； 用户界面（边界类）业务逻辑（控制类）持久（实体类）、外部系统 接口（边界类）； 结果 分析用例及UseCase实现； 分析类； 时序图；局部分析整理分析类 概念： 定义分析类的方法和属性 依据 场景描述图（时序图） 步骤 确定分析类的方法：将时序图中的消息映射为分析类的方法； 确定分析类之间的关联关系：消息的传递映射为分析类之间的方 法调用，以得到参与类图； 确定分析类的属性 结果 参与类图全局设计 角色 系统架构师 依据 层次架构 分析机制 概念模型 活动 确定开发架构 定义设计机制和实施机制 定义从分析类到设计类的映射方式 根据概念模型生成数据模型全局设计确定开发架构 概念： 架构（achitecture）来自于建筑学的概念，是框架（ framework）和结构（structure）的合称。其中它与框架 的区别主要体现在，它着重描述各个框架中的结构关 系以及之间的组合，描述框架间的联系，突出它的结 构特点。 常见的J2EE架构： StrutsSessionBeanEntityBean； StrutsSessionBeanHibernate； StrutsSpringHibernate； 对应开发架构的开发规范和包结构全局设计定义设计机制和实施机制 概念： 设计机制实现相应的分析机制，实施机制运用特定的实施技术实 现设计机制 开发框架提供了一些常用分析机制的实现； Hibernate “持久” Spring“分布式”、“安全” 来源 分析机制 步骤 将分析机制映射到设计机制； 落实设计机制的具体内容，即实施机制； 结果 设计机制、实施机制 开发框架（Struts、Spring、Hibernate）全局设计定义从分析类到设计类的映射 依据 开发架构 结果 从分析类到设计类的映射方式 例子 StrutsSessionBeanHibernate框架 界面类jsp 业务逻辑类actionBean、delegate、sessionFacade、biz 实体类dao、po全局设计根据概念模型生成数据模型 使用RationalRose的DataModel转换功能，可以自动将概念 模型转换成为数据模型： 每个对象被建模为一张表，类名称对应表的名称，对象属性对应 表的字段； 为每个对象对应的表生成了一个Number型的ID字段作为主键； 对象之间的多对多关系被建模为关联表，关联表将两个主表的主 键作为自己的主外键，除此之外没有其他字段； 对象之间一对多关系的“一”端将“多”端的主键作为自己的外键； 继承关系：基类所对应的表将父类对应的表的主键作为自己的主 外键； 对数据模型做调整和优化； 根据数据模型生成数据库；局部设计 角色 系统设计师； 依据 用分析类描述的分析用例； 开发框架和包结构； 活动 实现设计用例和开发模型； 精化设计类的属性和操作； 结果 用设计类描述的设计用例（场景描述图和参与类图）； 开发模型；局部设计实现设计用例和开发模型依据 从分析类到设计类的映射方式； 场景描述图、参与类图； 步骤 定义设计用例及UseCase实现 设计用例可能和分析用例不一致： 分析用例：新建、修改、删除、显示； 设计用例：取得、保存、删除； 根据定义好的映射方式映射设计类，更新场景描述图和参与类图； 落实设计、实施机制的支撑作用； 根据开发框架定义开发模型，将设计类置于相应的开发模型中； 结果 设计用例及UseCase实现； 精化后的场景描述图和参与类图； 开发模型；局部设计精化类属性和操作 概念： 精化属性：名称、类型、缺省值、说明、可见度 精化操作：名称、返回值、参数、说明、可见度 依据 设计类、设计用例 结果 设计类的属性和操作被精化