看uml的笔记，如有不对，请大家指教，谢谢！

<P>问题：应用系统分析？
1：得到一个非常明确的反映真实的客户需求，而不是一个能使客户和开发人都能充分理解的业务领域模型
2：得到分级别的有组织的用例而不是使用功能分解
3：识别相关领域和支持领域，开始计划他们与核心领域的集成

问题：应用系统的设计

步骤 --------------------- （相应的实现明晰：）
1：确定系统架构 --------------------- （相应的确定系统架构的静态，动态的功能模块 ，了解模式语言）
2：确定存在类的系统功能 --------------------- （增加crc到crd）
3：确定“实现联合，分解多样性，寻找方法和内部通讯“的设计机制 --------------------- （寻找存在类的新功能和新类）
4：在这个水平上设计可知的类 --------------------- （头文件<方法的前置和后置条件，不变类>，状态图，降低风险等级）
5：完成使用接口它需要程序员的判断力 --------------------- （更新用户手册）
6：根据用例验证设计的有效性 --------------------- （序列图）

设计活动过程显示：

1：选择和定制统一的架构，组件，模式，框架
2：模型设计和多样性分解
3：属性变成了类
4：责任变成了方法其中包括参数，返回值，异常处理，前置和后置条件
5：考虑性能，内存限制，垃圾回收，数据的持久性
6：创建新类

用例的粒度
1：概括性用例（它是粗粒度用例，它包含多个低级别的用例，它给他们提供一个上下文！）
2：用户性用例（它是用来描述主要的角色或用户已经完成/正在进行的系统目的。它通常由某个人在某个时间的某个地点进行一项任务，一旦目标完成，用户或角色就消失！）
3：子系统功能性用例（它是来支持用户性用例）

过程处理-----------------------------〉角色

1：所有的经具体讨论的角色和他们的主要目的
（1）：重新考虑那些主要贺次要角色，包括那些初始者，服务提供者，服务接收者，设备支持者
（2）：例举每一个主要角色的目标也就是他们的工作清单

过程处理----------------------------〉用例要点/概要

1：为每一个在系统中的角色目标来构造那些概要性的或用户级的用例细节


过程处理----------------------------〉用例主体

1：从触发到结束来捕获每一个角色的内容和责任
2：在处理例外之前为每一个角色填写主要的成功场景

过程处理----------------------------〉用例结构

1：对于每一个用例
1。如果正常的场景步骤超过了9步，就必须把它分成两个用例的东东
2。如果正常的场景步骤不超过三步，就要考虑把他们加到上一个调用他们的角色中去。


一般的技巧
1：清晰地分清角色的意图和责任和这些系统。形成清量级的系统边界
2：超连接是非常有用的对于相关的用例

用例模式：

用例包含的内容：

1：用例图和用例描述
2：用例中有三中关系（包含，实现，扩展）
3：用例的类型有抽象的和</P>

从楼上这位兄弟的描述来看使用的可能是visio，而不是rational rose，其实我觉得使用uml的最关键的地方在于首先：了解需求，让不同领域的人通过图形化的方式，达到对于某个系统的一致性的认知；其次：在于让设计人员和开发人员对于一个行业的流程从未知到专业级的，因为很多开发人员不是对于需求理解不透测而是对于相应的业务流程不清楚和相应的行业概念和术语不知道。通过当然了如果这样的化作出来的软件是无法使用的，使用uml能够清晰的表达各个流程之间的联系，例如顺序图、活动图等；第三：通过uml工具可以方便的构造和修改我们自己的类，以达到所见即所得的地步，以上是个人的一些看法。见笑了。