Introduction to UML with Together and Java

Borland Conference Talk 1584

by Charlie Calvert

Overview

• Now that object-oriented programming has become the norm for most developers, the next step is learning how to properly architect your applications. Experience has shown that the best architectures often emerge from a process of iterative development. The best applications are not simply made, they are grown. Learn how to use the principles of refactoring to allow your application to evolve on top of a robust code base that supports the best object-oriented practices. Following techniques outlined by authors like Kent Beck and Martin Fowler, learn how to develop classes that are easy to reuse and maintain. Also learn to recognize classic bad practices and how to use refactoring to morph poorly designed code into robust, reusable classes that are easy to maintain.
• This document maintained at http://www.elvenware.com/charlie/index.html

Unified Modeling Language

• Helps developers understand complex systems
• Helps them state requirements for a program
• Helps them find the right design for a system. You can change a model more easily than a complete program.
• In source code, you see one class at a time. In a diagram, you can see several. You see relationships.
• You can generate simulations or the main classes for a project from a UML model
• You can document a project, or part of a project with the UML

Books and Articles

• UML Distilled by Martin Fowler
• The Elements of UML Style by Scott Ambler
• Agile Modeling by Scott Ambler
• The Unified Modeling Language Reference Manual, 2nd edition, Rumbaugh et al. Unreadable, but a good reference. Lean from other books, but if you already know the subject, go to this one to resolve disputes.
• The Unified Modeling Language User Guide, by Grady Booch et al.

History

• There were many schools of thought about diagramming
• Three of the most famous leaders of these schools came together to form the UML.
• The Three Amigos: James Rumbaugh, Ivar Jacobson, Grady Booch.
• Task complete by late nineties.
• UML Version 2.0 out this year.

The Key Word is Model

• A model is a simplification of a real object. It is a description of an object, not the object itself.
• Grady Booch says, "A model is a simplification of reality."
• A model can help you visualize and understand a complex system.
• A model can help you describe the architecture of a complex program.
• Often models emphasize the main features of a package, algorithm, or program, and leave out the details.
• This is the solution when you "can't see the forest for the trees."
• The goal is to outline or simplify your program, not to duplicate it line by line in pictures.

The Blueprint Analogy

• Grady Booch points out that you don't need blueprints to build a doghouse, but you do to build a skyscraper.
• Software is complex, and you need some way to describe it.
• UML is a technology for describing the architecture of an application.
• It can provide a set of blueprints that a developer can follow
• It can provide a language so that an architect can see if ideas make sense.

Visualize, Specify, Guide and Document

• Use UML to help you visualize a complex system.
• Use UML to help you specify the features or structure of a system
• Use UML to give developers a plan to follow when they implement a program
• Use UML to document an existing program.
• Uml is a artifact of program development, not the program itself.

UML is Abstract

• Some of the tasks listed in the previous section are rather abstract by nature.
• UML is not a visual counterpoint of a computer language such as C++ or Java.
• It is possible to very precisely define the intent and structure of a computer language
• The UML is more abstract. it is meant to help you model reality, not define it precisely. The precise model of reality is reality itself. The precise model of a program is the program itself. If that's what you want, then go to the program. But the UML is more abstract.
• The UML can be very precise about requirements, or about some small subsystem inside a larger system, but it is not really meant to accurately describe a whole system.
• The UML is what you want it to be. If that makes you uncomfortable, you are probably working with the wrong technology.

UML is not a Programming Language

• This is a subject over which there is some controversy.
• However, I personally do not want to use UML to implement the details of a program.
• The developers of UML did not think of UML as a programming language. More precisely, they said: "UML is not primarily a programming language.. it lacks the syntactic and semantic conveniences that most programming languages provide..." [The Unified Modeling Language Reference Manual, 2005, page 4].
• I want to use it to model a program, to describe it.
• If I am writing a technical article, I want to use UML to help illustrate key points.
• I want to use UML to help solve or document programming problems.
• Do you want to use UML to create a linked list or a stack?

UML is not a Programming Methodology

• XP and Agile are programming methodologies. So are object oriented and structured programming.
• The UP, Unified Process, aka the Rational Unified Process, is a methodology.
• Top down or bottom up are types of programming strategies.
• UML is not meant to promote a particular methodology or strategy.
• UML provides a common modeling language that can be used to describe computer methodologies, programs, architectures, or computer related systems of any type.

UML is Huge

• UML is so large that few people can hope to grasp it in its entirety.
• Fortunately, you do not need to know everything about UML to use it.
• It is possible, and quite common, for people to know only one or two diagrams, and yet still use them effectively.
• Some features of UML, such as use case diagrams, are meant to be very simple and easy to use.
• Other features, such as sequence diagrams, are more complicated. But even a subset of the sequence diagram notation can be useful.
• This is not always a precise science. UML is meant to be helpful, it can be a loose, informal way of talking about a more rigorously defined system.
• Learn to play with UML.
• It's big, and sometimes its messy. However, it is also very useful.

The Interface

• Accessing Together from JBuilder
• Finding the help files
• The parts of the IDE: content, project, structure and message panes
• Round trip engineering
• Language vs Design Mode
• Other ways to tweak the environment
• Toolboxes
• Choose View | Panes | Model Navigator
• Choose View | Panes | Diagram Navigator
• Bring up the Inspector

