【正文】 牙科診所管理系統(tǒng)的主要功能是實現(xiàn)病人預約，狀態(tài)圖如下，圖中把除了完成病人預約之外的事務籠統(tǒng)地稱為日常事務。牙科診所管理系統(tǒng)完成預約*1111*查詢預約*職員*更新預約取消預約1*牙醫(yī)1打印工作安排訪問預約登記表訪問病人記錄*用數(shù)據(jù)流圖建立所述牙科診所管理系統(tǒng)的功能模型。王大夫（牙醫(yī)的實例）小鎮(zhèn)（牙科診所的地址屬性）牙科診所牙科助手 牙科保健員 接待員（外部角色，不是問題域內(nèi)的對象）軟件系統(tǒng)（與“系統(tǒng)”同義，指將來開發(fā)的軟件產(chǎn)品）預約病人預約登記表 就診時間（與“預約時間”，“約定時間”同義，都是“預約登記表”的屬性）預約時間 約定時間 系統(tǒng)名字（與“姓名”同義，是病人記錄的屬性）記錄的病人數(shù)據(jù)（即“病人記錄”）病歷號（病人記錄的屬性）姓名日期（“預約登記表”的屬性）預約信息（與“病人清單”包含的信息基本相同）病人清單病人記錄電話號碼（病人記錄的屬性）每天工作安排 每周工作安排（3）確定問題域中對象彼此之間的關系。接待員還可以打印出關系所有病人的每天和每周工作安排。接待員可以取消預約，可以打印出前兩天預約尚未接診的病人清單。在每次治療或清洗后，助手或保健員將標記相應的預約診治已經(jīng)完成，如果必要的話會安排病人下一次再來。如果病人同意建議的就診時間，接待員將輸入約定時間和病人的名字。王大夫需要一個軟件系統(tǒng)來管理預約。建立牙科診所管理系統(tǒng)的對象模型（1）詞法分析，找出（名詞）作為對象的候選者；王大夫在小鎮(zhèn)上開了一家牙科診所。用數(shù)據(jù)流圖建立所述牙科診所管理系統(tǒng)的功能模型。建立牙科診所管理系統(tǒng)的對象模型。系統(tǒng)可以從病人記錄中獲知病人的電話號碼。系統(tǒng)能夠按病人姓名和按日期進行查詢，能夠顯示記錄的病人數(shù)據(jù)和預約信息。系統(tǒng)將核實病人的名字并提供記錄的病人數(shù)據(jù)，數(shù)據(jù)包括病人的病歷號等。當病人打電話預約時，接待員將查閱預約登記表，如果病人申請的就診時間與已定下的預約時間沖突，則接待員建議一個就診時間以安排病人盡早得到診治。他有一個牙科助手、一個牙科保健員和一個接待員。表 表類“人為”所對應的數(shù)據(jù)庫表的結(jié)構(gòu)本表的主要害字為事情證號表 表類“人為表”所對應的數(shù)據(jù)庫 表的結(jié)構(gòu)本表的主要害字為事情證號+時間，外鍵為事情證號。對付類“員工”和類“人為治理員”也分別設立一張表，用于存儲相應的東西。圖 登入界面圖 選擇時間界面在選擇時間并確定后，出現(xiàn)下圖所示的界面。下圖 所示的是用戶登入界面，該界面也適用于員工。故需要憑據(jù)供需雙方配合約定的借口規(guī)約設計相應的數(shù)據(jù)庫表的結(jié)構(gòu)，并在接口相關的類操縱中結(jié)構(gòu) SQL 語句即可。這種說明往往不能清楚的描述事物間的交互情況，這就需要使用交互圖來予以準確的表達。類“銷售獎金表”及類“保險用度表”和類“人為治理員”、類“員工”之間的關聯(lián)創(chuàng)建與上述類似。人為治理員還要生成人為報表，因此在類”人為治理員與類“人為表”間設立一個關聯(lián)“盤算”。上述的六個類及其間的干系如下圖所示。它另有一個操縱“查詢保險用度”，供員工查詢保險用度。（5）類“保險用度表” 該類中有屬性“姓名”、“事情證號”、“時間”和“保險用度”。它與類“人為”組成組合干系，在其中要設立操縱“生成銷售獎金組成”、“查詢銷售獎金組成”。它另有一個操縱“查詢?nèi)藶椤?，供員工查詢?nèi)藶橹?。?）類“人為表”該類中有屬性“姓名”、“事情證號”、“時間”和“人為額”。（1）類“員工”該類中屬性有“姓名”、“事情證號”、“密碼”和“職務”，操縱有“登入”、“查詢”、“修改密碼”、“查詢?nèi)藶椤焙汀安樵兡杲K獎金”。下圖展示的是針對人為表的狀態(tài)機圖。施加在人為表上的時間有：宣布、查詢和封閉?，F(xiàn)針對子系統(tǒng)“人為治理”中的類“人為表”繪制一個狀態(tài)機圖。子系統(tǒng)“人為治理”要向財務系統(tǒng)提供數(shù)據(jù)，需要設立供接口“財務系統(tǒng)”。種種人為組成許多，需要設立類“人為表”，它與類“人為組成”形成組合干系。 尋找類人為治理 在子系統(tǒng)“人為治理”中，也要設立兩個類“員工”和“人為治理員”，用它們分別模擬相應的參加者。系統(tǒng)出現(xiàn)出供錄入和修改人為、銷售獎金及保險用度的界面 人為治理員處理懲罰完數(shù)據(jù)（錄入、修改）后，發(fā)控制命令若為生存，系統(tǒng)進行存儲，并通知結(jié)果治理員是否樂成 若為取消，退出本成果用況：盤算人為、銷售獎金及保險用度 【前置條件：人為治理員已經(jīng)登錄樂成】人為治理員發(fā)出進行人為、銷售獎金及保險用度盤算的請求按事情證號生成人為、銷售獎金及保險用度報表，并發(fā)送到子系統(tǒng)“財務系統(tǒng)”中 用況：查詢?nèi)藶椤N售獎金及保險用度 【前置條件：員工已經(jīng)登錄樂成】交互內(nèi)容見表 中編號為 1 的那欄的輸入/輸出部分。此處要求給出各個用況的相關運動圖 如下是對上述各用況的描述。所宣布的人為報表、銷售獎金報表及保險用度表供參加者“員工”、“財務系統(tǒng)”和“人為治理員”使用。首先，使用系統(tǒng)的員工和人為治理員都先要進行登錄。下面進一步創(chuàng)建參加者與用況之間的干系，并對用況進行詳細的描述。（4）登錄 人為治理員和員工進入該子系統(tǒng)都需要登錄。（2）盤算人為或銷售獎金及保險用度 人為治理員按事情證號碼進行盤算做出人為報表、銷售獎金報表及保險用度表。 識別用況對 節(jié)的中的用況需求，現(xiàn)歸納整理如下。 識別 參加者子系統(tǒng)“人為治理”的人員用戶有人為治理員和員工。子系統(tǒng)“人為治理”要分別使用子系統(tǒng)“統(tǒng)計部分”和“員工治理”中的員工信息和統(tǒng)計的人為信息。下圖給出了這些子系統(tǒng)以及它們之間的依賴。分別子系統(tǒng)限定人為治理系統(tǒng)的成果為：人為治理、統(tǒng)計部分、財務系統(tǒng)、員工治理。(6)盤算若干保險的扣除用度 人為治理員憑據(jù)事情證號碼進行若干保險的盤算統(tǒng)計，然后生成報表上報給財務部、(7)人為或銷售獎金、保險用度查詢 公司員工可以憑據(jù)自己的事情證號碼查詢自己的人為或銷售獎金及保險用度。（4）盤算人為 人為治理員按事情證號碼來進行人為的盤算統(tǒng)計，然后生成報表再上報給財務部。（2）銷售獎金錄入 人為治理員錄入員工的銷售獎金，修改錄入的墮落（維護），形成銷售獎金表。 在取得授權(quán)的情況下，有關人員要進行如下事情。這篇學習總結(jié)寫得比較亂，但我都有用心，在以后的學習過程中我會繼續(xù)努力，再次多謝莊老師的教誨。通過對學籍管理系統(tǒng)的開發(fā)可以看到，uml作為軟件工程中的建模語言，代表了面向?qū)ο蠓椒ǖ能浖_發(fā)技術的發(fā)展方向，具有重大的經(jīng)濟價值和國防價值，并獲得了國際上的廣泛支持，具有非常好的應用前景。它的各個模型可以幫助開發(fā)人員更好地理解業(yè)務流程，建立更可靠、更完善的系統(tǒng)模型。能促進軟件復用，方便地集成已有的系統(tǒng)，并能有效處理開發(fā)中的各種風險。使用uml進行系統(tǒng)分析和設計，可以加速開發(fā)進程，提高代碼質(zhì)量，支持動態(tài) 的業(yè)務需求。(5)易于掌握使用。(4)獨立于程序設計語言。(3)獨立于過程。通過uml的模型圖能清晰地表示系統(tǒng)的邏輯模型和實現(xiàn)模型。uml支持面向?qū)ο蠹夹g的主要概念，提供了一批基本的模型元素的表示圖形和方法，能簡潔明了地表達面向?qū)ο蟮母鞣N概念。但是，目前的面向?qū)ο髷?shù)據(jù)庫在實現(xiàn)技術上還不十分成熟，即使應用面向?qū)ο蠹夹g和環(huán)境開發(fā)應用系統(tǒng)，通常的做法是使用UML進行建模，用關系型數(shù)據(jù)庫儲存和管理數(shù)據(jù)。而UML是用于面向?qū)ο笙到y(tǒng)開發(fā)的全程建模語言，可用于需求分析、系統(tǒng)分析與設計、系統(tǒng)實現(xiàn)、系統(tǒng)測試等系統(tǒng)開發(fā)的所有環(huán)節(jié)。在E—R圖中，應用型數(shù)據(jù)庫系統(tǒng)的重點是數(shù)據(jù)庫結(jié)構(gòu)。因此，需要對抽取的持久型類進行分析，以確定它們之間的相互關系，建立起反映這些類關系的類圖。2．確定類關系在比較復雜的系統(tǒng)分析和設計中，并沒有建立立足于整個系統(tǒng)的整體類圖，而只是建立了一個個針對具體用例的類圖。1．抽取持久型類持久型類是指類的完整信息需要在數(shù)據(jù)庫中存儲的類。UML概念設計的基本工作分為兩個方面：對于關系模型來說，可以用類圖描述數(shù)據(jù)庫模式，用類描述數(shù)據(jù)庫表。但E—R圖設計數(shù)據(jù)庫存在的主要問題是只能對資料建模，而不能對行為建模。數(shù)據(jù)庫設計的方法與系統(tǒng)使用的開發(fā)方法有著密切的關系，同時還與所應用的數(shù)據(jù)庫模型(層次模型、網(wǎng)狀模型、關系模型、對象模型)有關。在《面向?qū)ο笙到y(tǒng)分析與設計》 的上級課程上，我們的實踐能力方面著重設計構(gòu)思和設計技能的得到基本訓練，熟練的上機操作能力和分析能力，加深理解、驗證、鞏固課堂教學內(nèi)容。下面是一些我掌握的基礎知識9種UML圖：類 圖：描述類的結(jié)構(gòu)（包括屬性以及類之間的相互關系）對象圖：對象以及對象之間的相互關系構(gòu)件圖：構(gòu)件及其相互依賴關系部署圖：構(gòu)件在各節(jié)點上的部署順（時）序圖：強調(diào)時間順序的交互圖，用于將系統(tǒng)行為分配給類。莊老師上課經(jīng)常說一些與課程無關的內(nèi)容，我已開始并不理解他的作法，后來我慢慢認識到面向?qū)ο蠓治鲈O計的學習就是培養(yǎng)思想的一種過程，這種思維方式還是需要大量的實踐才能靈活的運用。針對面向?qū)ο蟮姆治雠c設計課程的授課內(nèi)容及方法，我個人覺得對我還是有不少的幫助和 提高。OOA與OOD的不可分割性正好說明了OO思想的強大，即軟件過程階段的無縫連接，在交流與溝通中不會產(chǎn)生鴻溝，這是相對結(jié)構(gòu)化思想的好處，因為從功能模塊到某塊詳細控制邏輯設計兩者之間的聯(lián)系不是十分緊密，需要分析人員與設計人員的再溝通。這樣便可以使用具體迭代器角色來遍歷容器了。至于迭代器模式的使用。這樣便保護了容器的封裝。Iterator模式就是分離了集合對象的遍歷行為，抽象出一個迭代器類來負責，這樣既可以做到不暴露集合的內(nèi)部結(jié)構(gòu)，又可讓外部代碼透明的訪問集合內(nèi)部的數(shù)據(jù)。在面向?qū)ο蟮能浖O計中，我們經(jīng)常會遇到一類集合對象，這類集合對象的內(nèi)部結(jié)構(gòu)可能有著各種各樣的實現(xiàn)，但是歸結(jié)起來，無非有兩點是需要我們?nèi)リP心的：一是集合內(nèi)部的數(shù)據(jù)存儲結(jié)構(gòu)，二是遍歷集合內(nèi)部的數(shù)據(jù)。同時還簡化了容器的接口。l 為遍歷不同的聚合結(jié)構(gòu)提供一個統(tǒng)一的接口。l 支持對聚合對象的多種遍歷。并了解到迭代器設計模式一般在以下三類場合使用較多。完成設計研究后，我對迭代器的設計模式有了更為深刻的理解。面向?qū)ο蟮囊匕撼橄蟆⒎庋b性、共享性三方面。面向?qū)ο蟮母拍畎ǎ簩ο?、對象的狀態(tài)和行為、類、類的結(jié)構(gòu)、消息和方法。OOD的步驟：細化重組類→細化和實現(xiàn)類之間的關系，明確其可見性→增加屬性,指定屬性的類型和可見性→分配職責,定義執(zhí)行每個職責的方法→對消息驅(qū)動的系統(tǒng),明確消息傳遞的方式→利用設計模式進行局部設計→畫出詳細的類圖和時序圖。OOA的優(yōu)勢：復用、可擴展、可維護性、彈性。OOA（面向?qū)ο笙到y(tǒng)分析)主要內(nèi)容: 研究問題域和用戶需求,運用面向?qū)ο蟮挠^點和原則發(fā)現(xiàn)問題域中與系統(tǒng)責任有關的對象,獨立于具體實現(xiàn)的系統(tǒng)模型。我覺得學習這門課還是受益匪淺的。至于實際的分析設計，還需要深入的學習和實踐的積累。而且軟件分析設計本來就不是一個固定模式的過程，隨著系統(tǒng)的不同整個過程會有變化。D的過程。但這些已經(jīng)超出了本文討論的范圍。要注意，序列圖在實際中是很多的，幾乎每個類方法都配有相應的序列圖。其中UserServices作為業(yè)務組件，首先調(diào)用數(shù)據(jù)訪問組件的GetByName確定用戶是否存在，如果存在，再調(diào)用GetByNameAndPassword確定輸入密碼是否是此用戶的密碼。上圖給出的是用戶登錄的序列圖。 ， MVC作為表示層，整體使用三層架構(gòu)。因此，實現(xiàn)類圖是很復雜的，而且是平臺技術有關的。實現(xiàn)類圖和領域類圖不一樣，它描述的是真正系統(tǒng)的靜態(tài)結(jié)構(gòu)，是和最后的代碼完全一致的。但是，設計和平臺、語言、開發(fā)模型等內(nèi)容關系緊密，因而很難找出一個一致的過程。而下面的步驟就是設計了。其實，在領域分析階段，實體的屬性并不重要，重要的是找出實體的操作。理解以上這段話非常重要，我經(jīng)?？吹接捎诨煜藢嶓w和Actor的關系而導致畫出的領域類圖不準確或職責分配不準確。并且，這里的“注冊會員”實體也不是剛才用例圖中注冊會員這個Actor，而是作為一個系統(tǒng)內(nèi)的業(yè)務實體，供Actor們使用的。這里要特別強調(diào)：這里的實體不是Actor，而是Actor使用系統(tǒng)時使用的所調(diào)用的實體，是處在系統(tǒng)邊界之