类图:用来描述系统静态部分。它是最常用的UML图,可以显示出类、接口以及它们的静态结构和关系,它用于描述系统的结构化设计。
类图通常包括:类,接口,协作,关系。
类:如图所示。如果类名为斜体,表示类为抽象类;如果方法为斜体,表示此方法为抽象方法。类的属性和方法前面的图标为可见性修饰符。这里画错了,人这个类应该是抽象类。
从上到下,依次表示为:
加号(+),public,公有可见性,
减号(-),private,私有可见性,
#号,protected,受保护的可见性,
~号,package,包级别的可见性。
接口:就跟类差不多,应该说和抽象类类差不多。抽象类有属性有方法,但是它的方法不是都是抽象方法,也就是说抽象类中的非抽象方法是可以有具体实现的。而接口中的方法全部都是抽象方法,只有方法名,没有具体实现。
如下图所示,
如果“人”这个抽象类实现“学习”这个接口,但是具体学习什么,是学习语文,数学还是英语,这是由继承“人”类的具体对象来决定的。
关系:实现(接口),泛化(继承),关联(组合,聚合(整体部分),普通关联),依赖关系(使用)。
这是我画的关于机房收费系统的第一版类图。我自己是这么分析的。
上面是机房收费系统的所有窗体,然后他们和机房收费系统的关系都是组合关系。下面是数据库以及数据库中10张表。也是组合关系,因为我觉得数据库要是不在了,那么这些表也就不存在了。然后中间有user类和student类(额,首字母应该是大写的),student类和上下机界面和注册窗体,其实还有充值和退卡窗体都有关系。然后user用户类和整个机房收费系统都有关系。
这样看上去,我个人觉得还是可以的。但是当我给我写出来的类,添加属性和方法的时候我就犯难了。比如上面的frmMain窗体。如下图,很明显这是不正确的,因为类的概念是具有相同属性相同操作相同关系相同语义的对象的描述,也可以说是对象的抽象。而汉语解释类:很多相似事物的综合。很明显这个不是综合而是个个例。所以这些窗体类都不应该这么写,应该抽象出一个Form类,然后所有的窗体类继承这个Form类。但是这个frmMain可以作为一个类吗,我想是不可以的吧!
经常可以看见这样的继承关系,学生继承Person类,
但是你有见过某个具体的学生作为类然后继承Student类吗?这个具体的学生应该是个对象而不是个类。
所以,上面的那些窗体类应该都不能作为类。机房收费系统也不是个类,同理那10张表也不是类,数据库应该也不是类。用户和学生是类,抽象出来的Form是类,把所有表抽象出来也应该是个类。
所以第二版的机房收费系统类图:额,好像是太简洁了点。
分析下:我觉得学生就是和用户(教师)在打交道,然后User就是在使用系统,系统又对数据库表进行操作。
好像这么看,又算是画完了。但是
类图一般是在详细设计阶段中使用,主要用来描述系统中各个模块中类的关系。包含类或者类与接口的实现关系,类之间的依赖,关联等关系。它来描述每一个类的详细信息,属性和方法。通过类图,就可以实际的把系统中的各个类描述清楚,然后就可以编码了。所以,如果把软件当成房子,那么类图就是最后的施工图了。
我真心觉得,如果用我这张类图来做施工图,那么这个房子一定建的很抽象。所以,还是要再描述清楚点,再详细点。
然后就是如下图所示。在写Form中的方法的时候不知道应该写些什么,我的每个窗体的方法都不一样。抽象出来的类的方法没办法统一,突然想到,我想错了。实现接口的话才需要完全实现所有方法,而类中的方法,子类其实是可以不完全实现的。所以我大可以将所有的方法都列举出来,然后子类自己去实现自己需要的方法。可以那样的话,我的Form的方法大概就有20多种方法,因为我打算把每种窗体名都写出来作为方法。这样可以吗?
写完一看,额,又发现不对了。我的每种窗体可没法子继承Form中的这么多方法,而且这算是方法吗??还得多加思考。所以,Form中的方法写错了,Form这个抽象应该还是可以的,但是方法不对。我得想想我的窗体有什么方法是一直在用的,增删改查。
最后,我的类图就是这样。
有问题就请多多指教了,以后等我学到更多之后,就能更加明白了!