關(guān)于OrCad原理圖設(shè)計中模塊化的調(diào)用

　　模塊化設(shè)計，可能通常我們的工程師還用的不多，但它在某些場合下還是很有用的，一個是它能減少我們重復(fù)性的工作。以下是小編整理的關(guān)于OrCad原理圖設(shè)計中模塊化的調(diào)用，希望對大家有所幫助。

　　關(guān)于OrCad原理圖設(shè)計中模塊化的調(diào)用

　　在進行原理圖設(shè)計的時候，有些功能模塊要重復(fù)調(diào)用多次，這時候可以采取模塊設(shè)計原理圖，然后在頂層多次調(diào)用此功能模塊。在實際操作過程中發(fā)現(xiàn)這個方法很好用，只是由于長期不畫原理圖的時候有些技巧性的東西會忘記，記錄在此以備查閱。

　　我所說的“技巧”性的東西，有點忽悠色彩，主要是自己記性不好，經(jīng)常忘記該如何操作，每次都需要摸索很長時間，實在是浪費時間。主要問題有下面兩個：

　　第一個：是每個模塊里的器件編號要重新編號，如果單獨修改某一個模塊，那么剩余模塊的器件編號會同時變化成同一編號;

　　第二個：是頁的編號;實際模塊原理圖只有一頁，但是通過多次調(diào)用以后工程會為每一次調(diào)用重新分配一個頁號，只是在原理圖設(shè)計過程中由于其他原因?qū)е马撎栃枰�修改的時候，會發(fā)生類似第一個問題的情緒，即修改某次調(diào)用的頁號其他調(diào)用的頁號會同時修改成一樣的頁號。

　　其實出現(xiàn)上述問題的原因，是在修改的時候只是簡單的雙擊了圖1的模塊(或者說簡單Syncronize Down)，然后就進行修改，這樣是不行的。

　　選擇“Edit Object Properties”命令。默認進入Parts頁，該頁可以修改功能模塊里的part屬性，特別是編號，所有模塊的parts編號可以同時修改，這樣就不會上述第一個問題。同理，進入“Title Blocks”頁面里，也可以同時修改所有調(diào)用頁的頁號修改，這樣也不會出現(xiàn)上述第二個問題了。

　　什么是模塊化設(shè)計？

　　這兩年來，產(chǎn)品模塊化設(shè)計逐漸受到大家的推崇，那么什么是產(chǎn)品模塊化設(shè)計呢？

　　產(chǎn)品模塊化設(shè)計就是將產(chǎn)品分成幾個部分，每一部分都具有獨立功能，具有一致的幾何連接接口和一致的輸入、輸出接口的單元，相同種類的模塊在產(chǎn)品族中可以重用和互換，相關(guān)模塊的排列組合就可以形成最終的產(chǎn)品。

　　通過模塊的組合配置，就可以創(chuàng)建不同需求的產(chǎn)品，滿足客戶的定制需求；相似性的重用，可以使整個產(chǎn)品生命周期中的采購、物流、制造和服務(wù)資源簡化。

　　模塊化或者說接口式開發(fā)，讓產(chǎn)品在功能使用過程中，靈活性更高，下面是我在今年平臺成長體系搭建過程中，進行了任務(wù)體系產(chǎn)品設(shè)計時，運用模塊化設(shè)計思路，將功設(shè)計成模塊接口形式，提高運用效率的過程。

　　模塊化設(shè)計思維的轉(zhuǎn)變

　　在了解到模塊化設(shè)計方法后，我對任務(wù)體系的設(shè)計有了一個新的想法：將任務(wù)和獎勵進行分離。

　　任務(wù)模塊進行功能拆解，將用戶屬性，時間維度，行為等變成可編輯式， 生成后隨時調(diào)控，靈活運營。

　　獎勵模塊作為工具化產(chǎn)品開發(fā)，以接口形式對外進行組合搭配，不僅僅適用于任務(wù)，還可以對接至活動，從而實現(xiàn)一個模塊多處使用，真正實現(xiàn)隨時調(diào)用，隨時上線。

　　此時，產(chǎn)品開發(fā)前期需要梳理的內(nèi)容就只剩下平臺行為，其他的工作，例如運營方案、運營效果的預(yù)估均可以在開發(fā)過程中同步完成，而不必占用項目的開發(fā)時間。

　　數(shù)據(jù)效果

