UML NO : 8 在分析完了系统的活动流程、数据流之后，如何提取类？请各位来谈谈！ (300分)

谢绝灌水！

《统一软件开发过程》

thanx []

2 子陵:
http://www.rational.com/products/whitepapers/100420.jsp
<<Rational Unified Process:Best Practices for Software Development Teams>>
Rational Software Whitepaper
这文章如何？

麻烦提供《统一软件开发过程》的下载地址！中英文都可以！

我又来了:
提取类的问题我先给你明确我们接着下来要提的类包括哪些?
1.实体类:是用于存储信息,资料的类(如银行的帐户)
2.边界类:是用于与外界的接口的类(如ATM交款的接入,或是给用户输入信息的类)
3.控制类:是用于控制实体类的存储的类;(如各种的SAVE(),DELETE()等)
4.接口类:是用于软件与硬件间的接口的类;
基本的类已经确了,哪你可以根据你所做的用例模型进行分析(用例模型是在需求分析中做成的)
注意:类包括参数与函数,与一些属性等!
当然你可能会问接着我们要进行什么吧!我在这里也为你提一提吧!
定义好以上的类后我们将要做的是用例实现(是虚线的圆),这是最难的一项
主要是做顺序图与协作图,是将你每一个用例如何运行,如何调用数据库中的数据,如何传递
参数等全部详细表述,(我试过省些功夫,但在定程序过程中同样要考虑以上的问题,但不是专
一的去想,想出来的效果并不好!)
最后便是根据你所定议的类与用例实现(一定要按这些顺序图与协作图去写程序否则容易跑题)
最后告诉你一声,UML(ROSE2002)只是用以程序分析并不能真正生成有用的代码,我曾试过生成
JAVA的架构是可以的,但全部的代码还是要自己填上去)
就谈到这里吧!886 ^_^

忘了告诉你一些注意事项,以下一些为注意事项最好能做到,不过不用强求,因为太严谨了难以
开展工作!^O^
分析类名是唯一的。
该类至少用于一个协作中。
类的简要说明阐明了类的目的并对其职责进行了简要概述。
该类代表一组相互之间关系紧密的职责。
职责名称是说明性的，并且责任说明是正确的。
该类的职责与该类所在协作对它的期望相符。
执行用例所需的所有类（不包括设计类）均已确定。
主角与系统的所有交互均由某一边界类支持。
没有两个类具有相同的职责。
每个分析类均代表一组不同的职责，且与类的目的相符。
用例之间的关系（包括、扩展、泛化关系）在分析模型中的处理方式一致。
对各分析类的整个生命周期（创建、使用、删除）均进行了说明。
该类直接或通过委托关系履行了对其要求的职责。
类协作由相应的关联关系来支持。
对该类的所有需求均已满足。
如果该类是边界类，则主角的所有需求均已满足（包括输入错误）。
所有永久类都已映射到数据库结构。
已经优化了数据的存储和检索。
如果使用的是关系数据库，则已经对表进行了取消规格化（在必要的地方）以提高性能。
在已使用取消规格化的地方，已经考虑了所有更新、插入和删除的情况，以确保取消规格化不会降低这些操作的性能。
已经定义了索引来优化访问。
已经在其他表操作中考虑了索引更新的影响。
已经计划了数据的分布。
已经定义了数据和参照完整性约束。
数据规则变更时，存在维护确认约束的计划。
已经确定了存储过程和触发器。
永久性机制一致地使用存储过程和数据库触发器
类必须满足由该类所参与的用例实现和用例示意板所确定的需求。
各类之间尽可能独立。
类的特征，包括它的职责、单向关系和属性，需要调整并且彼此之间保持一致。
具有双向关系的类涉及的角色清楚而又直观。
其成员的可见性（主要指属性）正确。可见性可为“公有”、“私有”等等。
其成员的范围（主要指操作和属性）正确。对于类型/类范围来说，范围是“真”；而对于对象/实例范围来说，范围是“假”。
特殊需求简明易懂，且符合设计目的。
说明类的图简明易懂且与其他特征一致。
实体类
实体类在那些处理长生存期（永久性）对象的所有系统中非常实用。
边界类
边界类在那些要求系统及其用户，或系统和其他系统之间存在某类交互的所有系统中非常实用。
控制类
在具有复杂行为的所有系统中 - 即系统提供的不仅仅是“填空”式的简单用例，控制类非常实用。
类的名称清楚地反映出它所起到的作用。
类的说明清楚表达它的目的。
类代表一个明确定义的抽象。
类的属性和操作对于履行类职责是必不可少的。
每一个类都代表一个统一且唯一的小型职责集。
类的职责需要明确定义、清楚说明，并且与类的目的具有明确的关系。
每个类相对独立，并且与其他类松散耦合。
类的职责具有一致的抽象层次（也就是说，高层次（应用层）职责和低层次（实施层）职责没有混淆）。
同一继承分层结构中的类具有独特的类属性、操作和关系（也就是说，它们继承所有常见的属性、操作和关系）。
类实例的完整生命周期需要进行说明。每个对象由一个或多个用例实现创建、使用并删除。
类满足用例实现规定的行为要求。
需求规约中类的所有需求已经得到阐明。
对类的需求（正如在类说明中以及通过序列图中的对象所反映）需要与类的状态机保持一致。
类的所有职责互相关联，因此类就不可能存在于这样一个系统中：某些职责得到使用而其他职责却无法使用。
没有两个类具有相同的目的。
每个操作的名称都是描述性的，并且可以让人理解。
状态机和操作需要保持一致。
状态机和操作完整地说明类的行为。
每个操作的参数在数量、名称和类型上均正确无误。
所定义的每个操作的实施规约需要正确无误。
操作签名需要符合目标编程语言的标准。
每个操作至少由一个用例实现使用。
状态机虽然要尽可能保持简单，但仍然要求它能够表达所需的行为。
状态机不包含任何多余状态和转移状态。
状态机有一个清楚的环境。
所有引用的对象对于附带对象都是可见的。
状态机效率较高，并在执行行为过程中对其发出的操作所定义的时间和资源进行优化平衡。
状态机易于理解。
在系统领域的环境中可以理解状态名称和转移名称。
状态名称表示正在等待或正在发生的事情，而不是已经发生的事情。
状态名称和转移名称在状态机内部必须唯一（虽然不是严格要求，但是这有助于在调试过程中确保名称唯一）。
状态的逻辑分组包含在复合状态中。
是否已经有效地使用复合状态以减小复杂性？
转移标注反映转移的基本原因。
状态转移的代码段没有超过 25 行详细代码；相反，已经有效地使用了函数来降低转移代码的复杂性。
状态机嵌套情况需要进行检查，以确保嵌套深度不宜过深而不可理解；通常对于大多数的复杂行为而言，有一或两个级别的子状态就足够了。
使用封装体（活动类）而不要使用并行子状态；因为封装体始终是比并行子状态更好的备用方法，而且更加容易理解。
错误或维护状态已得到说明。
已经使用子状态替代了扩展状态变量；就测试若干个变量的转移警戒条件而言，没有任何迹象可用于确定表明应该进行状态转移的变量。
状态机与流程图不同。
状态机看上去没有过多地分解，它是由带有单个子状态的已嵌套状态机组成。如果将嵌套子状态作为将来设计工作或建立子类的“占位符”来使用，这一选择只要是理智的，就可以暂时接受。