Demo

• Create a new project
• Show packages and drilling down into packages
• Show renaming packages
• Create a new class called MyClass
• Put MyClass in a new package called filestuff
• Create an association between MyClass and Frame1
• Create a new diagram and show the relationship line between Frame1 and MyClass

Diagrams

• The rest of this outline covers types of diagrams
• First we cover Use Case Diagrams
• Then I cover a set static diagrams, including class, package and object.
• Lastly there are three behavioral diagrams: sequence, collaboration and state machine
• Only three types of diagrams generate code: class, sequence and collaboration (communication)

Use Case Diagram Overview

• Primarily used to define requirements.
• They also document the functionality of a program.
• Can help define the scope of a project
• Participants: Actors, Use Cases, System Boundaries
• The Use Case element is a doing element, give it a verb name: Buy Food, Create Purchase Order.
• Relationships: Associations, generalizations
• Stereotypes: <<include>>, <<extend>>, <<system>>

Use Case Examples

Feed Cat (Click picture to expand)

Speaker (Click picture to expand)

Project Manager (Click picture to expand)

Use Case Associations

• If an actor initiates a relationship with a use case, or trades information, then it has an association with that use case
• Arrows define who starts a relationship, not the direction in which information travels. Use them sparingly

Use Case Tips

• Include System Boundaries only if useful
• Never have more than two layers of <<include>> relationships
• Mark actors that are not people or organizations with the <<system>> stereotype. They are machines or programs

Two Main Types of Diagrams

• Technical writers often make a distinction between Static and Behavioral diagrams.
• This division is somewhat arbitrary, and differs even among the three amigos.
• So don't get too hung up on the division, but use it if it is helpful.
• Static diagrams are about the structure, the architecture of a program.
• Behavioral diagrams are about the dynamic features of a program that change over time or that interact with one another. In other words, it include method calls and various forms of messages.

Static Diagrams

• Class
• Package
• Object

Class Diagrams

• There is more than one type of class diagram.
• Design based class diagrams show a relatively detailed view of each member of a class.
• Analysis based class diagrams don't include attributes and operations, but only responsibilities.
  • A ShowTime design class would have showDate:DateTime.
  • A ShowTime analysis class diagram would just have Show Date.
• Like a Use Case Diagram, you can use this tool for specifying requirements

Class Diagrams: Two Types

• You can draw a class diagram with operations or attributes in three boxes,
• You can put only a single box and one name, leaving out the attributes and operations

Class Diagram Visibility

• Use these symbols only in design based class diagrams.
• Public: A Plus symbol: +
• Protected: A hash (pound) mark: #
• Private: A Minus symbol: -
• Package: A tilde: ~

Class Diagram Relationships

• Model important relationships, not all relationships
• Generalizations (Inheritance)
• Implementations (Implement an interface)
• Associations (One class is a field of another class)
• Dependencies (A relationship not covered by any of the above.)

Class Diagram Associations

• Associations and attributes are two ways of showing the same thing.
• Use association syntax when the user needs to see the model of both classes, attributes when you need to see only one class.
• For instance, there is no need to see a String class, or class with which the user is already very familiar. So use an attribute.
• Associations are usually binary, that is, a relationship between two classes
• N-ary relationships occur, but are not covered in this talk.

Class Example Diagram

• It helps to say the relationships outloud.
  • A marina harbors zero or more boats
  • A boat is harbored in one marina
  • A sailboat may have a motor
  • A motorboat has one or two engines
  • A motor is part of one motorboat
  • A motor may be part of one sailboat
  • A sailboat is a type of boat
  • A motorboat is a type of boat
• So which is clearer to you? The diagram or the sentence? Do they complement one another?
• Note that this is only one of many possible relationships between marinas, boats and motors.
• This describes one particular relationship, but other relationships are possible.

Class Diagram Dependencies

• Associations and Generalizations are types of dependencies
• If you don't have a reason to call a relationship an association or a generalization, then it is a dependency. (UML Ref, p. 62)

Class Diagram Multiplicity Symbols

• Multiplicity

  Value	Interpretation
  0..1	Zero to one
  0..*	Zero or more
  0..n	Zero to n
  1	One
  1..*	One or more
  1..n	One to n
  n	Some fixed number n
  n..m	n to m, all positive
  n..*	n or more

Class Diagrams and Interfaces

• There are two ways to show interfaces.
• One is a lollipop diagram
• The other is a class diagram with a dashed line and closed arrow head.
• The lollipop is preferred.
• Put your interfaces on one diagram and your classes on another and uses lollipops. This cuts down on clutter.
• Do not include details of interfaces inside the class that implements them.

Behavioral Diagrams

• Communication (formerly Collaboration) and Sequence Diagrams
• Activity Diagrams
• State machines

Sequence Diagrams

• Sequence diagrams are dynamic.
• They talk about the order in which changes occur over time.
• In short, they are about methods and messages.
• Together can reverse engineer sequence diagrams

Sequence Diagram Example

• This simple example shows a user pressing a button and causing a dialog to be displayed.
• Event 1: This cause the jButton1Click method to be called
• Event 1.1: jButton1Click creates an instance of MyClass called myClass
• Event 1.2: jButton1Click calls myClass.showMessage("My data");
• Event 1.2.1: showMessage called JOptionpane.showMessageDialog.