UML 2 For Dummies

Overview

  • Uses friendly, easy-to-understand For Dummies style to help readers learn to model systems with the latest version of UML, the modeling language used by companies throughout the world to develop blueprints for complex computer systems
  • Guides programmers, architects, and business analysts through applying UML to design large, complex enterprise applications that enable scalability, security, and robust ...
See more details below
Paperback
$21.94
BN.com price
(Save 31%)$31.99 List Price

Pick Up In Store

Reserve and pick up in 60 minutes at your local store

Other sellers (Paperback)
  • All (29) from $1.99   
  • New (8) from $5.99   
  • Used (21) from $1.99   

Overview

  • Uses friendly, easy-to-understand For Dummies style to help readers learn to model systems with the latest version of UML, the modeling language used by companies throughout the world to develop blueprints for complex computer systems
  • Guides programmers, architects, and business analysts through applying UML to design large, complex enterprise applications that enable scalability, security, and robust execution
  • Illustrates concepts with mini-cases from different business domains and provides practical advice and examples
  • Covers critical topics for users of UML, including object modeling, case modeling, advanced dynamic and functional modeling, and component and deployment modeling
Read More Show Less

Product Details

  • ISBN-13: 9780764526145
  • Publisher: Wiley
  • Publication date: 7/3/2003
  • Series: For Dummies Series
  • Edition number: 1
  • Pages: 436
  • Sales rank: 789,886
  • Product dimensions: 7.44 (w) x 9.04 (h) x 0.98 (d)

Meet the Author

Michael Jesse Chonoles ia an established system developer, educator, author, and consultant. Michael has done just about everything that you can do in software and system development—business, requirements, and software analysis; software, system, and architectural design; coding in many languages; testing and quality control—right through marketing, packing, and shrinkwrapping the software. He is former Chief of Methodology at the Advanced Concepts Center (ACC) and has an MSE in Systems Engineering from the University of Pennsylvania and BSs in Math and Physics from MIT. 

James A. Schardt is Advanced Concepts Center’s Chief Technologist. He provides 24 years of experience and a firm grounding in object oriented development, data warehousing, and distributed systems. He teaches and mentors Fortune 50 companies in the U.S. and abroad. His many years of practice in object-oriented systems, database design, change management, business engineering, instructional design, and team facilitation bring a wealth of experience to his assignments. 

Read More Show Less

Read an Excerpt


UML 2 For Dummies



By Michael Jesse Chonoles James A. Schardt


John Wiley & Sons



Copyright © 2003

Michael Jesse Chonoles, James A. Schardt
All right reserved.



ISBN: 0-7645-2614-6



Chapter One


What's UML About, Alfie?


* * *


In This Chapter

* Understanding the basics of UML

* Exploring the whys and whens of UML diagrams


* * *


So you've been hearing a lot about UML, and your friends and colleagues
are spending some of their time drawing pictures. And maybe you're
ready to start using UML but you want to know what it's all about first. Well,
it's about a lot of things, such as better communication, higher productivity,
and also about drawing pretty pictures. This chapter introduces you to the
basics of UML and how it can help you.


Introducing UML

