Professional UML with Visual Studio.NET: Unmasking Visio for Enterprise Architects / Edition 1

Paperback (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 96%)
Other sellers (Paperback)
  • All (14) from $1.99   
  • New (3) from $28.24   
  • Used (11) from $1.99   
Sort by
Page 1 of 1
Showing All
Note: Marketplace items are not eligible for any coupons and promotions
Seller since 2008

Feedback rating:



New — never opened or used in original packaging.

Like New — packaging may have been opened. A "Like New" item is suitable to give as a gift.

Very Good — may have minor signs of wear on packaging but item works perfectly and has no damage.

Good — item is in good condition but packaging may have signs of shelf wear/aging or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Acceptable — item is in working order but may show signs of wear such as scratches or torn packaging. All specific defects should be noted in the Comments section associated with each item.

Used — An item that has been opened and may show signs of wear. All specific defects should be noted in the Comments section associated with each item.

Refurbished — A used item that has been renewed or updated and verified to be in proper working condition. Not necessarily completed by the original manufacturer.


Ships from: fallbrook, CA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Seller since 2015

Feedback rating:


Condition: New
Brand new.

Ships from: acton, MA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Seller since 2015

Feedback rating:


Condition: New
Brand new.

Ships from: acton, MA

Usually ships in 1-2 business days

  • Standard, 48 States
  • Standard (AK, HI)
Page 1 of 1
Showing All
Sort by


What is this book about?

If you want to use Visio to create enterprise software, this is the book for you.

The integration of Visual Studio .NET Enterprise Architect and Visio for Enterprise Architects provides a formidable tool. Visio offers powerful diagramming capabilities, including such things as creating UML models, mapping out databases with Entity Relationship diagrams, and aiding the development of distributed systems. Its integration with Visual Studio .NET Enterprise Architect means that C# or Visual Basic .NET code can be generated from the UML diagrams, and Visual Studio .NET projects can be reverse engineered to UML models.

For the developer already familiar with UML and looking to get the best out of Visio, the Visual Studio .NET and Visio for Enterprise Architects combination is weakly documented, and the quality information needed to realize the time-saving features of Visio just does not seem to be available, until now.

This book presumes that you are already familiar with the basic concepts of UML notation — this book will not teach you UML. Instead, this book will take you forward into the Visio environment, showing you how to make the most of its software related features.

What does this book cover?

In this book, you'll learn how to

  • Diagram business components in Visio
  • Generate code from a UML model
  • Reverse engineer Visual Studio .NET projects into a UML model
  • Reverse engineer into a UML model without source code
  • Document the project with UML and Visio
  • Design distributed applications with Visio's diagrams
  • Work with Entity Relationship database modeling, and round-trip engineering for database design
Read More Show Less

Product Details

  • ISBN-13: 9780764543760
  • Publisher: Wiley
  • Publication date: 12/1/2002
  • Series: Professional Series
  • Edition number: 1
  • Pages: 360
  • Product dimensions: 7.22 (w) x 8.94 (h) x 0.78 (d)

Meet the Author

Andrew Filev is President of dotSITE Software. This company specializes in cost-effective development on the .NET platform. Andrew's team has been developing commercial solutions using .NET since the first public announcement of this new Microsoft strategy. Andrew set up one of the first .NET portals, and has held a number of seminars and lectures dedicated to .NET in state and private companies.
Andrew has implemented numerous solutions in various high-tech fields – Web Services, ERP applications, medical systems, development frameworks, among others. He can be reached at or

