系統設計
講述系統設計的感想、思想、工具、步驟和方法等。
摘要: 個人覺得設計人員可以分為四種類型：模塊設計人員、框架設計人員、專業領域設計人員、系統設計人員，這四種類型的設計人員并沒有什么絕對的誰強誰弱，只能說各有千秋吧，但一定程度上來講，四種類型之間還是存在著一些關聯，來看看這四類設計人員的專注點和關聯吧：
閱讀全文
摘要: 每個系統中都會有需要配置的屬性，而通常這些屬性的配置都會是分散式的管理，而且很多時候都是不支持動態，在實現這些屬性的管理(新增、編輯、刪除、保存等)時總是要不斷的做重復的工作，如果框架中能提供一個這樣的基礎設施那么對于系統的配置屬性管理來說就會比較好了，這樣的話系統中所有的屬性配置就可以采用統一的方式進行配置、獲取、管理和動態的更新了，如果能動態的管理系統配置屬性的話，簡單的動態改變系統行為也就自然的可以實現了。
閱讀全文
摘要: C/S結構的軟件的可維護性一直就認為是較大的問題，當然，在引入了自動升級這樣的小功能就好很多了，這里談談C/S結構軟件的可管理性，意思就是指Server對Client端的管理，在大多數C/S結構的軟件中，并沒有很強的管理性的概念，更多的面都是關注Server的業務處理、數據存儲這些功能，當然，不一定所有的C/S結構軟件都強調Server對Client的管理功能，來說說自己看法中的Server對Client的管理功能吧。
閱讀全文
摘要: 在進行系統設計時，采取的通常都是逐級分解的策略，無論是分層、分模塊都是典型的分而治之的策略，而系統在通過逐步分解形成架構、詳細設計時，輸入、輸出以及擴展都是考慮的重點。
閱讀全文
摘要: 早上上班，就聽聞用戶評價系統代碼寫的很爛，作為programmer，聽到這句話估計都有很不服的心理，但從用戶評價系統的觀點去看，就可以表示理解，在這個項目中尤其突出，用戶最為看重的是系統漂不漂亮，操作起來是否方便，最后才是系統功能實現是否和需求一樣，而事實證明，很多時候其實系統功能是已經實現了的，為什么他們還覺得和他們的需求不一樣呢，問題出現在交互上，操作上他們按照他們的想法去進行，發現沒法用，在這種情況下，他們就認為系統是不可用的，在系統設計的可用性上要引起足夠的重視，這種看起來的小事往往容易造成客戶對于系統的不信任和抵觸。
閱讀全文
摘要: 動態產生的持久模型和數據存儲，這個詞語感覺挺晦澀的，不過估計在實際的項目中或者研發的產品中大家都碰到過這樣的場景：
例如在一個簡單的考試系統中，出題人在系統中出題，答題人進行相應的答題。
希望能發起討論，總結出一個這樣的設計模式，^_^，順便還發起對于另外一個場景的設計模式的討論，需要動態的擴展目前已有的PO或表，不知道在這個場景中大家會采用什么樣的解決方案，預留字段？動態修改表？關聯屬性擴展表？抑或別的..........
閱讀全文
摘要: 系統的不斷抽象形成的接口實現與配置實現，系統的簡易性、復雜性、可維護性到底是增強了還是降低了呢？...
閱讀全文
摘要: 在設計時會碰到兩種類型的設計，一種是框架級產品的設計，一種是項目產品的設計，在面向這兩種進行設計時覺得還是非常不同的，框架級產品的設計強調一種通用性的抽象上，在這點上通常依賴開發或設計經驗來進行抽象，難度不僅在此，通常框架級產品的設計都會面對技術性的問題，也就是說在設計階段根本就是無法進行細化的一些部分，這種現象在框架級產品中通常出現，這時在進行設計時就要慎重考慮，通常按照敏捷工程的方法的話是先進行spike，spike后再進行相應的設計；對于項目產品的設計強調的是對項目需求的實現，這個時候通常需要的是業務角度的抽象，當然，這點也是具有難度的，通常來說項目產品上不會出現太多的技術難度，也不希望出現。
閱讀全文
摘要: 一直以來對于Acegi實現Domain Object Instance的權限控制就比較感興趣，今天抽空大致的看了一下，感覺和我以前提出的數據權限那部分的實現是大致相同的。
閱讀全文
摘要: 一直以來，各種行業都宣傳要本著用戶是上帝來服務，確實，真正做的成功的企業其實都取勝于這個原則上，軟件行業其實同樣如此，要把用戶真正的當成上帝才行，就像MS，MS從很多方面都是在為用戶考慮，不論是面向最終用戶還是面向開發人員的產品。
閱讀全文
摘要: 女媧造人，耳熟能詳的神話，作為一個技術人員，不得不佩服女媧的系統設計和實現能力，^_^，人是一個極度復雜的系統，需要實現N多的功能，其系統的分解和設計需要有極強的抽象能力，女媧就像是一個偉大的架構師，同時又不僅僅如此，還是一個偉大的程序員，將系統實現的如此完美。
閱讀全文
摘要: 界面對象化是指以對象的思想去描述頁面元素以完成UI的集成和開發，以使UI原型能夠映射或轉化為可運行的系統原型，提升系統開發的效率，避免大量的花費時間在UI的集成、維護上。
閱讀全文
摘要: 回顧自己所經歷的兩個項目，來對設計階段進行了總結，自己也算是個XPer，經歷過的這兩個項目也基本都是采用XP的方式進展，大家都知道，XP在設計階段推崇的是群體設計，通過CRC來完成，在這里就對兩個項目執行的情況做做總結。
閱讀全文
摘要: 就設計文檔的編寫、意義來探討設計文檔。
閱讀全文
摘要: 數據集表現層組件暴露對外的接口，組件可通過參數設置等方式來達到對組件的如下控制：
閱讀全文
摘要: 擔任系統設計師的職位一年了，盡管自己到現在為止仍然是個不合格的設計師，雖然這一年以來也不是完全從事設計的工作，但畢竟站在這個崗位上，主要從事的還是系統設計方面的工作，加上自己也有志于在這個方向發展，所以做一個年度總結是有必要的，也希望能對希望進入設計崗位的朋友們有些幫助，同時也希望得到在設計崗位上有經驗的同行們的指點。
這也是自己真正擔任系統設計師這個崗位的第一年，盡管在以前的工作中也曾經負責過設計部分，但現在回顧起來，覺得如果不在這個職位上，很多時候是無法了解到這個職位應該做的事的，自然也就無法去做了，在整個一年的工作中學到了很多的東西，同時也暴露了自己很多的不足，但總體而言自己是覺得已經踏入了系統設計的大門，但還需要不斷的提高。
閱讀全文
摘要: 前天那篇blog更多的是講了下數據驅動、模型驅動的大致概念，今天更多的是講數據驅動以及模型驅動在進行系統實現時的方法、過程以及自己的一些思考。
閱讀全文
摘要: 數據驅動、模型驅動作為如今軟件設計中兩種不同的模型驅動方法，應該說各有各的優缺點以及適用的場合，不能就一概的去認為哪種必然就是更好的。
閱讀全文
摘要: 軟件建設需要考慮的重要的兩點我覺得是：
1、客戶的功能需求以及非功能需求。
2、軟件的維護性。
軟件的技術架構就是為了滿足以上重要的兩點而誕生的，同時由于軟件的技術架構決定了使用它的開發人員所需的水平以及開發的難易，此時又要盡量做到降低對使用者素質的要求以及開發的門檻，以保證開發的高效性，但這個相對上兩點來說更沒那么重要。
閱讀全文
摘要: 插件架構體系是我一直就非常關注的內容，其實插件架構體系的發展已經有很久的背景了，插件架構體系的優點我們也是能看的非常明顯，象硬件一樣的即插即用、無論對于公司還是業界而言的良好的積累方式、為公司或業界提供統一而規范的開發方式以及穩定的內核架構等等，這些優點無論對于公司還是業界來說都是非常重要的。
插件架構體系基本的一個概念就是基于松散的模塊積累方式，通過新增插件以及擴展原有插件的方法來完成系統的實現，凡事有利必有弊，在看到插件架構體系的這些優點的同時，在實現和使用插件架構體系的時候仍然會碰到不少的問題，在本文中大概的整理了一些也相應的提出了一些自己的看法。
閱讀全文
摘要: 幾乎在所有的系統中對于權限控制都有直接的需求，而這類需求往往有其相似性，綜合常見的對于權限系統的需求構成了本文檔，文檔主要從功能復用以及模型復用的角度來對權限系統進行總結，以便在各種系統中可對照此篇文檔來進行權限系統的實現，考慮到文檔的關注點在復用度，在文檔中不會過多的去描述功能點到模型產生的過程，而是采用直接通過產生的模型來說明基于此模型如何實現功能點的需求。
閱讀全文
摘要: CMS中緩存顯的至關重要，CMS中的緩存主要有靜態緩存和動態緩存兩種技術，但看下來現在覺得這兩種也只是對于最終信息頁面的緩存，現在的需求是：
1、站點、欄目、信息列表的緩存。
2、信息頁面的緩存。
閱讀全文
摘要: Domain Model對于大多數的人來說都不怎么的陌生，Domain Model作為實現業務層的兩種重要方法之一，在PoEAA(企業應用架構模式)中得到Martin Fowler的大力推廣，但個人覺得在Domain Model上的應用并不是那么的理想，這個還得從業務層實現的兩種模式談起，分別為Domain Model和Transaction Script，Domain Model的原則為采用Domain Object的方式來實現業務邏輯，使得業務邏輯得以聚合到對象本身，從本質上提升業務對象的可復用性，其優點就在于提升了業務對象的復用性和代碼的整潔性，缺點則在于實現的難度較高，有一定的學習曲線；Transaction Script則為采用Script的方式編排業務邏輯，其優點在于實現起來簡單，缺點在于代碼中出現較多重復的業務邏輯塊，在業務邏輯一旦變動時需要修改很多地方，降低了業務邏輯的復用性。
閱讀全文
摘要: 本篇為漫談權限系列之結尾篇，涉及到權限系統的開源產品、個人觀點以及其知識體系的描述。
閱讀全文
摘要: 本文描述了基于ACL模型實現權限系統需求的方案以及優缺點！
閱讀全文
摘要: 按照目錄完成實現方案中的技術策略和基于RBAC的實現兩部分。
閱讀全文
摘要: 按目錄結構完成的漫談權限系統系列的概述、目的和需求部分。
閱讀全文
摘要: 昨天沒什么條理的寫了昨天那篇文檔后，今天想想覺得權限系統還是挺值得寫寫的，今天先大概的整理了下思路，準備按照以下的目錄結構系統的對權限系統的實現進行描述和分析。
閱讀全文
摘要: 本文作為漫談權限系統的開篇，主要描述了權限系統的一般需求、實現方法以及實現時的難點。
閱讀全文
摘要: 架構設計，一直就是軟件業界中顯得高深的名詞之一，會造成很多的人對于它都充滿了神秘感，但接觸過幾年軟件業的人很多時候又會覺得軟件架構原來不過如此，特別是看到一些架構設計文檔后更是得出如此的感想，但真的是如此嗎？也許是因為那些架構設計文檔并沒有起到它們真正的作用，只是拿來糊糊人的吧，架構設計文檔最重要的是要能對系統的軟件設計做出指導，做出規范性的約束，不談這些，重點還是談架構設計。
閱讀全文
摘要: 這是在這次寫架構設計文檔后的一些感想，總體來說我覺得最重要的仍然是需要明確的知道架構設計文檔的目的，何謂架構，架構設計的過程，架構對于需求的滿足，在這之后可進行模塊的概要設計，模塊的概要設計其實同樣是一個由繁化簡的過程，產生出關鍵類以及類的接口設計，詳細設計則是具體的對象設計以及接口實現。
閱讀全文
摘要: 在一個Web文檔管理系統中，用戶通過管理界面可增加新的目錄分類，并且目錄下既可包含子目錄又可直接包含文檔，同時用戶可對目錄以及文檔分別授予訪問、編輯、刪除的權限，并且權限均為繼承的，意思也就是比如有A目錄，A目錄下有B子目錄和C文檔，如用戶未對B子目錄進行權限設置，那么B子目錄的權限控制是和A目錄相同的，如用戶對C文檔已單獨授權，那么則取其和A目錄權限的交集；同時對于目錄以及文檔的權限都可分別授予給角色、組織機構、用戶或三者的合集。
閱讀全文
摘要: 對于B/S結構的權限控制，有N多種實現方式的權限模型，但很多都是非常的復雜，以前在做這塊時一直就做的不是很好，考慮的過于復雜，其實應該遵循Simple原則先做出自己能想到的最簡單的方案，再逐漸的重構，一種基于URL方式的權限模型就非常簡單，很容易理解，也是非常的有效。
閱讀全文
摘要: 國內的軟件公司來說仍然以行業化公司居主，而這其中大部分是做中小型的應用系統的，在這些公司中或多或少的存在著自己的一些多年項目積累形成的技術體系，但由于行業化公司來說，畢竟其優勢在于行業化軟件上，有想法的公司嘛就會自己去搞一套框架，使得自己的行業化軟件均可在此之上進行快速、有積累的搭建，盡管這樣，但畢竟其是行業化公司，在這方面自然不如專業做此類中間件的軟件廠商來得強，雖然很多行業化軟件也許根本就不需要一個強大的中間件，但畢竟專業做此類中間件的軟件廠商可以從技術上、穩定性上、延續性發展上保證中間件的有利，而行業化軟件公司應該發揮本身在行業業務的特長，基于此快速的搭建出適合行業的業務軟件，這個我覺得就是雙方互相發揮彼此的優勢，何必以己之短對他人之長呢。
閱讀全文
摘要: 系統設計師做為軟件開發過程中的一個重要的角色，承擔著系統的架構設計、概要設計的重要職責，對整個系統的技術負責，為整個系統開發過程中出現的技術問題負責。
閱讀全文
摘要: 粒度這個詞對于設計人員來說也不是什么陌生的詞，粒度上通常稱為粗粒度和細粒度，而這里講的粒度控制主要指的是在系統設計的過程中如何根據需求去控制設計的范圍。
閱讀全文
摘要: 架構設計這個詞聽的非常的多，但真正何謂架構設計呢？？可能要你真的來講還真的講不太清楚，很多人都知道架構設計是對系統進行分層、分模塊進行設計，但又有多少人知道這步應該怎么去做呢，往往很多的programmer在剛進入架構設計這個領域的時候，受到以前做模塊的那種影響，把自己的眼光限定到了具體的模塊實現上去了，并沒有站在系統的高度上來把握系統的架構，這都是些理論性的話，來講點實際的，^_^，具體架構設計指的是什么呢？目的是什么呢？如何去做呢？下面來講講我的體會。
閱讀全文
摘要: 雖然這些文檔一般來說公司都是有模板的，但我寫這些文檔以來基本上是每寫一次就把目錄結構給改一次，應該說這是因為自己對這些文檔的理解開始加深，慢慢的越來越明白這些文檔的作用和其中需要闡述的東西，覺得這三份文檔主要闡述了一個系統的設計和實現過程，從系統分解為層次、層次內的模塊以及相互的接口、模塊分解為對象以及對象的接口、實現這些對象接口的方法。這次又整了一份，^_^，歡迎大家指正。
閱讀全文