其他

大哥公司的系統是我在看軟體工程之初做的，做完了之後，軟體工程重頭戲幾乎也看完了。隨之我也越來越感到這個系統有多垃圾。原來一個真正的軟體，前期需要這麼多鋪墊和準備工作。開始的時候，大哥跟我說，編程的重頭戲交給我，調好了給他就好了。然而系統調試、軟體調試、軟體維護工作還是我一直做的。系統沒有進行可行性分析和需求分析，前期的需求也不是很明確，只有他寫給我的一個需求文檔。由於在他的需求文檔中的闡述也不是很清晰，對很多地方的要求不是很明確，我只是參照這需求文檔，按著我自己的想法給他補充空缺的地方。系統雖然

學習UML有一段時間了，下面就結合機房收費系統說一下UML中的使用案例圖。使用案例圖用來描述使用者的需求，從使用者的角度描述系統的功能，並指出各功能的執行者，強調誰在使用系統，系統為執行者完成哪些功能。它建模的最主要功能就是用來表達系統的功能性需求或行為。使用案例圖由角色（Actor）、用例（Use

UML中類圖是最常用的圖。類圖由許多靜態說明性的模型元素組成。類圖可以組織在包中，僅顯示特定包中的相關內容，它用於描述系統的結構化設計。下面先介紹類圖中的重要概念，最後給出機房收費系統的類圖用作參照。類圖中的元素有類、介面、協作、關係、注釋、約束、包。關係把類、協作、介面串連在一起構成一個圖。在學習類圖這塊兒的時候，感覺關係這塊兒最亂。這裡多說兩嘴。類圖中的關係包括四種，分別為：依賴關係——Dependency、泛化關係——Generalization、關聯關係——Association、實現關

執行個體分析1——登入模組      某基於C/S的即時聊天系統登入模組功能描述如下：      使用者通過登入介面(LoginForm)輸入帳號和密碼，系統將輸入的帳號和密碼與儲存在資料庫(User)表中的使用者資訊進行比較，驗證使用者輸入是否正確，如果輸入正確則進入主介面(MainForm)，否則提示“輸入錯誤”。      根據以上描述繪製初始類圖。     參考解決方案：      參考類圖如下：     

順序圖也叫做時序圖，它是顯示對象之間互動的圖，這些對象是按時間順序排列的。時序圖強調的是參與互動的對象及其對象之間訊息互動的順序。順序圖縱向是時間軸，角色用一條虛線表示，當對象的過程處於啟用狀態時，生命線是一個雙道線。下面是我在機房收費系統中畫的時序圖：一般使用者：操作員：儲值：管理員：

驗證控制項對我們來說，還是比較重要的。雖然它並不高深，但是它確是我們經常用到的。驗證控制項的應用涉及到的知識：1、可以被定義外觀；2、驗證程式的顯示方式，可以是靜態也可以是動態；3、分組顯示錯誤資訊；4、自訂服務端驗證；5、自訂用戶端驗證；6、Regex。 下面我們來看個註冊資訊的例子，這裡就不做過多介紹了，直接給出介面，一看便知：   RequiredFieldValidator控制項：使用者名稱、密碼、確認密碼的輸入使用的該控制項。那使用者名稱來說，最主要的是設定該驗證控制項的Control

執行個體分析3——售票機控製程序      某運輸公司決定為新的售票機開發車票銷售的控制軟體。圖I給出了售票機的面板以及相關的控制組件。圖I   售票機面板      售票機相關組件的作用如下所述：      (1) 目的地鍵盤用來輸入行程目的地的代碼（例如，200表示總站）。      (2) 乘客可以通過車票鍵盤選擇車票種類（單程票、多次往返票和座席種類）。      (3) 繼續/取消鍵盤上的取消按鈕用於取消購票過程，繼續按鈕允許乘客連續購買多張票。      (4)

UML（整合模組化語言）是當前軟體開發中使用最為廣泛的建模技術之一，通過使用UML可以構造軟體系統的需求模型（用例模型）、靜態模型、動態模型和架構模型。UML通過圖形和文字元號來描述一個系統，它是繪製軟體藍圖的標準語言。熟練掌握UML建模技術是一個優秀的軟體從業人員所必備的基本技能之一，越來越多的軟體企業在招聘中也需要應聘者具備一定的UML知識基礎和實踐經驗。作為UML的初學者，很多人也在嘗試使用UML中的圖形來描述一個軟體系統，構造一個軟體系統的藍圖。然而，在使用UML的過程中，一部分人並沒有

皮膚是應用到一個控制項上的樣式資訊，這些內容儲存在.skin檔案中。然後控制項在使用皮膚時，設定它的skinID屬性。如果不設定，它會自動化佈建為預設值。主題實際上是皮膚的集合，儲存在Thremes子目錄中。我們在default.aspx頁面上最上一行中增加Theme="blue"。也可以在設定檔中如下代碼設定預設皮膚： <system.web> <pages theme="blue" /> </system.web>

