UML学习笔记

UML: Unified Modeling Language

基本的使用模型：草稿、蓝图、程序语言，草稿是为了理清思路，或便于沟通，使用最多，通常为了突出问题而比较精简，蓝图是为了以此为凭据作代码，会作得比较全面而细致，作为程序语言的典型用法是MDA（Model Driven Architecture）中，MDA有两个步骤，首先用UML建立PIM（Platform Independent Model），然后由相应的工具转化为PSM(Platfrom Specific Model），PSM可为UML或其它，再由工具将PSM转化为程序代码。MDA & UML都是由OMG（Object Managment Group）掌握的。OMG是一个由多家公司共同掌握的开放性组织，它的杰作之一就是CORBA（Common Object Request Broker Archetecture）。与MDA类似的还有Executable UML，它首先也是建立一个类似于PIM的系统，然后由相应的“模型编译器”，直接生成对应平台的代码，它没有生成PSM的过程。 至目前为止，将UML视为语言的做法并没有得到广泛的实施和推广。反向工程（code ->UML）当作为代码的动态浏览器时比较有意义，如果只是产生一堆文件则无意义。

只靠UML是不夠的
雖然UML中提供了相當多、一整組各式各樣的圖，以幫助我們定出應用程式來，不過我們還是不可能完整列出所有你可能會用到的有用圖形。在許多地方，其他不同的圖都會有幫助，而且如果沒有UML的圖適合你的用途，那麼請毫不猶豫地去用不屬於UML的圖。

顺序图和类图是最常用的图

如果有些圖看起來對你的工作沒有任何幫助的話，不要怕，請把它們丟掉。

瀑布式开发的最大问题在于发现致命问题太晚

瀑布式(waterfall)和迭代式(iterative)开发的本质区别在于迭代式一次完成一部分需求，并形成产品，然后第二次。。。大多数现在所宣称自己在进行迭代开发的实际上都是在做着瀑布式开发

多数迭代开发都使用固定时间长度(time boxing),每一次迭代在固定时间内完成，如果发现某些功能无法实现，应将此功能放在下一个迭代，而不是延长当前迭代开发的时间

迭代时三个有用的技术： 自動化的回歸測試（automated regression tests）、重构（Refactoring）、持续整合（continuous integration），持续整合是指一个自动化系统，当程序员将一个build版本放入库中时自动进行Build,并可能运行自动测试用例来检查错误。

使用可调整式计划（Adaptive planning）时，使用者须与开发团队持续配合（参予其中），这个时候所做的计划是为了用来评估变动的结果，而不是用来预测未来

宣稱遵從敏捷式軟體開發流程的有終極（程式開發）流程（Extreme Programming，XP）、Scrum、系統特性驅動開發方式（Feature Driven Development，FDD）、水晶開發流程（Crystal）、動態系統開發方法論（Dynamic Systems Development Method，DSDM）等

敏捷式開發流程也傾向於有較低的儀式性。在專案進行當中，高儀式性或重量級的開發流程會產生很多文件與控制點。敏捷式開發流程則認為儀式性讓專案變得很難變動，其工作方式也不符合有才能成員的本質。因此，敏捷式開發流程通常會展露出輕量級的特徵出來。有一點要了解的是，它不具有儀式性是因為調整性與人員導向的結果，儀式性並不是它的基本特質

RUP(Rational Unified Process)本質上都是反覆式開發流程

RUP的四个阶段：初始阶段（inception)、詳述階段（elaboration）、建構階段（construction）、轉換階段（transition）

不論任何時候，只要是有助於溝通，我們心裡面都要有打破那些UML規則的準備。在分析時用UML的最大風險就是：那些領域專家無法完全理解你所畫的圖。如果了解領域的人無法理解這張圖，那麼它所造成的後果比沒有用更糟；因為它會引起大家對開發團隊的不信任感。

迭代时我们会去修改现有模型，而不是建立一个新模型

UML的草稿雖然有用，卻不应認為它們可被視為絕對正確的東西

产生整个系统的UML图一般来说是没有必要的

Ward Cunningham："小心節選出來、寫得很好的一段說明，可取代掉傳統包羅萬象的設計文件。後者中只有幾個單獨地方會引起我們的注意。請強調出這些地方…並忘掉其他東西吧"

类图：

性质（Property）有两种表示方法，一种是表现为属性，一种是表现为关联，其差别在于关联可同时表现出两端的多重性。一般来说关联适宜在突出重点时使用

属性(Attributes):

 visibility name: type multiplicity = default {property-string}

sample:                        - name: String [1] = “Untitled” {readOnly}

如果属性是可修改的，可将readOnly改为unrestricted

多重性中常见的0...*一般简写为*

多重性为多值时,若有序，应在关联端加上{ordered}，若不具唯一性，应在关联端加上{ununique}，默认为{unordered}，{unique}

拥有多值性质的类的一般不应把多值性质直接暴露出来，而应该用一个proxy来屏蔽，或者暴露一个只读的Iterator比较好

一个类一般不应该只拥有性质和对应的存取动作，如果出现这种情况则应考虑将这些性质分散到其它类中

双向关联有两种表示法： 双箭头 & 可浏览性箭头(navigability arrow)，其中第一种比较常用 

双向关联有比较固定的实作手法，代码如下(C#)：

class Car…
 public Person Owner {
     get {return _owner;}
     set {
         if (_owner != null) _owner.friendCars().Remove(this);
         _owner = value; 
         if (_owner != null) _owner,friendCars().Add(this);
    }
 }
 private Person _owner;
…
 class Person…
  public IList Cars {
      get {return ArrayList.ReadOnly(_cars);}
  }
  public void AddCar(Car arg) {
      arg.Woner = this;
  }
  private IList _cars = new ArrayList();
  internal IList friendCars() {
       //它只會被Car.Owner用到
       return _cars;
  }
…

这段代码咋一看比较奇怪，为什么AddCar()里面不是_cars.Add(this)呢？ 因为这是双向关联...