系统概要设计中的UML静态建模2.docx

系统概要设计中的UML静态建模2.docx

《系统概要设计中的UML静态建模2.docx》由会员分享，可在线阅读，更多相关《系统概要设计中的UML静态建模2.docx（30页珍藏版）》请在冰豆网上搜索。

系统概要设计中的UML静态建模2

4.2UML包图

4.2.1UML中的包图

1．UML中的包和包图（PackageDiagram）

一个企业应用系统中可能包含数百个类，如何有效地管理这些类就成了一个需要解决的问题。

一种有效的管理方式是将类分组，功能相似或相关的类组织在一起，形成功能模块或者子系统。

在各种面向对象的编程语言中都提供了对类进行分类管理的机制——如Java语言的包（Package），而在UML中，对类或者其他的模型元素进行分组时则使用包图。

（1）包图是保持系统整体结构简明、清晰的重要工具。

在RationalRose中对包采用类似于文件夹的符号来表示（如图4.19所示的“留言功能包”、“用户权限管理包”），并且一个包可嵌套在另一个包中形成子包。

使用包图可以将相关模型元素分组，包图由包和包之间的关系构成，它是维护和控制系统总体结构（系统架构）的重要建模工具。

（2）在RationalRose2003中的包图是通过类图来体现的。

如果某个包为其他包的子包，则应该将子包放入父包中，如图4.19所示。

图4.19RationalRose2003中的包图是通过类图来体现的

2．包之间的关系及其UML图示

在设计包时，首先要决定系统中应该有哪些包，比如要尽量将系统中不稳定的模型元素和相对稳定的模型元素分配到不同包中，以提高软件系统的可维护性；或者将可选功能和核心功能实现分置于不同的包或子包之中。

其次决定包之间的关系，包之间存在两种关系：

依赖和泛化（继承或者构成）。

下面分别介绍这两种关系，以及它们在RationalRose中的具体实现。

（1）包之问的依赖关系。

如果对类A的修改会导致类B的改变，则称B依赖于A。

如果两个包中存在具有依赖关系的两个类，则认为这两个类所属的两个包之间则存在着依赖关系。

图4.19所示的“留言功能包”和“用户权限管理包”之间存在依赖。

包之间的依赖关系应尽量简单、稀疏，通常要求某一包中的模型元素只与同层及相邻下一层的模型元素之间存在依赖关系。

（2）包之间的泛化关系。

包之间的泛化关系其实更多的是指包之间的构成关系，也就是指在某个包中嵌套包含其他的包，即包中不仅可包含类等模型元素，还可以包含子包。

图4．19所示的“用户权限管理包”中包含有“用户信息包”，称“用户信息包”为“用户权限管理包”中的子包。

3．包图的应用目的

（1）能够体现系统的层次关系。

使用包圈的目的是把模型元素组织成组或者集合并为其命名，以便作为一个整体进行处理。

对于一个大型的软件系统，使用包来组织大量模型元素以便于系统的理解和处理，使之有很好的层次关系。

（2）通过包可以形成一个高内聚、低耦合的类的集合。

（3）在概要设计阶段，设计人员可以用包图来建立软件系统的体系架构。

4.2.2RationalRose2003对UML包图的支持

1．设计项目包图中的各个包

（1）新建项目中的各个包。

右击【LogicalView】的节点，在弹出的快捷菜单中选择【New】，然后再选择【Package】菜单项，如图4.20所示。

图4.20新建项目中的各个包

（2）命名该包图。

输入包的名称为“表示层包”，如图4.20所示的输入图示。

（3）根据具体的应用要求设计其子包。

当然也可以在该包的基础上再产生出其子包，如图4.2l所示。

图4.21设计项目中各个包的子包

（4）分别设计其他的各个子包。

分别对各个包和对应的子包进行设计和命名，如图4.22所示。

图4.22分别设计其他的各个子包

2．设计项目中的包圈

（1）新建一个包图。

右击【LogicalView】的节点，在弹出的快捷菜单中选择【New】，然后再选择【classDiagram】菜单项，如图4.23所示。

图4.23设计项目中的包圈

（2）命名该包图。

输入包图的名称为“BBS系统前台包图”，如图4.23所示。

（3）在该包图中分别添加各个不同的包。

将需要的各个包从左侧的层次树拖动到右侧的包图中，如图424所示。

图4.24在该包圈中分别添加各个不同的包

（4）决定各个包之问的组成关系。

根据系统层次划分的要求，分别添加各个不同的包所对应的子包，如图4.25所示。

