Sams Teach Yourself UML in 24 Hours

( 2 )


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

See more details below
$32.55 price
(Save 18%)$39.99 List Price

Pick Up In Store

Reserve and pick up in 60 minutes at your local store

Other sellers (Paperback)
  • All (23) from $1.99   
  • New (6) from $21.74   
  • Used (17) from $1.99   
Sending request ...


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.

Read More Show Less

Editorial Reviews

From The Critics
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 (
Read More Show Less

Product Details

  • ISBN-13: 9780672326400
  • Publisher: Sams
  • Publication date: 3/17/2004
  • Series: Sams Teach Yourself Series
  • Edition number: 3
  • Pages: 504
  • Sales rank: 1,440,581
  • Product dimensions: 7.25 (w) x 9.13 (h) x 1.16 (d)

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.

Read More Show Less

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

Read More Show Less

Table of Contents


What's New in This Edition. Who Should Read This Book? Organization of This Book. Conventions Used Throughout This Book.


Hour 1: Introducing the UML.

Adding a Method to the Madness. How the UML Came to Be. Components of the UML. Some Other Features. New Diagrams in UML 2.0. Why So Many Diagrams? But Isn't It Just a Bunch of Pictures? Summary. Q&A. Workshop.

Hour 2: Understanding Object-Orientation.

Objects, Objects Everywhere. Some Object-Oriented Concepts. The Payoff. Summary. Q&A. Workshop.

Hour 3: Working with Object-Orientation.

Visualizing a Class. Attributes. Operations. Attributes, Operations, and Visualization. Responsibilities and Constraints. Attached Notes. Classes—What They Do and How to Find Them. Summary. Q&A. Workshop.

Hour 4: Working with Relationships.

Associations. Multiplicity. Qualified Associations. Reflexive Associations. Inheritance and Generalization. Dependencies. Class Diagrams and Object Diagrams. Summary. Q&A. Workshop.

Hour 5: -Understanding Aggregations, Composites, Interfaces, and Realizations.

Aggregations. Composites. Composite Structure Diagram. Interfaces and Realizations. Interfaces and Ports. Summary. Q&A. Workshop.

Hour 6: Introducing Use Cases.

Use Cases: What They Are. Use Cases: Why They're Important. An Example: The Soda Machine. Including a Use Case. Extending a Use Case. Starting a Use Case Analysis. Summary. Q&A. Workshop.

Hour 7: Working with Use Case Diagrams.

Representing a Use Case Model. Visualizing Relationships Among Use Cases. Use Case Diagrams in the Analysis Process. Applying Use Case Models: An Example. Taking Stock of Where We Are. The Big Picture. Summary. Q&A. Workshop.

Hour 8: Working with State Diagrams.

What Is a State Diagram? Substates. History States. New in UML 2.0. Why Are State Diagrams Important? Building the Big Picture. Summary. Q&A. Workshop.

Hour 9: Working with Sequence Diagrams.

What Is a Sequence Diagram? Cars and Car Keys. The Soda Machine. Sequence Diagrams: The Generic Sequence Diagram. Creating an Object in the Sequence. Framing a Sequence: Sequence Diagramming in UML 2.0. Building the Big Picture. Summary. Q&A. Workshop.

Hour 10: Working with Communication Diagrams.

What Is a Communication Diagram? Cars and Car Keys. The Soda Machine. Creating an Object. One More Point About Numbering. A Few More Concepts. Building the Big Picture. Summary. Q&A. Workshop.

Hour 11: Working with Activity Diagrams.

The Basics: What Is an Activity Diagram? Applying Activity Diagrams. Swimlanes. Hybrid Diagrams. New Concepts from UML 2.0. An Overview of an Interaction. Building the Big Picture. Summary. Q&A. Workshop.

Hour 12: Working with Component Diagrams.

What Is (and What Isn't) a Component? Components and Interfaces. What Is a Component Diagram? Applying Component Diagrams. Component Diagrams in the Big Picture. Summary. Q&A. Workshop.

Hour 13: Working with Deployment Diagrams.

What Is a Deployment Diagram? Applying Deployment Diagrams. Deployment Diagrams in the Big Picture. Summary. Q&A. Workshop.

Hour 14: Understanding Packages and Foundations.

Package Diagrams. A Hierarchy. To Boldly Go… Packaging the Infrastructure of UML. And Now At Last…the UML! Extending the UML. Summary. Q&A. Workshop.

Hour 15: Fitting the UML into a Development Process.

Methodologies: Old and New. What a Development Process Must Do. GRAPPLE. RAD3: The Structure of GRAPPLE. The GRAPPLE Wrap-up. Summary. Q&A. Workshop.


Hour 16: Introducing the Case Study.

Getting Down to Business. GRAPPLEing with the Problem. Discovering Business Processes. Lessons Learned. Summary. Q&A. Workshop.

Hour 17: Performing a Domain Analysis.

Analyzing the Business Process Interview. Developing the Initial Class Diagram. Grouping the Classes. Forming Associations. Forming Aggregates and Composites. Filling Out the Classes. General Issues About Models. Lessons Learned. Summary. Q&A. Workshop.

Hour 18: Gathering System Requirements.

Developing the Vision. Setting Up for Requirements Gathering. The Requirements JAD Session. The Outcome. Now What? Summary. Q&A. Workshop.

Hour 19: Developing the Use Cases.

The Care and Feeding of Use Cases. The Use Case Analysis. The Server Package. Components of the System. Summary. Q&A. Workshop.

Hour 20: Getting into Interactions.

The Working Parts of the System. Interactions in the System. Implications. Summary. Q&A. Workshop.

Hour 21: Designing Look, Feel, and Deployment.

Some General Principles of GUI Design. The GUI JAD Session. From Use Cases to User Interfaces. UML Diagrams for GUI Design. Mapping Out System Deployment. Next Steps. And Now a Word from Our Sponsor. Summary. Q&A. Workshop.

Hour 22: Understanding Design Patterns.

Parameterization. Design Patterns. Chain of Responsibility. Your Own Design Patterns. The Advantages of Design Patterns. Summary. Q&A. Workshop.


Hour 23: Modeling Embedded Systems.

Back to the Restaurant. The Mother of Invention. Fleshing Out the GetAGrip. What Is an Embedded System? Embedded Systems Concepts. Modeling the GetAGrip. Flexing Their Muscles. Summary. Q&A. Workshop.

Hour 24: Shaping the Future of the UML.

Extensions for Business. Lessons from the Business Extensions. Graphic User Interfaces. Expert Systems. Web Applications. That's All, Folks. Summary. Q&A. Workshop.


Appendix A. Quiz Answers.

Hours 1-24.

Appendix B. Working with a UML Modeling Tool.

What You Should Find in a Modeling Tool. Working with UML in Visio Professional Edition. A Few Words About a Few Tools.

Appendix C. A Summary in Pictures.

Activity Diagram. Class Diagram. Communication Diagram. Component Diagram. Composite Structure Diagram. Deployment Diagram. Object Diagram. Package Diagram. Parameterized Collaboration. Sequence Diagram. State Diagram. Timing Diagram. Use Case Diagram.


Read More Show Less


It's all about vision. A complex system comes into being when someone has a vision of how technology can make things better. Developers have to fully understand the vision and keep it firmly in mind as they create the system that realizes the vision.

System development projects are successful to the extent they bridge the gap between visionary and developer. The Unified Modeling Language (UML) is a tool for building the bridge. It helps you capture the vision for a system, and then enables you to communicate the vision to anyone who has a stake in the system. It does this via a set of symbols and diagrams. Each diagram plays a different role within the development process.

The goal of this book is to give you a firm foundation in the UML in 24 hours of study. Each hour presents examples to strengthen your understanding, and provides exercises that enable you to put your newfound knowledge to use.

I've divided the book into three parts. Part I gives an overview of the UML and then moves into object orientation, which forms the foundation concepts for diagramming objects and classes. We examine the use case--a construct for showing how a system looks to a user, and then show how to diagram use cases. The remaining hours in Part I get you working with the rest of the UML diagrams.

Part II presents a simplified methodology for development along with a fictional case study. Thus, the hours in Part II show how the UML fits into the context of a development project. You'll see how the elements of the UML work together in a model of a system.

In Part III we apply the UML to design patterns and embedded systems, and then examine its potential applicability in acouple of other areas.

Several vendors provide packages that enable you to create UML diagrams and coordinate them into a model. The two most notable are Rational Rose and SELECT Enterprise. Visual UML is another worthy contender. Microsoft has licensed Rational's technology and markets Visual Modeler, a subset of Rational Rose. For this book, however, all you'll need are pencil and paper to draw the diagrams, and a healthy curiosity about the state of the art in system design.

Let's get started!

Read More Show Less

Customer Reviews

Average Rating 5
( 2 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation


  • - By submitting a review, you grant to Barnes & and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Terms of Use.
  • - Barnes & reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing all of 3 Customer Reviews
  • Posted November 11, 2009

    more from this reviewer

    I Also Recommend:

    Great book

    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.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted June 9, 2004

    From Underground to The Sky

    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!!

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted June 18, 2001

    very intuitive to begiinning programmers

    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.

    Was this review helpful? Yes  No   Report this review
Sort by: Showing all of 3 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)