OOAD(Object-Oriented Analysis and Design)介绍
1. OOAD方法论的定义
答:1) 面向对象是一种系统建模技术;
2) 将系统描述为许多相互作用的有关系对象;
3) 系统中相互作用的对象被组织成类;
4) OO方法论由以下三部分组成:
. 一个过程
. 一个符号
. 一系列规则
2. 在一个OOAD软件开发过程,我们要完成二个不同的工作:
答:1) 分析阶段我们主要:
. 建立一个清晰的商业问题的视图;
. 概述系统必须执行的任务;
. 建立商业问题描述的通用词汇;
. 概述商业问题的最佳方案。
2) 设计阶段我们主要:
. 解决商业问题;
. 定义“how”代替“what”;
. 介绍将使系统工作的支撑元素;
. 定义系统的实现策略。
3. 对象
答:1) 是单个的、唯一确认的实体或项目;
2) 作为面向对象的构建块被使用;
3) 有身份、数据和行为;
4) 可以是简单或复杂的;
5) 可以是真实或想象的;
6) 有属性和操作;
7) 是一个类的动态实例;
4. 类
答:多个相同对象的一种抽象,对象都创建自类
5. 面向对象编程的特征
答:1) Abstraction(抽象):
. 忽略细节,处理对象或实体本质的特征;
. 简化功能以及信息;
. 帮助用户和对象交互;
2) Encapsulation(封装):
. 隐藏对象的数据;
. 处理每个对象的二种视图:
a. 外部视图:显示一个对象做什么;
b. 内部视图:显示对象如何完成它的任务;
3) Association(关联)
. 对象间交互的方式;
. 一个对象使用另一个对象的服务或操作另一个对象,这时候对象相互关联。
4) Aggregation(聚合)
. 定义一个对象是另一个对象的一个组成部分;
. 是一种比较强的关联;
. 通过“Has A”关系可进行确认。一辆车有轮子、座椅以及门,它们是一部车的组成部分。假如你移除其间的任何一部分,车没有了相应的功能,但仍是一部车。
5) Composition(合成)
. 一个对象包含另一个对象;
. 是最强的关联形式;
. 通过“contain”关系可进行确认。
. 假设部件不存在,对象亦不存在。
6) Inheritance(继承)
. 是一种根据既存类定义新类的机制;
. 通过“Is A”或者“Kind of”关系可进行确认;
. 允许你组织相关类,这样这些类可共同地被管理以及重用。
7) Cohesion(类聚)和Coupling(耦合)
. Cohesion: 一个或一组类对系统中单个功能贡献程度的度量;
. Coupling: 二个或多个类间对联系紧密程度的度量;
8) Polymorphism(多态)
. 不同对象完成相同语义上的结果;
. 基于继承;
. 多态功能的实现依赖于它应用的对象;
. 举例:足球-扔-需二只手、网球-扔-只需一只手,同样是扔,有不同的实现。当你将不同的球给一个小孩子,他知道是用一只手还是二只手。小孩都知道多态。
6. 开发过程预览
答:1) 传统开发过程:
. 瀑布式开发:需求->分析->设计->实现->测试。每个步骤完成和文档化后才进入下一个阶段。
. 假设在后期阶段出现问题,很难返回到先前阶段。
. 项目组成员花费大量时间和精力于每个阶段确保它是正确的.
. 各阶段所用符号和术语均是变化的。完成的软件虽然正确,但与它所表现的商业逻辑相关甚少。
2) OOAD开发过程
. 典型的处理方式是将一个项目作为一系列的小项目;
. UML(Unified Modeling Language)是一种符号,不是一个处理过程;
. USDP(Unified Software Development Process)是迭代增量式的;
. USDP和RUP(Rational Unified Process)都是流行的OOAD过程。
7. 迭代增量式项目生命周期
答:1) “迭代”指生命周期中每一个步骤;
2) 迭代的结果便是整个项目功能完成的一步步增长;
3) 在每个迭代的构建阶段,你应该:
. 选择并分析相关的用例;
. 使用选择的体系结构创建一个设计;
. 用组件实现设计;
. 检验组件满足用例。
8. 迭代增量生命周期的主要阶段
答:1) Inception(开始)阶段:
. 这个阶段的增长集中在:
a. 开始项目;
b. 为这个项目建立起商业原则;
c. 定义一个商业问题;
d. 识别潜在的风险;
e. 定义对问题更好理解的范围;
f. 创建对商业问题的解释文档。
. 每个循环包括一至多个反复,每个阶段的完成结果都是里程碑式的。
2) Elaboration(细节)阶段:
. 这个阶段的增长集中在:
a. 高水平的分析和设计;
b. 为项目建立一个架构体系的基线;
c. 监测潜在的风险;
d. 创建一个实现项目目标的构建计划;
3) The Construction(构建)阶段:
. 这个阶段的增长集中在软件项目日益成型;
4) The Transition(跃迁)阶段:
. 这个阶段的增长集中在:
a. 发布产品给客户;
b. 完成beta测试;
c. 实现性能调整、用户培训以及接受度测试。
9. 阶段期间的工作步骤
答:1) 每个阶段由以下五个工作步骤组成:
. 需求
. 分析
. 设计
. 实现
. 测试
2) 不同的反复对每个工作步骤完成的程度不同;
3) 早期的反复在深度上覆盖了第一个工作步骤,以后的反复在深度上覆盖了最后的工作步骤。
4) 8/2原则:假如完成了80%, 即可进入下一个反复。
10. 反复和工作步骤
答:1) 在每个反复过程,根据需求你可以包括五个工作步骤中的任何一个。
2) 早期的反复过程集中在靠前的工作步骤,后期的反复过程集中在靠后的工作步骤。
3) 当你发现应该修改早先工作步骤中的某些错误,你可以:
. 继续并在下一个反复过程中修正;
. 继续并增加一个新的反复过程修正问题;
. 假如时间允许,返回到当前的反复并修正这个问题。
4) 不同的反复执行每个工作步骤于不同的程度。
11. 迭代增量生命周期的好处
答:1) 减少费用;
2) 对项目进度的更好保证;
3) 对于开发团队而言开发速度更快;
4) 可适应用户需求的改变;
UML(Unified Modeling Language)介绍
1. UML定义
答:1) UML是一种图形化语言用于:
. 说明;
. 构建;
. 肉眼观察;
. 文档化系统原型;
2) 在分析阶段,你创建类图以帮助你理解商业概念(还没有实现的细节);
3) 在构建阶段,我们通过为相同的类图增加附加的细节——实现商业细节;
2. UML和蓝图的关系
答:开发OOAD程序——UML
建房——蓝图
3. UML图形类型
答:1) 静态模型:代表你正在建模的软件系统的基本结构;
2) 动态模型:强调了系统的行为;
4. 静态模型
答:1) 构建以及文档化一个系统的静态方面;
2) 反映了一个软件系统基本的、稳定的框架;
3) 创建问题主要元素的代表;
4) 由以下图形组成:
. 用例图
. 类图
. 对象图
. 组件以及部署图
5. 动态图
答:1) 构建显示系统行为的图形;
2) 由以下图形组成:
. 时序图
. 协作图
. 状态图
. 活动图
6. 用例图
答:1) 显示谁或什么使用系统以及它的特征;
2) 一个用例图中特征的用户称为“actors”;
3) 用例用椭圆表示;
4) 为使建模容易,用例图需区分先后顺序;
7. 类图
答:1) 代表一系列包含普通属性和特征的对象;
2) 结构化的图形显示了一系列的类、接口、对象间的协作以及关系;
3) 由一至多个描述了以下信息的矩形组成:
. 类型(类名)
. 可选择的属性
. 操作部分
8. 对象图
答:1) 代表一个明确的对象
2) 结构化的图形显示了一系列对象以及他们之间的关系
9. 组件图
答:显示软件组件间的关系
10. 部署图
答:显示能用于部署软件应用程序的物理设备
11. 时序图
答:1) 不同对象一定时间范围发生的消息;
2) 强调消息的时间顺序
12. 协作图
答:1) 显示了使用消息期间对象间的协作;
2) 强调发送和接收消息的结构化组织;
13. 状态转换图
答:强调对象行为的事件顺序
14. 活动图
答:1) 描述一项活动到另外一项间的流程
2) 强调一项活动到另外一项间的流程
15. 包的符号
答:1) 指组织项目的一种方式;
2) 通常用于控制类的名域空间;
3) 在UML中使用包组织类、软件组件、硬件组件、其它包以及和你模型相关的任何其它东西
2004-11-5 星期五 阴
需求和初始化分析
1. 开始开发过程
答:1) 分析最初的工作流;
2) 收集信息;
3) 创建一个问题的状态;
4) 创建用例;
5) 引介组件以及部署图;
2. 收集信息
答:你可从许多资源中收集信息,这些资源包括:
. 用户的初始化需求详情
. 行业专家
. 顾客和用户
. 管理者
. 市场
. 以前类似项目
3. 避免习惯性的假设
答:1) 你必须避免习惯性的假设,包括:
. 用户是天真的,开发者最清楚
. 需求是静态的
. 一开始便能建立正确的方案
2) 记住项目的发展以及客户的需求均是变化的。
3) 为了避免这些假设,我们应该:
. 明确用户的需求
. 确保你的模型能适应不断变化的需求
. 确保你能修改你的模型
4. 行业专家
答:1) 指某个特定商业领域的专家
2) 可大致细分为:
. 通用行业专家
. 特定应用程序行业专家以及当前商业领域专家
. 类似商业领域专家
3) 没有行业专家,从其它领域抽象通用元素很困难
5. 问题声明
答:1) 文档清楚地描述了客户和系统需求吗?
2) 用户输入对于文档很重要
3) 使用客户熟悉的语言词汇
4) 句义清楚,不用行话
5) 函盖项目范围内的细节
6) 详细说明问题的背景
7) 详细说明所知的约束
8) 问题声明提供了关于商业背景、范围以及计算机术语无关方面的约束。它用于作为确认问题范围的基础。
6. 对象和类的侯选值
答:1) 可从问题声明中确定
2) 给问题声明中的名词短语加下划线以建设对象和类侯选值列表
3) 在接下去的分析阶段,你需要确定你系统中所需的对象和类的列表
7. 数据字典
答:1) 描述了用于项目所有词汇的文档
2) 通过和用户沟通积累所得的条款
3) 用于整个项目和系统
4) 在整个项目期间会不断地加入新的术语
5) 帮助消除歧义
6) 必须对所有项目组成员可用
7) 数据字典对于大型项目中各团队沟通非常重要。这时,它既是商业文档也是系统文档。
8. 创建用例
答:1) 一个用例是用户和系统交互的图形化的表现形式;
2) 是定义和理解系统需求和背景的工具;
3) 是任何系统某一方面的简单印象。当你将所有印象收集在一块,你便拥有了系统的整个描述;
4) 图形具体表现为实线的椭圆。
9. 用例图中的“include”和“extend”
答:1) “include”集中于包含关系,完成某个模块之前,你必须使用另一个模块;
2) “extend”集中于扩展关系,也许或也许不基于某个模块,不是强制性的;
10. 用例中的情节假设
答:1) 用例从用户的角度显示了软件的功能。也许存在超过一种方式完成一指定功能。
2) 一个假设情节指用例的一个实例——从开始到结束的一个逻辑路径。
3) 情节假设不包括有条件的声明——因为它们描述了用户多个可能路径中的一种。
4) 所有的情节假设从相同的方式开始,但结果却不同。
5) 一个用例中成功或不成功的路径都应该显示出来——在一个ATM中,你必须考虑一些情节诸如用户个人身份号码输入不对或者金额不足。
11. 用例表单
答:1) 每个用例的摘要
2) 用例表单不是UML的内容,但是建议完成它。
3) 在这个表单中,包括以下项目:
. 用例名称
. 参与者
. 优先权
. 状态
. 扩展内容部分
. 预处理/假想情节
. 提交条件
. 事件流
. 可选路径
. 执行
. 频率
12. 活动图
答:1) 创建用例图后,你可以使用图形说明活动或工作流
2) 图形化了所有用例假想情节
3) 显示活动、过程或工作流
13. 风险评估
答:1) 有必要对项目进行风险评估
2) 用例可以是风险评估的起点
3) 高风险的用例应该在早期的迭代中开发
4) 风险能出现在以下方面:
. 需求风险
. 技术风险
. 技能风险
. 资源风险
. 政策风险
14. 需求风险
答:1) 需求风险指没完全满足客户需求
2) 你应该使工作于该系统的所有用户和管理者都参与进来
15. 技术风险
答:记住已证实过的技术比未证实的技术所冒风险要小
16. 技能风险
答:确信你有所需的全部技能
17. 资源和政策风险
答:1) 资源风险指超出时间和资金预算
2) 政治风险指与现行的政治规则冲突
18. 包图
答:1) UML中存在符号以包装任何逻辑相关的UML元素(类、对象、用例等等);
2) 就像Java一样,相关的类组织成不同的包;
3) 这个符号像文件夹图标;
4) 有助于降低复杂性;
5) 包间可存在依赖关系;
6) 包有助于:
. 查看没有太多细节的大图;
. 查看独立的小部分;
. 创建部件中的一小部分;
. 显示组件间的依赖性;
. 组件图显示了代码物理组织形式,可以是一个类文件、Java源文件、jar文件、Java中的包、共享库、对象代码、RDB等等;
. 当一个组件改变,它能影响其它——依赖性;
. 组件应该有一个良好的接口,这样你可以使用其它实现该接口的组件去替换它。
19. 部署图介绍
答:1) 显示了硬件组件间的物理关系;
2) 每个符号代表了一些硬件设备:服务器、工作站、个人PC、传感器、时钟、电话交换机等。
3) 当你获得信息的时候可在任何阶段添加以及修正。
4) 符号间的连接伴随着协议一起显示。
系统对象和类分析
1. 分析阶段的理解
答:1) 定义系统必须做什么;
2) 避免描述和实现的问题;
3) 专注于系统的组件;
4) 分析阶段确定对象在运行时需要什么以确保系统正确的功能;
5) 分析阶段在需求收集阶段和用例阶段之后,在系统设计阶段之前;
6) 在确定哪些是类和对象的时候,你应该回答以下问题:
. 什么对象组成了这个系统?
. 什么是可能的类?
. 每个对象或类的责任是什么?
. 对象和类间是如何相联系的?
7) 记住将所有新项目加入数据字典;
2. 关键字的提取
答:1) 当你定义组成系统的对象时,你应该创建一个满足系统功能对象的列表;
2) 列表中的对象称为对象侯选值;
3) 然后你可以为这个列表中最重要的对象准备一个子列表;
4) 关键字代表了系统中主要或第一位的对象;
3. 用UML表示对象和类
答:1) 对象模型显示了逻辑和特理的静态视图;
2) 对象模型有二种图:
. 类图:显示了你必须创建一个系统所需的类。在运行时你可使用一个类创建许多对象。类图必须显示类间所有可能关系。
. 对象图:代表了系统中真实的对象,描述了特定案例中外在关系。
3) 你可以使用主键去创建类图和对象图。
4) 类图在整个分析阶段都会被更新和修正。
4. 属性和方法
答:1) 对象包含了定义对象状态的属性;
2) 方法定义了对象能执行的操作;
3) 因此类必须定义这些属性和方法;
4) 在类执行之前,你必须定义所有的属性和方法;
5) 但是很多属性和方法到设计阶段才知道,加上所有你能加的先;
6) 在设计阶段存在的属性和方法足够了,但是他们的类型和参数还不够。
5. 属性和方法
答:二种类型的属性:
. 普通属性:是一个对象中真实存在的变量或常量。一个普通属性将会存储对象中一些有意义的值。
. 衍生属性:并未存储在系统中,通过系统中其它信息计算得出。
6. 联接和链接
答:1) 联接——针对类而言
. 指类图中用直线表示的关系;
. 线可以是水平也可以是垂直的;
. 可以在关系线上给一个逻辑名称描述这个关系;
2) 链接——针对对象而言
. 指对象图中二个对象间的关系;
7. 联接和多样性
答:1) 多样性显示了一个类中对象和另一个类中对象联系的可能性;
2) 在类图中,每个类只有一个矩形,因此联接会确定一个类有多少个对象链接于另一个类的对象;
3) 联接线的末端有标记;
8. 多样性的值
答:1) 2: 刚好二个;
2) *: 0至多个;
3) 5..15: 5到15个;
4) 2,4,6: 2、4、6个;
5) 10..*: 最少10个;
6) 0..10: 最多10个;
9. 复杂性的联接
答:1) 多样性标记“*”出现在联接的两端;
2) 你命名了类图中所有联接并分配了多样性后,是时候重新审视他们并尝试解决复杂联接。可使用联接类或符合条件联接。
10. 联接类(类似于数据库中索引表)
答:1) 这意味着联接它本身必须编码为一个类,这个类带有解决冲突的属性;
2) 这种技术用于分析阶段解决多对多关系;
11. 符合条件的联接
答:1) 通过使用属性值可解决多对多问题;
2) 分配一个唯一的属性值;