Lecture notes UML

lecture notes on uml diagrams, how uml helps in system modelling, how uml helps in software development, how uml helps in database implementation,how to uml eclipse, how to explain uml diagrams
Prof.SteveBarros Profile Pic
Prof.SteveBarros,United Kingdom,Teacher
Published Date:28-07-2017
Your Website URL(Optional)
Comment
04.067232640X.chap01.qxd 2/20/04 10:55 AM Page 7 HOUR 1 Introducing the UML What You’ll Learn in This Hour: . Why the UML is necessary . How the UML came to be . How to represent UML components in diagrams . Why it’s important to use a number of different types of diagrams The Unified Modeling Language (UML) is one of the most exciting and useful tools in the world of system development. Why? The UML is a visual modeling language that enables system builders to create blueprints that capture their visions in a stan- dard, easy-to-understand way, and provides a mechanism to effectively share and communicate these visions with others. Communicating the vision is of utmost importance. Before the advent of the UML, system development was often a hit-or-miss proposition. System analysts would try to assess the needs of their clients, generate a requirements analysis in some nota- tion that the analyst understood (but not always the client), give that analysis to a programmer or team of programmers, and hope that the final product was the sys- tem the client wanted. Some Terms By the Way Throughout this book, consider a system to be a combination of software and hardware that provides a solution for a business problem. System development is the creation of a system for a client, the person who has the problem to be solved. An analyst documents the client’s problem and relays it to developers, programmers who build the software that solves the problem and deploy the software on computer hardware.04.067232640X.chap01.qxd 2/20/04 10:55 AM Page 8 8 Hour 1 Because system development involves communication among people, the poten- tial for error lurked at every stage of the process. The analyst might have misun- derstood the client. The analyst might have produced a document the client couldn’t comprehend. To add to the mess, analysts often created wordy, volumi- nous requirements documents that were difficult for others on the project team to work with. Paradoxically, the sheer weight of these documents often allowed important requirements (and dependencies among requirements) to slip through the cracks. Thus the results of the analysis might not have been clear to the pro- grammers, who subsequently might have created a program that was difficult to use and didn’t solve the client’s original problem. Is it any wonder that many of the long-standing systems in use today are clunky, cumbersome, and hard to use? Adding a Method to the Madness In the early days of computing, few programmers relied on in-depth analyses of the problem at hand. If they did any analysis at all, it was typically on the back of a napkin. They often wrote programs from the ground up, creating code as they went along. Although this added an aura of romance and daring to the process, it has proved to be inappropriate in today’s high-stakes business world. Today a well-thought-out plan is crucial. A client has to understand what a devel- opment team is going to do, and must be able to indicate changes if the team hasn’t fully grasped the client’s needs (or if the client changes his or her mind along the way). Also, development is typically a team-oriented effort, so each member of the team has to know where his or her work fits into the big picture (and what that big picture is). As the world becomes more complex, the computer-based systems that inhabit the world also must increase in complexity. They often involve multiple pieces of hardware and software, networked across great distances, linked to databases that contain mountains of information. If you want to create successful systems, how do you get your hands around the complexity? The key is to organize the design process in a way that analysts, clients, program- mers, and others involved in system development can understand and agree on. The UML provides the organization. Just as you wouldn’t build a complex structure like an office building without first creating a detailed blueprint, you wouldn’t build a complex system to inhabit04.067232640X.chap01.qxd 2/20/04 10:55 AM Page 9 Introducing the UML 9 that office building without first creating a detailed design plan. The plan should be one that you could show a client just as surely as an architect shows a blue- print to the person who’s paying for a building. That design plan should result from a careful analysis of the client’s needs. Short time frames for development are another feature of the contemporary sys- tem development landscape. When the deadlines fall on top of one another, a solid design is an absolute necessity. Still another aspect of modern life necessitates solid design: corporate takeovers. When one company acquires another, the new organization might change important aspects of an in-progress development project (the implementation tool, the coding language, and more). A bulletproof project blueprint will facili- tate the changeover. If the design is solid, a change in implementation can pro- ceed smoothly. The need for solid designs has brought about a need for a design notation that analysts, developers, and clients will accept as a standard—just as the notation in schematic diagrams of circuits serves as a standard for electronics engineers and the notation in Feynman diagrams serves as a standard for physicists. The UML is that notation. How the UML Came to Be The UML is the brainchild of Grady Booch, James Rumbaugh, and Ivar Jacobson. Dubbed “the Three Amigos,” these gentlemen worked in separate organizations through the 1980s and early 1990s, each devising his own methodology for object-oriented analysis and design. Their methodologies achieved preeminence over those of numerous competitors. By the mid-1990s, they began to borrow ideas from each other, so they decided to evolve their work together. Objects by the Hour By the Way Hour 2, “Understanding Object-Orientation,” Hour 3 “Working with Object- Orientation,” and Hour 4, “Working with Relationships,” deal with object-oriented con- cepts. These concepts play major roles throughout the book. In 1994 Rumbaugh joined Rational Software Corporation, where Booch was already working. Jacobson enlisted at Rational a year later. The rest, as they say, is history. Draft versions of the UML began to circulate throughout the software industry, and the resulting feedback brought substantial04.067232640X.chap01.qxd 2/20/04 10:55 AM Page 10 10 Hour 1 changes. Because many corporations felt the UML would serve their strategic pur- poses, a UML consortium sprung up. Members included DEC, Hewlett-Packard, Intellicorp, Microsoft, Oracle, Texas Instruments, Rational, and others. In 1997 the consortium produced version 1.0 of the UML and submitted it to the Object Management Group (OMG) in response to the OMG’s request for a proposal for a standard modeling language. The consortium expanded, generated version 1.1, and submitted it to the OMG, who adopted it in late 1997. The OMG took over the maintenance of the UML and produced two more revisions in 1998. The UML has become a de facto stan- dard in the software industry, and it continues to evolve. Versions 1.3, 1.4, and 1.5 have come into being, and OMG recently put its stamp of approval on ver- sion 2.0. The earlier versions, referred to generically as version 1.x, have been the basis of most models and most UML modeling books. Throughout this book, I’ll show you differences between the old and the new. Components of the UML The UML consists of a number of graphical elements that combine to form dia- grams. Because the UML is a language, it has rules for combining these elements. Rather than tell you about these elements and rules, let’s jump right into the dia- grams because they’re what you’ll use to do system analysis. Jumping Right In By the Way This approach is analogous to learning a foreign language by using it, instead of by learning its grammar and conjugating its verbs. After you’ve spent some time using a foreign language, it’s easier to understand the grammatical rules and verb conjuga- tions anyway. The purpose of the diagrams is to present multiple views of a system; this set of multiple views is called a model. A UML model of a system is something like a scale model of a building along with an artist’s rendition of the building. It’s important to note that a UML model describes what a system is supposed to do. It doesn’t tell how to implement the system. The subsections that follow briefly describe the most common diagrams of the UML and the concepts they represent. Later in Part I you’ll examine each one much more closely. Bear in mind that hybrids of these diagrams are possible, and that the UML provides ways for you to extend its diagrams.04.067232640X.chap01.qxd 2/20/04 10:55 AM Page 11 Introducing the UML 11 Models By the Way The concept of a model is useful throughout the scientific and engineering fields. In the most general sense, when you create a model you’re using something that you know a great deal about to help you understand something you know very little about. In some fields, a model is a set of equations. In others, a model is a comput- er simulation. Many types of models are possible. For our purposes, a model is a set of UML diagrams that we can examine, assess, and modify in order to understand and develop a system. Class Diagram Think about the things in the world around you. (A pretty broad request, admit- tedly, but try it anyway) The things that surround you have attributes (proper- ties) and they behave in certain ways. We can think of these behaviors as a set of operations. You’ll also see that things naturally fall into categories (automobiles, furniture, washing machines. . . ). We refer to these categories as classes. A class is a catego- ry or group of things that have the same attributes and the same behaviors. Here’s an example. Anything in the class of washing machines has attributes such as brand name, model, serial number, and capacity. Behaviors for things in this class include the operations “accept clothes,” “accept detergent,” “turn on,” and “turn off.” Figure 1.1 shows an example of the UML notation that captures these attributes and behaviors of a washing machine. A rectangle is the icon that represents the class. It’s divided into three areas. The uppermost area contains the name, the middle area holds the attributes, and the lowest area holds the operations. FIGURE 1.1 WashingMachine The UML class brandName icon. modelName serialNumber capacity acceptClothes() acceptDetergent() turnOn() turnOff()04.067232640X.chap01.qxd 2/20/04 10:55 AM Page 12 12 Hour 1 Notice the spacing in the names of the class, the attributes, and the operations. In UML, a multiword classname has initial capital letters for all the words and elimi- nates whitespace between each word (for example, WashingMachine). Attribute- names and operation-names follow the same convention, but the first letter of the first word isn’t capitalized (for example, acceptClothes()). A pair of parentheses follows the name of each operation—for reasons we’ll get into in Hour 3. As you’ll see in Hour 4, a class diagram consists of a number of these rectangle icons connected by lines that show how the classes relate to one another. Why bother to think about classes of things and their attributes and behaviors? In order to interact with our complex world, most modern software simulates some aspect of the world. Decades of experience suggest that it’s easiest to devel- op software that does this when the software represents classes of real-world things. Class diagrams provide the representations that developers work from. Class diagrams help on the analysis side, too. They enable analysts to talk to clients in the clients’ terminology and thus stimulate the clients to reveal impor- tant details about the problem they want solved. Object Diagram An object is an instance of a class—a specific thing that has specific values of the class’s attributes. Your washer, for example, might have the brand name Laundatorium, the model name Washmeister, a serial number of GL57774, and a capacity of 16 pounds. The icons in Figure 1.2 show how the UML represents an object. Note that the icon is a rectangle, just like the class icon, but the name is underlined. In the icon on the left, the name of the specific instance is on the left side of a colon, and the name of the class is on the right side of the colon. The name of the instance begins with a lowercase letter. It’s also possible to have an anonymous object, as the icon on the right of Figure 1.2 shows. This just means that you don’t supply a specific name for the object, although you do show the class it belongs to. FIGURE 1.2 myWasher:WashingMachine :WashingMachine Two UML object icons—The icon on the left represents a named object, the icon on the right represents an anonymous object.04.067232640X.chap01.qxd 2/20/04 10:55 AM Page 13 Introducing the UML 13 Use Case Diagram A use case is a description of a system’s behavior from a user’s standpoint. For system developers, the use case is a valuable tool: It’s a tried-and-true technique for gathering system requirements from a user’s point of view. Obtaining informa- tion from the user’s point of view is important if the goal is to build a system that real people (and not just computerphiles) can use. We’ll discuss use cases in greater detail in Hours 6, “Introducing Use Cases”; 7, “Working with Use Case Diagrams”; 18, “Gathering System Requirements”; and 19, “Developing the Use Cases.” For now, here’s a quick example. You use a wash- ing machine, obviously, to wash your clothes. Figure 1.3 shows how you’d repre- sent this in a UML use case diagram. FIGURE 1.3 Washing Machine The UML use case diagram. Wash clothes Washing Machine User The little stick figure that corresponds to the washing machine user is called an actor. The ellipse represents the use case. Note that the actor—the entity that initi- ates the use case—can be a person or another system. Note also that the use case is inside a rectangle that represents the system, and the actor is outside the rectangle. Pronunciation Tip By the Way To help clarify the meaning of this concept, say the use in “use case” with a soft “s,” as though it rhymes with truce. Don’t say it as though it rhymes with snooze. State Diagram At any given time, an object is in a particular state. A person can be a newborn, infant, child, adolescent, teenager, or adult. An elevator is either moving or sta- tionary. A washing machine can be either in the soaking, washing, rinsing, spin- ning, or off state. The UML state diagram shown in Figure 1.4 captures this bit of reality. The figure shows that the washing machine transitions from one state to the next.04.067232640X.chap01.qxd 2/20/04 10:55 AM Page 14 14 Hour 1 FIGURE 1.4 The UML state diagram. Soaking Washing Rinsing Spinning The symbol at the top of the figure represents the start state and the symbol at the bottom represents the end state. Transitions By the Way Transitions from state to state aren’t always linear. Sometimes conditions dictate one path or another. We’ll talk about this in Hour 8, “Working with State Diagrams.” Sequence Diagram Class diagrams and object diagrams represent static information. In a function- ing system, however, objects interact with one another, and these interactions occur over time. The UML sequence diagram shows the time-based dynamics of the interaction. Continuing with the washing machine example, the components of the machine include a timer, a water pipe (for fresh water input), and a drum (the part that holds the clothes and the water). These, of course, are also objects. (As you’ll see, an object can consist of other objects.) What happens when you invoke the “Wash clothes” use case? Assuming you’ve completed the “add clothes,” “add detergent,” and “turn on” operations, the sequence of steps goes something like this: 1. At the beginning of “Soaking,” water enters the drum via the water pipe. 2. The drum remains stationary for 5 minutes.04.067232640X.chap01.qxd 2/20/04 10:55 AM Page 15 Introducing the UML 15 3. At the end of “Soaking,” water stops entering the drum. 4. At the beginning of “Washing,” the drum rotates back and forth and con- tinues doing this for 15 minutes. 5. At the end of “Washing,” the drum pumps out the soapy water. 6. The drum stops rotating. 7. At the beginning of “Rinsing,” water entry restarts. 8. The drum rotates back and forth. 9. After 15 minutes water entry stops. 10. At the end of “Rinsing,” the drum pumps out the rinse water. 11. The drum stops rotating. 12. At the beginning of “Spinning,” the drum rotates clockwise and continues for 5 minutes. 13. At the end of “Spinning,” the drum rotation stops. 14. The wash is done. Imagine that the timer, the water pipe, and the drum are objects. Assume that each object has one or more operations. The objects work together by sending messages to each other. Each message is a request from the sender-object to the receiver-object. The request asks the receiver to complete one of its (the receiver’s) operations. Let’s get specific about the operations. The timer can . Time the soaking . Time the washing . Time the rinsing . Time the spinning The water pipe can . Start a flow . Stop a flow04.067232640X.chap01.qxd 2/20/04 10:55 AM Page 16 16 Hour 1 The drum can . Store water . Rotate back and forth . Rotate clockwise . Stop rotating . Pump water Figure 1.5 shows how to use these operations to create a sequence diagram that captures the messages among the timer, water pipe, drum, and drain represented as anonymous objects at the top of the diagram. Each arrow represents a message that goes from one object to another. Time, in this diagram, proceeds from top to bottom. So the first message is timeSoak(), which the timer sends to itself. The sec- ond message is sendWater(), which the timer sends to the water pipe. The final message, stopRotating(), goes from the timer to the drum. Notice that an object (in this case, the timer) can send a message to itself. Notice also that the arrowheads do not all have the same shape. You’ll learn more about that in Hour 9, “Working with Sequence Diagrams.” Note: If you don’t remember what an anonymous object is, go back and look at Figure 1.2. Activity Diagram The activities that occur within a use case or within an object’s behavior typically occur in a sequence, as in the steps listed in the preceding subsection. Figure 1.6 shows how the UML activity diagram represents steps 4 through 6 of that sequence. Transitions Again By the Way In an earlier note I mentioned that the transitions from state to state aren’t always linear, but sometimes take one path or another. It’s the same for activity diagrams. You’ll see that in Hour 11, “Working with Activity Diagrams.” Communication Diagram The elements of a system work together to accomplish the system’s objectives, and a modeling language must have a way of representing this. The aforementioned 04.067232640X.chap01.qxd 2/20/04 10:55 AM Page 17 Introducing the UML 17 sequence diagram does this. The UML communication diagram shown in Figure 1.7 also does this, but in a slightly different way. Rather than show you the communi- cation diagram that’s equivalent to the sequence diagram in Figure 1.5, Figure 1.7 shows you one that captures just the first few messages among the timer, the water pipe, and the drum. Rather than represent time in the vertical dimension, this diagram shows the order of messages by attaching a number to the message label. FIGURE 1.5 :Timer :WaterPipe :Drum The UML sequence diagram. timeSoak() sendWater() storeWater() stopFlow() timeWash() rotateBackAndForth pumpWater() stopRotating() timeRinse() sendWater() storeWater() rotateBackAndForth() pumpWater() stopRotating() timeSpin() rotateClockwise() stopRotating()04.067232640X.chap01.qxd 2/20/04 10:56 AM Page 18 18 Hour 1 FIGURE 1.6 Drum rotates back and forth 15 minutes The UML activity diagram. Drum pumps out soapy water Drum stops rotating Both the sequence diagram and the communication diagram show interactions among objects. For this reason, the UML refers to them collectively as interaction diagrams. FIGURE 1.7 :Timer 1:timeSoak() The UML communication diagram. 2:sendWater() 3:storeWater() :WaterPipe :Drum Changing Names By the Way The name communication diagram is new in version 2.0. In version 1.x, this was called a collaboration diagram. Don’t be surprised if you find the two terms used interchangeably as version 2.0 settles in. Component Diagram This diagram and the next one move away from the world of washing machines because the component diagram and the deployment diagram are geared expressly toward computer systems. Modern software development proceeds via components, which is particularly important in team-based development efforts. Without elaborating too much at04.067232640X.chap01.qxd 2/20/04 10:56 AM Page 19 Introducing the UML 19 this point, Figure 1.8 shows how the UML version 1.x represents a software component. FIGURE 1.8 A Component The software com- ponent icon in UML 1.x. Here’s where UML 2.0 makes an entrance. In response to the many modelers who felt this symbol was awkward, UML 2.0 provides a revised symbol. Figure 1.9 shows the new way to represent a software component. FIGURE 1.9 The software com- «component» ponent icon in UML 2.0. A Component What’s the Angle? By the Way What are those angle brackets around the word “component” in Figure 1.9? That notation has a special status within UML. You’ll read about it in the subsection enti- tled “Keywords and Stereotypes” a couple of pages from here. Deployment Diagram The UML deployment diagram shows the physical architecture of a computer- based system. It can depict the computers, show their connections with one another, and show the software that sits on each machine. Each computer is rep- resented as a cube, with interconnections between computers drawn as lines con- necting the cubes. Figure 1.10 presents an example.04.067232640X.chap01.qxd 2/20/04 10:56 AM Page 20 20 Hour 1 FIGURE 1.10 The UML deployment Cobalt Networks Qube Microserver 2700WG diagram. Vectra VL Series 7 Dell Dimension XPS R450 Some Other Features Earlier I mentioned that the UML provides features that enable you to extend the diagrams. This section describes a couple of prominent ones. Notes It often happens that one part of a diagram doesn’t present an unambiguous explanation of why it’s there or how to work with it. When that’s the case, the UML note is helpful. Think of a note as the graphic equivalent of a yellow sticky. Its icon is a rectangle with a folded corner. Inside the rectangle is explanatory text. Figure 1.11 shows an example. You attach the note to a diagram element by connecting a dashed line from the element to the note. FIGURE 1.11 Some explanatory text In any diagram about Class1 you can add explanatory comments by attaching a note. Class1 Keywords and Stereotypes The UML provides a number of useful items, but it’s not an exhaustive set. Every now and then you’ll create a model that requires some new concepts and new symbols. Stereotypes enable you to create new UML elements by basing them on existing elements. It’s sort of like buying a suit off the rack and having it altered04.067232640X.chap01.qxd 2/20/04 10:56 AM Page 21 Introducing the UML 21 to fit your particular measurements (as opposed to creating one out of a bolt of cloth). Think of a stereotype as just this kind of alteration. You represent it as a name enclosed in two pairs of angle brackets called guillemets, and then you add that name to a UML symbol. The guillemet-enclosed name is called a key- word. Sometimes the UML does this for you. Rather than create an entirely new symbol for something, the UML adds a keyword to an existing element. The keyword indicates that the element is used in a somewhat different way than originally intended. The concept of an interface (which you’ll read about at length in Hour 5, “Understanding Aggregations, Composites, Interfaces, and Realizations”) provides a good example. An interface is a class that just has operations and has no attributes. It’s a set of behaviors you might want to use again and again through- out your model (for reasons that become clearer in Hour 5). Instead of inventing a new element to represent an interface, UML uses a class icon with the keyword «Interface» situated just above the classname. (See Figure 1.12.) FIGURE 1.12 A stereotype is an «Interface» existing UML InterfaceName element with the addition of a keyword in guillemets. The keyword indicates that the element is used in a some- what different way than originally intended. The stereotype concept is particularly useful when you use a UML modeling tool. One important feature of a modeling tool is a “dictionary” that keeps track of all the elements you create in your model—classes, use cases, components, and oth- ers. (“Dictionary” is my own term. Different tools call it different names.) The dic- tionary can only work with existing UML elements and with stereotypes based on these elements. Thus, stereotyping allows you to create something new and store it in the dictionary. This is important because the dictionary helps you organize and manage your model and enables you to reuse the elements you create. In Hour 14, “Understanding Packages and Foundations,” I look under the hood of the UML and examine the foundations of concepts like the stereotype. For now just bear in mind that to visualize a stereotype you add a keyword to a UML icon. Also bear in mind that as you work with UML (particularly if you work with a04.067232640X.chap01.qxd 2/20/04 10:56 AM Page 22 22 Hour 1 UML modeling tool), you’ll find that UML comes with some built-in stereotypes and predefined keywords (like «component» and «Interface»). De-Evolution? By the Way I first brought up this guillemet notation in the “Component Diagram” subsection a couple of pages ago. I mentioned that the UML 1.x software component symbol in Figure 1.8 has given way to the UML 2.0 notation in Figure 1.9. Everything I just told you about stereotypes indicates that you use a stereotype to create a symbol when you don’t have one. In the case of the component icon, however, it all worked in reverse from 1.x to 2.0—a class icon with a keyword replaced an existing symbol. New Diagrams in UML 2.0 In addition to new takes on UML 1.x diagrams (like the software component icon), UML 2.0 adds some new ideas to the mix. Composite Structure Diagram When you’re modeling a class, you might find it useful to show something about the class’s internal structure. This often happens if the class consists of component classes. For example, let’s assume that a person consists of a mind and a body. In Hour 5 you’ll see the traditional way of modeling that statement. It consists of lines and symbols that join the Person class to the Mind class and to the Body class. With UML 2.0’s composite structure diagram you add a dimension. You put each component class inside the whole. This conveys the idea that you’re looking inside the class into its structure. Figure 1.13 shows you what I mean. Version 1.x allowed this kind of notation in class diagrams. Version 2.0 explicitly identifies this technique as its own kind of diagram. FIGURE 1.13 The composite Person structure diagram models a class’s internal structure. MInd Body04.067232640X.chap01.qxd 2/20/04 10:56 AM Page 23 Introducing the UML 23 Philosophy on the Line By the Way As you’ll see when we get deeper into object-orientation, a line that joins two class- es (like Mind and Body) usually has a name. In Figure 1.13 how should we label the line that joins Mind and Body? Philosophers have been puzzling over that one for ages They’ve been arguing over the name of that association, whether it even exists, whether the Mind component exists, and on and on and on. . . . Interaction Overview Diagram Consider once again the activity diagram (Figure 1.6). This shows you a series of steps, that is, “activities.” Suppose each of those activities involves a sequence of messages among objects. If you replaced some of the activities with sequence diagrams or communication diagrams (or a combination of the two), you’d have UML 2.0’s new interaction overview diagram. Here’s an example. Imagine you’re at a library. 1. You find a book in the library’s database. 2. You bring the book to the circulation desk to borrow the book. 3. A guard at the exit verifies that you checked out the book before you can leave the library with it. Figure 1.14 shows a simple activity diagram that captures these three steps. FIGURE 1.14 Find book Three activities in visiting a library. Borrow book Leave library Now let’s analyze each activity. In the first one, you ask the library database to locate the book, and the database responds by telling you to go to the book’s location. In the second, you ask the librarian to check the book out to you, and04.067232640X.chap01.qxd 2/20/04 10:56 AM Page 24 24 Hour 1 after the checkout, the librarian tells you to take the book. In the third, you can leave the library only if a guard verifies that you have checked out the book. Figure 1.15 shows how to organize all this in sequence diagrams taken in . . . well . . . sequence. FIGURE 1.15 An interaction overview diagram :User :LibraryDatabase that expands the activity diagram in Figure 1.14. () find goToLocation :Librarian :User processCheckOutRequest() takeBook() :Guard :User verifyCheckOut() exitLibrary() Timing Diagram Think back to the examples involving the washing machine. I used this venerable appliance to discuss diagrams for classes, states, sequences, and communications.04.067232640X.chap01.qxd 2/20/04 10:56 AM Page 25 Introducing the UML 25 In the part about sequence diagrams, I mentioned the duration of each state—5 minutes for soaking, 15 minutes for washing, 15 minutes for rinsing, and 5 min- utes for spinning. If you carefully examine the sequence diagram in Figure 1.5, you’ll see that it never explicitly shows these durations. UML 2.0’s timing diagram handles this. It’s designed to show how long an object is in a state. Figure 1.16 shows one form of this new diagram. FIGURE 1.16 :WashingMachine Spinning The UML timing diagram. Rinsing Washing Soaking 05 10 15 20 25 30 35 Something Old, Something New—The Package Diagram Version 1.x includes a capability for organizing the elements of a diagram. Dubbed a package, its icon is a tabbed folder, as in Figure 1.17. The idea is to put elements that go together inside one of these tabbed folder icons. For example, if a number of classes or components constitute a particular subsystem, they would go into a package. FIGURE 1.17 PackageName The UML package icon. Class1 Class2 Class3 By specifying a package diagram, Version 2.0 gives a sort of promotion to the package. No longer considered just a way of organizing a diagram’s elements, the package has attained diagram status of its own. 04.067232640X.chap01.qxd 2/20/04 10:56 AM Page 26 26 Hour 1 Why So Many Diagrams? As you can see, the UML’s diagrams make it possible to examine a system from a number of viewpoints. It’s important to note that not all the diagrams must appear in every UML model. Most UML models, in fact, contain a subset of the diagrams I listed. Why is it necessary to have numerous views of a system? Typically, a system has a number of different stakeholders—people who have interests in different aspects of the system. Let’s return to the washing machine example. If you’re designing a wash- ing machine’s motor, you have one view of the system. If you’re writing the operating instructions, you have another. If you’re designing the machine’s overall shape, you see the system in a totally different way than if you just want to wash your clothes. Conscientious system design involves all the possible viewpoints, and each UML diagram gives you a way of incorporating a particular view. The objective is to communicate clearly with every type of stakeholder. But Isn’t It Just a Bunch of Pictures? Some might argue that UML modeling isn’t very important. After all, isn’t pro- gramming the most important part of the project? Don’t developers do the “real” work while modelers just draw pictures? To understand the importance of accurate visual modeling, consider a well- known, long-term construction project in Boston, Massachusetts. Formally known as the Central Artery/Tunnel, but more popularly known as “The Big Dig,” the goal of this project is to alleviate Boston’s massive traffic crush: A system of tun- nels and bridges through the center of the city will ultimately eliminate an aging, undersized, elevated highway. In addition to solving the traffic problem, the Big Dig will have major economic and environmental benefits. Those benefits better be huge, because the project has generated cost overruns in excess of a billion dollars. According to a report in the Boston Globe, one reason is that the drawings (that is, the visual models) that guide excavation and construc- tion were incomplete and inaccurate. For example, the FleetCenter (Boston’s sports and entertainment facility) was missing from one drawing. That glaring omission misled contractors into think- ing they had an unobstructed path for laying utility lines in a particular area of the city. Another drawing showed a manhole (intended as a connection for elec-

Advise: Why You Wasting Money in Costly SEO Tools, Use World's Best Free SEO Tool Ubersuggest.