Transcript Unified Modeling Language - Colorado School of Mines

Unified Modeling Language
UML
Much of the information in this presentation is
adapted from Wikipedia
Open Source Software
 DIA can be used to create UML diagrams
 http://dia-installer.de/download.html
 You may want to start the program, if you like to follow
along.
Example
Example
Example
Questions you may ask…
SO, you need to get up to speed in a hurry on an existing
system. OR, you want to quickly communicate the overall
design of a system (i.e., the system architecture*) to other
programmers. What’s important to know?
 What classes are involved?
 What’s the purpose of each class? (what methods can I call
so the class “works” for me)
 What’s the relationship between classes?
* covered in more detail during field session
What is UML?
 The Unified Modeling Language (UML) is an open method
used to specify, visualize, modify, construct and document
the artifacts of an OO software project.
 UML 1.0 Spec proposed in January 1997
 UML 1.1 adopted in November 1997
 UML 2.0 adopted in 2005
What is UML (continued)
• UML is not a development method. It is compatible with
leading OO software development methods.
• System model includes diagrams + “semantic backplane” –
written use cases etc.
• UML diagrams represent two views of system model:
– Static structure of the system using objects, attributes,
operations and relationships. The structural view includes class
diagrams and composite structure diagrams.
– Dynamic (behavioral) behavior. Shows collaboration among
objects and changes to system state, represented via sequence
diagrams, activity diagrams and state machine diagrams.
UML – How?
UML 2.0 has 13 types of diagrams divided into 2 categories
We’ll only study Class Diagrams, State Machine Diagram also useful.
Let’s try DIA
 Be sure you’re in UML mode
 Use tool tips to identify buttons
 Select Class icon
switch to
UML
 Click to place on diagram
 Double-click to edit details
 We’ll primarily use Attributes and Operations
 (you think of these as variables and methods)
Class Diagram
 Shows system classes, attributes, relationships among classes
 Class diagrams are static -- they display what interacts but not what
happens when they do interact.
Class name at top of diagram
Attributes in next section.
# indicates protected, - indicates private
+ indicates public, ~ indicates package
Methods (operations) in bottom section. + indicates public., - indicates private.
Common to omit getters/setters
Another class
Attributes may specify a type
Class variables (i.e., static) are underlined
Accessibility is indicated with +, -, #
Parameters (with optional types) can be specified
Translating to code
public class Student {
protected String name; // type not in UML
private String address; // make reasonable
private String email; // assumptions
public boolean isEnrolled() {
return true;
} // body not specified, return needed to compile
}
public class GamePanel {
public static final int CELL_SIZE = 20;
private int whoseTurn;
public void drawBoard (Graphics g) { }
}
final is a low-level detail, no consensus on whether/how to represent in UML
How do we know it’s final? Class convention of ALL_CAPS
Why are we doing this again?
 It’s good to think about the high-level structure of your
program before you begin to code.
 If only two classes in your system, probably not needed.
 What if you have 20 interacting classes?
How am I supposed to
figure this out??!!
But how do these classes work
together?
 Need to specify relationships between classes
 Inheritance. Also called generalization and specialization.
• Association.
• Means an instance of one class can send a message to an instance of another.
Class sending the message must have access to the receiver (e.g., via a
pointer, reference etc).
• Aggregation. Whole/part relationship. (e.g., car has 4 wheels; wheels
may outlive car). May be called a “has-a” relationship.
• Composition. Like Aggregation except lifetime of ‘part’ must match
lifetime of ‘whole’ (e.g., car has a carburetor)
 Dependency
 One class relies on another, but doesn’t contain a variable.
Composition and Aggregation are types of associations; distinction is not that critical.
Inheritance in UML
 Called a generalization relationship
General
Open triangle, points to parent
Specific
HINT: To remember direction, think that a child has only one parent, a parent
may have many children. Our diagram has only one arrow – must point to
parent.
Translate to Code
public class Book {
private String title;
private String author;
}
public class Textbook extends Book {
private String course;
}
public class Dictionary extends Book {
private int numWords;
}
NOTE: We do not repeat Title and Author in the child classes…
instance variables are all inherited –
GENERAL RULE: Don’t clutter the diagram!
Here’s an association in code
public class Student {
public class Dog {
private String name;
public void bark() {
private Dog dog;
System.out.println("Woof");
}
public Student(String name){
dog = new Dog();
}
public void takeAWalk() {
dog.bark();
}
}
}
Note that Student has a variable of
type Dog – but it does not appear in
the UML as an attribute. Why?
How does this help us design?
Functions are put in various classes. Where does the functionality live?
How can our classes work together to create a solution?
UML relationships
Association.
• Arrow indicates navigability.
• Include arrow if unidirectional
• If no arrows, indicates bidirectional
• May have multiplicity (e.g., 0 .. *)
• May have role (e.g., subscriber)
Here’s an aggregation in code
public class Car {
private ArrayList<Wheel> wheels;
}
Note the open diamond
attached to the owner.
public class Wheel {
}
We will not make the distinction between aggregation and composition –
these look no different in code.
Enumerated type + code +
dependency
Dotted line is a dependency.
• Weaker association.
• Notice WeekendDays is a parameter, but not an attribute.
public enum WeekendDays { SATURDAY, SUNDAY }
public class Event {
public void addParty(String name, WeekendDays day) { … }
}
Abstract Classes, Interfaces and Static
 Abstract class and method names are normally italicized (must set the
Properties -> Style in DIA)
 An interface is a stereotype, show inside << …>>
 Indicate static methods/variables with a $ or underline
Translate to Code
public abstract class Shape {
private int x, y;
public abstract void draw();
}
public interface Comparable {
public int compareTo(Object o);
}
public class Book implements Comparable {
private String title, author;
public int compareTo(Object o) { …. }
Bookstore Example
Package Example
Note that sometimes we just want class names – in DIA, uncheck Attributes
visible and Operations visible
Another Example