图4.25分别添加各个不同的包所对应的子包

（5）设计完成后的结果如图4.26所示。

图4.26项目巾的各个包及对应的包图

3．设置项目包图内各个包之问的依赖关系

包与包之间的依赖关系是由包中的类与另一个包中的类是否存在关联关系来决定的，不允许包与包之间直接发生相互依赖。

因此，如果在系统层次划分的过程中发现有这样的依赖关系存在，那就说明项目系统中包的设计有问题，需要考虑将这两个包合并或重新分配包中的类。

比如，如果有A包和B包，A包与B包产生泛化关系，那就不允许出现B包依赖A包的情况。

本项目示例中各个包之间的依赖关系如图4.27所示，不仅要确定包与包之间的依赖关系，还应确定某个包的各个组成包之间的依赖关系。

图4.27BBS论坛项目的最终包图

4.2.3网上商城项目的架构包图

由于在3.3.4节有关刚上商城项目的系统架构设计示例中，已经具体给出了网上商城项目的架构包图。

在此不再重复列出，请参见图3.11所示的架构包图。

4.2.4BBS论坛项目的架构包图

BBS论坛项目系统的整体架构设计采用的是DWR+Struts+Spring+Hibernate等框架架构组成，同时整个系统被分为4层——表示层、控制层、业务处理层和持久层。

其中在表示层和控制层中应用Struts框架技术。

而在业务处理层中则应用了Spring框架技术，在系统的持久层中采用Hibernate框架来达到O/RMapping的效果。

具体的架构包图如图4.27所示。

4.3UML类图

4.3.1UML中的类图

1．UML类图

（1）类图。

类是面向对象模型最基本的模型元素。

类图表达了实现某用例中一组对象类之间的静态结构，以及它们之间的联系和交互关系：

并且类图还用来模拟开发中的实际代码，而且有许多LJML，建模工具（如RationalRose等）可以直接根据IJMI_。

类图生成目标语言的类程序代码，或者实施反向工程，读取类的源代码文件，创建出新的类图。

（2）类图的作用。

类图的作用主要体现在描述系统的静态结构和关系上，因为它不仅定义系统需要的各个类，还能够表示类之间的关系（关联、依赖、聚合和泛化等），还包括类的内部结构（类的属性和操作）的定义和描述。

（3）类与类之问的关系。

类与类之间的关系分为两种不同的形式：

结构性关系（静态组成关系）和行为性关系（动态交互关系）。

·结构性关系主要指父类与子类间的泛化/特化（类之间的继承与派生），类与类之间的关联和依赖、聚合和组合等关系。

·行为性关系指类之间可以通过消息联系，通过系统预定义或用户自定义的语义联系。

2．类的UML图示

（1）在UML中，类的图形表示为实线矩形框。

类是对象的集合，这些对象有共同的结构特征、行为特征、联系和语义；但要注意的是：

在类图中不一定要列出全部的成员（属性和方法）内容。

如在建立分析模型或设计模型时，可以只列出类名，在模型中着重表达类之间的联系；而在建立实现模型时，则在类图中给出属性和操作等详细的成员内容。

在RationalRose2003中对类及成员定义的支持如图4.28所示。

图4.28类的UML图示及类中成员的图示

（2）类的属性成员及其UML图示。

属性体现类的对象所在的状态性质，在类图中用文字串说明。

其表示方式如下：

可视性属性名（多重性）：

类型=初始值

·可视性用可视性标记表示：

公共（

）、保护（

）、私有（

）。

·类型（即数据类型）依赖于选择的工具语言，例如下面为在RationalRose2003中表示数据类型为String的userName成员属性。

（3）类中的静态（static）成员属性及其UML图示。

应该注意的是，类的静态成员属性也就是static成员属性在类图中的表示为带下划线的形式。

（4）类中的方法成员及其UML图示。

操作（方法）是类的行为特征或动态特征，用于对服务或实体相关的操作建模。

一个类可以有操作并且允许有多个操作，也可以没有操作。

没有操作的类经常用于表达数据（如业务实体组件类或者持久组件类）。

操作在类图中位于最底部，同时用文字串说明。

其表示如下：

可视性操作名（参数列表）：

返回列表{性质}

3．类之间的关系

在面向对象领域中，各个类之问一般存在“关联、继承、聚合和组合”等形式的关系，据此，分析设计人员再对项目中的各个实体进一步地分析，找出它们之间的各种关系。

有关面向对象技术中类之间关系的详细介绍请读者参考本书第l1章“对象/关系映射设计”中的有关内容。

