基于.NET的醫藥進銷存管理系統(六)

參 考 文 獻
1.（美） Wendy Boggs,Michael Boggs．UML與Rational Rose2002從入門到精通．北京： 電子工業出版社，2002．
2.（美）Joseph Schmuller．UML基礎、案例與應用．北京：人民郵電出版社，2001．
3. 李滿潮 .Visual C#.NET編程基礎.北京：清華大學出版社，2002．
4. Meilir Page.JonesUML．面向對象設計基礎．北京：科學出版社，2003．
5. 劉潤東．UML對象設計與編程．北京：希望電子出版社2002．
6. Martin Flower,Kendall Sott．UML精粹——標準對象建模語言簡明指南．北京： 清華大學出版社 ，1999．
7. Karli Watson  Marco Bellinaso．康博譯．C#入門經典．北京：清華大學出版社， 2002．
8. 孫三才 張智凱 許薰尹．C#與.NET技術平臺實戰演練．北京：中國青年出版社， 2002．
9. (美)普拉持(Platt，D.s.) ．黃惠萍等譯．Microsoft.NET精髓著．北京：機械工業出版社 ，2003．

附錄1：英文原文
 UML basics: An introduction to the Unified Modeling Language by Donald Bell
  , IBM  Global Services,  June 2003
 Way back in the late twentieth century -- 1997 to be exact -- the Object Management Group (OMG) released the Unified Modeling Language (UML). One of the purposes of UML was to provide the development community with a stable and common design language that could be used to develop and build computer applications. UML brought forth a unified standard modeling notation that IT professionals had been wanting for years. Using UML, IT professionals could now read and disseminate system structure and design plans -- just as construction workers have been doing for years with blueprints of buildings. 
 It is now the twenty-first century -- 2003 to be precise -- and UML has gained traction in our profession. On 75 percent of the resumes I see, there is a bullet point claiming knowledge of UML. However, after speaking with a majority of these job candidates, it becomes clear that they do not truly know UML. Typically, they are either using it as a buzz word, or they have had a sliver of exposure to UML. This lack of understanding inspired me to write this quick introduction to UML 1.4. When you are finished reading you will not have enough knowledge to put UML on your resume, but you will have a starting point for digging more deeply into the language.
 A little background
 As I mentioned, UML was meant to be a unifying language enabling IT professionals to model computer applications. The primary authors were Jim Rumbaugh, Ivar Jacobson, and Grady Booch, who originally had their own competing methods (OMT, OOSE, and Booch). Eventually, they joined forces and brought about an open standard. (Sound familiar? A similar phenomenon spawned J2EE, SOAP, and Linux.) One reason UML has become a standard modeling language is that it is programming-language independent. (UML modeling tools from IBM Rational are used extensively in J2EE shops as well in .Net shops.) Also, the UML notation set is a language and not a methodology. This is important, because a language, as opposed to a methodology, can easily fit into any company's way of conducting business without requiring change.
 Since UML is not a methodology, it does not require any formal work products (i.e., "artifacts" in IBM Rational Unified Process® lingo). Yet it does provide several types of diagrams that, when used within a given methodology, increase the ease of understanding an application under development.
 There is more to UML than these diagrams, but for my purposes here, the diagrams offer a good introduction to the language and the principles behind its use. By placing standard UML diagrams in your methodology's work products, you make it easier for UML-proficient people to join your project and quickly become productive. The most useful, standard UML diagrams are: use case diagram, class diagram, sequence diagram, statechart diagram, activity diagram, component diagram, and deployment diagram.
 It is beyond the scope of this introductory article to go into great detail about each type of diagram. Instead, I will provide you with enough information for a general understanding of each one and then supply more details in later articles.
