OOA＆OOD（一）

一、OOA＆OOD
OOP：面向对象的编程
OOA：面向对象的分析
OOD：面向对象的设计
UML：统一建模语言(以图形来表示)
在开发中往往遇到的问题是：怎么解决一个现存的客观问题
操作步骤：
1）对问题进行分析，选择可以解决该问题的方案；
2）对方案进行设计，实现完整的设计模型；
3）在设计模型基础上进行开发(代码实现)；
4）测试;

5）维护；
---------------------------------------------------------------------------------------------------
OO开发中类和类的关系：
1.继承:A "is a" B
2.关联:A "use a" B 比如:Person和Address
 聚合:关联的特殊形式,表示has a关系,关联性较强;比如:电脑和CPU;
 组合:关联的特殊形式,表示has a关系,并且主对象决定从对象的生命周期,关联性最强;比如:容器和对象;
---------------------------------------------------------------------------------------------------
统一软件开发模型(USDP)
核心思想:迭代,递增
迭    代:将大项目分割为若干个小项目,后期小项目在前期小项目基础之上完成;
递    增:通过完成每个小项目逐步接近最终的目标;
注    意:在小项目内部的开发模型接近于瀑布模型的思想和方式;
---------------------------------------------------------------------------------------------------
80/20原则:除了项目管理人员外,几乎所有的开发角色的工作量都集中在少数的阶段中;
---------------------------------------------------------------------------------------------------
测试
单元测试:对每个模块进行测试,偏重于白盒测试,一般由开发该模块的程序员完成;
集成测试:对整个项目进行测试,偏重于对模块之间的关联进行测试(白盒),一般有测试组完成;
Alpha测试:由客户完成,在开发人员的指导下进行,偏重于黑盒测试;
Beta测试:由客户完成,完全根据使用的要求进行,一般在项目试运行阶段进行,测试方法为黑盒;
白盒:在知道代码细节的前提下进行,主要用于测试代码逻辑;
黑盒:在不关心代码细节的前提下进行,主要用于测试系统的功能;
---------------------------------------------------------------------------------------------------
产品:根据市场需求进行开发,开发完成后进行销售,一般是通用软件;
项目:根据具体客户需求进行开发,开发后由特定客户使用;
---------------------------------------------------------------------------------------------------
迭代次数:
小项目不需要迭代;
中等项目2-3次迭代;
大型项目4-6次迭代;
任何项目的迭代次数不应超过6次,超过6次迭代会使项目的复杂程序急剧上升;
二、UML
图形化建模语言,用于在OOAD中表示系统的模型,描述模型中的信息;提供了一系列标准化的图形格式,便
于在开发人员
之间传递信息;
UML开发的模型,和具体实现语言无关,在具体建模时应考虑实现语言的特性,避免设计无法实现的模型内
容;
---------------------------------------------------------------------------------------------------
UML工具
用于实现UML,有多种不同的工具产品

必须遵循UML的图形格式,但在细节上的表现可能有所不同
最常用的工具是:Rational Rose
---------------------------------------------------------------------------------------------------
有九种基本图形，可以分为两大类
静态模型(描述系统的静态特征)：
用例图：
作用：用来描述系统的用户以及提供的功能
语法：有多个"活动者"和多个用例(椭圆表示)构成活动者指的是使用系统的每一个角色
      活动者指的是使用系统的每一个角色
      用例图以功能为单位，比如页面上的一个按钮就是一个用例一个活动者使用一个用例(功能)，
      就将活动者和用例用实线连接起来，实线上可以有箭头(一般在后期细化过程中加入)，
      表示活动者在使用系统功能的时候，需要提交数据
类图：
作用：用来描述系统中的类内部的特征和行为，以及类与类之间的关系
语法：有三个长方形构成，第一个长方形描述类名，
第二个长方形描述属性第三个长方形描述方法
类跟类之间的关系描述：
继承：实线加三角形
实现：虚线加三角形
依赖：虚线加箭头
普通关联：实线，如果是单向要加箭头
聚合：空心菱形加实线，如果是单向要加箭头
组合：实心菱形加实线
对象图：
作用：描述对象的特征和对象跟对象之间的关系，通过对象图可以进一步验证类图是否合理
语法：使用一个长方形表示，内部可以描述对象名字和类型
组件图：
作用：描述系统包含的组件以及各个组件之间的关系
语法：由三个长方形构成
部署图：
作用：描述软件系统被部署之后，物理设备的信息
语法：使用立方体表示一个物理设备，各个物理设备之间的通讯使用一根实线
动态模型(描述系统的动态行为)：
时序图：
作用：系统在运行的过程中，某一个时间范围内，对象跟对象之间的交互过程，
强调的是交互的时间顺序。
语法：由多个对象组成，对象下面的虚线表示对象的生命线，
虚线上的长方形表示对象在这个区域内是处于"激活"