（1）关联（Association）关系。

关联是一种结构化的关系，指一种对象和另一种对象有联系。

它是对具有共同结构特性、行为特性、关系和语义链接的描述。

在UML类图中，关联用一条实线将类连接在一起。

如果是单向关联，则在关联端加箭头表示方向。

在RationalRose工具中，如果是双向关联，则不用双向箭头表示。

具体参见图4.29中的Computer与UserInfo之间的关联关系的图示。

另外还应该注意关联的重数，由于关联分为两元关系和多元关系，两元关系是指一对一的关系，多元关系是一对多或多对一的关系。

并且在关联端需要标出关联中的数量关系——重数（多重性）。

关联端的多重性规定了该类中有多少个对象参与该关联，关联分为“一对一”、一对多”、“多对一”和“多对多”关联。

常用的关联关系如下：

·“0..1”：

表示0到1个对象。

·“1”：

表示1个对象。

·“0..*”或者“*’：

表示0到多个对象。

·“1..10”：

表示1到10个对象。

客户和订单之间的关联关系如果写成Java程序，则意味着在UserInfo类中需要定义一个Order类型的集合成员变量。

同时Order类应该定义UserInfo类的对象。

例4-1是UserInfo类和Order类之间关联关系的代码示例。

例4-1UserInfo类和Order类的定义代码示例。

PublicClassUserInfo

privateArrayListallOrders；//客户和订单之间为“一对多”关联

//UserInfo类与ContactMethod类之间为聚合关系

privateContactMethodoneContactMethod；

//…其他的代码

publicbooleanaddGoodsToCart（GoodsoneGoods）

{//UserInfo类与Goods之间的关系为依赖关系

//将商品添加到购物车中的代码

returntrue；

}

}

publicclassOrder{

privateUserInfosomeOneUser；／／订单和客户之间为“一对一”关联

publicvoidsetSomeOneUser（UserInfooneUserInfo）{

someOneUser=oneUserInfo；

}

}

（2）依赖（Dependency）关系。

依赖体现类之问的“使用和调用”关系，指特定事物的改变有可能影响使用该事物的事物，反之不成立。

通常情况下，依赖关系体现在目标类的对象出现在局部变量或者方法的参数中以及静态方法的调用。

依赖与关联不同，依赖关系总是单向的。

例如，某一个类使用了另一个类的对象作为操作方法中的参数，则这两个类之问就具有依赖关系；如果一个类存取另一个类中的全局对象以及一个类调用另一个类中类作用域的操作方法，则这两个类之间也同样具有依赖关系。

依赖在UML图示中用一个从客户指向提供者的虚箭头表示，具体请见图4.29中的Computer与UserInfo之间的关联关系的图示。

例4-1中的UserInfo类与Goods之间的关系为依赖关系，用户在购买某个商品时，addGoodsToCart的行为是依赖于Goods类的。

（3）聚合（Aggregation）关系。

聚合表示事物的部分与整体的一种松散（比较弱）的对象间关系，即A对象可以包含B对象，但B对象不一定是A对象的组成部分。

比如计算机和它的外围设备就是一例，再比如汽车和停车场之间的关系，停车场中有汽车，但汽车不是停车场的一部分，汽车和停车场之间没有整体和一般的关系。

聚合关系在UM~．中的表示法为在关联线端加一个小空心菱形，菱形连接处代表整体事物类，称为聚合类，另一端连接处代表部分事物类。

给例4-1中的UserInfo类添加一个联系方式的对象oneContactMethod，此时UserInfo类与ContaetMethod类之间应该为聚合。

为什么不将它们看成关联呢？

因为UserInfo应该拥有或者包含一个联系方式，将“用户”与“联系方式”不是平等地看待，而是作为“整体”和“局部”来看待。

同时，UserInfo与ContactMethod之间不存在物理上的包含和组成的关系。

如果将“用户”与“联系方式”平等（同级别）地看待，它们两者之间就应该是关联关系。

参见例4-1中的代码示例。

在RationalRose2003中则通过【ByReference】的方式进行引用，如图4.29所示。

图4.29在RationalRose2003中对聚合关系的支持

（4）组合（Composition）关系。

组合表示事物的部分与整体的一种紧密（比较强）的对象问关系，此时，构成整体类的部分类完全属于整体类，并且体现树状层次结构的关系。

在一个合成对象里，部分与整体的生命周期都是相同的。

一个合成的新对象完全拥有对其组成部分的支配权。