Use-case diagram

 Figure 1: Sample use-case diagram
 A use case illustrates a unit of functionality provided by the system. The main purpose of the use-case diagram is to help development teams visualize the functional requirements of a system, including the relationship of "actors" (human beings who will interact with the system) to essential processes, as well as the relationships among different use cases. Use-case diagrams generally show groups of use cases -- either all use cases for the complete system, or a breakout of a particular group of use cases with related functionality (e.g., all security administration-related use cases). To show a use case on a use-case diagram, you draw an oval in the middle of the diagram and put the name of the use case in the center of, or below, the oval. To draw an actor (indicating a system user) on a use-case diagram, you draw a stick person to the left or right of your diagram (and just in case you're wondering, some people draw prettier stick people than others). Use simple lines to depict relationships between actors and use cases, as shown in Figure 1.
 A use-case diagram is typically used to communicate the high-level functions of the system and the system's scope. By looking at our use-case diagram in Figure 1, you can easily tell the functions that our example system provides. This system lets the band manager view a sales statistics report and the Billboard 200 report for the band's CDs. It also lets the record manager view a sales statistics report and the Billboard 200 report for a particular CD. The diagram also tells us that our system delivers Billboard reports from an external system called Billboard Reporting Service.
 In addition, the absence of use cases in this diagram shows what the system doesn't do. For example, it does not provide a way for a band manager to listen to songs from the different albums on the Billboard 200 -- i.e., we see no reference to a use case called Listen to Songs from Billboard 200. This absence is not a trivial matter. With clear and simple use-case descriptions provided on such a diagram, a project sponsor can easily see if needed functionality is present or not present in the system.
Class diagram
 The class diagram shows how the different entities (people, things, and data) relate to each other; in other words, it shows the static structures of the system. A class diagram can be used to display logical classes, which are typically the kinds of things the business people in an organization talk about -- rock bands, CDs, radio play; or loans, home mortgages, car loans, and interest rates. Class diagrams can also be used to show implementation classes, which are the things that programmers typically deal with. An implementation class diagram will probably show some of the same classes as the logical classes diagram.The implementation class diagram won't be drawn with the same attributes, however, because it will most likely have references to things like Vectors and HashMaps.  A class is depicted on the class diagram as a rectangle with three horizontal sections, as shown in Figure 2. The upper section shows the class's name; the middle section contains the class's attributes; and the lower section contains the class's operations (or "methods").
Figure 2: Sample class object in a class diagram

 In my experience, almost every developer knows what this diagram is, yet I find that most programmers draw the relationship lines incorrectly. For a class diagram like the one in Figure 3,you should draw the inheritance relationship1 using a line with an arrowhead at the top pointing to the super class, and the arrowhead should a completed triangle. An association relationship should be a solid line if both classes are aware of each other and a line with an open arrowhead if the association is known by only one of the classes.
Figure 3: A complete class diagram,including the class object shown in Figure 2
 In Figure 3, we see both the inheritance relationship and two association relationships. The CDSalesReport class inherits from the Report class. A CDSalesReport is associated with one CD, but the CD class doesn't know anything about the CDSalesReport class. The CD and the Band classes both
 
 
 
know about each other, and both classes can be associated to one or more of each other.
 A class diagram can incorporate many more concepts, which we will cover later in this article series.
Sequence diagram
 Sequence diagrams show a detailed flow for a specific use case or even just part of a specific use case. They are almost self explanatory; they show the calls between the different objects in their sequence and can show, at a detailed level, different calls to different objects.
 A sequence diagram has two dimensions: The vertical dimension shows the sequence of messages/calls in the time order that they occur; the horizontal dimension shows the object instances to which the messages are sent.
 A sequence diagram is very simple to draw. Across the top of your diagram, identify the class instances (objects) by putting each class instance inside a box (see Figure 4). In the box, put the class instance name and class name separated by a space/colon/space " : " (e.g., myReportGenerator : ReportGenerator). If a class instance sends a message to another class instance, draw a line with an open arrowhead pointing to the receiving class instance; place the name of the message/method above the line. Optionally, for important messages, you can draw a dotted line with an arrowhead pointing back to the originating class instance; label the return value above the dotted line. Personally, I always like to include the return value lines because I find the extra details make it easier to read.
 Reading a sequence diagram is very simple. Start at the top left corner with the "driver" class instance that starts the sequence. Then follow each message down the diagram. Remember: Even though the example sequence diagram in Figure 4 shows a return message for each sent message, this is optional.

Figure 4: A sample sequence diagram

 By reading our sample sequence diagram in Figure 4, you can see how to create a CD Sales Report. The aServlet object is our example driver. aServlet sends a message to the ReportGenerator class instance named gen. The message is labeled generateCDSalesReport, which means that the ReportGenerator object implements this message handler. On closer inspection, the generateCDSalesReport message label has cdId in parentheses, which means that aServlet is passing a variable named cdId with the message. When gen instance receives a generateCDSalesReport message, it then makes subsequent calls to the CDSalesReport class, and an actual instance of a CDSalesReport called aCDReport gets returned. The gen instance then makes calls to the returned aCDReport instance, passing it parameters on each message call. At the end of the sequence, the gen instance returns aCDReport to its caller aServlet.
 Please note: The sequence diagram in Figure 4 is arguably too detailed for a typical sequence diagram. However, I believe it is simple enough to understand, and it shows how nested calls are drawn. Also, with junior developers, sometimes it is necessary to break down sequences to this explicit level to help them understand what they are supposed to do.
 
Statechart diagram 
 The statechart diagram models the different states that a class can be in and how that class transitions from state to state. It can be argued that every class has a state, but that every class shouldn't have a statechart diagram. Only classes with "interesting" states -- that is, classes with three or more potential states during system activity -- should be modeled.
 As shown in Figure 5, the notation set of the statechart diagram has five basic elements: the initial starting point, which is drawn using a solid circle; a transition between states, which is drawn using a line with an open arrowhead; a state, which is drawn using a rectangle with rounded corners; a decision point, which is drawn as an open circle; and one or more termination points, which are drawn using a circle with a solid circle inside it. To draw a statechart diagram, begin with a starting point and a transition line pointing to the initial state of the class. Draw the states themselves anywhere on the diagram, and then simply connect them using the state transition lines.
Figure 5: Statechart diagram showing the various statesthat classes pass through in a functioning system

 The example state chart diagram in Figure 5 shows some of the potential information they can communicate. For instance, you can tell that loan processing begins in the Loan Application state. When the pre-approval process is done, depending on the outcome, you move to either the Loan Pre-approved state or the Loan Rejected state. This decision, which is made during the transition process, is shown with a decision point -- the empty circle in the transition line. By looking at the example, a person can tell that a loan cannot go from the Loan Pre-Approved state to the Loan in Maintenance state without going through the Loan Closing state. Also, by looking at our example diagram, a person can tell that all loans will end in either the Loan Rejected state or the Loan in Maintenance state.
Activity diagram
 Activity diagrams show the procedural flow of control between two or more class objects while processing an activity. Activity diagrams can be used to model higher-level business process at the business unit level, or to model low-level internal class actions. In my experience, activity diagrams are best used to model higher-level processes, such as how the company is currently doing business, or how it would like to do business. This is because activity diagrams are "less technical" in appearance, compared to sequence diagrams, and business-minded people tend to understand them more quickly.
  An activity diagram's notation set is similar to that used in a state chart diagram. Like a state chart diagram, the activity diagram starts with a solid circle connected to the initial activity. The activity is modeled by drawing a rectangle with rounded edges, enclosing the activity's name. Activities can be connected to other activities through transition lines, or to decision points that connect to different activities guarded by conditions of the decision point. Activities that terminate the modeled process are connected to a termination point (just as in a statechart diagram). Optionally, the activities can be grouped into swimlanes, which are used to indicate the object that actually performs the activity, as shown in Figure 6. 
Figure 6: Activity diagram, with two swimlanes to indicate control of activity by two objects: the band manager, and the reporting tool

 In our example activity diagram, we have two swimlanes because we have two objects that control separate activities: a band manager and a reporting tool. The process starts with the band manager electing to view the sales report for one of his bands. The reporting tool then retrieves and displays all the bands that person manages and asks him to choose one. After the band manager selects a band, the reporting tool retrieves the sales information and displays the sales report. The activity diagram shows that displaying the report is the last step in the process.
Component diagram
 A component diagram provides a physical view of the system. Its purpose is to show the dependencies that the software has on the other software components (e.g., software libraries) in the system. The diagram can be shown at a very high level, with just the large-grain components, or it can be shown at the component package level.2
 Modeling a component diagram is best described through an example. Figure 7 shows four components: Reporting Tool, Billboard Service, Servlet 2.2 API, and JDBC API. The arrowed lines from the Reporting Tool component to the Billboard Service, Servlet 2.2 API, and JDBC API components mean that the Reporting Tool is dependent on those three components.
Figure 7: A component diagram shows interdependencies ofvarious software components the system comprisesDeployment diagram

 The deployment diagram shows how a system will be physically deployed in the hardware environment. Its purpose is to show where the different components of the system will physically run and how they will communicate with each other. Since the diagram models the physical runtime, a system's production staff will make considerable use of this diagram.
  The notation in a deployment diagram includes the notation elements used in a component diagram, with a couple of additions, including the concept of a node. A node represents either a physical machine or a virtual machine node (e.g., a mainframe node). To model a node, simply draw a three-dimensional cube with the name of the node at the top of the cube. Use the naming convention used in sequence diagrams: [instance name] : [instance type] (e.g., "w3reporting.myco.com : Application Server").
Figure 8: Deployment diagram. Because the Reporting Tool component is drawn inside of IBM WebSphere, which in turn is drawn inside of the node w3.reporting.myco.com, we know that users will access the Reporting Tool via a browser running on their local machine, and connecting via HTTP over their company's intranet.

 The deployment diagram in Figure 8 shows that the users access the Reporting Tool by using a browser running on their local machine and connecting via HTTP over their company's intranet to the Reporting Tool. This tool physically runs on the Application Server named w3reporting.myco.com. The diagram shows the Reporting Tool component drawn inside of IBM WebSphere, which in turn is drawn inside of the node w3.reporting.myco.com. The Reporting Tool connects to its reporting database using the Java language to IBM DB2's JDBC interface, which then communicates to the actual DB2 database running on the server named db1.myco.com using native DB2 communication. In addition to talking to the reporting database, the Report Tool component communicates via SOAP over HTTPS to the Billboard Service.
Conclusion
 Although this article provides only a brief introduction to Unified Modeling Language, I encourage you to start applying the information you have learned here to your own projects and to dig more deeply into UML. There are several software tools that help you to integrate UML diagrams into your software development process, but even without automated tools, you can use markers on a whiteboard or paper and pencils to draw your UML diagrams and still achieve benefits.
附錄2：中文翻譯：
UML基礎： 統一的模型建立語言的介紹
Donald Bell   IBM  2003年6月
 讓我們回到20 世紀末——確切的說是 1997年， Object Management Group (OMG)解放了統一的模型建立語言(UML)。 其目的之一 ，是為了提供一種能用來發展并且建造計算機應用的一種穩定和普及的設計語言。 UML產生了許多IT專業人員多年來一直想要的一個統一的標準模型化表達式。 使用UML，IT專業人員現在能讀并且描述系統結構與詳細設計計劃 ——就像一直做多年前建筑工人使用過的大樓建筑藍圖一樣。
 現在讓我們來到二十一世紀——準確的說是2003年。如今，UML已經在我們的職業里獲得了長足的發展。 在我看過的簡歷中，有百分之七十五的人聲稱他們有一定的UML的知識。 不過，經過與超過大半的這些求職者談話之后，我發現他們很顯然并不真的了解UML。 通常，他們正準備或者正在使用它作為專門用語，或者是他們只不過對UML有那么一絲半點的認識。 這種對UML缺乏足夠認識的現狀激發著我寫這篇UML 1. 4快速入門的介紹。 讀完這篇文章，也許并不能使你具備足夠的知識可以把“精通UML”寫在你的簡歷上，但是你已經會在這個時候站在一個起點上，從而走上更深入認識與挖掘這門語言的道路。
一些背景知識
 正如我所提到的，UML意味著一種統一的建模語言可以讓IT專業人士來構建計算機應用軟件。 它的主要作者是有各自頗具競爭力方法(OMT，OOSE 和Booch)的Jim Rumbaugh, Ivar Jacobson,以及Grady Booch。最終，他們合力推出一個公開的標準。 (聽起來熟悉嗎？類似大量生產J2EE，SOAP和Linux的現象.) UML成為標準模型建立語言的一個原因是它獨立于編程語言。 (來自 IBM Rational 的UML建模工具在. Net系列產品與J2EE系列產品中均被廣泛采用.) 此外，UML的符號表達式是一種語言而非方法學。 這是很重要的，因為一種語言，與方法學相反，能很容易的適應任何公司的那種業務管理方式而不需要任何變化。
 因為UML不是方法學，它不需要任何正式的工作產品(即，在IBM 統一過程語言中的“artifacts”)。然而，它提供幾種圖，用來規定設計的方法，增加對落后于發展潮流的軟件的理解的容易度。與這些圖相比較，UML有更多值得講的地方，但是我的目的是在于說明，這些圖為這門語言提供了很好的介紹，以及規定了在它背后所用到的法則。通過在你的方法學的工作產品里引入標準UML 圖解，你可以很容易的使精通UML的人們加入你的工程并且迅速投入生產中。最有用，標準的UML 圖是：用例圖，類圖，順序圖，協作圖，活動圖，構件圖和部署圖。
 關于每種類型圖的細節說明不屬于這篇引導性文章的敘述范圍。取而代之的，是我將為你提供足夠的信息來讓你對這些圖有一個大體上的了解，在今后的文章里我會陸續提供更多的詳細介紹。
Use-case——用例圖介紹（圖略）
 一個用例是由系統提供的一個功能性單位。 使用用例圖的主要目的是幫助開發團隊對系統的職能要求有一個形象化的理解， 包括"演員"(與系統相互作用的人)在系統中所必需經歷的過程， 以及不同用例之間的關系。1. 用例圖一般顯示了多種的用例情況 ——完整系統的用例或者一組功能上有一定關聯的用例 ( 例如，全部與安全管理有關的用例)。要在用例圖上表示一個用例時，先在圖的中央畫一個橢圓形并在它的內部或下方寫上用例的名字。在這個圖上畫使用這個用例的主角（演員——表明一個系統用戶)時，我們可以畫一個持棒的人形 ( 為了讓你感覺新奇，有些人會畫一些比其他人畫得更漂亮的持棒人出來)。 使用簡單的線表現主角與用例之間的關系，如圖1中所示。
 系統圖通常被用來描述系統高層結構中的通訊以及劃定系統范圍。從圖1中我們看出，你可以很容易的說出系統所提供的功能。這系統可以讓樂隊經理瀏覽銷售統計報告以及為樂隊的CD做200個宣傳報告。它同樣也可以讓唱片公司經理瀏覽銷售統計報告以及200個某個特定樂隊的CD宣傳報告。這個用例圖也告訴我們，系統是從一個叫做宣傳報告服務的外部系統傳送我們的宣傳報告的。
 此外，這個用例圖中沒有出現的用例表示系統不做這件事。 例如，它沒有提供樂隊經理在200個宣傳的唱片中聽取來自不同的集子的歌的功能——即，我們看到圖中沒有涉及到關于聽歌的用例。 這個用例的缺席并不是一件不值一提的小事。由于這張圖提供了簡單而清晰的用例描述，一個工程發起人能很容易的看出是否需要在這個系統中增加或者刪除一些功能。
