×

Uh-oh, it looks like your Internet Explorer is out of date.

For a better shopping experience, please upgrade now.

Sams Teach Yourself UML in 24 Hours
     

Sams Teach Yourself UML in 24 Hours

5.0 2
by Joseph Schmuller
 

See All Formats & Editions

Learn UML, the Unified Modeling Language, to create diagrams describing the various aspects and uses of your application before you start coding, to ensure that you have everything covered. Millions of programmers in all languages have found UML to be an invaluable asset to their craft.

More than 50,000 previous readers have learned UML with Sams Teach

Overview

Learn UML, the Unified Modeling Language, to create diagrams describing the various aspects and uses of your application before you start coding, to ensure that you have everything covered. Millions of programmers in all languages have found UML to be an invaluable asset to their craft.

More than 50,000 previous readers have learned UML with Sams Teach Yourself UML in 24 Hours. Expert author Joe Schmuller takes you through 24 step-by-step lessons designed to ensure your understanding of UML diagrams and syntax. This updated edition includes the new features of UML 2.0 designed to make UML an even better modeling tool for modern object-oriented and component-based programming. The CD-ROM includes an electronic version of the book, and Poseidon for UML, Community Edition 2.2, a popular UML modeling tool you can use with the lessons in this book to create UML diagrams immediately.

Editorial Reviews

Introduces the Unified Modeling Language (UML) for modeling object- oriented programs, presents a simplified methodology for development along with a fictional case study, and applies UML to design patterns and embedded systems. Use case, state, sequence, collaboration, activity, component, and deployment diagrams are covered. Annotation c. Book News, Inc., Portland, OR (booknews.com)

Product Details

ISBN-13:
9780672326400
Publisher:
Sams
Publication date:
03/17/2004
Series:
Sams Teach Yourself Series
Pages:
504
Product dimensions:
7.25(w) x 9.13(h) x 1.16(d)

Read an Excerpt


Hour 1: Introducing the UML

The Unified Modeling Language (UML) is one of the most exciting tools in the world of system development today. Why? The UML enables system builders to create blueprints that capture their visions in a standard, easy-to-understand way and communicate them to others.

In this hour, you'll learn

  • Why the UML is necessary
  • How the UML came to be
  • The diagrams of the UML
  • Why it's important to use a number of different types of diagrams

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 notation 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 system the client wanted.

Because system development is a human activity, the potential for error lurked at eve stage of the process. The analyst might have misunderstood the client. The analyst might have produced a document the client couldn't comprehend. The results of the analysis might not have been clear to the programmers, who subsequently might have created a program that was difficult to use and not a solution to 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, programmers typically didn't rely 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's inappropriate in today's high-stakes business world.

Today, a well-thought-out plan is crucial. A client has to understand what a development team is going to do, and 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 the systems that will take you into the next millennium, how do you get your hands around the complexity?

The key is to organize the design process in a way that analysts, clients, programmers, 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 inhabit 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 blueprint to the person who's paying for a building. That design plan should result from a careful analysis of the client's needs.

Short timeframes for development are another feature of the contemporary system development landscape. When the deadlines fall on top of one another, a solid design is an absolute necessity.

Still another aspect of modem 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 facilitate the changeover. If the design is solid, a change in implementation can proceed 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. The UML is that notation.

How the UML Came to Be

The UML is the brainchild of Grady Booch, James Rumbaugh, and Ivar Jacobson. Recently dubbed "the Three Amigos," these gentlemen worked in separate organizations through the '80s and early '90s, each devising his own methodology for object-oriented analysis and design. Their methodologies achieved preeminence over those of numerous competitors. By the mid '90s, they began to borrow ideas from each other, so they decided to evolve their work together.

Note: Hours 2, "Understanding Object-Orientation, and 4, "Working with Relationships," deal with object-orientation. Object-oriented 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 substantial changes. As many corporations felt the UML would serve their strategic purposes, a UML consortium sprang 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 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 standard in the software industry, and it continues to evolve.

The Components of the UML

The UML consists of a number of graphical elements that combine to form diagrams. Because it's a language, the UML has rules for combining these elements. Rather than telling you about these elements and rules, let's jump right into the diagrams because they're what you'll use to do system analysis.

Note: 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 conjugations anyway.

The purpose of the diagrams is to present multiple views of a system, and 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 1, 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 organize and extend its diagrams.

Class Diagram

Think about the things in the world around you. (A pretty broad admonition, admittedly, but try it anyway!) It's probably the case that most of them have attributes (properties) and that they behave in a certain way. 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 category or group of things that have similar attributes and common 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 "add clothes," "add detergent," "turn on," and "remove clothes."

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 shows the operations. A class diagram consists of a number of these rectangles connected by lines that show how the classes relate to one another.

FIGURE 1.1 The UML class icon.

Why bother to think about classes of things and their attributes and behaviors? In order to interact with our complex world, most modem software simulates some aspect of the world. Decades of experience suggest that it's easiest to develop 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 important details about the problems they want solved.

Object Diagram

An object is an instance of a class--a specific thing that has specific values of the attributes and behavior. 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.

Figure 1.2 shows how the UML represents an object. Note that the icon is a rectangle, just like the class icon, but the name is underlined. 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...

Meet the Author

Joseph Schmuller, a veteran of over 20 years in Information Technology, is a Technical Architect with Blue Cross-Blue Shield of Florida. From 1991 through 1997, he was Editor in Chief of PC AI Magazine. He has written numerous articles and reviews on advanced computing technology and is the author of ActiveX No experience required and Dynamic HTML Master the Essentials. Holder of a Ph.D. from the University of Wisconsin, he is an Adjunct Professor at the University of North Florida.

Customer Reviews

Average Review:

Post to your social network

     

Most Helpful Customer Reviews

See all customer reviews

Sams Teach Yourself Uml in 24 Hours 4.7 out of 5 based on 0 ratings. 3 reviews.
Nada12 More than 1 year ago
This book is good for people want to be professional in System analysis, and to learn how to develop a new system. it used for Master Degree in Information system and it is work prefectly.
Guest More than 1 year ago
No matter who you are or what you are, this book will make you happy to learn about UML,even you only read chapter I of this book.It clear and smooth book for learning UML.The author truly make you easy to understand about what exactly UML is.NO doubt!!
Guest More than 1 year ago
i find this book extremely accessible to the people who believe what is written can be learned,'crowd'.I am very pleased with Sams publishing;this being my second title from them.Until I see otherwise I feel this is more than an adequate step for the beginner or those with a cursory hunger for knowledge in computer science.