2 Alix88:
thanx for ur help.我到需要好好看看上面的内容呢！呵呵！[]
你看看http://www.delphibbs.com/delphibbs/dispq.asp?lid=956101
上次你给我的例子，我就认为你对包的理解有点偏差。如果你有什么不同的看法，到上面
地址发言！谢谢！

2 Alix88:
有空的时候把上面你的文章换行！谢谢！

taozhiyu 这两天吃蜂蜜了？[]

2 Alix88：
为什么你那么喜欢用商务用例呢？这个东西描述的是现实的商业活动。我觉得还不如用活动
图好了。另外建立商务的用途是为了评价投资回报的吧！我只是用了use case，用它来捕捉
系统需求。你给我说说商务用例和用例的区别！

2 Alix88：
请看下面的：
[red]
The purposes of business modeling are:
To understand the structure and the dynamics of the organization in which a
system is to be deployed (the target organization).
To understand current problems in the target organization and identify improvement potentials.
To ensure that customers, end users, and developers have a common understanding
of the target organization.
To derive the system requirements needed to support the target organization.
[/red]
从上面的说明可以看出，商业建模应该是在软件工程的初期进行的，是为了对目前运转中
的系统进行认识而使用的！！！所以我认为下需求分析阶段就不应该用商业模型了！不知道
你怎么看！

另外，你的分析类的方法不错，我来try一下！*^_^*

建议搭配《UML用户指南》和《统一软件开发过程》一起看。一个讲语言，一个讲过程。
网上好像没有电子书，可以在china－pub买dowm币看电子书，不过中文版翻译的不太好，
凑合的看吧。
我也初学，正在看这些软件工程方面的书，感觉收获颇大。

子陵,
把《统一软件开发过程》给我们下载啦！你肯定有啦！

没有，我是买书看的，电子书看起来太累人了！

不好意思,这段时间忙不气来,(做一个OA系统)
还是针对你的问题解说几句吧~!
首先:我给你的哪个例子只是做了业务分析与需求分析,系统分析只做了一点,(类的定义)
至于用例实现并没有做,时间不够)
其次:活动图是用以描述复杂的用例的,是用以用例的子图,还说一声对不起我上次所发的
是英文版的例子,
至于你说到的包问题我同意,在我做的例子中也是这样分的,另外,若你有时间可以参考
RUP2001(中文版)若是英文好可以看看RUP2002,里面有很详细的说明,我便是看那里而做
出来的,我们的研究所正在研究这一套的流程,或许有些偏差,不过若不是重大的问题,应该
没有什么的,若你认为是比较严重,我可代你向RATIONAL公司一个朋友询问;
我曾上过你的网站看过,你没有将最新的东西传上去,不知道你的情况,若可以可将你的做的
模寄过来一起来审审!

给我介绍一个rational公司的人啦！

我覺得提取類這個問題﹐不能單從理論上來做﹐我舉個例子
比如一個人事系統﹐按分析呢員工理所當然是一個類,但是當類的數據
存在數據庫的時侯就有了問題。
假如客戶要一個列表﹐那么怎么做呢﹐我們只能從數據庫讀出,歷遍,create class,
然后再歷遍這一大堆員工類﹐讀到列表中。如果用戶來一個過濾﹐我們又要重復一次。
這樣就結合了 難編寫﹐速度慢﹐耗資源多的各個"優點"于一身................

lqy,
我知道提取类这个问题仁者见仁，智者见智的。所以我就是想听听各位的心得哦。
你举的例子应该是说用户的需求是不断变化的，会导致一些重复性的工作。这个的确是个事实。
我想我们做分析的目的就是要构建一个平台，他能够适应变化的需求，而我们的工作量却
不会因需求的变化而突增N倍。
怎么做这样的平台？我想这是一个需要探讨的问题，RUP只能说给我们了一条不是很坏的指导。
或许他又缺陷，不过就我现在的水平来看，我觉得蛮好。同时我相信他不是最完美的，需要完善。