The first thing you need to know is what the initials UML stand for. Don't
laugh - lots of people get it wrong, and nothing brands you as a neophyte
faster. It's not the Universal Modeling Language, as it doesn't intend to model
everything (for example, it's not very good for modeling the stock market;
otherwise we'd be rich by now). It's also not the Unified Marxist-Leninists, a
Nepalese Political party (though we hope you'll never getthat confused). It is
the University of Massachusetts Lowell - but not in this context. UML really
stands for the Unified Modeling Language.

Well, maybe that's not the most important thing to know. Probably just as
important is that UML is a standardized modeling language consisting of
an integrated set of diagrams, developed to help system and software
developers accomplish the following tasks:

  •   Specification
  •   Visualization
  •   Architecture design
  •   Construction
  •   Simulation and Testing
  •   Documentation

UML was originally developed with the idea of promoting communication and
productivity among the developers of object-oriented systems, but the readily
apparent power of UML has caused it to make inroads into every type of
system and software development.


Appreciating the Power of UML

UML satisfies an important need in software and system development.
Modeling - especially modeling in a way that's easily understood - allows
the developer to concentrate on the big picture. It helps you see and solve
the most important problems now, by preventing you from getting distracted
by swarms of details that are better to suppress until later. When you model,
you construct an abstraction of an existing real-world system (or of the system
you're envisioning), that allows you to ask questions of the model and get
good answers
- all this without the costs of developing the system first.

After you're happy with your work, you can use your models to communicate
with others. You may use your models to request constructive criticism and
thus improve your work, to teach others, to direct team members' work, or
to garner praise and acclamation for your great ideas and pictures. Properly
constructed diagrams and models are efficient communication techniques
that don't suffer the ambiguity of spoken English, and don't overpower the
viewer with overwhelming details.


Abstracting out the essential truth

The technique of making a model of your ideas or the world is a use of
abstraction. For example, a map is a model of the world - it is not the
world in miniature. It's a conventional abstraction that takes a bit of training
or practice to recognize how it tracks reality, but you can use this abstraction
easily. Similarly, each UML diagram you draw has a relationship to your reality
(or your intended reality), and that relationship between model and reality
is learned and conventional. And the UML abstractions were developed as
conventions to be learned and used easily.

If you think of UML as a map of the world you see - or of a possible world you
want - you're not far off. A closer analogy might be that of set of blueprints
that show enough details of a building (in a standardized representation with
lots of specialized symbols and conventions) to convey a clear idea of
what the building is supposed to be.

The abstractions of models and diagrams are also useful because they suppress
or expose detail as needed. This application of information hiding allows you
to focus on the areas you need - and hide the areas you don't. For example,
you don't want to show trees and cars and people on your map, because
such a map would be cumbersome and not very useful. You have to suppress
some detail to use it.

You'll find the word elide often in texts on UML - every field has its own
jargon. Rumor has it that elide is a favorite word of Grady Booch, one of
the three methodologists responsible for the original development of UML.
Elide literally means to omit, slur over, strike out, or eliminate. UML uses
it to describe the ability of modelers (or their tools) to suppress or hide
known information from a diagram to accomplish a goal (such as simplicity
or repurposing).

Chapter 2 tells you more about using these concepts of information hiding
and abstraction during development.


Selecting a point of view

UML modeling also supports multiple views of the same system. Just as you
can have a political map, a relief map, a road map, and a utility map of the
same area to use for different purposes - or different types of architectural
diagrams and blueprints to emphasize different aspects of what you're
building - you can have many different types of UML diagrams, each of
which is a different view that shows different aspects of your system.

UML also allows you to construct a diagram for a specialized view by limiting
the diagram elements for a particular purpose at a particular time. For example,
you can develop a class diagram - the elements of which are relevant things
and their relationships to one another - to capture the analysis of the problem
that you have to solve, to capture the design of your solution, or to capture
the details of your implementation. Depending on your purpose, the relevant
things chosen to be diagram elements would vary. During analysis, the elements
that you include would be logical concepts from the problem and real world;
during design, they would include elements of the design and architectural
solution; and during implementation, they would primarily be software
classes.

A use case diagram normally concentrates on showing the purposes of the
system (use cases) and the users (actors). We call a use case diagram that
has its individual use cases elided (hidden) a context diagram, because it
shows the system in its environment (context) of surrounding systems
and actors.


Choosing the Appropriate UML Diagram

UML has many diagrams - more, in fact, than you'll probably need to know.
There are at least 13 official diagrams (actually the sum varies every time we
count it) and several semiofficial diagrams. Confusion can emerge because
UML usually allows you to place elements from one diagram on another if
the situation warrants. And the same diagram form, when used for a different
purpose, could be considered a different diagram.

In Figure 1-1, we've constructed a UML class diagram that sums up all the
major types of UML diagrams (along with their relationships), using the
principle of generalization, which entails organizing items by similarities
to keep the diagram compact. (See Chapter 2 for more information on
generalization.)

In Figure 1-1, the triangular arrows point from one diagram type to a more
general (or more abstract) diagram type. The lower diagram type is a kind-of
or sort-of the higher diagram type. Thus a Class Diagram is a kind of
Structural Diagram , which is a kind of Diagram . The diagram also uses a
dashed arrow to indicate a dependency - some diagrams reuse the features
of others and depend on their definition. For example, the Interaction
Overview Diagram depends on (or is derived from) the Activity Diagram
for much of its notation. To get a line on how you might use UML diagrams,
check out the summary in Table 1-1.


Slicing and dicing UML diagrams

There are many ways of organizing the UML diagrams to help you understand
how you may best use them. The diagram in Figure 1-1 uses the technique of
organization by generalization (moving up a hierarchy of abstraction) and
specialization (moving down the same hierarchy in the direction of concrete
detail). (See Chapter 6 for more on generalization and specialization.) In
Figure 1-1, each diagram is a subtype of (or special kind of) the diagram it
points to. So - moving in the direction of increasing abstraction - you can
consider a communication diagram from two distinct angles:

  •   It's a type of interaction diagram, which is a type of behavioral diagram,
    which is a type of diagram.
  •   It's derived from a composite structure diagram, which is a kind of
    structural diagram, which is a type of diagram.

After you get some practice at creating and shaping UML diagrams, it's
almost second nature to determine which of these perspectives best fits
your purpose.

This general arrangement of diagrams that we used in our Figure 1-1 is
essentially the same as the UML standard uses to explain and catalog UML
diagrams - separating the diagrams into structural diagrams and behavioral
diagrams
. This is a useful broad categorization of the diagrams, and is
reflected in the categorizations in Table 1-1:

  •   Structural diagrams: You use structural diagrams to show the building
    blocks of your system - features that don't change with time. These
    diagrams answer the question, What's there?
  •   Behavioral diagrams: You use behavioral diagrams to show how your
    system responds to requests or otherwise evolves over time.
  •   Interaction diagrams: An interaction diagram is actually a type of
    behavioral diagram. You use interaction diagrams to depict the
    exchange of messages within a collaboration (a group of cooperating
    objects) en route to accomplishing its goal.

Because UML is very flexible, you're likely to see various other ways of
categorizing the diagrams. The following three categories are popular:

  •   Static diagrams: These show the static features of the system. This
    category is similar to that of structural diagrams.
  •   Dynamic diagrams: These show how your system evolves over time.
    This category covers the UML state-machine diagrams and timing
    diagrams.
  •   Functional diagrams: These show the details of behaviors and
    algorithms - how your system accomplishes the behaviors requested
    of it. This category includes use-case, interaction, and activity diagrams.

You can employ UML diagrams to show different information at different times
or for different purposes. There are many modeling frameworks, such as
Zachman or DODAF (Department of Defense's Architecture Framework) that
help system developers organize and communicate different aspects of their
system. A simple framework for organizing your ideas that is widely useful is
the following approach to answering the standard questions about the system:

  •   Who uses the system? Show the actors (the users of the system) on
    their use case diagrams (showing the purposes of the system).
  •   What is the system made of? Draw class diagrams to show the logical
    structure and component diagrams to show the physical structure.
  •   Where are the components located in the system? Indicate your plans for
    where your components will live and run on your deployment diagrams.
  •   When do important events happen in the system? Show what causes
    your objects to react and do their work with state diagrams and
    interaction diagrams.
  •   Why is this system doing the things it does? Identify the goals of the
    users of your system and capture them in use cases, the UML construct
    just for this purpose.
  •   How is this system going to work? Show the parts on composite
    structure diagrams and use communication diagrams to show the interactions
    at a level sufficient for detailed design and implementation.


Automating with Model-Driven
Architecture (MDA)

Model-driven architecture (MDA) is new way to develop highly automated
systems. As UML tools become more powerful, they make automation a real
possibility much earlier in the process of generating a system. The roles of
designer and implementer start to converge. UML provides you with the keys
to steer your systems and software development toward new horizons utilizing
model-driven architectures.

In the past, after the designer decides what the system would look like - trading
off the design approach qualities such as performance, reliability,
stability, user-friendliness - the designer would hand the models off to the
developer to implement. Much of that implementation is difficult, and often
repetitious. As one part of an MDA approach to a project, UML articulates the
designer's choices in a way that can be directly input into system generation.
The mechanical application of infrastructure, database, user interface, and
middleware interfaces (such as COM, CORBA, .NET) can now be automated.

Because UML 2 works for high-level generalization or for showing brass-tacks
detail, you can use it to help generate high-quality, nearly complete implementations
(code, database, user-interface, and so on) from the models.

In MDA, the Development Team is responsible for analysis, requirements,
architecture, and design, producing several models leading up to a complete,
but Platform-Independent Model (PIM). Then UML and MDA tools can generate
a Platform-Specific Model (PSM) based on the architecture chosen and
(after some tweaking) produce the complete application.

This approach promises to free the development team from specific middleware
or platform vendors. When a new architecture paradigm appears - and it
will - the team can adopt it without going back to Square One for a complete
redevelopment effort. The combination of UML and MDA also promises to
free development teams from much of the coding work. Although the required
UML models are much more specific than most organizations are used to,
their use will change the way developers make systems.

With the advent of MDA and its allied technologies, UML becomes a sort of
executable blueprint - the descriptions, instructions, and the code for your
system in one package. Remember it all begins with UML.

Continues...




Excerpted from UML 2 For Dummies
by Michael Jesse Chonoles James A. Schardt
Copyright © 2003 by Michael Jesse Chonoles, James A. Schardt.
Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Read More Show Less

Table of Contents

Introduction.

Part I: UML and System Development.

Chapter 1: What’s UML About, Alfie?

Chapter 2: Following Best Practices.

Part II: The Basics of Object Modeling.

Chapter 3: Objects and Classes.

Chapter 4: Relating Objects That Work Together.

Chapter 5: Including the Parts with the Whole.

Chapter 6: Reusing Superclasses: Generalization and Inheritance.

Chapter 7: Organizing UML Class Diagrams and Packages.

Part III: The Basics of Use-Case Modeling.

Chapter 8: Introducing Use-Case Diagrams.

Chapter 9: Defining the Inside of a Use Case.

Chapter 10: Relating Use Cases to Each Other.

Part IV: The Basics of Functional Modeling.

Chapter 11: Introducing Functional Modeling.

Chapter 12: Capturing Scenarios with Sequence Diagrams.

Chapter 13: Specifying Workflows with Activity Diagrams.

Chapter 14: Capturing How Objects Collaborate.

Chapter 15: Capturing the Patterns of Behavior.

Part V: Dynamic Modeling.

Chapter 16: Defining the Object’s Lives with States.

Chapter 17: Interrupting the States by Hosting Events.

Chapter 18: Avoiding States of Confusion.

Part VI: Modeling the System’s Architecture.

Chapter 19: Deploying the System’s Components.

Chapter 20: Breaking the System into Packages/Subsystems.

Part VII: The Part of Tens.

Chapter 21: Ten Common Modeling Mistakes.

Chapter 22: Ten Useful UML Web Sites.

Chapter 23: Ten Useful UML Modeling Tools.

Chapter 24: Ten Diagrams for Quick Development.

Index.

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com 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 & Noble.com 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 & Noble.com 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 BN.com 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

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com 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 BN.com. 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

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