初级问题,已研究两天.use case图在rose中如何进行分层.
　

---

具体点讲,actor需要与一个use case交互,但这个use case是一个概括性的use case,其中包含更多的具体的use case,我无法在一张图中全部画出来,那样会使整张图难以理解.显然需要分层描述.
下面是我具体实现分层时碰到的问题:
我了解一些 package在rose中的含义,可以定义个package,将详细的use case置于其下,但是我还需要一个概括性的use case,这个用来在上层的use case图中使用,那么,这个概括性的use case如何与这些package中的详细use case关联起来?它们能够关联起来么?
一般大家具体如何实现分层的?(我指的是在rose中的具体操作)

 回复: 初级问题,已研究两天.use case图在rose中如何进行分层.
　

---

你为什么要这样分呢？有没有问过自己这样分对不对？

 回复: 初级问题,已研究两天.use case图在rose中如何进行分层.
　

---

这是我的个人体会,不知你对此有什么具体建议或者有另外关于分层实现的具体方法.

你可以看一下idleOO的讨论稿use case：http://upload.smiling.com.cn/file/120353/usecase.rar

这个小组的文件共享：http://www.smiling.com.cn/search/groupinfo.ecgi?group_id=37268

我的意思是你把use case这样分层组织是不是合理，对use case的理解是不是正确呀

 回复: 初级问题,已研究两天.use case图在rose中如何进行分层.
　

---

有道理。
分层只是一种思想，最终目的还是分出了对象。

这种用法应该不对，只能说明你对用户的需求还不是非常清楚，Use case不应该有层次之分，它是用户的一种实际的行动，如果非常多的话，应该使用包。

 贴上另一篇帖子，大家继续讨论。
　

---

在整理USE CASE的过程中，常常会发现一些USE CASE需要进一步细化。例如：
项目管理 可以细化为任务管理和活动管理，其中任务管理由可以细化为添加任务、删除任务等，请问一般情况下该怎样做？（删除项目管理，添加任务管理、活动管理，以此类推？还是直接将项目管理单独分离出来，形成一个包？）谢谢！！

--------------------------------------------------------------------------------
当然不用删，如果添加的用例不多的话也不用单独加一个包，直接在原用例图上加不行吗？

--------------------------------------------------------------------------------
如果原用例不删除，那么它和细化后的用例图之间是什么关系？

--------------------------------------------------------------------------------
这个问题要看你的用例的数量而定。我们一般在最高层不超过12-15个用例，以下每层不超过上一层的10倍。所以你可以计算一下你的用例的数量，如果数量不多就没必要分包，数量多的话再根据数量确定分几层。此外，“XX管理”可能不是一个好的Use case。因为在它的里面，可能包含了互相独立的一些功能。它可能更适合做一个模块的名字。

--------------------------------------------------------------------------------
我一般这么做，仅供参考：
包和用例包括(include)
1、包是在逻辑上的大的模块的划分，包内尽量于其他用例关系很少，包内用例关系密切。其只是在逻辑上和组织上使用，如包可以unit协同开发。

2、你说的情况一般作为include，单独一个用例图，描述主use case，当然也可以把这use case diagram放在一个包中，而且一般这么做也比较好，可以协同开发和分离用例的层次。
如果仅需要使用主use case，则不必引入include的用例，很多情况下可能用倒主用例的子用例，那么将主用例和这个子用例引入即可，带上include。

个人看法，仅供参考。

--------------------------------------------------------------------------------
对不起，我不太明白，如果不分包，那么你是怎样将用例分层的？

--------------------------------------------------------------------------------
我还有一个问题请教，你是怎样处理包内用例和其他包内用例之间的关系？谢谢！
--------------------------------------------------------------------------------
比如说，你只有十个用例。那样所谓的“XX管理”用例就都不要了，你只需要“添加任务”、“删减任务”等。如果你有几十个用例，那就分成“任务管理”、“活动管理”等几个包，每个包分别包含各自的用例。

