UML面向对象建模与设计——笔记(二)

UML面向对象建模与设计(第二版)笔记——第二部分:分析与设计


1.开发过程

开发过程由以下几个过程:系统构思,分析,系统设计,类设计,实现,测试,培训,部署,维护。

1.1.系统构思

构思一项应用并系统的猫叔临时性的需求。

1.2.分析

注重模型的建立。通过创建模型来捕获并审视需求。在需求分析阶段,开发者需要考虑如何利用现有的信息资源(文档,业务会谈和相关的应用)并消除歧义。

系统包括了两个子阶段:领域分析和应用分析。领域分析关注的重点是真实世界中传达应用语义的内容。领域分析强调的是概念和关系。应用分析描述的是应用为用户可见的计算机层面,描述应用从外界看来会是什么样子——应用黑盒视图。

1.3.系统设计

需要尽可能详尽的描述架构,并选择全局策略和政策来指导后续更加详细的设计。架构是用于解决应用问题的高层计划或策略。架构应该包含一个可执行的和可测试的基本框架。设计人员必须掌握一套新系统是如何对其他系统进行交互的,也要支持应用程序的未来修改。

1.4.类设计

扩充并优化分析模型,决策算法。

1.5.实现

实际编码过程。

1.6.测试

审视原始业务需求,验证系统是否交付正确的功能。
测试应该在几个层次上:单元测试,系统测试。

1.7.培训

培训是祖苏用户的软件学习过程。

1.8.部署

系统必须能在不同的平台上用不同的配置完成实际的工作。

1.9.开发生命周期

OO软件开发常用的方法:瀑布式开发和迭代开发。

瀑布开发指开发者严格顺序执行软件的开发阶段,不需要回溯。这在需求频繁改变的项目中会出现直到借宿才能交付,在项目出现偏差的时候加大评估进度和纠正项目的难度。

迭代开发需要一个过程的基点(分析,设计,实现和交付),在扩大范围,增加已有对象的属性和行为,以及增加新的对象,这是一个迭代的过程。每次迭代都包括完成的一套阶段(分析,设计,实现和测试),每次迭代都可以有目标的实现,这也有助于评估进度,及时调整计划。


2.系统构思

系统构思的目的是延迟细节实现,并理解完整图景。考虑系统具体的可实现性。
系统构思的过程主要有以下几个方面:

1>.阐释概念

即考虑系统的可行性和原始目的用途和价值。

2>.准备问题陈述

问题陈述可以构建系统的目标和总体方案。问题陈述应该描述要完成那些事,而不是如何实现,应该是需求陈述,避免描述系统内部机制和系统架构。


3.系统分析

3.1.领域分析

领域分析是关注设计一套精准简洁的,可以理解正确的真实世界模型。
创建领域模型,要与业专家交流,检查需求描述和审视相关制品。重新陈述,抽象终于特征,推迟细节。

分析模型描述对象的三个方面:对象的静态结构(类模型),对象间的交互(交互模型)和对象的生存期(状态模型)。我们需要对分析模型进行不断地迭代,细化分析模型。

1>创建领域类模型

分析过程中,类模型的优先级要高于状态和交互模。
创建领域类模型,需要经过以下几个步骤:
1.寻找类
2.准备数据词典
3.寻找关联
4.寻找对象和连接的属性
5.使用继承组织和简化类
6.验证可能查询的访问路径
7.迭代并细化模型
8.重新考虑抽象的层次
9.把类编组成包

2>.分析领域状态模型。

构造领域状态模型的步骤:
1.确定具有状态的了领域类
2.寻找状态
3.寻找事件
4.构造状态图
5.评价状态图

3>.领域交互模型

这个步骤在领域分析过程总并不是特别重要,而在应用建模时会是重点。

3.2.应用分析

应用分析模型包括应用交互模型,应用类模型,应用状态模型。

1>.应用交互模型

完成领域建模之后,我们要考虑应用程序中的细节,考虑进一步的交互。通过系统的整体边界来开始交互建模。

交互建模的具体步骤如下:
1.确定系统边界。
即应用程序的准确范围。
2.寻找参与者
3.寻找用例。
用例将系统功能划分成少数离散单元,所有的系统行为必须在某种用例之下。我们可以写几句小结来详细描述用例。
4.寻找初始和终止事件。
初始事件是触发连串的活动事件。终止事件是用例最后的结果。
5.准备普通场景。
场景是指一组交互对象之间发送的一系列事件,主要描述了主要的交互,外部显示格式,信息互换等。
6.增加变化和异常场景。
包括一下被忽略输入错误,计算错误错误,无效操作及一些异常非法情况。
7.寻找外部事件。
包括所有输入,决策,中断以及用户或者外部设备额往来交互。应该为某一种场景都准备一张顺序图,顺序图显示了交互过程中的参与者和他们之间的消息序列。
8.编制复杂用例的活动图。
用顺序图捕获参与者之间的对话与相互作用。可以用一想描述主导交互流的顺序图,还需要描述每种错误和决策点的其他顺序图。
9.组织参与者和用例。
用关系(包含,扩展,泛化)来组织用例。
10.检查领域类模型

2>.应用类模型

具体步骤如下:
1.确定用户界面。分析阶段的重点在信息流的控制,而不再表现格式。可以通过草拟一份示例界面来帮助我们将应用程序的操作可以可视化。
2.确定边界类。边界类可以理解为一个或多个外部资源的格式,可以让传输信息在外部和内部系统之间传递。
3.确定控制器。控制器是一种管理应用程序内部控制权的主动对象。他接受外界或系统的内部对象信号,并响应并回调操作。
4.检查交互模型。

