Horn Network

循序圖用來表達資訊系統內部一群物件之間的互動行為，是UML 2十三款圖中，排名第三重要的圖。

指南140 把語句規則應用在聚合關係上（Apply the Sentence Rule for Aggregation）
指南141 對「整體」與「部分」皆感興趣 （Be Interested in Both the Whole and the Part）
指南142 把整體放置於部分的左邊（Place the Whole to the Left of the Part）
指南143 在表達實體物品的聚合現象時，可以使用組合關係（Apply Composition to Aggregates of Physical Items）
指南144 當部分跟整體共享自己永續的生命週期時，可以使用組合關係（Apply Composition When the Parts Share Their Persistence Life Cycle with the Whole）
指南 145 別擔心菱形（Don’t Worry About the Diamonds）
指南158 由左向右依序放置訊息（Strive for Left-to-Right Ordering of Messages）
指南159 依層級放置物件存活線（Layer Object Lifelines）
指南160 如果需要的話，參與者與類別可以同名（Give an Actor the Same Name as a Class, If Necessary）
指南161 包含邏輯敘述（Include a Prose Description of the Logic）
指南162 將主動性的系統參與者放置在循序圖的最左側（Place Proactive System Actors on the Leftmost Side of Your Diagram）
指南 163 將被動性的系統參與者放置在循序圖的最右側（Place Reactive System Actors on the Rightmost Side of Your Diagram）
指南164 避免繪製物件的消滅狀況（Avoid Modeling Object Destruction）
指南165 避免繪製活動期的長條框（Avoid Activation Boxes）
指南166 在訊息中有參考使用到某物件時，才為該物件命名（Name Objects Only When You Reference Them in Messages）
指南167 當存在數個相同型別的物件時，才為這些物件命名（Name Objects When Several of the Same Type Exist）
指南168 在存活線上，一致性地使用文字模版（Apply Textual Stereotypes to Lifelines Consistently）
指南169 聚焦於關鍵性的互動上（Focus on Critical Interactions）
指南170 將訊息名稱放置於訊息箭頭旁（Justify Message Names Beside the Arrowhead）
指南171 直接建立物件（Create Objects Directly）
指南 172 以操作簽名做為軟體訊息的名稱（Apply Operation Signatures for Software Messages）
指南173 涉及人類或組織參與者的訊息，以一般的散文體命名（Apply Prose to Messages Involving Human and Organization Actors）
指南174 列出參數的名稱，優於列出參數的型別（Prefer Names over Types for Parameters）
指南175 標示出型別，代替參數名稱（Indicate Types as Parameter Placeholders）
指南176 遇到呼叫使用案例時，可以使用《include》字標（Apply the 《include》 Stereotype for Use Case Invocations）
指南177 不要在圖中表達明顯的回傳值（Do Not Model Obvious Return Values）
指南178 需要參考到回傳值時，才在圖中表達回傳值（Model a Return Value Only When You Need to Refer to It Elsewhere in a Diagram）
指南179 將回傳值放置於回覆訊息箭頭旁（Justify Return Values Beside the Arrowheads）
指南180 把回傳值視為方法的一部分（Model Return Values as Part of a Method Invocation）
指南181 標示出型別，代替回傳值（Indicate Types as Return-Value Placeholders）
指南182 簡單的回傳值，可以直接標示出實際數值（Indicate the Actual Value for Simple Return Values）

在UML類別圖中，關係線畫得越多，不一定有助於溝通，而是要用的恰當。