-------------------------------------------------------------------------------

 回复: 这种用法应该不对
　

---

“如果非常多的话，应该使用包”
正是出于这个原因，可能我们对“分层”的含义理解的不同。
我所指的分层是指将与actor交互的use case层次化，一个系统中与actor交互的use case有很多（我指在use-case model,不是busness use-case model）,这些use case不可能放在同一张图中，那么，必然需要一些概括性的use case，以便在图中隐藏详细的use case。
另，讲到用包，我的考虑也是如此，但是，有一个很实际的问题，package不可能与actor用association连起来，而两者之间一般使用association，使用dependcy或者generalization不合适。那么只能生成一些概括性的use case，这样的话，use case可就体现出层次性了。

 回复: 这种用法应该不对
　

---

“如果非常多的话，应该使用包”
正是出于这个原因，可能我们对“分层”的含义理解的不同。
我所指的分层是指将与actor交互的use case层次化，一个系统中与actor交互的use case有很多（我指在use-case model,不是busness use-case model）,这些use case不可能放在同一张图中，那么，必然需要一些概括性的use case，以便在图中隐藏详细的use case。
另，讲到用包，我的考虑也是如此，但是，有一个很实际的问题，package不可能与actor用association连起来，而两者之间一般使用association，使用dependcy或者generalization不合适。那么只能生成一些概括性的use case，这样的话，use case可就体现出层次性了。

 回复: jdst有道理，我认为bool是将需求分析和系统分析工作合在一起了。
　

---

用户需求没有层次性么？
用户有大的模块上的需求，
模块中有若干功能的需求，
每个功能又有多种细节的需求。

 回复: jdst有道理，我认为bool是将需求分析和系统分析工作合在一起了。
　

---

需求是有层次性，系统分析也有层次性。
只要不走偏了，就好了。

 回复: 那么，具体看法？
　

---

我认为，如果从用户的视角出发，进行分层，那么就是需求分层。
如果从系统分析员架构系统的视角出发，来进行分层，那就是系统分层。
我认为系统分析员是不对用例进行分层加工工作的。
对用例进行分析，或分层，那是需求分析员的工作，即他只描述，并不考虑实现，所以，如果你是兼有需求分析员或系统分析员双重角色，那么可能会将这些工作混在一起，并一同推进。
这常是没法避免的，毕竟，你会不由自主地就进行了软件分析和设计工作。

我明白你的意思，但是你这样对Use case有很大的伤害，因为Use Case应该就是
用户（包括系统）的一种使用方式，它是以后开发的基础，如果现在可以被抽象，我觉得会影响需求的准确性。
比如一个看病的过程，用户Case是挂号，就诊，取药等。如果这是一个大系统的一部分，然后抽象出来一个大Case看病，这个Case将用户的需求的特点全部掩盖了，如果这个Case是你自己用，没有问题，但是作为需求，它是给后面的人用，这里就会有很大的问题。
所以如果你自己用，什么问题都没有，如果是一个开发的环节，就必须使用统一的概念，这也是UML的目的。
因为你抽象的这个Case和它包括的Case是什么关系呢？

 设想实际将会遇到的问题
　

---

就拿看病这个例子讲吧

如你所言，可以分成挂号，就诊，取药三个use case，那么现在我可以画一张use case图了（暂将该图命名为A图，注：不是毛图），图的内容病人（actor）与这三个use case的relationship，可能use case之间也会包括一定的relationship。

可是大家有没想过，挂号这个 use case又包含排队，指定就诊科室，付钱，得到挂号单这几个use case，同样，就诊也包括叙述病情，医生判断，（可能还需要进行检查，这里就要引入检查这个case了，而检测这个case又将包含几个小case），最后可能是开具药方。显然取药也将包括几个小use case。

我不可能把所有这些use case都放在一张图中吧？或许这里可以，但加入更复杂的use case呢，显然把所有use case拼在一起不是长久之计。
但我又必须得把挂号，就诊，取药这三个环节描述清楚吧，所以需要一张图来说明这三个环节，这就是A图，而每个环节又需要单独著图说明。

