這兩天在家畫了兩天的uml圖，當做是對自己所掌握知識的乙個複習。
大概是這麼乙個過程，
首先是編寫用例文件，將使用者的需求描述清楚。------此步驟要盡可能的簡潔，盡量採用客戶的語言，不要採用計算機語言。
其次抽象出參與者和動作，完成初步用例圖。---------確定主要動作和行為
分層，確定大致的開發框架。確定目錄結構
然後根據用例開始畫每個動作的順序圖，同時可以建立起每個物件的類圖。建立物件之間的關聯。
最後用rational將語言描述轉換為操縱方法。此時再來細化類。
採用何種框架------運用哪些模式------採用ooa/d的方式，多角度的思考，這些都需要經驗的積累和個人不斷的總結和探索。
現在在國內缺的不是程式設計師，缺的是理解了底層設計思想，專注於某一領域，能夠靈活的進行專案的分析和設計的人員。
只有將一件東西理解透了，才能真正的做到舉一反三。專注於某一方面才能將成就最大化，就像我們設計的一套優秀的系統，每個部分都要求非常完整，這樣藕合性才低，效能才好。
某君的一點軟體測試思考
測試的過程應該嚴格遵循一定的過程與計畫，這樣的過程體現於測試案例中，測試者可以只按照測試案例便可以找出該軟體的問題所在，而不需要對軟體的需求有深入的了解，恰恰這個測試案例的編寫人卻需要很深入了解軟體需求設計架構，可是能夠編寫好的測試案例的是乙個測試員的基本素質。總結幾年風雨兼程的測試歷程,有以下的一...
中日軟體行業的一點思考
公司一專案發生質量問題，被日本客戶要求進行根本原因分析，並提出對策。我們乙方的心態是怎麼能盡快把這件事情結束，而且盡量對未來的工作不產生太大的影響。當然能讓客戶看到好像是真正的原因，是最重要的。交涉了幾次之後，終於客戶納得 接受 了。歡欣鼓舞。天空頓時晴朗的感覺。根本原因分析是質量管理方面的乙個非常...
遞迴的一點思考
廢話不說，直接上 searchtree delete int x,searchtree t else if t left null 沒有兒子的情況也包含了，因為t right 為null else else if x t element t right delete x,t right else t...