指南112 關係線水平放置（Model Relationships Horizontally）
指南113 繪製「限定元」（qualifier）的矩形圖示時，要小於類別的矩形圖示（Draw Qualifier Rectangles Smaller than Classes）
指南114 只有當兩個元素之間有關係時，彼此才能夠合作（Model Collaboration Between Two Elements Only When They Have a Relationship）
指南115 要建立暫時性的關係的話，使用依賴關係（Model a Dependency When the Relationship Is Transitory）
指南116 連到同一個類別的關係線，可以使用樹狀結構來呈現（Tree-Route Similar Relationships to a Common Class）
指南117 永遠指出個體數目（Always Indicate the Multiplicity）
指南118 避免只使用「無限多」的個體數目（Avoid a Multiplicity of “*”）
指南119 用屬性型別來替代關係線（Replace Relationship Lines with Attribute Types）
指南120 別建立隱含關係（Do Not Model Implied Relationships）
指南121 不宜建立出所有的依賴關係（Do Not Model Every Dependency）
指南122 結合名稱置中（Center Names on Associations）
指南123 使用主動語態的動詞來為結合關係命名（Write Concise Association Names in Active Voice）
指南124 使用方向標記讓結合名稱更清楚（Indicate Directionality to Clarify an Association Name）
指南125 讓單向結合的名稱和它的方向同向（Name Unidirectional Associations in the Same Direction）
指南126 結合名稱由左唸到右（Word Association Names Left to Right）
指南127 兩個類別之間存在多個結合關係時，標示出角色名稱（Indicate Role Names When Multiple Associations Between Two Classes Exist）
指南128 在反身結合關係上，標示出角色名稱（Indicate Role Names on Recursive Associations）
指南129 當兩個方向上都會有合作發生時，才建立雙向的結合關係（Make Associations Bidirectional Only When Collaboration Occurs in Both Directions）
指南130 只有在單向結合關係上，才標示出方向性（Indicate Direction Only on Unidirectional Associations）
指南131 避免標示出不可航性（Avoid Indicating Non-Navigability）
指南132 只有在有改變時，才重新繪製繼承而來的結合關係（Redraw Inherited Associations Only When Something Changes）
指南133 詢問個體數目的上下限（Question Multiplicities Involving Minimums and Maximums）
指南134 把語句規則應用在繼承關係上（Apply the Sentence Rule for Inheritance）
指南135 把子類別放置於父類別的下方（Place Subclasses Below Superclasses）
指南136 謹防以資料為基礎的繼承關係（Beware of Data-Based Inheritance）
指南137 子類別應該繼承一切（A Subclass Should Inherit Everything）
指南138 結合之間存有一般化關係時，區別之（Differentiate Generalizations Between Associations）
指南139 在共有繼承關係中，標示出「超型別」（Indicate Power Types on Shared Generalization）

類別圖是UML中最重要的圖，也是最難設計的一款圖，59條類別圖風格指南，協助你清晰地畫出系統內部靜態結構。 分為六個小節：一般性指南、類別風格、關係、結合關係、繼承關係、聚合與組合關係。

指南87 在領域類別模式中，專注辨識出「責任」就好（Identify Responsibilities on Domain Class Models）
指南88 只有在設計模式中，才指定「能見度」（Indicate Visibility Only on Design Models）
指南89 跟程式語言有關的能見度，可以標示在「性質字串」中 （Indicate Language-Dependent Visibility with Property Strings）
指南90 只有在該型別為實際需求時，才在分析模式中指定之（Indicate Types on Analysis Models Only When the Type Is an Actual Requirement）
指南91 注意屬性名稱與型別的一致性（Be Consistent with Attribute Names and Types）
指南92 在分析圖中，建立「結合類別」（Model Association Classes on Analysis Diagrams）
指南93 如果結合關係已經表達成結合類別的話，就別再為該結合關係命名了（Do Not Name Associations That Have Association Classes）
指南94 結合類別的虛線，連接到結合關係線的中間（Center the Dashed Line of an Association Class）
指南95 使用一般性術語做為類別名稱（Use Common Terminology for Class Names）
指南96 最好使用完整的單數名詞做為類別名稱（Prefer Complete Singular Nouns for Class Names）
指南97 使用強動詞做為操作名稱（Name Operations with Strong Verbs）
指南98 使用領域相關的名詞做為屬性名稱（Name Attributes with Domain-Based Nouns）
指南99 別建立「鷹架碼」（Do Not Model Scaffolding Code）
指南100 類別名稱置中（Center Class Names）
指南101 屬性和操作名稱靠左（Left-Justify Attribute and Operation Names）
指南102 別建立「鍵值」（Do Not Model Keys）
指南103 避免只顯示兩格類別（Never Show Classes with Just Two Compartments）
指南104 標示出非一般性的類別格（Label Uncommon Class Compartments）
指南105 未完成列的最後一列可放置「省略號」（Include an Ellipsis （…） at the End of an Incomplete List）
指南106 靜態操作/屬性條列於個體操作/屬性之前（List Static Operations/Attributes Before Instance Operations/Attributes）
指南107 依照能見度遞減的順序放置操作／屬性（List Operations/Attributes in Order of Decreasing Visibility）
指南108 針對物件參數，僅條列出它們的型別（For Parameters That Are Objects, List Only Their Types）
指南109 使用一致性的操作與屬性簽名（Develop Consistent Operation and Attribute Signatures）
指南110 程式語言命名慣例可以表達的資訊，別濫用「模版」重複表達相同的資訊（Avoid Stereotypes Implied by Language Naming Conventions）
指南111 使用操作的性質字串指出例外控制（Indicate Exceptions in an Operation’s Property String）

