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

ooa(object oriented analysis)面向对象分析 ood(object oriented design)面向对象设计 如所熟知,面向对象作为一种程序设计技术最早于60年代后期提出,用于Simula的应用程 序开发。到了70年代,面向对象成为Smalltalk语言的一个重要特征。当时,面向对象技术主要 用于程序设计。进入90年代,人们的注意力逐渐从程序设计转向系统分析和设计,用对象的观 点来认识现实世界、设计问题的可行解,随之也就出现了许多OOAOOD方法。但这些方法 还不很成熟,在OOAOOD的边界划分上也存在着争议。如:有人认为面向对象软件开发 过程可以分为面向对象分析、面向对象设计和面向对象程序设计三个阶段;有人认为分析和设 计可以交叉进行不必做严格区分;还有人沿用传统方法进行分析和设计,用面向对象程序设计 语言来实现系统。O OA/OOD的一些较有代表性的工作有Gray.Booch的OOAD方法,Coad&Yourdon的 OOAOOD方法,Shlaer&Mellor的OOA方法,Rumbaugh的OOAD方法等。不同的方法 体系都分别体现了人们对OOAOOD,以及面向对象软件开发过程的不同认识。本文的主要 目的就是,试图通过对现有OOAOOD方法的共性进行纵观分析,弄清二者之间的边界问 题,评析从OOAOOD过渡的难易,并讨论实现这种过渡所涉及的主要工作。 ooa:分析阶段所做的主要工作是理解问题和需求构模,将现实世界中的问题映射到问题域。在该 阶段,要明确用户提出了哪些功能要求,为完成这些要求,系统应有哪些构件,采用什么样的结构,并写出详细的需求规约。OOA中引入了许多面向对象的概念和原则,如,对象、属性、服务 、继承、封装等,并利用这些概念和原则来分析、认识和理解客观世界,将客观世界中的实体抽 象为问题域中的对象,即问题对象,分析客观世界中问题的结构,明确为完成系统功能,对象间 应具有的联系和相互作用。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值