　　在這樣的設(shè)計思路下，每一次的運營活動只需要進行活動邏輯設(shè)計，不再需要重復(fù)進行獎品模塊和任務(wù)模塊的開發(fā)。

　　同時運用模塊化的思路，每一次的活動都做成模版工具，和任務(wù)模塊，獎勵模塊做好功能接口對接，直接調(diào)用，在后續(xù)的運營過程中，活動的復(fù)用性也得到了保證。

　　經(jīng)過這套模塊化工具設(shè)計方法，活動運營的前置開發(fā)時長減少了85%，運營人員只需要準備好活動方案，就可以在后臺進行活動的設(shè)置，獎品的設(shè)置以及任務(wù)關(guān)聯(lián)。

　　模塊化設(shè)計思維的好處

　　也許你會說上面的經(jīng)歷僅僅是某次需求設(shè)計時的思路變化，但當真正掌握模塊化設(shè)計思維方式，并應(yīng)用在其他方面時，你就會發(fā)現(xiàn)模塊化設(shè)計思維的強大。

　　1. 輸出的統(tǒng)一性

　　舉個例子，當有兩個設(shè)計師負責同個項目，列表模塊在多個頁面都會出現(xiàn)，這時兩個設(shè)計師就會設(shè)計出兩個不同樣式的列表在APP中出現(xiàn)，這樣子是極其不合理的。

　　這個時候，采用模塊化設(shè)計思維，針對復(fù)用性高的模塊形成設(shè)計規(guī)范，保證最終成品輸出的統(tǒng)一性，就像微信小程序的設(shè)計規(guī)范一般：

　　統(tǒng)一的頁面體驗和有延續(xù)性的界面元素都將幫助用最少的學習成本達成使用目標，減輕頁面跳動所造成的不適感。

　　2. 便于維護

　　每當系統(tǒng)出現(xiàn)bug的時候，查找問題總會是一個大難題，錯綜復(fù)雜的接口代碼關(guān)系總會讓錯誤查找也變成一個難題，如上文的例子如采用第一種設(shè)計思路，功能設(shè)計的高耦合度會讓任務(wù)體系出現(xiàn)問題時，問題查找極其麻煩，無法定位問題究竟是在任務(wù)模塊出現(xiàn)的還是在獎勵模塊出現(xiàn)的，只能全部代碼所有流程跑一次。

　　而當你采用模塊化設(shè)計時，bug的初始就能很快定位是哪個模塊出現(xiàn)了問題，你只需要在對應(yīng)模塊查找問題，將模塊內(nèi)的問題解決就可以了；

　　3. 提高效率

　　以最近遇到的web端頭部UI修改舉例，前端人員根據(jù)設(shè)計師重新設(shè)計好的頁面頭部進行修改時發(fā)現(xiàn)，web端的部分頁面采用的是同一套js代碼，修改后即可直接替換，而部分頁面卻是獨立設(shè)計，無法進行復(fù)用，如果要進行頭部修改，只能一個頁面一個頁面的修改，修改工作繁重。

　　如果在網(wǎng)站建立的初期，我們就采用模塊化設(shè)計思路，復(fù)用性高的模塊抽取出來共用，將來需要修改時，也只需要修改對應(yīng)模塊，而不需要每個使用到的頁面都進行修改。

　　4. 低耦合高內(nèi)聚的程序思維

　　在產(chǎn)品功能設(shè)計的過程中，我們現(xiàn)在經(jīng)常采用的是敏捷開發(fā)，快速迭代的方式。

　　在這個過程中，若設(shè)計思路不明確，就會在功能設(shè)計中出現(xiàn)功能之間交互復(fù)雜，聯(lián)系過于緊密，開發(fā)的時候也會因為功能設(shè)計的缺陷，而造成功能模塊之間耦合性加強，即使是敏捷開發(fā)，在迭代過程中也要不斷地為前面的功能進行修補，對后續(xù)的功能迭代和拓展造成影響。

　　當采用模塊化設(shè)計思維時，我們其實就進入了程序開發(fā)中經(jīng)常講到的低耦合高內(nèi)聚設(shè)計思維降低模塊間的耦合度能減少模塊間的影響，防止對某一模塊修改所引起的“牽一發(fā)動全身”的水波效應(yīng)，保證系統(tǒng)設(shè)計順利進行，使得模塊的可重用性、移植性大大增強。