9.4 類適配器       除了對象適配器模式之外，適配器模式還有一種形式，那就是類適配器模式，類適配器模式和對象適配器模式最大的區別在於適配器和適配者之間的關係不同，對象適配器模式中適配器和適配者之間是關聯關係，而類適配器模式中適配器和適配者是繼承關係，類適配器模式結構9-5所示：圖 9-5 類適配器模式結構圖      

(1) 關聯關係關聯關係是指執行者與用例之間的關係，又稱為通訊關係，如果某個執行者可以對某個用例進行操作，它們之間就具有關聯關係，如所示，“經理”有一個功能為“查看庫存報表”，因此可以在執行者“經理”和用例“查看庫存報表”之間建立一個關聯關係，關聯關係用實線表示。(2)

網站地圖的應用還是比較普遍的。哪怕一個簡單的個人首頁，也會有網站地圖。今天我們做一個小例子，作用只是拋磚引玉。首先，添加一個Web.sitemap，注意我們這裡不改變該檔案的名字。添加如下代碼： <?xml version="1.0" encoding="utf-8" ?><siteMap xmlns="http://schemas.microsoft.com/AspNet/SiteMap-File-1.0" ><siteMapNode url="a.aspx"

       在UML 2.0的13種圖形中，類圖是使用頻率最高的UML圖之一。Martin Fowler在其著作《UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition》（《UML精粹：標準對象建模語言簡明指南（第3版）》）中有這麼一段：“If someone were to come up to you in a dark alley and say, 'Psst, wanna

     行為型模式（上）      (13) 職責鏈模式：布馮手拋球給基耶利尼、基耶利尼傳給皮爾洛、皮爾洛帶球過人之後將球直塞給快速插上的巴洛特利，巴洛特利倒鉤射門，球進了，球進了，又是巴洛特利，巴洛特利立功了，偉大的意大利前鋒！他繼承了意大利的光榮傳統，巴喬、因紮吉、皮耶羅在這一刻靈魂附體！巴洛特利代表了意大利足球悠久的曆史和傳統，在這一刻他不是一個人在戰鬥，他不是一個人！      在此，足球就是一個請求，而球員就是請求的處理者，足球在球員間不斷進行傳遞，構成了一條傳遞鏈。     

類與類之間的關係（1）      在軟體系統中，類並不是孤立存在的，類與類之間存在各種關係，對於不同類型的關係，UML提供了不同的表示方式。      1. 關聯關係     

機房收費系統臨近開學的時候，就按計劃完成了。軟工視頻也看完了，儘管很多地方的知識，都談不上理解，只能說是過了一遍。其實軟工等於看了三遍。第一遍當然是看視頻，每當看完一章之後，我都會用思維導圖進行總結。這一遍下來，等於又看了一遍；最後，等視頻看完之後，自己又對軟工知識進行整理，然後整理在部落格上。下來之後，等於又是一遍。最近一直在寫機房收費系統的文檔。提起文檔，真的很頭疼啊——全身頭疼。做機房收費系統的感受是，一開始感覺很難，但是一開了個小頭，就行如流水一般做下來了；而寫文檔一開始的時候感覺很好寫

類與類之間的關係（2）      2. 依賴關係     

下面是某公司招聘vb.net程式員的筆試題（部分），可以一起討論哦！Question 1 The VB function, GetCurrencyCode demonstrates the translation between the currency code and currency number.  However, the performance of this function is not good enough; the higher order of input number

又到了一年畢業季，而這次即將離校的卻有一個了。不過好像畢業並沒有想象中的那麼可怕，好幾個同學都找到了不錯的工作，工作半年或者一年就能夠有編製，為他們加油吧。在寫畢業論文的過程中，學習了word中方程式編輯器的使用，今天拿出來跟大家分享下（不得不說，word中的是一款非常牛的軟體，不服不行呀）。由於在word中開啟方程式編輯器沒有快速鍵，所以每次輸入公式的時候，都需要手動點一大串操作。這裡介紹給大家一個自訂快速鍵的方法：①開啟word，按住ctrl+alt，再按小鍵盤上面的“+”號鍵，即：ctrl

大家手裡負責的項目都差不多OK了，前些天，大家在一起大概花了一整天的時間，對自己開發項目中的業務、問題、技術等，進行了交流。大家做項目的時間大概都是在3到4個月之間。記憶較為深刻的教務系統。它分為四個子系統：基礎、選課、評教、考試。這是大家做的項目中，規模最大、涉及人員最多的項目。教務——基礎部分設計：資料庫不要設定外鍵約束，所有的關係使用第三張表來維護。也就是說，只要兩張表有關係，就需要加一張表來維護它們的關係。目的就是通過降低效率，增加基礎資料表的靈活度；採用主鍵產生器，保證產生的主鍵不會重