包括它们的创建和删除（与代表整体的对象同时存在、消失）。

如果没有了整体类，则部分类也没有存在的价值，部分类的存在是因为有整体类的存在。

组合的UMIL表示法为在关联线端加一个小实心菱形，菱形连接处代表整体事物类，称为组合类，另一连接处代表部分事物类。

可以将组合理解成强类型的聚合。

其实现的代码示例，如例4-2所示。

在RationalRose2003中则通过【ByValue】菜单项进行引用，如图4.30所示。

图4.30在RationalRose2003中对组合关系的支持

例4-2组合关系的代码示例。

publicclassWindow{

privateTitleBaroneTiltle；//在窗口中包含一个标题条对象

}

在窗口类中包含一个标题条对象。

由于在物理构成关系上，窗口是由标题条等对象构成的。

因此，窗口类和标题条类之间有很强的整体和部分的组成关系。

（5）泛化（Generalization）关系。

泛化与特化是现实世界中一般性实体与特殊性实体之间的关系，一般性实体是特殊性实体的泛化，特殊性实体是一般性实体的特化。

类与其子类就具有这样的关系。

UML中的泛化体现了分类与继承原则，一个子类继承超类的全部属性、方法，子类本身还可以有自己的子类，从而构成复杂的一般与特殊的结构。

泛化的UML表示形式关系图示为一个带空心三角形的直线，空心三角形紧挨着父类，如图4.31所示的PCComputer与Computer之间的泛化关系图示。

但要注意抽象类的表示形式，抽象类或抽象操作的名称用斜体字表示。

关键字abstract可以放置在名称下面或后面的特性表中。

4．类之间的关系实例

在例4-3中，给出了一个表示对象之间各种关系的示例。

其中的computer与CPU、HardDisk之间为组合关系，因为CPU和HardDisk是Computer必备的组成部分；Computer与Printer之间为聚合关系，因为Printer并不是Computer的必备组成部件，而是可选的组成部件。

Computer与UserInfo（计算机的主人）之间为“一对一”的关联关系，Computer与Data之间为依赖关系，计算机在进行计算时依赖十需要进行计算处理的目标数据；PCComputer与Computer之间为泛化关系，并且其中的Computer类为抽象类。

例4-3类之间各种关系的示例。

例4-3中的各个类之间的关系对应的UML类图如图4.31所示，注意在RationalRose工具中聚合和组合表示形式的不同点。

图4.31例4-3中类之间的各种关系示例对应的UML类图

4.3.2RationalRose2003对UML类图的支持

1．添加某项目中与数据访问层组件相关的各个类

（1）新建项目中的一个类。

右击“LogicalView”的节点下某个包的节点，在弹出的快捷菜单中选择【New]】，然后再选择【class】菜单项。

如图4.32所示，输入类名称以命名该类。

图4.32新建项目中的一个类并命名该类

（2）分别在各个包中输入各个类，最后结果如图4.33所示。

2．添加本项目中与数据访问层组件相关的各个接口

（1）在数据访问层包中新建一个接口。

右击“数据访问层”的包名称节点，在弹出的快捷菜单中选择【New】，然后再选择【Interface】菜单项，如图4.33所示。

图4.33添加与数据访问层组件相关的各个接口

（2）输入接口的名称，比如为“OperaterDBInterface”。

在概要设计中，不需要考虑各个类或者接口中具体成员的定义。

可以将它们留在详细设计中完成。

这也是概要设计和详细设计类图中类的差别，如图4-34所示。

图4.34命名该接口

3．设计数据访问组件对应的类图

（1）新建一个类图。

右击“LogicalView”的节点下某个包的节点，在弹出的快捷菜单中选择【New】，然后再选择【classDiagram】菜单项，如图4.35所示，输入类图的名称，比如为“BBS数据访问组件的类图”。

图4.35新建一个类图并命名该类图

（2）生成一个空的类图。

RationalRose最后将生成如图4.36所示的一个空的类图。

图4.36生成一个空的类图

4．在该类图中添加各个相关的类

直接将前面设计的各个类从对应的包中拖动到类图中，最后的结果如图4.37所示。

图4.37在该类图中添加各个相关的类

5．设置类图中类对接口的实现关系

（1）在RationalRose中提供了某类对接口的实现按钮，如图4.38所示。

图4.38在RationalRose中提供了某类对接口的实现按钮

（2）在RationalRose中还可以对JDK中的标准接口进行实现定义。

如果某个类需要对JDK系统中的接口进行实现，则首先需要加载各个类或者接口所在的Jar包文件。

