Foundation1Developer建模工具Rose学习.docVIP

Foundation1 Developer 建模工具Rose学习 关系（Relations）是表示在Class自己的交互作用。在Foundation1中用到了如下的几种关系： ???????Aggregation：表示集合，聚合等关系。 ???????Association：表示联合关系。 ???????Dependency：表示一定的依赖从属关系。 ???????Generalization：一般的关系，包括扩展和继承等关系。 ? Aggregation关系： ???????集合（聚合）关系用来表示在两个LU中的Parent-Child的这种关系。一般来说是一种一对多的关系。如Customer?Order(Parent)?是由许多Order?Item(Child) 组成等。在Parent中拥有的Key在Child中会作为最先的主键存在于Child中。Parent应该比Child要先存在。 ? 在上面的图片中，DemoOrder就作为的是Parent（Owning），而DemoOrderItem就作为的是Child（Owned）。如果它们没有这些关系，那么在DemoOrder中，OrderID是Key，在DemoOrderItem中，RowNo是Key。现在存在这个聚合的关系，对于DemoOrderItem来说，生成的数据表（Table或View）的Key就是：Order_ID-Row_No。这种关系是一种By?Reference的关系。 另一种关系是种By?Value的关系，如下面的图片中，用实心的水晶箭头表示Parent(Owning)。与By?Reference不同的是，在生成的数据库中并不存在DemoDeliveryType类的数据结果等，通过这样的一个关系，在DemoOrder中增加了两个字段：Delivery_Type和Delivery_Type_DB，具体的用法在后面介绍。 ? Association：联合关系。 ???????一般来说，这种关系是用来表示一个LU对另一个LU是可知的，即Know?About，例如“Customer?Order”?就可以知道这单是为那个“Customer”生成，“Order?Item”?也可以知道它是为那个“Sales?Part”下达等等。一般是多对一的关系。如每个Order只可以有一个Customer，但一个Customer可以有不同的Order等等。我们称“Customer?Order”或?“Order?Item”?为“Knowing”部分，把“Customer”?或“Sales?Part”称为“Know?About”部分。在Oracle数据库中，就是把“Know?About”部分的主键包含在“Knowing”部分中，可以称作是外键，但在Rose中没有这种称呼，但在后续的Design的开发中，系统会生成一系列的Check动作对这些条件进行检查，也就相当于Oracle中的外键的作用。 ? 如上面的图，在数据表中，假设DemoCustomer中的主键是CustomerId，那么在生成的DemoOrder的时候，系统会在DemoOrder对应的数据表中增加一个字段是“Customer_Id”，但不是DemoOrder对应的数据表“Demo_Order”的主键。仅仅只是一个Attribute。 ???????另外一种多对多的关系（*…*），由两个独立的LU连接起来，如果对于这两个LU来说没有特别的意义，所以一般有第三个LU作为一个新的Link?Class，第一个和第二个LU都有自己的Key，但第三个LU就没有自己的Key，它的Key是通过把第一个和第二个LU的Key结合成为一个主键包含在第三个LU中。这样，第三个可以用于其它的层次，能够更加清晰的表示要表示的意思。如果被继承同时也包括它的主键。 在上面的例子中，独立的来看，DemoInventory的Key是“InventoryId”，DemoProduct的Key是“ProductId”，而DemoInventoryProduct没有Key。经过这样的一个关系，DemoInventoryProduct的新Key是“InventoryId-ProductId。 ??????? Dependency：依赖从属关系 ???????从属依赖关系通俗的是指一个LU可以使用另一个LU中的方法。相当于OOP中的友员之类的。 ???????在下面的例子中，DemoCustomer这个组件依赖组件DemoInvoiceUtil，可以使用DemoInvoiceUtil中的方法；同时组件DemoInvoiceUtil也依赖DemoInvoice，它也可以使用DemoInvoice中的方法。与继承不相同。同时在这个例子中，还存在有一个As