如果不分层说明，怎么办？
如果没有大的概括性的use case，怎么将过程说清楚？
　

只有认真地实践UML的人、只有肯动脑筋去掌握理论的人才能够提出这样的问题。回答这样的问题真让人有快感！这个问题曾经想了我三个月。

其实你自己离最后的答案只有一步之遥，请原谅我夺走了你自由思考的乐趣，不揣冒昧地替你捅破这层窗户纸吧

其实Use Case 之间可以有泛化关系（空心箭头的那种）。
“概括性的use case”是父Use Case，“具体的use case”是子Use Case。

你（或者是你的老板）愿意购买UML/RUP方面的咨询服务吗？如果愿意，请与我联系：wuyong@hotmail.com

 谢谢你的鼓励！可是我发现generalization的概念并非如此……
　

---

这是一段摘自The Unified Modeling Language Reference Manual：
A use case can also be specialized into one or more child use cases.This is use case generalization.Any child use case may be used in a situation in which the parent use case is expected.
[用例可以被特化成一个或多个子用例，即use case generalization。任何子例都可能出现在父例被使用的地方。]
-------------------------------------------------------------------
简单的讲,generalization中定义的父例与子例是继承的关系,而我所指的是组合的关系(这种关系可能用include和extented表达更合适).
　

其实你并不懂什么叫“特化”，或者对其只知其一不知其二。
如果你真的懂，当然就不必烦我饶舌了。
什么叫“继承”，看来你也并没有完全弄明白。你的问题可不正要用到他么？！
送块金子给你，还得奉送一块试金石！

本来我不打算大块地抄RUP的东西，这样的确有侵犯版权的嫌疑。
但是谁叫我人既懒水平又低呢？！
再次申明：下面的所有文字皆引至RUP，所有权利属于Rational(也许现在是IBM)。

指南：用例泛化关系

用例泛化关系 用例泛化关系是指一种从子用例到父用例的关系，它指定了子用例如何特化父用例的所有行为和特征。

主题
解释
执行用例泛化关系
描述用例泛化关系
使用示例
解释
父用例可以特化形成一个或多个子用例，这些子用例代表了父用例比较特殊的形式。尽管在大多数情况下父用例是抽象的，但无论是父用例还是子用例这两者都不要求一定是抽象的。子用例继承父用例的所有结构、行为和关系。同一父用例的子用例都是该父用例的特例。这就是可适用于用例的泛化关系（另请参阅指南：泛化关系）。

当您发现两个或更多用例在行为、结构和目的方面存在共性时，就可以使用泛化关系。这种情况发生时，您可以用一个新的、通常也是抽象的用例来描述这些共有部分，该用例随后被子用例特化。

示例：



“电话订购”和“Internet 订购”用例都是抽象用例“订购”的特例。

在订单管理系统中，“电话订购”和“Internet 订购”两个用例在结构和行为上存在很多的共同点。而一般用例“订购”是根据结构和公有行为的定义来定义的。虽然抽象用例“订购”本身无须完整，但是它提供了一个大体的、通过子用例进行完善的行为框架。

父用例并不总是抽象的。

示例：

考虑在上一示例中的订单管理系统。假设要增加一个订单登记员主角，该订单登记员可以代表客户将订单输入到系统内。此主角将启动一般的“订购”用例，此时必须要有一个完整的事件流来说明该用例。子用例可以在父用例提供的结构上添加行为，也可以修改父用例中的行为。



订单登记员主角可以将该一般的“订购”用例实例化。“订购”用例还可以被“电话订购”或“Internet 订购”用例所特化。

子用例依赖于父用例的结构（请参阅指南：用例，关于事件流结构的讨论）。子用例可以将附加行为添加到父用例中，方法是将行为段插入到被继承行为中或者声明对子用例的包含关系和扩展关系。虽然子用例可以从父用例继承行为段，但是必须慎重修改，以便保持父用例的使用目的。父用例的结构由子用例保持。这意味着尽管所有行为段（即父用例事件流的步骤或分支流）仍然必须存在，但是这些行为段的内容可以被子用例修改。