Tony Loton works through his company LOTONtech Limited ( as an independent consultant, course instructor, and technical writer. The current area of interest at LOTONtech is the enhancement of UML visual modeling tools – specifically Rational Rose and Visio for Enterprise Architects – to facilitate .NET application design. Further details can be found at
Tony graduated in 1991 with a BSc. Hons. degree in Compute r Science and Management and he currently holds an appointment as associate lecturer with the Open University in the UK.

Kevin McNeish is President of Oak Leaf Enterprises, a company that specializes in object-oriented developer tools, training, and software. He started his programming career twenty years ago working with Assembly Language, then moved to C, Visual FoxPro, and currently uses C# as his primary .NET development tool. He authored the book .NET for Visual FoxPro Developers and teaches both .NET and UML training classes in North America and Europe.
He has also written UML articles for CoDe, FoxPro Advisor, and FoxTalk magazines. Kevin, a Microsoft MVP, is the creator of a .NET business application framework called "The Mere Mortals Framework for .NET". He also mentors software companies in a variety of vertical markets to design and build component-based applications that scale from the desktop to the Internet. He can be reached at or

Benjamin Schoellmann credits his move to sunny Houston, Texas, with providing the inspiration necessary to pursue a development and writing career. Currently he is involved with evangelizing .NET technologies among his coworkers at Synhrgy HR Technologies. Among his favored activities are golfing, tinkering with his network, talking incessantly, and integrating hardware and software solutions, primarily home automation, to enhance his leisurely pursuit of Slack. He maintains several content-free WEB domains, including He is obsessive about keeping pace with emerging technologies, and is very quick to credit his developer friends with all his success in the IT field.

John Slateris a project manager at Management Reports International in Cleveland, OH. At MRI he is currently developing applications for the property management industry. Right now, he is working on several projects using .NET development tools and .NET Enterprise servers.
In his free time John enjoys outdoor activities and playing with his children Rachel and Nathan. He can be reached at

Chaur G. Wu currently works for Trend Micro Inc. as a senior software engineer. He started software programming before was old enough to qualify for a driving license. The first program he wrote was a bingo game – in assembly code on a 8051 single chip. To capitalize on the program, he ran a small casino in the lab – he developed primitive game boxes that connected his pals and allowed them to place bets.
He's also been involved in much larger projects. For example, he developed a program in C++ to simulate the movement and geographical coverage of GPS satellites. As a research assistant in his graduate study, he implemented a wavelet-based video compression algorithm for a traffic surveillance system sponsored by Boston City Department of Transportation. He also helped solve a blurred image problem using inverse filters and other image processing algorithms for a client who designs fiber optics components in San Jose, CA.
His technical interests include distributed software systems in Java, COM, and .NET, generative programming, software design, and neural networks. Outside of work, his favorite vacation combines a one-night gambling trip to Reno followed by a day of skiing at some resort near Lake Tahoe. You can e-mail Chaur at

Read More Show Less

Table of Contents


Chapter 1: Review of UML.

Chapter 2: A Tour of Visio.

Chapter 3: Diagramming Business Objects.

Deriving Classes from Use Cases.

Chapter 4: Generating Code from the Visio Model.

Chapter 5: Reverse Engineering.

Chapter 6: Documenting the Project.

Chapter 7: Distributed System Design.

Chapter 8: Database Modeling with Visio for Enterprise Architects.


Read More Show Less

First Chapter

Professional UML Using Visual Studio .Net

By Andrew Filev Tony Loton Kevin McNeish Ben Schoellmann John Slater Chaur G. Wu

John Wiley & Sons

ISBN: 0-7645-4376-8

Chapter One

Review of UML

The purpose of this chapter is to set the scene by reviewing the key UML concepts, the main diagram types, and the role of those diagrams within the software development process. If you're quite new to UML this will serve as a practical introduction that will help you make sense of the rest of the book, before you move on to further reading. If you're experienced with UML the chapter will serve as handy revision and you might just find some nuggets of information that have so far eluded you.

Either way we'll all be moving on from roughly the same starting point: with the same appreciation of UML notation, with an understanding of relevant software development processes, and with a common bias towards .NET and the Visio for Enterprise Architects tool.

The final point is quite important, and the raison d'être for this book. In recent years the body of UML literature has focused mainly on Java development and the use of modeling tools such as Rational Rose. In this book we're applying a .NET development perspective at the same time as demonstrating the so far under-documented Visio modeling tool that comes bundled with the Visual Studio .NET Enterprise Architect.

With all this in mind we can now press on with the introduction to - or revision of, depending on your background - the Unified Modeling Language.

What is the Unified Modeling Language?

When discussing UML, we need to establish one important point right up front.

The Unified Modeling Language is a notation; that is a set of diagrams and diagram elements that may be arranged to describe the design of a software system. UML is not a process, nor is it a method comprising a notation and a process.

In theory you can apply aspects of the notation according to the steps prescribed by any process that you care to choose - traditional waterfall, extreme programming, RAD - but there are processes that have been developed specifically to complement the UML notation. You'll read more about the complementary process(es) later in this chapter.

Why use UML?

Hidden inside that specific question there's a more generic question, which is "Why use a formal analysis and design notation, UML or otherwise?" Let's start to answer that question by drawing an analogy.

Suppose you wanted to make a bridge across a small stream. You could just place a plank of wood across from one side to the other, and you could do so on your own. Even if it failed to hold your weight, the only downside would be wet feet.

Now suppose you wanted to make a bridge across a narrow river. You'd need to do some forward planning to estimate what materials you'd need - wood, brick, or metal - and how much of each. You'd need some help, and your helpers would want to know what kind of bridge you're building.

Finally, suppose you wanted to build a bridge across a very wide river. You'd need to do the same kind of forward planning as well a communicating your ideas to a much bigger team. This would be a commercial proposition with payback from fare-paying passengers, so you'd need to liaise with the relevant authorities and comply with health-and-safety requirements. You'd also be required to leave behind sufficient documentation to allow future generations to maintain the structure long into the future.

In a software context, this means that formal design becomes increasingly important as a function of the size and complexity of the project; in particular, as a function of the number of people involved. Based on that analogy, and wider project experience, we could conclude that a formal design notation is important in:

Establishing a blueprint from the application

Estimating and planning the time and materials

Communicating between teams, and within a team

Documenting the project

Of course, we've probably all encountered projects in which little or no formal design has been done up-front (corresponding with the first three bullet points in that list); in fact more projects than we care to mention! Even in those situations, UML notation has been found to be invaluable in documenting the end result (the last bullet point in that list). Though not recommended, if that's the extent of your commitment to UML you'll be most interested in the Reverse Engineering discussion in Chapter 5.

Now that we've answered the generic question, let's return to the specific question of why use UML?

Well it's become something of an industry standard, which means that there's a good chance of finding other people who understand it. That's very important in terms of the communication and documentation bullet points in our list. Also if you or anyone else in the team does not understand it, there's a good chance of finding relevant training courses, or books like this one.

That's very pragmatic reasoning and perhaps more convincing than a more academic (or even commercial) argument such as:

"The application of UML has a proven track record in improving the quality of software systems."

A Brief History of UML

Taking the phrase Unified Modeling Language as our starting point, we've discussed in the previous section the "language" (namely, notation) aspect. In the next section, we'll investigate the "modeling" aspect, which leaves us here with the word "unified". What, or who, preceded the UML and how did it all become unified? This will become clear as we step through a brief history of UML.

In the beginning although there was a plethora of object-oriented "methods", there were three principal methods:

The Booch method devised by Grady Booch

Object Modeling Technique (OMT) devised by Jim Rumbaugh

Object Oriented Software Engineering (also known as Objectory) devised by Ivar Jacobson

These three methods have many ideas in common, yet different notation for expressing those ideas. Some of you may remember that in an OMT class diagram the classes were represented as rectangular boxes whereas in the Booch method they were represented as stylized cloud shapes. Also, each method placed emphasis on different aspects of object-oriented software development. For example Jacobson introduced the idea of use cases, not addressed by the other methods.

The unification of these three methods combined the best bits of each method with a common notation (UML) for the common concepts - the end result being an industry-standard notation for analysis and design. If you speak with anyone who claims to be doing object modeling, chances are they'll be using UML.

So how did this unification play out in time? The key dates are:

OOPSLA '94 - Jim Rumbaugh leaves General Electric to join Grady Booch at Rational Software, so as to merge their methods and achieve standardization across the industry.

OOPSLA '95 - Booch and Rumbaugh publish version 0.8 of the Unified Method. Rational Software buys Objectory and Ivar Jacobson joins the company.

January 1997 - Booch, Rumbaugh, and Jacobson (the three amigos) release - through Rational - a proposal for the UML version 1.0.

September 1997 - UML version 1.1 is adopted by the Object Management Group (OMG).

The Object Management Group, previously best known for the CORBA standard, is a non-profit organization - comprising many member companies - that encourages, standardizes, and supports the adoption of object technologies across the industry. You can find out more about the OMG at

If we've given the impression that the Unified Modeling Language is the exclusive work of only three contributors, the three amigos, then let's set the record straight. Some of the concepts are based in the early work of other individuals - for example, David Harel's work on Statechart diagrams - and some further enhancements have come from other member organizations of the OMG; for example, the Object Constraint Language (OCL) devised by IBM.

OCL was devised so that additional rules could be added to a UML model in a language that less ambiguous than English. For example, the statement "Person.Employer=Person.Manager.Employer" may be less ambiguous than "a person and their manager must both work for the same company."

At the time of writing, the UML specification is at version 1.4 and in mid-2001 the OMG members started work on a major upgrade to UML 2.0. Modeling tools - including Visio for Enterprise Architects - will always be one or two steps behind in their support for the specification, but that's not usually a big problem because the core concepts discussed in the next section are now quite mature and stable.

At the time of writing, the version of Visio for Enterprise Architects used in the construction of this chapter provides support for UML at least up to version 1.2 - this can be determined from the About error checking in the UML model section of the Microsoft Visio Help:

"Semantic error checking occurs automatically, noting errors in the design of UML model elements, based on the well-formedness rules in the UML 1.2 specification."

End-to-End UML Modeling

Having looked at why UML is useful, and where it came from, we'll now look at the notation itself. To cover the complete notation in a single chapter would be impossible, so for a deeper coverage I'll refer you to some other works.

Instant UML by Pierre-Alain Muller (Wrox Press, ISBN 1-86100-087-1).

The Unified Modeling Language User Guide by Grady Booch, James Rumbaugh, and Ivar Jacobson (Addison Wesley, ISBN 0-201-57168-4).

UML Distilled by Martin Fowler with Kendall Scott (Addison Wesley, ISBN 0-201-65783-X).

What we'll do here is cover the essential notation and core concepts that will allow us to progress through the rest of the book with a common understanding.

We'll also aim to address one of the problems of many UML courses and books. The problem being, that all too often the various diagrams are presented in isolation without a clear indication of how they relate to one another. To make matters worse, different examples are often used to demonstrate the different diagrams, not one of those examples being for a system that you might actually want to build. Think here of a statechart diagram that describes a motor car gearbox, or a sequence diagram that describes the operation of a hotel elevator.

So in the following section we'll have a single example, an Order Processing system, which you should be able to relate to even if you don't intend to build such a thing, and at the end, we'll pull it all together.

UML Essential Notation and Core Concepts

Now we'll step through the UML diagrams in turn, all the way from an activity diagram through to a deployment diagram in this order:

Activity Diagram

Use Case Diagram

Sequence and Collaboration Diagram

Statechart Diagram

Static Structure Diagram

Component Diagram

Deployment Diagram

Each diagram is labeled in light gray with some of the names given to the UML elements that are shown, which - for the record - reflects the UML metamodel.

On the whole, the model elements have been labeled using Visio EA terminology so as to reduce the potential for confusion when you come to use the tool. Historically - and in other modeling tools - you may have encountered alternative UML terminology. The alternative terms have been tabulated towards the end of this chapter.

As you'll see later in this chapter, the software development process that you follow might well be described as use-case driven, which implies the use case diagram as an obvious starting point. But those use cases will doubtless fit into some kind of overall business process, perhaps modeled up-front by a business analyst. So we'll take a business process as our starting point and use this as a vehicle for demonstrating the most suitable diagram for that purpose; the activity diagram.

Activity Diagram

The activity diagram is the closest you'll get in UML to a flow chart, and the closest you'll get to a business process diagram. Here is a sample activity diagram with the important UML elements labeled, followed by a description of those elements.

Initial state is where the diagram begins.

Control flow shows a transfer of control from one activity to another.

State represents a period of time during which a piece of work is carried out by person or team.

Transition (fork) shows the point as which two or more parallel activities will commence.

Transition (join) shows the point as which two or more parallel activities must synchronize and converge.

Swim lane allows all of the activities carried out by a particular person or team arranged into a column.

Entry action shows what must happen when the activity begins.

Object in state shows an object that is produced or consumed in the course of an activity, with the production or consumption (object flow) being represented by the dashed line.

What the diagram shows

The Order Processing business process begins when an Order Clerk performs the Take Order activity. This activity results in an Order object being created in unpicked state. Next, the Pick Stock activity is performed (for the Order) by the Logistics team.

At this point some parallel behavior occurs - the Logistics team Deliver Item(s) around the same time that the Accounts department Prepare Invoice. Only when the items have been delivered and the invoice has been prepared can the Accounts department then Send Invoice. Immediately prior to sending the invoice they must Print Invoice.

Those are the essential points of an activity diagram, but not a complete coverage. In particular you will see some additional syntax in the description of a Statechart diagram.

Use Case Diagram

Here is a sample use case diagram with the important UML elements labeled, followed by a description of those elements.

Actor represents a person or external system that initiates a use case in order to get some value from the application.

Use case is a well-defined unit of functionality that the system provides to one or more actors.

Communicates shows that a particular actor makes use of a particular use case.


Excerpted from Professional UML Using Visual Studio .Net by Andrew Filev Tony Loton Kevin McNeish Ben Schoellmann John Slater Chaur G. Wu 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

Customer Reviews

Be the first to write a review
( 0 )
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

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