類圖
 類圖顯示不同實體(人，事情和數據)與彼此間有著怎樣的關聯； 換句話說，它表現系統的靜態結構。 一個類圖常常用來描述邏輯類——常常是組織中的人提到的事物——搖滾樂樂隊，CD，多媒體游戲； 或者貸款，住宅抵押貨款，汽車貸款和利率。類圖也能用來表示執行類，這是程序員通常處理的事情。一張執行類圖可能會表達一些相似的類作為邏輯類圖。執行類圖不能以相同的屬性來畫出，不過，因為它似乎和具體事物有著類似矢量和向量的關系。
 如圖2中所示，一種種類被用3 個水平的部分在種類圖解上描繪為一個長方形。 上面部分顯示種類的名字； 中間部分包含種類的屬性； 并且部分包含種類的行動(或者"方法")越低。
圖2：類圖（圖略）
 在我的經驗里，幾乎每個開發者都知道這張圖是什么，然而我發現大多數程序員都不能正確的畫出里面的關系線。在像圖3這樣的一張類圖里面。你應該用一條在頂端帶箭頭的線畫出對超級類的繼承關系，這個箭頭應該是一個實心三角形。如果兩個如果類之間對對方可見，則這種連接關系應該被表現為一條實線，而如果兩個類之間只有一方被對方可見，則應該被一條空心箭頭來表現。
 如圖2中所示，一個類圖中，類是用一個包含3 個水平部分的長方形描繪的。最上邊的那個部分顯示類的名字；中間部分包含類的屬性；最底層是類的行為(或者"方法")。
