OOA面向对象分析
面向对象分析产生三种分析模型
功能模型(即用例模型à作为输入)
对象模型:对用例模型进行分析,把系统分解成互相协作的分析类,通过类图/对象图描述对象/对象的属性/对象间的关系,是系统的静态模型
动态模型:描述系统的动态行为,通过时序图/协作图描述对象的交互,以揭示对象间如何协作来完成每个具体的用例,单个对象的状态变化/动态行为可以通过状态图来表达
OOD面向对象的设计
OOD是对OOA的细化
没有严格的界线
OOD的结果直接用于编码
与OOA的输出一样，只是更加详细完善
OOA与OOD的区别
OOA偏重于理解问题，描述软件要做什么，而OOD偏重于理解解决方案，描述软件要如何做
OOA只考虑理想的设计，不关心技术与实现底层的细节，而OOD需要得到更具体详细更接近于真实的代码的设计方案
在设计结果的描述上，OOA偏重于描述对象的行为，OOD偏重于描述对象的属性与方法
OOA只关注功能性需求，OOD还需要关注非功能性需求
OOA步骤
从用例中提取实体对象／实体类
添加边界类
添加控制类
提取类的属性（一般省略，放到OOD中）
提取分析类间的关系
绘制类图／时序图
编制术语表(可选)
三种分析类
分析类
实体类(Entity Class)
边界类
控制类
实体类
是应用中的核心类
与现实事物相对应的类
用于长期保存系统中的信息,以及针对这些信息的相关处理行为
一般实体类的对象和应用系统本身有相同的生命周期
边界类
从与那些系统和外界进行交互的对象中归纳和抽象出来的
边界类是系统内的对象和系统外的参与者的联系媒介
外界的消息只有通过边界类的对象才能发送给系统
大多数为用户界面(表示层)
控制类
管理实体对象与边界对象之间的交互的仲裁对象
通过控制类协调系统内边界类与实体类之间的交互
1、提取实体类
用例驱动:从用例模型中找名词或名词短语,再进行筛选
候选实体类:用户/帐户/系统管理员/聊天服务器/消息
用户在系统中表现为帐户,因此用户就不需要了
本项目中系统管理员仅完成启动/关闭系统的作用,而没有其他管理任务,也不需要作为一个实体类
聊天系统:代表整个系统,大多数情况这个实体对象不必存在
聊天消息:聊天的内容本项目不需要保存
可以得到实体类: 帐户类
2.添加边界类
交互型软件的边界类就是用户界面
边界类:
注册界面:注册类
登陆界面:登陆类
聊天界面:聊天类
3.添加控制类
有人认为每个用例确定一个控制类,但可能会得到很小的控制类,应该考虑进行恰当的合并
我们项目可以把注册/登陆/聊天用例合并为一个控制器类
4、提取属性
建议放到设计时再提取，因为现在只能对属性进行与语言无关的描述
5、提取分析类之间的关系
一对一
一对多
多对对
归纳关系
6、绘制类图(参见demo)
7、绘制时序图(流程简单可省略)
8、编制术语表(罗列系统模型中需要澄清的术语)
架构分析
架构分析主要从宏观上考虑一个软件系统应该如何组织
目的:通过科学的解析,将整个软件系统划分为不同的组件,并准确定义出组件和组件之间的接口
最典型的架构模式:分层模式(Layer),客户/服务器模式,MVC模式等等
获得架构图
OOD步骤
细化重组类
细化和实现类间关系,明确其可见性
增加属性,指定属性的类型与可见性
分配职责,定义执行每个职责的方法
对消息驱动的系统,明确消息传递方式
利用设计模式进行局部设计
画出详细的类图与时序图
|
|