3>.应用状态模型

应用状态模型专注于应用类,扩展了领域类模型,拥有了重要的时序行为。

应用类状态的构造步骤如下:
1.使用状态来确定应用类。
2.寻找事件。从前面的交互模型的大量场景中,提取事件。
3.构造状态图。用时序行为构造诶一个应用类的状态图。
4.检查其他状态。检车每个类的状态图的完整性和一致性。每次事件都应该有一个发送者和一个接收者。
5.检查类模型。要确保状态图和领域和应用类模型的一致性。
6.检查交互模型。


4.系统设计

在系统设计的过程中,我们要设计高层策略,及系统架构,用于给构造问题的解决方案。我们要做出决策,把系统划分成多个子系统,给每个子系统配置软硬件资源,并形成可以作为类设计基础的主要策略。

系统设计阶段,必须完成下面的决策(并不完整):
1.估算系统性能
2.制定复用计划
3.将系统划分成子系统
4.确定问题内部的并发性
5.配置子系统的硬件
6.管理数据存储
7.处理全局资源
8.选择软件控制策略
9.处理边界条件
10.设置权衡优先级
11.选择架构风格


5.类设计

类设计的目标是完成类和关联的定义,并选择操作的算法。
类的设计是以分析模型为基础,根据系统设计的粗略引导做决策,充实分析模型的类。
分析模型描述了系统必须包含的信息和必须执行的高层操作,我们可以把分析类直接带到设计阶段。类设计就变成了增加细节和执行精细决策的过程。

类设计包括以下几个步骤:
1.填充从高层需求及到底层服务中间的空白
2.用操作实现用例
3.阐述每个操作的算法
4.向下递归到支持更高层操作的设计操作
5.把模型重构成更简洁的设计
6.优化数据的访问路径
7.具体化必须操作的行为
8.调整类的结构以增加继承
9.组织类和关联

5.1.填补空白区

想要系统实现的功能与可用资源之间的差距就是空白区。
高层需求有几项来源:用例,应用程序命令以及系统操作与服务。资源包括操作系统架构,类库和以前的应用程序。填补空白区可以发明一些中间元素,如果系统复杂,还需要将中间元素划分成多层。中间元素可以是操作,类或者其他UML制品。

分解高层的操作首先要先推测出一组中间操作,然后试着把它们构建出来。把这些相似的操作合并成数量更少的公共操作,可以降低代码规模,增加清晰度。

5.2.实现用例

首先我们需要列出用例或者操作的职责。每项操作有不同的职责,一些操作又会别别的操作共享和复用,需要将职责组织成簇,并努力保持簇的一致性。接着要定义每个职责簇的操作。最后把新的低层操作分配给类。

5.3.设计算法

1>.选择算法

选择算法的考虑因素:计算复杂性,易实现和可理解性,灵活性。

2>.选择数据结构

数据结构不会给分析模型增加信息,但他会将信息以方便算法的形式进行组织,许多数据结构都是容器类。

3>.定义内部类的操作

在分解高级操作的过程中,我们需要创建新的低层操作;在拓展高层操作的时候,也需要增加新的外部操作。
算法的拓展可能会引导创建新的对象类,来保持中间结果。客户对问题的描述一般不会提到这些底层的类。

4>.把操作分配给个类

必须确定在操作中由哪个对象扮演领导者的角色,考虑以下问题:活动的接收者,查询与更新,焦点类,与真实世界的类比。

5.4.向下递归

设计的过程一般是有向上而下的。向下递归主要有2种方式进行:按功能递归和按机制递归。
任何大型系统都会混用功能分层和机制分层。完全功能分层递归出来的系统是脆弱的,对于需求变化过分敏感。完全用机制递归出的系统实际上不能完成任何有用的工作。

1>.功能分层

功能递归意味着采用必要的高层功能,并将它拆成更小的操作。需要邦正组合了相似的操作,并在类上附加了这些操作。同时,必须把操作依附与类上,并拓宽它们以求复用。仔细地附着在类上的操作比起自由变动的功能,风险要小。

2>.机制分层

机制递归意味着要从需要的支持机制的分层中构造出系统。在提供功能的时候,需要不同的机制来存储星系,序列化控制,协调对象,传输信息,执行计算以及提供其他类型的计算架构。

5.5.重构

重构定义成软件内部结构的变化,在不改变外部功能的情况下改进其设计。这表示如果我们后退一步,纵览一下多个不同的类和操作,将他们重新组织,以便更好的支持开发工作。

5.6.设计优化

设计系统的一种好方法是首先保证逻辑的正确,然后对逻辑进行优化。最好是集中在关键领域考虑优化,而不是平均分配工作量。
优化设计涉及了一下几个任务:
1.提供高效额访问路径
2.重新调整计算,以求达到更高的效率
3.保存中间结果,以免重新计算

5.7.具体化行为

具体化是指将非对象的内容提升为对象。行为通常符合这种描述,但并不是我们习惯操作的内容。如果将行为具体化了,就可以存储他,将其传递给其他操作以及转换他。虽然具体化增加了复杂性,但也大大的拓展了系统的灵活性。

5.8.调整继承

随着类设计的进行,为了增加继承性,通常要调整类和操作的定义,可以通过执行以下步骤完成:
1.重新调整类和操作移增加继承
2.从分组类中提取公共行为
3.当继承在语义上不合法的时候,要使用委托来共享行为。

5.9.组织设计

程序里包含了一些离散的实体单元,这些单元可以被编辑,导入或者操作。我们可以使用以下步骤来改进类设计的组织方式
1.隐藏内部信息,使不为外部视图所见
2.维护实体的一致性
3.微调包的定义

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页