圖3 一張完整的包括圖2 中顯示的類的類圖（圖略）
 在圖3中，我們看見繼承關系和兩種連接關系。 CDSalesReport 類繼承于“Report” 類。 一個CDSalesReport與一個Report相關聯，但是CD類對CDSalesReport中的任何信息都是不了解的。 CD 類和Band類都是互相可見的，并且兩個類之間都可以被一個或多個彼此所相聯系。
 一張類圖能包含很多的概念，這在今后的系列文章中我們在會有更多的介紹。
順序圖
 順序圖顯示了一個具體用例、甚至部分特定用例的動作順序。它們基本上是自我理解的；它們顯示按照它們的順序的對象與其它對象之間的消息響應，并且能在一個非常詳細地層次上顯示這些消息響應。
 順序圖顯示了一個具體用例、甚至部分特定用例的動作順序。它們基本上是自我理解的；它們顯示按照它們的順序的對象與其它對象之間的消息響應，并且能在一個非常詳細地層次上顯示這些消息響應。
  一張順序圖畫起來非常簡單。在圖的頂端，以將每個類對象填入方框中的方式來確定類的實例(對象)。(參閱圖4)。在方框內，對象名和類名用一個表示空間/ 冒號/ 空間的符號來分開"：" ( 例如myReportGenerator：ReportGenerator)。 如果一個類的實例發消息給另一個類的實例，只需畫一個指向收消息方空心的箭頭，消息名寫在線的上方。在某種特定情況下，對于一些重要的消息，你可以畫一條帶箭頭的虛線指回發出消息的對象，并在虛線上方標出返回值。 就我個人來說，我總是喜歡包括返回值的箭線，因為我發現額外的細節使整個圖更容易讀懂。
 讀一個順序圖也是非常簡單的。從圖的左上角開始，我們順著“發起對象”開始看起。 然后沿著圖中的每條信息向下跟蹤。不過我們要記住：即使圖4所示的順序圖示例所顯示的每一條發出消息都有一條返回消息，但這并不是必需的，我們應該根據實際情況來選擇是否有返回消息。
