下午開會討論了關於系統架構設計問題，也引申出關於架構圖中包間關係的思考。
其實，主要分歧點是在
uml關係中的關聯關係和依賴關係，有種觀點，認為在架構圖（包圖關係）中，有一種包間關係叫做關聯。
我們大家都知道，在
uml中存在
5中關係，而從
rationalrose2007
中支援的
uml標準來看，包與包之間，只支援依賴和泛化這兩種關係，在
enterprise architect 7.5
中對包間關係支援的要豐富一些，有
package merge
和package import
兩種關係
(可能還要多，希望大家指正
)。並且，這兩種建模工具中關於包間關係符號，都是基於虛線箭頭的表示，唯一區別的就是個別的一些文字標識了。
如下圖中
4個包圖，在做架構的時候，我們應該如何對待這樣十分具有指導意義的設計呢？
包圖間關係對於指導開發人員做好時序圖、互動圖，有著一定的作用。那麼，如何分辨他們各種關係呢？
對於架構層次的東西，接觸的不多，以前一直按照自己的想法來做，並沒有太認真的對待他們，今天乍一認真看待，發現這其中關係有點認識不足。
先溫故一下概念。
依賴
可以簡單的理解，就是乙個類a使用到了另乙個類b，而這種使用關係是具有偶然性的、、臨時性的、非常弱的，但是b類的變化會影響到a；比如某人要過河，需要借用一條船，此時人與船之間的關係就是依賴；
表現在**層面，為類b作為引數被類a在某個method方法中使用；
關聯
他體現的是兩個類、或者類與介面之間語義級別的一種強依賴關係，比如我和我的朋友；這種關係比依賴更強、不存在依賴關係的偶然性、關係也不是臨時性的，一般是長期性的，而且雙方的關係一般是平等的、關聯可以是單向、雙向的；
表現在**層面，為被關聯類b以類屬性的形式出現在關聯類a中，也可能是關聯類a引用了乙個型別為被關聯類b的全域性變數；
(關聯、依賴解釋，摘自：
)為了更好的區分這兩個關係，我們一切從**實現說起，這樣更容易理解一些。
我理解，依賴和關聯最大的實現區別就是，乙個作用域的問題，也就是上面說到得，類b在類
a中的某個方法中使用；類
b以類屬性
(成員變數
)的形式關聯在類
a中。前者的作用於小於後者，於是，我便以此作為分析的基礎。
(本人拙見，希望指正。)在
rose
中，包間關係只有依賴和泛化，是正確的。ui和
bll之間存在依賴關係，從根本上可以說，
ui中每個介面類的例項物件中都會在每個事件方法中引入相應的
bll類，例項成物件進而完成相應的功能。若，考慮到系統優化、節省資源等，或許我們可以把這其中的
ui介面類和
bll中相應類的關係描述為關聯，這樣豈不是ui和
bll之間會是關聯關係？
不是這樣的，我的理解，ui和
bll的包中各類之間的關係可能有依賴、有泛化，但是基於包層關係，還是要從基本的規範、出發點開始，也就是對於
bll中相應類，都單獨引入到
ui類實體物件的方法中去，這樣就是依賴關係，而非關聯。
在ea中，包間關係，有
package import
，也就是包與包之間
(層與層之間的引用，更偏向於實現一些就是引入命名空間，進而能夠例項該層類、呼叫類方法
)的引用。
從包的層次角度來看待之間的關係，我更傾向於
ea中這種對包間關係的表述。
並且，rose
下，設計架構圖，包間關係沒有關聯這種關係，而是應該為依賴或泛化(繼承
)。如下，我比較認可ea中的這種關係表述：
思維受限，各位多多指教。
OSI協議各層之間的關係
物理層 主要定義物理裝置的標準，如網線的介面型別，傳輸速率之類的。這一層的資料稱為位元，主要作用就是傳輸位元流。資料鏈路層 對從物理層接收的資料進行mac位址的封裝和解封裝，這一層的資料稱為幀，主要裝置是交換機。正確說法是在不可靠的物理介質上提供可靠的傳輸，主要作用是 實體地址定址 資料成 幀 資料...
DDD中的分層架構
ddd中的分層架構很好的應用了關注點分離原則separation of concerns soc 每一層做好自己的事情，減少交叉 表現層提供用來完成任務的使用者介面，如webform wpf asp.net mvc 以及winform等，一般而言，我們把表現層顯示的任何資料稱為檢視模型，把任何從螢幕...
解析三層架構 如何分層？
三層結構是基於模組化程式設計的思想，為實現分解應用程式的需求，而逐漸形成的一種標準模式的模組劃分方法。三層架構的優點在於不必為了業務邏輯上的微小變化而遷至整個程式的修改，只需要修改商業邏輯層中的乙個函式或乙個過程 增強了 的可重用性 便於不同層次的開發人員之間的合作，只要遵循一定的介面標準就可以進行...