| 作者 |
内容 |
| inhill |
请教关于“分析模式”中图2.6的一个问题!
在图2.6中的“Organization
Structure”与“Organization”有两个关系:parent和subsidiary,其关联性都是从“Organization”到“Organization
Structure”的一对多关系。本人以为parent关系是从Organization
Structure”到“Organization”的多对一,而subsidiary关系是从“Organization
Structure”到“Organization”的一对多关系。 |
| 02/08/27 10:01 |
酷帖! 臭帖! 回复 |
|
酷帖评价: 臭帖评价: |
| 返回页首 |
|
| windy.j |
换一个角度看
请注意,在这个模式中,Organization
Structure才是模式的核心,在系统中,由两个Organization的实例(分别充当parent和subsidiary),以及一个Type实例(来说明该结构的类型)一起构成一种组织结构。
以上摘自我的分析模式笔记---责任模式之一
这样是我的理解,如果有不同意见,欢迎讨论。 |
| 02/08/27 15:45 |
酷帖! 臭帖! 回复 |
酷帖评价: 臭帖评价: |
| 返回页首 |
|
| killcamel |
主要类不是O,是O.S
O.S内有一个O充当parent,另一个O充当sub,只是一个关系的两端而已,关系的类型是O.T决定的,比如上下级,检查,协作等等。T.P是关系有效期间。
不考虑T.P,如果要考虑一个部门有五个子部门,不是在上级部门设定子部门数组,而是一个名为子部门的O.T实例,六个O实例(上级+五下级),五个O.S实例,其中的type=子部门O.T实例,parent=上级O实例,sub分别为下级O实例 |
| 02/08/27 17:56 |
酷帖! 臭帖! 回复 |
酷帖评价: 臭帖评价: |
| 返回页首 |
|
| inhill |
回复:
主要类不是O,是O.S
好!不过还是不很明白。如何用此图来表示图2-5? |
| 02/08/30 09:46 |
酷帖! 臭帖! 回复 |
|
酷帖评价: 臭帖评价: |
| 返回页首 |
|
| inhill |
回复:
换一个角度看
高人能否把你的分析模式笔记贴出来共享?小弟切以为在系统中,由一个Organization的实例同时充当parent和subsidiary的角色,还请高手指点! |
| 02/08/30 09:52 |
酷帖! 臭帖! 回复 |
|
酷帖评价: 臭帖评价: |
| 返回页首 |
|
| gemskk |
回复:
请教关于“分析模式”中图2.6的一个问题!
Organization Structure Pattern是一个分析模式,这个模式由一个Organization
Structure和跟Organization Structure有着联系的其他部分组成,可以这样理解,Organization
Structure由一个parent,一个subsidiary,一个Organization Structure Type,一个Time
Period组成。其中心就是一个Organization Structure,这个Organization
Structure的语义是它的subsidiary向它的parent在Period时期内,负Organization Structure
Type这样的责任。 |
| 02/08/30 10:43 |
酷帖! 臭帖! 回复 |
酷帖评价: 臭帖评价: |
| 返回页首 |
|
| inhill |
回复:
请教关于“分析模式”中图2.6的一个问题!
Thanks.俺大致明白了! |
| 02/08/30 12:04 |
酷帖! 臭帖! 回复 |
|
酷帖评价: 臭帖评价: |
| 返回页首 |
|
| windy.j |
回复: 换一个角度看
笔记在以前的非程序员杂志里有,请查以往目录
另:这个模式是为了提供非常灵活的组织结构配置,例如,一个部门可能是好几个部门的上级部门,同时又是好几个部门的下属部门,根据给定的部门去查它所有相关的组织结构就可以找到所有的上下级关系,你说的可能是树形结构:一个上级对多个下级的组织,这样的情况没有必要用这个复杂的模式,用它上面提到的层次结构那个模式就够了 |
| 02/09/03 14:32 |
酷帖! 臭帖! 回复 |