圖4：一張樣品順序圖（圖略）
 通過閱讀我們圖4中所示的示例順序圖，你能看出怎樣做出一份CD銷售報告。 aServlet 對象是我們的發起人。 aServlet發消息給命名為gen的ReportGenerator類的實例。這條消息被標為generateCDSalesReport，這表明ReportGenerator 對象執行這個消息處理過程。進一步查看下來，我們看到generateCDSalesReport 消息標簽帶有一個加了括號的cdId，說明了在消息傳遞過程中aServlet被賦予了變量cdId。當對象gen接收到generateCDSalesReport發出的消息時，它會向類CDSalesReport發出一個并發的消息，然后在CDSalesReport類中，一個現實中存在的名叫aCDReport的對象值返回。隨后，對象gen向返回的aCDReport對象發出消息，查看每一條消息呼叫中的參數。在順序的末端，對象gen將aCDReport返回它的調用者Servlet。
    請注意： 在圖4中所示的順序圖相對于典型的順序圖來說有些太過詳細了。不過，我相信它很容易去理解，而且它表示出了嵌套的調用是怎么畫的。此外，對于初級的開發者來說，有時很有必要把順序打亂到這種清晰的級別，可以有助于他們理解應該怎么做。
狀態圖
 狀態圖描述了一個類可能所處的狀態以及類怎樣從一個狀態轉換到另一個狀態。應該說每個類都有一個狀態，但并不是每個類都必須要有狀態圖。只有當類擁有一些“有趣”的狀態——即一個類在系統活動中存在三個或者更多的可能狀態——的時候，它才有必要被建模出來。
 如圖5所示，狀態圖的符號設定有5 種基本的要素： 動作的初起點，用一個實心的圓形來代表； 狀態間轉換，被一條帶著開口箭頭的線來表示； 一個狀態，用一個圓角長方形代表； 結束點用一個空心的圓套著一個實心圓的形狀來代表。在畫一張狀態圖時，要從起點開始，畫一條轉換線到類的初狀態。可以把表示狀態的圓角矩形放在圖的任何地方，只需要用轉換線來將它們連接起來。
 在圖5的實例狀態圖中顯示了他們能交流的一些潛在的信息。 例如，你可以說出貸款的步驟開始于貸款請求狀態。 當預批準完成后，你需要由輸出的結果決定而轉換到另一個狀態——預批準狀態或者是貸款被拒狀態。這個決定是在轉換過程期間完成的，用一個決定點——在轉換線上的空心圓來顯示。通過看這個例子， 一人能看出一個貸款項目不能從預批準狀態那里繞開貸款結束的狀態而到達貸款維護狀態。此外，通過看我們的例子圖解，一個人能說出全部貸款項目的終結點是貸款拒絕狀態或者貸款維護狀態。
 