如果父用例为抽象用例，则它可以具有不完整的行为段。但是，子用例必须补充完善这些行为段，并使得它们对于主角而言是有意义的。

如果父用例是一个抽象用例，则它无需与主角发生关系。

如果两个子用例都对同一父用例（或基本用例）进行特化，则二者之间的特化是相互独立的，这意味着它们可以在各自独立的用例实例中执行。这与包含关系和扩展关系不同。在包含和扩展关系中，一些附加用例隐式或显式地修改了执行相同基本用例的一个用例实例。

用例泛化关系和包含关系都可以用来复用该模型用例间的行为。二者的区别是，在用例泛化关系中，执行子用例不受父用例的结构和行为（复用部分）的影响；而在包含关系内，执行基本用例只依赖包含用例（复用部分）执行有关功能的结果。另一个区别是，在泛化关系中，子用例有相似的目的和结构；而在包含关系中，复用相同包含用例的基本用例在目的上可以完全不同，但是它们需要执行相同的功能。

执行用例泛化关系
执行子用例的用例实例将遵循父用例的事件流，同时插入附加行为或修改在子用例事件流中定义的行为。



用例实例遵循父用例，而行为按子用例中的说明插入或进行修改。

描述用例泛化关系
通常，您可以不用描述泛化关系本身。相反，在子用例事件流中，您必须指定如何将新步骤插入到继承行为中以及如何修改继承行为。

如果子用例特化不止一个的父用例（多继承），则必须在子用例的规约中明确说明父用例的行为序列如何在子用例中交替执行。

使用示例
对于一个简单电话系统的两个用例，可考虑以下分步概述：

拨打本地电话
呼叫方拿起听筒。
系统发出拨号音。
呼叫方拨打一位数字。
系统结束拨号音。
呼叫方输入电话号码的其余数字。
系统分析该号码。
系统找到相应的当事人。
系统连接相应的当事人。
当事人之间断开连接。
拨打长途电话
呼叫方拿起听筒。
系统发出拨号音。
呼叫方拨打一位数字。
系统结束拨号音。
呼叫方输入电话号码的其余数字。
系统分析该号码。
系统将号码发送到其他系统。
系统连接该线路。
当事人之间断开连接。
在这两个用例中，使用蓝色的文本部分是非常相似的。当这两个用例是如此相似时，我们应该考虑将它们合二为一。其中，其他分支流显示了拨打本地电话和拨打长途电话之间的差别。

然而，如果它们之间存在某些重大的差别，而且有一个值指明了该用例模型中本地电话和长途电话之间的关系，那么我们就可以提取它们之间的公有行为，组成一个新的、更一般的用例即“拨打电话”用例。

在用例图中，已创建的泛化关系如下图所示：



“拨打本地电话”用例和“拨打长途电话”用例都继承了“拨打电话”抽象用例的公有行为。



© 1987 - 2001 Rational Software Corporation。版权所有。



Rational Unified Process
　

我也刚开始学用ROSE,希望大家多多指教。
我知道的是，分层可以通过给PACKAGE加上LAYER扩展型表示

 唔，你引用的这份资料翻译得不赖。
　

---

可以的话给我一份～
--------------------------------------------------
仔细地读了你引用的文字，它的确对泛化描述地比较清楚。
但是，你可能误解我的提问了(我想是我的问题不够清晰)。
其实我的提问的本意是：
一个系统的use case图数量可能有很多,因为一个UC便是用户的一个操作,而use case view的目的是列举出所有的actor与UC。
那么，应该如何组织这么多零零总总的use case图呢？怎么让阅读者明白自己阅读的这张图在整个系统中的位置呢？
-------------------------------------------------
所以,我提问的本意并非是讨论一个UC间的relationship的问题.
原先,我的想法是将UC们依照功能范围分一下层次,功能范围上大的UC由更详细的UC来组成.这就好比是给一篇文章分一下段落,大段里有小段,这样,读起来就比较清楚了.
但我现在开始怀疑这样的做法有背于UC的概念,一个UC是一次完整交互过程的动作序列,UC是具体的,不是笼统的,这不是指不允许UC抽象,而是指如果一个UC定义成没有具体交互操作序列,只是纯粹表明由其他一些UC随机组合而成(比如某某管理这类的UC的定义往往就是这种情况,没有具体的操作序列,只是存在着若干种操作的可能性).

 回复: 初级问题,已研究两天.use case图在rose中如何进行分层.
　

