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

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