在RationalRose中可以采用如图4.39所示的方式实现。

图4.39在RationalRose中还可以对JDK中的标准接El进行实现定义

（3）选择JDK中的某个接口。

比如选择java.io.Serializable接口，如图4.40所示。

图4.40选择JDK中的java.io.Serializable接口

（4）确定本项目中的某个类与其对应接口的实现关系。

本项目中有UserlnfoEntityBean和BBSInfoEntityBean两个实体类，这两个类需要满足序列化的要求，因此它们需要实java.io.Serializable接口，如图4.41所示。

图4.41确定本项目中的某个类与其对应接口的实现关系

6．设置类图中的各个类之间的聚合关系

（1）在RationalRose中提供了对类之问聚合关系的支持。

首先应该区分的是类图工具条中各个关系按钮，并找到体现聚合关系的按钮，如图4.42所示。

图4.42在RationalRose中提供了对类之间的聚合关系的支持

（2）右击聚合关系中的总体端。

右击聚合关系中的总体端并在弹出的快捷菜单中选择【Aggregate】菜单项，如图4.43所示。

图4.43右击聚合关系中的总体端

（3）选择【Aggregate】的关系类型

在弹出的快捷菜单中选择【Aggregate】菜单项后，将生成如图4.44所示的状态。

图4.44设置类图中各个类之间的聚合关系

7．设置类图中各个类之间关联关系的重数

（1）如果关系为关联关系，则应该进一步设置关联的重数。

右击靠近关联的目标方，在弹出的快捷菜单中选择【Multiplicity】菜单项，然后根据具体关联的重数选择对应的重数的项目，如图4.45所示。

图4.45设置类图中各个类之间关联关系的重数

（2）最后将生成关联关系的重数。

RationalRose工具将自动地在关联线上显示出关联关系重数的状态（0...*），如图4.46所示。

图4.46设置类图中各个类之问的关联关系

（3）据此设置本项目中其他类之间的关联关系和重数。

最后结果如图4.47所示。

图4.47设置项目类图中其他各类之间的关联关系

8．设置类图中各个类之间的依赖关系

（1）在RationalRose中提供了对类之间依赖关系的支持。

区分类图工具条中的各个关系按钮，并找到体现依赖关系的按钮，如图4.48所示。

图4.48在RationalRose中提供了对类之间依赖关系的支持

（2）设置项目中的类之间的依赖关系。

根据应用的状态进行定义和设置，如UserInfoManageBean类依赖于UserInfoEntityBean类，而BBSInfoManageBean类依赖于BBSInfoEntityBean类，如图4.49所示。

图4.49定义和设置项日中类之间的依赖关系

4.3.3网上商城项目的类图

1．表示层的类图

项目表示层主要包括各个JSP页面文件、各种标签库标签（Struts标签库标签和自定义设计的标签库标签）以及具有视图助手（ViewHelp）功能的JavaBean组件类。

具体的各个类及类之间的关系图示如图4.50所示。

图4.50网上商城项目表示层的类图

2．控制层的类图

由于本项目的控制层采用Struts框架来实现，因此，项目控制层主要包括前端控制器组件ActionServlet和各种完成具体业务调度的后端业务控制器Action类。

由于本项目需要对标准的ActionServlet类进行继承，以扩展ActionServlet的功能，因此设计了自定义的前端控制器组件NetShopActionServlet类；又由于各个Action类有共同的功能实现要求，因此为各个不同的Action类提供了一个基类BaseAction，以完成一些共性的任务。

具体各个类及类之间的关系图示如图4.5l所示。

图4.5l网上商城项目控制层的类图

3．业务层的类图

网上商城项目的具体业务功能主要有4类：

与用户有关的信息管理功能（UserManageBean承担）、与商口有关的信息管理功能（GoodsManageBean承担）、与订单有关的信息管理功能（OrderManageBean承担）、与购物车有关的信息管理功能（BuyCartManageBean承担）；每个具体的业务功能类都实现各自的接口，这样将便于Spring框架中的IoC进行对象管理。

另外，考虑到各个业务功能类都会存在一些共同的功能实现要求。

因此，将实现这些共同功能的代码提取出来并放到对应的基类中。

这样就为各个业务类设计了一个业务基类BaseModelBean类。

具体的各个类及类之间的关系图示如图4.52所示。

图4.52网上商城项目业务层的类图

4．数据访问层的类图

本项目的持久层主要包括以下类型的类：

持久实体类、数据访问组件DAO类。

与