研究分析之后呢我们就要进入另外一个阶段,叫系统分析阶段。
这个实际上这个,我们这个课程中
所定义的这个分析实际上包括需求分析和系统分析,但是二者是 截然不同的两个阶段。
这个需求分析呢这个视角是主要是黑盒的一个视角, 就是说把这个系统看成是一个黑盒子,这里边是什么我们先不用管它,
我们主要是考察它与外界的输入和输出,它与外界 哪些对象发生关系。
这时候呢,但是到系统分析的时候呢我们要 用白盒的这种方式,我们要推测一下
用,当然是,不是胡乱推测,而是要 结合我们课程中,课本上的一些这个技巧和策略
我们这个通过一定的过程来推测我们这个系统 到底,这个内部到底有哪些结构。
就是 面向对象视角来看就是它有哪些对象,哪些类,以及它们之间的关系。
这个东西呢并不是 非常这个,主观性很强的,
而是呢必须得遵守一定的 类和对象,或者说关系的一些识别策略。
这样的话呢 这个分析出来才能是一个非常好的一个分析模型。
但是这个分析本身呢 和设计的区别呢,也是有很大的区别的。
因为这个分析本身 尽管它是一个白盒的,设计当然也是白盒的,但是我们分析主要侧重在什么呢?
主要侧重在这个业务本身。
也就是说用这个比较专业的术语,那就是用 侧重于问题域和系统责任。
这二者呢又有一些区别,这个什么却别呢我们 在后续的课程中会详细给大家介绍。
所以这里我们给大家简单 看一下这个分析到底做什么。
首先我们了解它是一个白盒的。
既然是白盒的话,那就是它的关注点就是在系统内部而不是系统边界上。
所以呢在 系统分析的时候呢我们画的这个模型,建的模型呢和这个,我们这个
需求分析的时候的模型是截然不同的。
我们需求分析只是做一个 usercase,我们在系统分析的时候 就是需要做这个类图和顺序。
下面我们这个看一下这个系统分析 的时候建立哪些模型。
第一个呢就是需要建立类图。
这个类图呢实际上是 本身的它的这个观察范围就是把视角呢从系统之外或系统边界上 移动到系统内部。
从这个,以前我们在做需求分析的时候它是个 黑盒,系统里面到底什么结构我们不管它。
现在我们要 打开这层这个窗户,我们要看一下这个系统内部究竟是什么样。
这实际上呢 这种研究思路实际上是在处理任何工程问题和科学问题是通用的一种方式。
我们在进行科学研究的时候,当我们不知道这个原子内部有什么结构时候,或者我们不知道离-
我们很遥远的这个 一个天体到底这个内部什么结构时候我们所做的
也就是通过它的输入和输出,来 猜想它内部有什么结构。
而我们做面向对象这个系统分析,系统设计时候, 这种视角或者这种方法也是类似的。
所以我们这些本身建立的模型,和科学中的模型本身,在这一点上 是一样的。
并且我们建立这个模型本身呢也是需要进行这个证伪的,需要 进行测试,需要进行评估,来确定我们是不是符合这个要求。
所以我们在建立这个类图的时候呢实际上就是我们 通过输入和输出,我们推测,猜想这个
系统内部究竟应该有哪些对象,有哪些类。
但是这个 我们在做需求分析和系统设计的时候都是在猜测,但是二者视角不同:一个是
针对我们的业务本身,而在设计时我们要针对
这个我们的这个技术,如何从技术上来支持这个 我们的这个业务。
一个就是, 简单说一个是面向现实世界,一个是面向这个 软件世界。
但是呢二者的边界呢也不是很清晰,我们在后续系统分析 结束之后,我们在进一步系统设计之前呢,我们要详细的
为大家呢分析系统,分析和系统设计之间的这条边界。
这个我们回到这个当前的这个 我们这个系统分析来。
在当前的这个游戏上, 如何识别这个类呢?这个识别类的这个时候呢,实际上呢 就涉及到一些策略。
首先呢我们要从系统边界上来找。
比如说这个游戏者, 这是我们这个参与者本身,在参与者本身他是作为系统边界之外的一个 对象。
但是呢我们在 识别类图的时候呢我们往往,或者说
绝大多数情况下我们要将这个游戏者,这个参与者,这个外界参与者呢
要拿到这个系统边界里,之内,作为系统的一个 类来进行这个考察。
这是为什么呢?有些同学可能 很多同学如果说是从这个直观上来说,觉得这样好像是 有一些这个不合理。
实际上这样确实是有它的一些 道理在里面。
至于什么道理呢?我们在 后续的系统分析这个阶段我们会给大家详细的 这个解释。
所以第一个我们识别出来的就往往是这个参与者,这个游戏者。
另外呢,这是一种视角。
另外呢我们还可以从这个 现实世界中这个角度来进行描述。
比如说现实世界, 本身这个真正的空战场景中究竟有哪些对象?
个比较符合我们自然人这种思维方式,在这个 真正的战场上那有战斗机,有各种各样的一些
这个子弹,子弹乱飞,然后还有各种各样的给养,这些都是我们可以想象到的
在现实世界战场上有的那些东西。
这个还有就是本身战场也是一个
容器,它所有的这些战斗机啊,给养啊,子弹啊都是在战场上 才能够运行的。
它也是这个一个现实世界中的一个 非常重要的一个类。
还有一些事件,比如说这个爆炸事件,这是
尽管它持续时间非常短暂,但是呢它也是可以作为一个对象,一个类来进行识别的。
那就是类和对象 不仅描述一些看得见的,摸得着的,也可以描述一些非常瞬间发生的,这些事件也可以作为-
一个类。
这个关于这个类和对象识别实际上是我们在类图中重点跟大家给大家介绍的。
这个另外呢 还有一个可能是大家可能考虑不太到的,就是这个 一些这个补给器。
这些东西本身是在战场没有的,但是呢是我们这个 Usercase 我们这个需求分析的时候要求的系统责任。
这个东西呢实际上呢 系统责任和这个问题域,本身是这个两个
相互交融但是有各自不同的两个概念,这个我们到时候也会给大家详细描述。
另外呢在识别完这些类之后,我们呢要建立各种关系。
建立关系呢 最主要的就是,一个就是关联关系,一个就是 泛化关系,也叫继承关系。
其中呢这个关联关系呢又包含这个 聚合关系或者整体部分关系。
这里呢 所有的这些战场上出现的这些
事物呢我们都可以认为它们是统称为一个精灵, 然后精灵呢进一步分为子类:分为爆炸, 自行装备和携带武器。
这样的话我们非常,用一种比较自然的这种思维方式 来进行这个分类。
自行装备呢包括 战斗机和给养,但是二者运动方式是不同的:给养是
做自由落体运动,而战斗机呢可以有动力,可以这个 进行这个上下左右的这种移动。
然后这个携带武器本身呢我们这个这里只是把,
由于我们当前是一个教学型的这么一种系统,所以我们只是 做了一种子弹这么一种武器。
但是我们为什么这时候要 将子弹和这个携带武器之间要建立一种泛化关系,那就是因为我们以后
便于我们这个系统进行扩展用的。
我们以后如果想进一步完善的话, 做一些更有威力性的一些武器,像这个导弹,火箭等等。
这时候呢我们直接可以从这个携带武器 这个类中呢进行扩展,这样的话呢就非常便于我们这个系统进行扩展。
实际上这个 为以后的复用创造条件,实际上就需要在
分析阶段,甚至是这个需求分析阶段就应该考虑的一个问题。
这个这也是我们建立模型的时候一些这个 重要性的体现。
如果我们直接编程序的可能没有来得及考虑这些问题,但是我们在一个更
抽象的一个视角上呢我们这个往往可以 这个容易的考虑到这些问题。
另外呢我们这个在建立类图之后呢 还要这个识别这个类的一些特征,这些特征包括一些属性和一些
方法和操作。
这个识别这些东西呢实际上呢 一方面呢主要是用我们自然人的思维方式就可以,另一方面也要遵循一定的 技术和方法。
这个我们在讲到这部分内容时候会详细跟大家讲一下这个策略。
另外呢识别关系的时候,特别是关联关系的时候呢并没有必要对这个所有的
一些关系啊,尽管它存在于我们的现实世界中,但是我们没有必要把它拿到 这个我们的软件识别中来。
比如说这个携带武器和自行 装备之间是有没有关系?当然它会有一种这个
啊,击中和被击中的一种关系,但是这种关系 需不需要拿到我们的软件世界中来呢?是吧,这时候我们要需要考虑。
这个关联关系存在两个条件,第一个就是要保存二者这个关系的一种信息,第二个那就是要 彼此之间调用服务。
只要有一个条件,这个关联关系就是可以存在的。
但是呢, 这个关联关系,针对它的目的不同,它
以后在设计中,在开发中映射到的一些技术是不同的。
但是呢,我们现在看来携带武器和自行装备之间,尽管呢,
我们这个子弹可以击中一个
某一个什么自行装备,这个,比如说一些 油箱啊,一些这个
这个子弹、 子弹箱、 或者说是这个生命医疗包等等,啊,这个时候主要是为了
自己有些情况下我这个,为了避免让对方能够 加上,我自己加不上的时候不让对方
加上,这时我要击落这个自行装备。
它们之间肯定是有个击中和被击中的关系,但是呢,我们要拿这两个条件来 比较一下。
第一我需不需要永久性的保存这个信息, 实际上,在当前的这个需求分析中我们没必要保存,到底是
哪个子弹,哪一发子弹击中的哪一个医疗包,这个东西是没必要保存的,所以这个不成立。
第二个,它们之间需不需要彼此调用对方的服务,这个实际上呢, 仍然是这个没有必要的。
就是说我们这个检测碰撞 实际上是由这个战场,这个在每走一定数据的时候呢,它这个
主动完成的,它们二者实际上没有这个 这个主动检测被对方碰撞的这么一种行为。
所以呢,我们这里呢, 这个红线的部分呢,实际上都是不需要的。
因为它不满足这两个条件,所以我们没有必要 把它作为我们的这个关联关系。
另外,类似的,爆炸和自行装备的这个发生关系,也是 不需要识别为我们当前软件系统中的一个关联。
所以尽管我们面向对象是这个 比较贴近现实世界,但是呢,也不能够我们完全按照自己这个自然
这种思维方式啊,这个把现实世界完全照搬过来,这个需要 进行某种程度的抽象,有些情况下是没必要拿到我们现实世界中来。
类似的,像战斗机和补给之间的一个关系,也没必要这个作为我们这个
当前的这个关联关系,因为我们这个既不需要保存这个信息,另一方面也不需要这个
访问对方的服务,我们这个不需要对方访问,它实际上是由第三者战场来对它们进行 这个碰撞检测。
所以在当前这个场景下,我们不需要这样。
战斗机和战斗机在战斗,也是如此。
所以 这个识别类图呢,实际上相对于识别
use case来说呢,它难度比较大,一方面它是从黑盒到白盒,
需要你凭空的来这个猜测构想未来 业务模型到底是什么样的,啊,里边的各种类体结构是什么样的。
另外呢,就是 这里边涉及到各种各样的比较繁琐的一些技术 和策略。
如何识别类、 如何识别关联关系,
识别完之后呢,还要进行检测,检验、 验证是不是进行审计,是不是它能够真正靠
立得住,如果立不住的话直接删除,没有必要在我们当前的这个系统分析的 这个模型中存在。
所以,这个我们这个后续,啊,将会给 重点给大家介绍这个识别类图的很多策略。
很多同学可能会,知道画类图,但是
真正这个画的是不是符合这些策略,这需要进一步研究和提高。