---

我觉的这个问题不是如何分层来实现的！！！而是你站的角度不同，划分的问题域不同，其实这是一个业务细分/迭代的过程。
首先，你所说的第一层实际上就是一个大的业务用例(假设A1)，他有自己的外部活动者，有自己的业务流程。A1时序图中的节点对象会表现众多不同的业务行为来实现当前的业务流程。同理，B1的分析同A1，C1、D1、...、N1等。
下面我们分析子业务，子业务实际上是由分析众多一级业务流程中节点对象的业务行为，汇总/归纳出子业务的。子业务也可看作为一个业务用例。然后同上分析当前子业务。
以此类推，就可分析到最末梢树叶用例。业务分析完毕！
用例没有分层关系，用例之间的关系只有泛化、扩展、包含关系。
欢迎讨论：gamesbox@sina.com.cn

 回复: 初级问题,已研究两天.use case图在rose中如何进行分层.
　

---

我觉的这个问题不是如何分层来实现的！！！而是你站的角度不同，划分的问题域不同，其实这是一个业务细分/迭代的过程。
首先，你所说的第一层实际上就是一个大的业务用例(假设A1)，他有自己的外部活动者，有自己的业务流程。A1时序图中的节点对象会表现众多不同的业务行为来实现当前的业务流程。同理，B1的分析同A1，C1、D1、...、N1等。
下面我们分析子业务，子业务实际上是由分析众多一级业务流程中节点对象的业务行为，汇总/归纳出子业务的。子业务也可看作为一个业务用例。然后同上分析当前子业务。
以此类推，就可分析到最末梢树叶用例。业务分析完毕！
用例没有分层关系，用例之间的关系只有泛化、扩展、包含关系。
欢迎讨论：gamesbox@sina.com.cn

 回复: 初级问题,已研究两天.use case图在rose中如何进行分层.
　

---

我觉的这个问题不是如何分层来实现的！！！而是你站的角度不同，划分的问题域不同，其实这是一个业务细分/迭代的过程。
首先，你所说的第一层实际上就是一个大的业务用例(假设A1)，他有自己的外部活动者，有自己的业务流程。A1时序图中的节点对象会表现众多不同的业务行为来实现当前的业务流程。同理，B1的分析同A1，C1、D1、...、N1等。
下面我们分析子业务，子业务实际上是由分析众多一级业务流程中节点对象的业务行为，汇总/归纳出子业务的。子业务也可看作为一个业务用例。然后同上分析当前子业务。
以此类推，就可分析到最末梢树叶用例。业务分析完毕！
用例没有分层关系，用例之间的关系只有泛化、扩展、包含关系。
欢迎讨论：gamesbox@sina.com.cn

 不应争论用例应不应有分层，而在于分层能不能有助于业务层面的分解、有助于分析。
　

---

如果你的业务系统不仅存有于一个横向的业务流，而且在纵向上，是有不同的业务层面，那么是分层还是分包，还是一个用例的分解呢，这完全取决于你看问题的视角及你头脑中的固有的模型。

 回复：我赞同你的说法，分包、分层只是分析者的视角、固有模式的结果
　

---

我赞同你的说法，分包、分层只是分析者的视角、固有模式的结果。但我更倾向于分包，毕竟父级/子级的业务并不一定向树状结构那样，实际上是有交叉，可能是多对多的样子。