状态的，对象跟对象之间的实线加箭头称为Object Message表示一次调用，
对象跟对象之间的虚线加箭头称为
Return Message，表示一次返回。
协作图：
作用：描述在一定范围内，对象跟对象之间的协作关系
语法：由多个对象组成，如果对象跟对象之间有协作关系，使用实线加箭头表示。
注：协作图跟时序图可以相互转换。
状态转换图：
作用：描述在出现一些事件之后，一个对象内部状态的变化过程
语法：状态开始用一个实心圆表示
状态结束用一个实心圆外部再套一个圆表示
状态用圆角的长方形表示
状态跟状态之间的转换用实线加箭头表示，可以标注事件名字
活动图：
作用：描述一个活动的流程，一般一个活动图对应一个用例
语法：活动开始用一个实心圆表示
活动结束用一个实心圆外部再套一个圆表示
活动用圆角的长方形表示
判断用菱形表示
并发进行的活动放入泳道中，进入泳道有一个活动分离，离开泳道有一个活动的合并
---------------------------------------------------------------------------------------------------
时序图与协作图的区别:
时序图和协作图描述信息的量是相同的，只是突出角度不同，小系统一般使用时序图，
大型系统两种图同时使用作为补充；
时序图中可以表示对象的重点关注时间，该信息在协作图中是无法表示的，
但是这点并非是关键内容，实际开发时这个区别可以忽略.
早期迭代的工作量主要集中在分析设计中;
后期迭代的工作量主要集中在编码和测试中;
主要目的:方便与客户的交流,尽可能减少无效的工作量;
---------------------------------------------------------------------------------------------------
角色与对象的区别:
角色是位于系统之外的(不在系统中描述);
对象是位于系统之内的(由代码描述)；
---------------------------------------------------------------------------------------------------
OO的开发过程
1.需求分析
2.面向对象分析
3.面向对象设计
注意:中小项目可以将1和2合并进行
----------------------------------------------------------------------------------------------------

对象和类的选择
在需求分析阶段,选择问题描述中的所有名词作为候选对象和类;
在OOA阶段,在候选对象和类中选择对系统起到决定性或框架性作用的对象和类;(越少越好)
在OOD阶段,在候选对象和类中选择系统中需要的其他对象和类;
---------------------------------------------------------------------------------------------------
用例:表示系统的一个功能,用椭圆表示;
用例模型:表示系统的一个功能模块,包含若干个用例;
用例场景:用例的一个分支,用例一般包含若干个用例场景,用例场景分为主要场景,次要场景和错误场景三
种;
用例描述:以文字的形式对用例图中所有需要说明的信息加以描述,相当于用例图的补充说明;
---------------------------------------------------------------------------------------------------
活动图
分支:由单线分为多个活动,逻辑含义为多个活动可以不受干扰的同时执行;
合并:由多个活动合为单线,执行合并时,必须所有的分支都到达汇合点时才能执行,逻辑含义为后续活动必
须在所有的的分支活动都完成后才能进行;
泳道:分支中的每一个活动分支称为一个泳道;
---------------------------------------------------------------------------------------------------
风险评估(将最大最难的问题提前暴露,越早成本越低)
需求风险:由于客户的需求变更导致的风险,在现代的开发中已经属于常规情况,甚至可以不称之为风险;
技术风险:由于客观技术的原因导致项目无法实施,需要尽量避免,
需要分析人员能够及时判断技术上的可行性;
技能风险:由于人员的能力导致无法解决特定的问题,如果无法避免
可以通过内部学习或者雇佣具有相应技能的人员解决风险;
资源风险:由于外部资源导致的风险,现在几乎不存在;
政策风险:由于客观政策导致的风险,是现在开发中最主要的无法控制的风险;
---------------------------------------------------------------------------------------------------
组件图
在需求分析或OOA阶段完成,视需求分析的程度而定
---------------------------------------------------------------------------------------------------
OOA阶段会完成系统的大多数模型的构建，但主要以构建框架为主，不会涉及具体的细节问题；
OOD阶段对框架进行细化，主要工作是细化OOA阶段定义的模型图以及增加一些必要的模型图，
OOD的模型图要尽可能完整和准确.
---------------------------------------------------------------------------------------------------
普通属性:值不依赖于其他的属性活数据库中的其他字段;
推导属性:值可以由其它属性或数据库中的其它字段计算获得;
设计原则:数据库不应包含推导属性对应的字段(违背第二范式);
类设计中如果有必要可以设计信息冗余的推导属性;
---------------------------------------------------------------------------------------------------
类的关联
在分析时一般设计为双向关联,在设计阶段尽可能去除不必要的双向关联,尽可能使用单向关联;
双向关联使用实现连接两个类,代码表现为两个类中保存关联类的信息;
单向关联使用实线+开放箭头连接两个类,代码表现在箭头出发端保存箭头指向端的信息;
注意:关联的设计不影响数据库中对关联的信息保存;

---------------------------------------------------------------------------------------------------
关联的多重性
用于精确定义关联两端的实例数量
确定的:1
不确定的:*
集合:2,4,6,8
范围:3..9
对于集合和范围定义,在代码中使用多的保存机制(集合),但需要通过变量对实例数量进行控制
---------------------------------------------------------------------------------------------------
多对多关联
关系型数据库中无法直接保存多对多关联,使用关联表进行保存;
类设计时,可以不使用中间类,而在类两边都使用集合保存关联类的信息,也可以增加中间类,具体以实际情
况作为参照;
增加中间类的实质:是将多对多关联转变为两个一对多关联;
---------------------------------------------------------------------------------------------------
泛化和特化的设计继承的两种方法;
继承是设计的结果;
---------------------------------------------------------------------------------------------------
时序图/协作图描述对象之间的交互
状态图描述对象(单个)状态的改变
---------------------------------------------------------------------------------------------------
状态图的临界条件时的处理
发生情况:相同的事件可能导致不同的状态改变,而判断状态改变是通过某些具体的值确定的;
操作方法:在状态图中对临界条件进行标注,该条件是状态图事件的一部分,又成为阈值条件;
---------------------------------------------------------------------------------------------------
设计原则:在设计时应遵循的一些规则,可以提高代码的可重用性和可维护性;
设计模式:对于常见的特点问题域总结得出的解决该类问题的通用方式,类似于公式,
  当开发中遇到特定类型问题时,只需要稍作调整就可以直接实现功能,可以提高开发的效率;