图书馆案例
1、需求分析
1）集思广益：通过与用户面对面交谈来获取用户意见
2) 初始化需求文档形成：提取用户意见的有用信息，形成初步的需求分档
2、角色及用例[use case Diagram]
确定系统的角色和用例（用例一般为系统的角色的操作或相关操作）。用例的建立应遵循以下原则：
1）用例应独立于实现：用例关注的是用户对系统的需求，而不是如何实现。用户不关心完成一个用例需要多少个步骤或多少行代码，也不关心系统要划分为几个模块或与多少个其它系统交互。
2）用例要尽可能完整：用例是系统的高级视图，用例的集合应让用户易于了解整个系统的概况。用例不能太粗地体现系统的功能，太多则失去了简单的好处。可以用使用与扩展关系将用例进行必要的分解，也可以将用例组合成组，以便于组织。
3）用例要关注系统外的用户：每个用例应表示用户与系统间的完整事务，为系统使用者提供一定的独立业务功能。用例应按业务术语命名，而不是按技术术语命名，应让用户一目了然。
3、用例分析[Activity Diagram]
1） 对用例进行详细的设计，通过与涉及到的用户进行细致的交谈来确定每一个用例的具体流程。
2）事件描述：通过自然语言对每个事件进行详细的描述，例如：用例叙述（即用例结果），假设条件，前置条件，后置条件，参与者，步骤序列（主事件流，其它事件流）等信息。
建立事件流时的主要问题是事件流需要的详细程度。要确定需要的详细程度，就考虑文档的阅读者。事件流的用户有以下三类：
一：用户通过审查这个文档以确认其准确反映用户的期望。事件流应足够详细，使你和用户对系统具有相同的理解程度。细节中留下的空白越多，产生分歧的可能性就越大。与此同时，又不能涉及到用户不了解或不关心的细节。
二：系统设计员用其创建系统设计和最终建立系统。事件流要提供足够的信息，以便理解用例中要发生的事件序列。尽管事件流不是针对实现方法的，但提供系统行为的丰富信息。一定要明确指定用户要什么，使设计人员了解用户需求。
三：测试人员以事件流为依据创建测试脚本。由于事件流一步步列出系统的工作，因此测试小组可以用事件流比较系统说的和做的是不是一回事。事件流本身不是测试脚本，但可以作为测试脚本的输入。
3）活动框图
通过上边的分析，对逻辑复杂的用例用框图的形式进行表示，这样更加直观。完成用例文档或活动框图后，应交给用户让用户看是否符合用户需求，然后再根据用户建议进一步修改完善文档或框图。
4）用例模型
当我们仔细分析所有的用例，可以清楚地看出在许多用例中对会重复用到一些一致的功能，我们可以将这些功能分解为用例，其它用例和这些用例建立包含关系。这种用例称为抽象用例。抽象用例不由角色直接启动（普通用例都应由角色启动），而是提供一些公共功能，让其它用例使用。抽象用例是参与使用和扩展关系的用例。
这步完了后应该对原有的用例模型进行修改。
4、系统静态分析 【Class Diagram】
1）寻找对象:初步的类图可以从用户的会谈记录或者用例文档中产生。文档中的名词主要包含以下四种类型(角色、对象、对象属性、除这3种以外的表达式)。通过这些名词我们可以确定初步的类对象，然后通过对类进行筛选，筛选的目的就是删除那些不必要和不正确的对象类，筛选应该遵循下列标准：
a)冗余：如果两个类表达同样的信息，则应该保留在问题域中最富于描述力的名称。
b）无关：现实世界存在许多对象，不能把它们都纳入到系统中去，仅需要把与问题域密切相关的类放到目标系统中。有些类在其它问题中可能很重要，但与当前需要解决的问题无关，同样应该将他们删除。
c）模糊：在需求陈述中常常使用一些模糊的、泛指的名词，虽然在初步分析时把它们作为候选对象类列出来了，但是，要么系统无须记忆有关它们的信息，要么在需求陈述中有更明确更具体的名词对应它们所暗示的事务，因此，通常把这些模糊的或笼统的类去掉。
d）属性：在需求陈述中有些名词实际上描述的是其它对象的属性，应该把这些名词从候选对象类中去掉。当然，如果某个性质具有很强的独立性，则应把它作为一个独立的类而不是作为属性。
e）操作：在需求文档中有时可能使用一些既可以作为名词又可作为动词的词，对于这些词应该慎重考虑它们在系统问题域中的含义，以便正确地解决是把它们作为类还是作为类中定义的操作。
f）角色：类名应该反映它本身的固有性质而不是一个在关联中扮演的角色。一个物理实体有时对应几个类，区分它们是很重要的。
g）实现结构：在分析阶段不应该过早地考虑怎样实现目标系统。因此，应该去掉仅和实现有关的候选对象类。在设计和实现阶段，这些对象类可能是重要的，但在分析阶段过早地考虑它们反而会分散我们的精力。
2)描述对象属性：添加类的主要属性
3）描述对象之间的关联。
5、系统动态分析
1）动态用例分析：通过时序图（Sequence Diagram）或者协作图（Collabration Diagram）这2种交互图来显示用例的一步步的流程。
2）动态状态分析：通过状态图（Statechart Diagram）来分析单个对象的行为。对于有多种内部状态的对象，状态图可以显示如何从一个状态过渡到另外一种状态，以及对象在不同状态中的不同行为。使用状态图我们可以了解对象行为的更多动态细节。
（注：交互图和状态图的区别为：交互图通过一个用例的完整事件流程分析多个多个对象之间的交互来了解每个对象的行为；而状态图只是针对单个对象建模，通过分析单个对象的内部状态转换来了解一个对象的行为。）
3）描述对象操作（方法、服务、职责）：加入类的主要操作。这步不包含读取属性等操作。
6、系统详细设计
1）系统总体设计：将系统从整体上分成耦合度低的各个模块，这样便于维护；
2）系统详细设计：主要完成的工作为：
a）细化、填充类的属性和操作；
b）设计类操作的实现算法；
c）优化数据的访问路径；
d）实现外部交互式的控制；
e）调整类结构以提高继承性；
f）设计类之间的关联的实现方法；
g）把类和关联封装成模块。【component，component Diagram】
6、系统实现
1）编写代码时从下面的设计模型中取出规范说明：
a）类规范：每个类的规范详细地显示了必要的属性和操作；
b）类图：类图由类构成，显示了类的结构以及类之间的关系；
c）状态图：类的状态图显示了类可能具有的状态以及需要处理的状态转移（以及触发状态转移的操作）
d）动态图：（时序图、协作图和活动图）：涉及到类的对象，显示了类中的特定方法如何实现，或对象之间如何使用其它类的对象进行交互；
e）用例图和规范：当开发者需要了解更多的关系系统如何被使用的信息时，用例显示了系统被使用的结果。
2）代码生成的主要元素如下：
a）类：代码中生成模型中的所有类；
b）属性：代码包括每个类的属性，包括可见性、数据类型和默认值。在某些语言中，相应属性的Get和Set操作也能自动生成；
c）操作：代码中声明操作及其参数、参数类型以及操作的返回值；
e）关系：模型中的有些关系会使属性在代码生成时产生；
f）组件：每个组件由相应源代码文件实现；
g）文档：添加文档时，代码生成器在适当的位置插入文档说明。
7、如果在代码实现时发现设计时的缺陷时，可通过rose的逆向工程来完成，从而保证设计模型和程序代码之间的同步，从而使模型能够成为系统系统的最终文档。