活動圖
 活動圖在處理一項活動時顯示為兩個或更多種類對象之間的控制過程的流動。 活動圖解可以在商業集合層中被用于構建高層的商業過程，或者描述底層的內部類的活動。 在我的經驗里， 活動圖解最好是用于高層處理的建模，例如公司目前正怎樣做生意，它想怎樣做生意。 這是因為活動圖解就外表而論"不那么技術"，與順序圖相比，那些具備更多商業頭腦的人們傾向于更迅速的理解它們。
 確定的一個活動圖的表達式類似于在一張狀態圖里使用的那些表達式。 像一張狀態圖一樣，活動圖解從連接最初活動的一個固體的圈開始。 那些活動由圓角的矩形表示，矩形內部標出活動的名稱。 活動可以通過過渡線，或者到連接到被決定點控制著條件的其他活動。 活動的結束被表示為一個終結點(正像在一張statechart 圖解里所表示的那樣)。有時候，活動可以被組合成泳道的形式，這用來表明實際上進行的活動，如圖6中所示的那樣。
圖6：活動圖，帶有兩泳道圖表明兩個物體對活動的控制： 樂隊經理和報告的工具（圖略）
 在我們的示例活動圖里，我們有兩個泳道，因為我們有兩個物體控制單獨的活動： 一位樂隊經理和一件報告工具。 過程從樂隊經理選擇性的查看他的一個樂隊唱片的銷售報告開始。 這個報告工具執行并且列出所有這個人管理的樂隊 然后讓他選擇其中的一個。在樂隊經理選擇了一個樂隊之后，報告的工具轉到銷售信息并且展示銷售報告。活動圖顯示展示報告是在過程里的最后一步。構件圖
 構件圖提供了系統的物理描述。它的目的是表現出 軟件對于系統中其它的軟件構件所具有的依賴性( 例如，軟件庫)。構件圖可以以大的粒狀構件表示一個相當高的層次，同時也可以被用在構件包的層次。
 怎樣構建一個構件圖最好是通過一個例子描述。 圖7中顯示了四個構件：從報告工具零構件發出的箭頭線指向宣傳服務，報告工具，以及Servlet 2.2 API 和JDBC API。其中JDBC API 構件意味著報告工具依賴于那三個零部件。
