实战UML(）

（1）.UML类图：允许标记静态内容与类之间的关系----系统的静态结构建模
    a.类的基本表示法：名称；属性（类型，可见型）；方法（参数，返回值）
    b.接口的基本表示法：圆型表示法，构造型表示法
    c.包：表示层级结构
    d.关系：依赖（一个事物的变化影响到另外一个事物）；关联（关联名、导航、角色、多重性、聚合、组合）；泛化（extends）；实现（implements）
      <1>.依赖
      <2>.关联
      <3>泛化
      <4>实现
（2）UML顺序图：--系统的动态建模,强调时间顺序图的交互图，重视对象的生命周期
     1--动态建模：随着时间的推移，一些对象被创建，属性值的改变，以及其中一些对象的销毁，对象之间的调用，内容：对象，对象生命线，消息(方法调用)，对象的创建与销毁
     用例：文本形式的情节描述，用于需求的发现和记录，会影响后续的OOA/OOD工作，主要包括参与者，场景，用例，系统边界
          参与者：某些具有行为的事物，可以是人(由角色标识)，计算机系统或组织
          场景：是参与者和系统之间的一系列特定的活动和交互
       用例强调用户的目标和观点，谁使用系统？它们使用的典型场景是什么？它们的目的是什么
       用例的编写形式：
              a.摘要---需求分析早期使用，通常用于主动场景
              b.非正式--需求分析早期使用，可覆盖不同的场景
              c.详述--详细编写所有的步骤及各种变化
      用例的名称应使用动词开头
      编写用例的时候应尽量使用行业的专业名称，而不是计算机专业术语
      用例编写的基本格式：
            a.用例编号
            b.用例名称
            c.用例描述
            d.参与者：系统外部与系统进行交互所有人或其他事物
            e.前置条件---用例是如何触发的
             f.后置条件---用例发生以后系统的状态会有怎样的改变
            g.基本路径---描述主成功场景，
            h.扩展点----描述其他场景
            i.补充说明 ---对于基本路径和扩展点描述不太清楚的信息进行补充
     如何发现用例？
      <1>选择系统边界
      <2>确定参与者
      <3>确定参与者的目标
      <4>定义满足用户目标的用例，根据目标对用例命名
     真实项目中如何发现用例
       <1>最先弄清楚有多少部门，多少岗位(参与者)----了解用户的组织架构图
       <2>找到每一个岗位的代表，问他们类似的问题：你平时做什么？(参与者目标)这件事是谁交办的？做完你需要通知或传达给谁吗？(业务流程的步骤)做这件事情你需要填写
              些什么表格(用例)
      用例关联：用例彼此之间可能具有联系
        <1>包含关系：避免用例文本的重复编写
        <2>扩展关系：可以将可选路径中的场景抽象为扩展关系(通常是不必要的)
<3>泛化关系：两个或更多用例在行为，结构，目的等方面存在共性时，可使用泛化关系。
（3）状态图：系统对象状态变化
        1----定义：用来描述一个特定对象的所有可能状态，以及由于各种事件的发生而引起的状态之间的转移和变化
        2----要素：如下图所示
            
（4）活动图：---------流程图
      1----定义：描述事物或对象的活动变化流程
      2----要素：如下图所示
          
（5）构件图：
      1----构件：一个相对独立的可装配物理模块，一般作为一个独立文件存在，构件具有确定的接口，相互之间可以调用，构件之间存在依赖关系。
 （6）部署图：
      1----定义：用来描述系统中计算结点的拓扑结构和通信路径与结点上运行的软件构件
      2----如图所示：
     
（7）基于职责设计对象：GRASP
    1---创建者：谁应该负责创建某类的新实例
          如果以下条件之一为真时，将创建A实例的职责分配给B
             a.B包含或组成聚合了A
             b.B记录A
             c.B紧密地使用A
             d.B具有A的初始化数据
    2---信息专家：给对象分配职责的基本原则是什么---把职责分配给具有完成该职责所需信息的类
    3---低耦合：