Table of Contents
Introduction.
Chapter 1. Review of UML.
Chapter 2. A Tour of Visio.
Chapter 3. Diagramming Business Objects.
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.
Index.
Read a Sample 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 omg.org.
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.
Continues...
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.
loading...