OA系统项目开发UML小结以及基于领域模型的系统设计初步UML不是OOA/D也不是方法,它仅仅是一种图形表示法。其目的就是让人能看懂你的东西。每一种图，都相当于一种角度。不同的图就是从不同角度来观察系统。比如交通图和行政区划图，从不同角度观察中国。必要性是画图的原则，虽然有这种关系，但不一定要画出来，如果非要画出来，则应考虑不要影响图形的美观。活动图活动图表示的是一种流程。例子：顺序图顺序图的目的是为对象分配职责，而不是步骤的罗列。上图中，ActionServlet是没有必要画出来的，它是一个很稳定，也不是我们自己提供的，没有必要来说明它的对象职责。插在这里显然多余.如下图这样就可以了：用例和用例图用例的定义：文本形式的情节描述。用例用于需求的发现和记录，它会影响后续的OOA/D工作用例不是用例图。用例图不重要，用例描述很重要。用例尽量不要用名词命名，尽量以动词开头，比如：管理商品。用例一般是用于功能性的需求而非性能性需求。编写用例时，在基本路径（即主成功路径）中，只书写主要的成功事件，而可能出现的其他情况（如找不到用户）应该写在扩展点中。用例粒度：比如：是把管理用户当做用例还是把添加用户和删除用户分别当做两个用例。确定用例的粒度时，应该考虑描述这个用例的基本路径需要几个步骤。十步以内，七八步比较合适。一个典型的用例描述一个典型用例图其中销售经理和收银员之关系是泛化关系，即经理拥有收银员所拥有的一切用例。另外还有其独有的用例。类图类图允许我们标记静态内容及类之间的关系，它是UML中最重要的图形，可以在任何时候尝试使用类图。不要使用类图描述所有的细节，保持类图的简单。UML中主要有三种类：边界类、控制类和实体类边界类位于系统与外界的交界处，例如窗体、报表、以及表示通讯协议的类、直接与外部设备交互的类、直接与外部系统交互的类等。通过用例图可以确定需要的边界类，每个Actor/UseCase对至少要一个边界类，但并非每个Actor/UseCase对要唯一的边界类。实体类可以通过事件流和交互图发现。通常每个实体类在数据库中有相应的表，实体类中的属性对应数据库表中的字段。控制类是控制其他类工作的类。控制类可以被多个用例共用。其他类并不向控制类发送很多消息，而是由控制类发出很多消息。类图中，要画出类之间的关系UML中继承、实现、依赖、关联、聚合、组合的联系与区别继承(也叫泛化)指的是一个类（称为子类、子接口）继承另外的一个类（称为父类、父接口）的功能，并可以增加它自己的新功能的能力，继承是类与类或者接口与接口之间最常见的关系；在Java中此类关系通过关键字extends明确标识，在设计时一般没有争议性；实现指的是一个class类实现interface接口（可以是多个）的功能；实现是类与接口之间最常见的关系；在Java中此类关系通过关键字implements明确标识，在设计时一般没有争议性；依赖可以简单的理解，就是一个类A使用到了另一个类B，而这种使用关系是具有偶然性的、临时性的、非常弱的，但是B类的变化会影响到A；比如某人要过河，需要借用一条船，此时人与船之间的关系就是依赖；表现在代码层面，为类B作为参数被类A在某个method方法中使用；关联他体现的是两个类、或者类与接口之间语义级别的一种强依赖关系，比如我和我的朋友；这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的，一般是长期性的，而且双方的关系一般是平等的、关联可以是单向、双向的；表现在代码层面，为被关联类B以类属性的形式出现在关联类A中，也可能是关联类A引用了一个类型为被关联类B的全局变量；聚合聚合是关联关系的一种特例，他体现的是整体与部分、拥有的关系，即has-a的关系，此时整体与部分之间是可分离的，他们可以具有各自的生命周期，部分可以属于多个整体对象，也可以为多个整体对象共享；比如计算机与CPU、公司与员工的关系等；表现在代码层面，和关联关系是一致的，只能从语义级别来区分；组合组合也是关联关系的一种特例，他体现的是一种contains-a的关系，这种关系比聚合更强，也称为强聚合；他同样体现整体与部分间的关系，但此时整体与部分是不可分的，整体的生命...
