Summary

Chapter 1 - Review of UML
byAndrew Filevet al.?
Wrox Press ©2002

	Team FLY

In this chapter we've introduced the Unified Modeling Language in terms of what it is (an analysis / design notation) and what it is not (a software development process). We said that the notation represents a synthesis of three predecessor methods - Object Modeling Technique (OMT), the Booch Method, and Object-Oriented Software Engineering (OOSE) - with contributions from some others.

In terms of why you might use UML at all, we offer four main reasons:

• Establishing a blueprint from the application

• Estimating and planning the time and materials

• Communicating between teams, and within the team

• Documenting the project

The remainder of the chapter was divided into two main sections, End-to-End UML Modeling dealing with the UML notation and Process Essentials dealing with the companion process(es). Let's now review the modeling and process sections.

Modeling Summary

In this section, we looked at seven UML diagram types:

• Activity diagrams

• Use Case diagrams

• Sequence diagrams

• Collaboration diagrams

• Statechart diagrams

• Component diagrams

• Deployment diagrams

Each kind of diagram was annotated with the UML metatypes such as actor, use case, class, dependency, association, and so on.

Each diagram represented a different view of exactly the same application, so that you could relate the diagrams to each other with the help of the What this diagram shows sections. We consider the relationships between the diagrams to be so important - and all too often ignored - that we placed further emphasis on this point in the Fitting the Pieces into the UML Jigsaw section.

Finally, we suggested that you will almost certainly be doing UML modeling with a dedicated modeling tool, and that doesn't just mean a good drawing tool. Visio for Enterprise Architects represents such a modeling tool, no longer just a drawing tool, that we set out as the preferred tool on which the rest of this book has been based.

In the main, Visio terminology has been used in this chapter so as to avoid confusion when you come to use the tool. Other modeling tools may use slightly different terminology and, in fact, the UML terms themselves have changed slightly over the years. To help with the transition to - or from - other books and tools, here is a summary of this chapter's Visio UML terms and the alternative terminology that you may encounter:

Visio Terminology	Other Terminologies
Static Structure Diagram	Class Diagram
Package	Category
<<uses>>	<<import>>
State	Activity (on Activity Diagram), State (on Statechart)
Statechart Diagram	State Transition Diagram
Transition (fork)	Synchronization (start)
Transition (join)	Synchronization (end)

Process Summary

As to which software development process you should adopt, two were picked out two for discussion. The Unified Process, because it's the natural companion for the Unified Modeling Language, and the Microsoft Solutions Framework, because it's the Microsoft process offering. What these have in common with each other - and with other good object oriented software processes, such as the Select Perspective - is that they are:

• Iterative and incremental

• Use-case driven

• Focused on Risk Management

You also have a choice of eXtreme Programming, traditional waterfall, or RAD, and as the UML notation is independent of the process, ultimately the choice is yours.

In the next chapter, to complete our foundations for working with Visio for Enterprise Architects, we'll take a tour of the Visio environment and look at some of the available diagram features relevant to the software developer.

	Team FLY