我這人感情比較豐富........,身體不舒服的~ 可以跳著看高亮字段......
要說這個uml學*計畫，無可避免還得說一下上週的安排，也難怪古人常說「
多事之秋~
」，不假。
從上週的週末開始，一共持續了三天，我和小兵都沒有來四樓學*，我們之前報名參加了 全國高教杯大學生數學建模比賽 ，說來報這個比賽的初衷也是想鍛鍊一下自己，面對問題時，抽象解決的能力。簡單說一下建模，建模就是將現實生活中的生活問題或工程問題，通過抽象問題，利用現有知識（涉及面很廣，這需要我們即時學*，並能夠拿來用之。），建立乙個或多個模型，能夠適應需求變化，並且給出乙個合理的解決方案。總的說，就和初中數學中的應用題似的，當然要困難複雜很多了。
隨後又緊接著是計算機等級考試，雖說現正是甲流高感危險時期，可是試還是要考的，自己防護好了，避免被傳染就好了。考試依舊......
如此，斷斷續續，一周過去了，在學*進度上慢了很多。其中發生了一些大事，我沒有能夠同步參與其中，有點遺憾的，不過在這一周我還是收穫了不少。
分說：建模後感，總體我參加過兩次數學建模比賽。
第一次：比賽分組，這意味著我們需要互相協助、相互配合。同樣，我們在進行軟體開發過程中也是需要開發團隊之間的默契配合，無奈，我是滿腔熱血，無奈應了那句話，「不怕虎一樣的敵人，就怕豬一樣的隊友 」，隊友的不配合，使得我很無奈，第一次真真的感受到，「志同道合」 這是很重要的乙個標準。好歹，最後通宵加時完成了一篇**，結果得了個成功獎。
比賽結束，感覺自己真是絞盡腦汁了，我們參定的問題設計物理方面，牽涉到光學知識，我們不會，怎麼辦？！
即時學*，需要我們在浩瀚的資訊庫中搜尋我們需要的資料，從中獲取我們所需要的知識，進而努力去解決問題。結果呢，那時只感覺到腦子不夠用的，一直就是暈暈的，對於其中涉及到的相關知識點，我們是一無所知，剩下的只是無望的搜尋著什麼。完全沒有目的，不知重點。
總結的說第一次建模，感觸還是很大的，從一開始的定題→獲取資訊→蒐集、吸收、整合知識，整個的乙個鏈式化處理過程，方知自己真是弱的不行，特受打擊（從而開始反思...），還有就是那些出題的人真厲害~ .....
第二次，這次報名比賽，主要是興奮，因為從第一次比賽後到這次已經在提高班學*了將*一年的時間了，對問題突然很感興趣，很是想來那麼幾個問題，沒事兒解著玩兒，很期待自己將問題解決掉的那種亢奮的感覺，同樣為了鍛鍊自己，報名了，並且把小兵也抓來了，(*^__^*) 嘻嘻…… 同時，我考慮到團隊的合作性，還是找的自己熟悉的人來組隊，但是這樣不利於多元化解決問題。但是隊員間的配合、了解加深了，戰鬥力自然也就強了。
說來這次，我們選擇了 病床安排處理 ，這相關及排隊論、運籌學等等知識，並且有張老師（排隊論專家）力挺我們，如是，我們選擇共抗難題，並且通過兩次通宵，終於「踩著點」把**交上了。
在針對不同問題相關的一些我們不懂的知識，通過網際網路的巨大知識庫都得到了補充，難得的是相比上一次，這個鏈式化處理過程我們處理資訊的能力強了很多，能夠分析出來哪些是需要的，去哪蒐集知識。這些不都是我們在提高班平常所學到的嘛 ~ ，所以說，一切盡在掌握。把問題抽象出來理解、分析，不像上次那樣一直迷糊，不會鑽進去以後就迷路，而是學會了從外邊看，從高處看，從巨集觀把控流程，這樣分析問題就很方便了。
總的說，兩次比賽比較之後，自己的確解決問題的能力強了些，很是希望出現一些問題來等我解決，這樣一次次之後，豐富了些，也更興奮了些。但是，突出的問題就是知識面太窄，像公尺老師說的「不怕不知道，就怕不知道」，後者占得比重還是很大的，當然這也牽涉到專業領域問題，可是哪個偉人不是博古通今、"上下通吃" 呢， 所以說，學*知識要博，要精，深度、廣度都要有，做到兩手都要抓，兩手都要硬。
計算機等級考試，沒什麼可說的，報了等級考試，也就是想著「以考促學」，抽出些時間學點知識，順便拿個證書啥的，其實考核的難度並不高，可是現在這種考核，不是很實用，考前背背就差不多能過，可是考後呢，不懂的真正弄懂了嗎？ 實際操練過嗎？ 學了以後，能用到嗎？ 這些都是需要考慮的，爭取走到學到了，真正的將這些知識放到自己的口袋裡，並且輔以實踐煉化它們。
基本上將一周的大事小情，又過了一遍。想過的就要總結，總結後就相當於在自己思維體系的繩索上打上了乙個結，不光是標誌一下，更重要的是這是乙個結點，它是可以發散的。
UML總結之建模與UML概述
前言 在說uml之前咱們應該來說說軟體工程，軟體工程發展到現在已經有幾十年的歷史了，這其種也出現過很多的問題，為了讓軟體更好的為人們服務，人們將軟體的開發規範化 系統化 數量化並逐漸的形成一門學科 軟體工程。在開發軟體最重要的就是如何滿足使用者和專案的需求，但是如何更好的了解使用者和專案的要求呢？這...
在實際專案中用UML建模的總結
做機房收費系統的時候，剛對uml有乙個大致的概念，就開始了對機房收費系統的建模。uml可以理解為乙個分析交流的方法。多個人建乙個系統，人多了，為了避免歧義，就得用標準化的交流方法。圖形表現力最強，所以在眾人進行交流的時候，畫圖最好。建模的過程 在建模的過程中花了大量的時間。開始其實沒有什麼建模的概念...
在實際專案中用UML建模的總結
做機房收費系統的時候，剛對uml有乙個大致的概念，就開始了對機房收費系統的建模。uml可以理解為乙個分析交流的方法。多個人建乙個系統，人多了，為了避免歧義，就得用標準化的交流方法。圖形表現力最強，所以在眾人進行交流的時候，畫圖最好。建模的過程 在建模的過程中花了大量的時間。開始其實沒有什麼建模的概念...