使用案例圖中會出現的關係線的話，我會把他們改成下列五種：

1. 一個參與者與一個使用案例之間的結合關係。
2. 兩個參與者之間的一般化關係。
3. 兩個使用案例之間的一般化關係。
4. 兩個使用案例之間的包含關係。
5. 兩個使用案例之間的擴充關係。

指南69 如果參與者出現在使用案例中，則可以在參與者與使用案例之間放置結合關係（Indicate an Association Between an Actor and a Use Case if the Actor Appears Within the Use-Case Logic）
指南70 參與者與使用案例之間的結合關係線上，避免出現箭頭（Avoid Arrowheads on Actor–Use-Case Relationships）
指南71 使用案例「一定」會被啟動，適用包含關係（Apply 《include》 When You Know Exactly When to Invoke the Use Case）
指南72 使用案例「可能」會被啟動，適用擴充關係（Apply 《extend》 When a Use Case May Be Invoked Across Several Use Case Steps）
指南73 謹慎地使用擴充關係（Apply Extend Associations Sparingly）
指南74 描述相似的企業邏輯時，適用一般化關係（Generalize Use Cases When a Single Condition Results in Significantly New Business Logic）
指南75 不要使用《uses》、《includes》或《extends》（Do Not Apply 《uses》, 《includes》, or 《extends》）
指南76 使用案例之間的包含關係或擴充關係，避免達兩層以上（Avoid More Than Two Levels of Use-Case Associations）
指南77 把被包用例放置於基礎用例的右方（Place an Included Use Case to the Right of the Invoking Use Case）
指南78 把擴充用例放置於基礎用例的下方（Place an Extending Use Case Below the Parent Use Case）
指南79 應用「就像是」規則來判斷使用案例之間的一般化關係（Apply the “Is Like” Rule to Use-Case Generalization）
指南80 把子參與者放置於父參與者的下方（Place an Inheriting Actor Below the Parent Actor）
指南81 應用「就像是」規則來判斷參與者之間的一般化關係（Apply the“Is Like”Rule to Actor Inheritance)
指南82 把子參與者放置於父參與者的下方（Place an Inheriting Actor Below the Parent Actor）
指南83 避免使用擴充點（Avoid Modeling Extension Points）
指南84 只有在不夠清楚的情況下，才使用擴充條件（Model Extension Conditions Only When They Aren’t Clear）
指南85 在系統範圍方框內指出釋出範圍（Indicate Release Scope with a System Boundary Box）
指南86 避免無意義的系統範圍方框（Avoid Meaningless System Boundary Boxes）

使用案例通常用來表達系統的功能觀，它的組成元素很簡單，就是「使用案例」（use case）、參與者（actor）和兩者之間的關係線。簡單來說，使用案例代表系統對外提供的服務或功能，而參與者則是位於系統外部，會直接接觸系統並啟動使用案例的使用者，或者是支援使用案例的其他連線系統。

