Think in UML 阅读笔记（三）
把从现实世界中记录下来的原始需求信息，再换成一种可以知道开发的表达方式。UML通过被称为之概念化的过程来建立适合计算机理解和实现的模型，这个模型被称为分析模型，它介于原始需求和计算机实现之间，是一种过渡模型。绘制分析模型最主要的元模型有：边界类（boundary）、实体类（entity）、控制类（control）。UML采用控制类来表达原始需求中的动态信息，即业务或用例场景中的步骤和活动。除了控制类外，其他类之间都不能直接相互访问，他们需要通过控制类来代理访问要求。这样做的目的是把动作和物体分开。通过一个儿时的小游戏来说明：只要有人、事、物和规则（定语），就能构成一个有意义的结果。
边界类代表了原始需求中的“事”，实体类代表了现实世界的“物”，控制类则体现了现实世界的“规则”，加上由参与者转化而来的系统的“用户”，这样一来，人、事、物、规则都有了。
在设计模式中，概念模型中的边界类可以被转化成操作界面或者系统接口；控制类可以被转化成计算程序或控制程序；实体类可以转化为数据库表、XMML文档或者其他带有持久化特征的类；这些转化可以遵循的规则有：软件架构和框架、编程语言、规范或中间件。
现实世界==》对象世界，Modeling 模型
业务模型==》概念模型，Conceptual 概念
概念模型==》设计模型，Design 设计
整个过程都涉及到了用例驱动；
对于UML统一建模语言，我们在大二的时候已经学习过，对于他的过程和基本概念有了一个基本的了解，而且也已经有过建模的项目，所以对此比较了解；像参与者、用例、边界、包等，像类之间的关系有：关联关系、依赖关系、扩展关系、包含关系、实现关系、泛华关系、聚合关系、组合关系等等；UML中的图有：用例图、类图、包图、活动图、状态图、协作图等；
对于如何确定自己想要做的方法就是软件过程，软件过程明确了软件的生命周期，明确了软件生命周期过程中的成果物和可交付物，同时也就明确了需要什么样的模型，软件过程明确了在软件项目的哪个阶段使用哪些模型；UML使用最多的几个工作流程：
（1）业务建模工作流程
（2）系统建模工作流程
（3）分析设计工作流程
（4）实施建模工作流程；
业务模型（位于统一过程中先启阶段）工作流程：在起步阶段时，评估业务状态，然后业务建模，说明当前业务，确定业务流程，改进业务流程，设计业务流程实现。改进角色和职责，流程自动化研究，开发领域模型，业务模式是以软件模型方式描述企业管理和业务所涉及的对象和要素、以及他们的属性、行为和彼此关系，业务模型强调以体系的方式来理解、设计和架构企业信息系统；
系统模型（需求过程）工作流程：在新系统或现有系统后分析问题理解涉众的需要，对于一些错误的问题，提出可选的解决方案，选出最佳解决方案，如果无法完成所有的工作，我们就需要改下系统的定义，知道需求定义完成；
需求属性是用来管理和追踪每个需求在项目进行过程中的变化情况；Rational专门有一个Rational Request Pro工具来管理需求属性；软件需求规约就是需求规格说明书，它需要将用例模型（包括用例规约、用例试图等）和补充规约、系统界面原型等集中起来；
分析设计模型工作流程：定义备选架构->分析行为->设计实时构件（设计构件），分析行为即分析用例场景，它是使用分析类或者设计类，并结合架构来实现用例场景的过程，对于这个过程，不要过多的关注细节，这样必将导致工作量的急速增加，同时也会产生巨大的信息量，降低人脑处理他们的能力。因为我们需要研究的是系统的行为以及对架构来说比较重要的那些对象，而不要详细到方法和属性。分析设计的目标在于将需求转化为未来系统的设计，逐步开发强壮的系统构架，使设计适合于实施环境，为提高性能而进行设计；
实施建模的目的是建立组件及其所在的实施子系统的集合，实施模型将开发工作分为许多工作包，因而可以协作生产这些工作包，然后组装他们以形成最终系统；