基于.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