圖7：一張顯示系統包括的各種各樣的軟件成分的構件圖（圖略）
 部署圖顯示了一個系統在硬件環境下怎樣進行物理上的配置。它的目的是顯示系統怎樣在物理設備上運行以及這些設備怎樣與其它硬件設備連接。從這張圖被構建起來開始，就被系統的開發團體廣泛的使用。
在一張部署圖里包括了一些構件圖里使用的表達式元素，包括一個節點的概念。 一個節點描述一個物理機器或者一個現實中的機器節點(例如，一個主機節點)。 在構建一個節點時，只需要畫一個三維空間立方體，把節點的名字寫在立方體的頂部。使用順序圖使用的命名規則： [ 實例名字 ]: [實例類型 ](例如，"w3reporting. myco. com：應用服務器")。
圖8：部署圖（圖略）
 我們知道用戶將通過一個瀏覽器在他們的本地機器上運行，并且在他們的公司的內部網上方通過HTTP 連結訪問報告的工具。
 在圖8所示的部署圖中顯示，用戶以使用瀏覽器的方式進入在他們的本地機器上運行并且使用HTTP協議通過他們公司內部網連接到報告工具。 這件工具在物理上運行在一個命名為w3reporting.myco.com的應用服務器上。這個圖表現出在IBM全球互聯系統中報告工具的組成部分。現在正在反過來被用在w3.reporting.myco.com 節點內。 報告工具使用Java 語言連接IBM DB2的JDBC接口，到達它的報告數據庫，然后傳遞到真實的名字為db1.myco.com服務器中的DB2數據庫里。除與報告數據庫交互之外，報告工具的組成使用SOAP通過HTTPS傳遞到廣告宣傳服務中。
 
總結
 雖然這篇文章只提供了簡單的統一建模語言的介紹， 但我鼓勵你可以開始使用你已經學習到的信息和掌握的知識開始深入鉆研UML。目前有幾種軟件可以幫助你聲稱UML 圖解并幫助你完成你的軟件開發過程。不過就算是沒有這些輔助建模的工具，你也一樣能用一支鉛筆在白紙上構建你的UML模型,無論怎樣，只要親自動手，你都可以從中獲益。

首頁 上一頁 3 4 5 6 下一頁 尾頁 6/6/6