指南58 以「強動詞」作為使用案例名稱的起頭（Begin Use-Case Names with a Strong Verb）
指南59 使用領域術語為使用案例名稱（Name Use Cases Using Domain Terminology）
指南60 以使用案例的堆放順序「暗示」其發生時間（Imply Timing Considerations by Stacking Use Cases）
指南61 把主要參與者放置於圖面的左上角（Place Your Primary Actor（s） in the Top Left Corner of the Diagram）
指南62 參與者放置於使用案例圖的邊框外（Draw Actors on the Outside Edges of a Use-Case Diagram）
指南63 用單數的、領域相關的名稱來為參與者命名（Name Actors with Singular, Domain-Relevant Nouns）
指南64 每個參與者關聯到一個或多個使用案例（Associate Each Actor with One or More Use Cases）
指南65 以角色命名參與者，不以職務頭銜命名（Name Actors to Model Roles, Not Job Titles）
指南66 使用《system》標示系統參與者（Use 《system》 to Indicate System Actors）
指南67 不允許參與者之間有互動（Don’t Allow Actors to Interact with One Another）
指南68 用「時間」參與者標示預定事件（Introduce an Actor Called “Time” to Initiate Scheduled Events）

顧名思義，一般製圖指南就是所有圖的通則，無論是否為UML圖，洋洋灑灑一共有二十六條之多。原著作者將這二十六條指南分為四大類，包括了「易讀」、「簡明」、「命名」和「一般」指南。上一期介紹了13條「易讀」指南，接下來從第14條指南開始談起。

指南14 僅秀出你想秀出的內容（Show Only What You Have to Show）
指南15 最好採用大家熟知的表示法（Prefer Well-Known Notation over Esoteric Notation）
指南16 把大圖重新組織成數張小圖（Reorganize Large Diagrams into Several Smaller Ones）
指南17 單頁圖最好（Prefer Single-Page Diagrams）
指南18 優先關注內容，版面其次（Focus on Content First, Appearance Second）
指南19 使用一致且易讀的字型（Apply Consistent, Readable Fonts）
指南20 規定並遵守有效的命名規則（Set and Follow Effective Naming Conventions）
指南21 拿領域術語當名稱（Apply Common Domain Terminology in Names）
指南22 設計階段的圖採用程式語言命名規則（Apply Language Naming Conventions on Design Diagrams）
指南23 跨圖面的元素，其名稱要保持一致（Name Common Elements Consistently Across Diagrams）
指南24 用問號指出未知處（Indicate Unknowns with a Question Mark）
指南25 考慮在圖中使用顏色（Consider Applying Color to Your Diagrams）
指南26 謹慎地使用顏色或不同字型（Apply Color or Different Fonts Sparingly）

從原著308條指南中精選167條來剖析，可以讓開發團隊統一UML文件風格，發展自己的指南。

指南1 避免交錯線（Avoid Crossing Lines）
指南2 使用「跳躍」來描繪交錯線（Depict Crossing Lines as a Jump）
指南3 避免對角線或曲線（Avoid Diagonal or Curved Lines）
指南4 使用一致尺寸的符號（Apply Consistently Sized Symbols）
指南5 線段連到節點中央（Attach Lines to the Middle of Bubbles）
指南6 字標水平放置（Align Labels Horizontally）
指南7 符號整齊放置（Arrange Symbols Symmetrically）
指南8 別指出「激增」節點（Don’t Indicate “Exploding” Bubbles）
指南9 減少節點種類（Minimize the Number of Bubble Types）
指南10 圖面上要留白（Include White Space in Diagrams）
指南11 從左至右、由上至下組織圖示（Organize Diagrams Left to Right, Top to Bottom）
指南12 避免太多緊密的線段（Avoid Many Close Lines）
指南13 提供表示法的圖例（Provide a Notation Legend）

StarUML is an open source project to develop fast, flexible, extensible, featureful, and freely-available UML/MDA platform running on Win32 platform.

繪製UML的工具。

Cayra這套免費的心智圖軟體操作方式直覺簡單，繪製出的圖形也相當美觀，而且跟上述兩者不同的是，Cayra除了舊有的固定版面(fixed layout)模式，它還多了動態版面(dynamic layout)功能。它能夠以你目前點選的心智圖節點(node)為中心重新繪製，周圍會自動出現與該節點相關聯的節點，並隱藏其他無關的節點(節點數目會用加號跟節點的個數來顯示，如+5表示有五個子節點)，能讓你更專心於目前感興趣的項目，是個相當有趣、實用的設計。