PPT UML (Unified Modeling Language)

advertisement
UML (Unified Modeling
Language)
Sources:
1. UML Toolkit. Eriksson, Hans-Erik; Penker, Magnus.
John Wiley & Sons, INC. 1998.
2. Program Development in Java. Liskov, Barbara;
Guttag, John. Addison-Wesley. 2001.
UML Tools


http://www.objectsbydesign.com/tools/um
ltools_byCompany.html is a good source of
tools available
TJHSST has “Dia”, which will be utilized.
Software Life Cycle







Requirements
Architecture Design
Detailed Design
Implementation (Coding)
Testing
Deployment
Maintenance
UML is concerned with
these two phases.
The Class Diagram

Drawn with a rectangle, divided into 3
compartments



Name compartment
Attribute compartment (Instance variables)
Operations compartment (Methods)
Class Diagram Example

Consider a Polynomial class (Poly)


Form: a1x0+a2x12+ …. Anxn-1n
Key attributes – terms and degree


Instance Variables : - means private variable;
+ means public variable
Underlined instance variables – static.
Poly
- trms[] : int
- deg : int
Name of class
Instance Variables
Methods will go here
Poly using “Dia”
Poly methods

Common things done to polynomials






return degree
return coefficient of corresponding exponent
Subtract two polynomials
Add two polynomials
Multiply two polynomials
Take the negative of a polynomial
Poly Class Diagram
Basic syntax: visibility name (parameter-list): return-type-expression
{property string}
Poly
- trms[] : int
- deg : int
+ degree(): int
+ coeff (d: int): int
+ sub (thePoly: Poly): Poly
+ minus (): Poly
+ add (thePoly: Poly): Poly
+ mul (thePoly: Poly): Poly
Name of class
Instance Variables
Methods will go here
Poly Implementation
public class Poly {
private int[] trms;
private int deg;
public Poly () {
// constructor goes here
}
public int degree { }
public int coeff (int d) { }
public Poly sub (Poly thePoly) { }
public Poly minus (Poly thePoly) { }
public Poly add (Poly thePoly) { }
public Poly mul (Poly thePoly) { }
Class Diagram Relationships




Association
Generalization
Dependency
Refinement
Class Diagram Relationships




Association
Generalization
Dependency
Refinement
Associations



A connection between classes.
Usually classes “know” about each other
(bidirectional.)
Name of association necessary (“Uses” in below
case.)
Author
Uses
Computer
Specifically, an author uses a computer;
hence, Author has an association with
Computer.
More Normal Associations
Person
1..*
Owns
Owned
by
Car
0..*
• A person owns 0-many cars. A car is owned by 1 to
many people.
• If relationships are not specified, then it assumed to be
1-1.
• Relationships can begin and end with any number ….
i.e. – can have 5..11 or 19..25.
• Relationships can be a multiple list – (1,4,6,8..12)
Another Normal Association
Example
1 has
Insurance Contract
Refers to
1..*
has
0..*
Refers
to
Insurance Company
0..*
Is
expressed
in an
Expresses
an
Insurance Policy
Customer
0..1
1
Object Diagram

A class diagram, but with a specific
instantiation
Author
name: String
age: Integer
Bob: Author
name = “Bob J”
age = 32
Computer
Use
0..*
name: String
1..*
mem: Integer
Bob’s PC:
Computer
name = “Dell 466”
mem= 64
Recursive Association


Class that calls itself.
Example: Network Nodes (Class Diagram)
*
Node
*
Connects
“Node” Object Diagram
Node1
Node2
Node3
Node4
Node5
Node6
Node7
Node8
Roles in Association

An association can have roles connected
to each class involved in the association.
Car
*
Company car
drives
*
driver
Person
Qualified Association


Used with one-to-many or many-to-many
associations.
Qualifier distinguishes among the set of
objects at the “many end” of an
association.
Canvas
figure id
*
Describes a unique identification for each figure (figure id)
Figure
“Or” Association


Occurs when all combinations in a model
are not valid.
Example:



A person can have an insurance contract with
an insurance company
A company can have an insurance contract
with an insurance company
A person and a company CANNOT have the
same insurance contract with an insurance
company.
“Or” Association Diagram
1
Insurance Company
0..*
Insurance Contract
0..*
0..*
{or}
1..*
Person
1..*
Company
Ordered Association


Links may have an implicit order.
Associations are unordered by default.
Standardized Insurance
Contract
0..*
{ordered}
1..*
Customer
Association Class



A class is attached to an association.
Not connected at any of the ends of the
associations.
Has attributes and operations also.
Association Class

Association “Queue” class.
Queue
Elevator Control
*
Button
4
Elevator
Ternary Association


More than 2 classes can are associated
with each other.
Shown with a large diamond.
Insurance Company
1
0..*
insurer
Insurance Contract
0..*
Insurance Policy
0.. 1
1..*
policyholder
Person
Aggregation




Special case of association
Relationship between classes is some sort
of “whole-part.”
Example: A CAR consists of 4 wheels,
engine, chassis, gear box, etc.
Shown as a line with a hollow diamond on
the end of it.
Aggregation Example
*
Navy
Warship
Contains
Excerpt from UML Toolkit: The navy contains warships. Warships can
be added or removed, but you still have a Navy. The hollow diamond
shows aggregation.
Shared Aggregation

The parts may be parts in any wholes
Team
*
*
Person
Members
A team has members. A person may be a member of many teams.
Remix
*
{ordered} *
Sound Clips
Contains
A remix has many sound clips; the same soundtrack could be a part of
many remixes.
Composition Aggregation


An aggregation that owns it parts.
I.E. – “Strong” ownership.
*
Text
Window
*
Listbox
*
Button
*
Menu
The window
contains (is
aggregated of)
many menus,
button, listboxes,
and texts.
Composite Aggregation
*
Window
Contains
*
Text
Listbox
*
Button
*
Menu
A different view of the same diagram on the previous slide.
Composition Aggregation (Yet
Another View)
Window
Text
Listbox
Button
Menu
*
*
*
*
Class Diagram Relationships




Association
Generalization
Dependency
Refinement
Generalization





Definition in UML: “A taxonomic (taxonomy is
the science of classification) relationship
between a more general element and a more
specific element.
More specific element is fully consistent with
more general element
More specific element contains more
information.
Also known as Inheritance.
“Is-a” relationship.
Normal Generalization




Subclass inherits everything from
superclass.
Attributes, operations, and all associations
are inherited.
Private members will be inherited, but not
visible to the subclass.
Protected members – accessible only by
subclass.
Class Hierarchy Diagram
Vehicle
Car
Boat
Truck
Another Class Hierarchy Diagram
Vehicle
Car
Boat
Truck
Abstract Classes



Not allowed to have objects.
Used only for inheritance
Described common attributes and
behavior for other classes.
Abstract Class Hierarchy Diagram
Person
drives
*
Vehicle {abstract}
color
drive () {abstract}
Car
drive ()
Boat
drive ()
Another Abstract Class Hierarchy
Diagram
Figures
*
Figure {abstract}
# position: Pos
draw () {abstract}
Group
draw ()
Polygon
draw ()
Java Implementation
Abstract public class Figure {
abstract public void draw();
protected Pos position;
}
public class Group extends Figure {
public void draw () {
for (int i= 0; i < consist_of.size(); i++) {
consist_of[i].draw();
}
private FigureVector figures; /* FigureVector is a specialized class
of the standard Vector class that implements a dynamic array.
FigureVector adds hard type checking */
}
Java Implementation (cont)
public class Polygon extends Figure {
public void draw () {
// draw polygon code
}
}
Overlapping and Disjoint
Generalizations


Overlapping – Further subclasses
inheriting from the subclasses in the
inheritance relationship can inherit more
than one of the subclasses (This is not
supported in Java – basically multiple
inheritance.)
Disjoint – Subclass are not allowed to be
specialized into a common subclass.

Is the default
Complete and Incomplete
Generalization


Complete – All subclasses have been
specified (i.e. – Final in Java)
Incomplete – Subclasses may be added
later on.


Generally the norm
The default
Example Complete Generalization
Person
{complete}
Man
Women
Class Diagram Relationships




Association
Generalization
Dependency
Refinement
Dependency Relationship



Semantic connection between 2 model elements
– one independent and one dependent
Changes in the independent element will affect
the dependent.
Examples



One class takes an object of another class
(Composition)
One class accesses a global object of another class
One class calls a class-scope operation in another
class.
Example Dependency Diagram
<< friend >>
Class A
Class B
•The dependency is shown as a dashed line with an
arrow
•The type of dependency is called a stereotype – in
this case, it is a friend dependency
Refinement


Relationship between two descriptions of
the same thing, but at different levels of
abstraction.
Can be between a type and class that
realizes it

Called a realization
Analysis class
Design class
Shown with a dashed line and a hollow triangle
Interfaces





Described as abstract operations.
In Java – the way to sneak around the inability
for multiple inheritance.
Shown as a small circle with a name.
Connected to its model element via a solid line.
A class that uses the interface as implemented in
a specific class is connected via a dependency
relationship to the interface circle.
Interface Diagram Example
Storable
Class A
Class B
Runnable
<<interface>>
<<interface>>
Runnable
Storable
{abstract}
{abstract}
run() {abstract}
Class C
Runnable
load() {abstract}
save() {abstract}
Class A implements the interfaces Runnable and Storable. Class C implements the
interface Runnable. Class B uses the interface Runnable and Storable from A, and
Runnable from C. The interfaces are specified as classes with the stereotype
<<interface>> and contain the abstract operations that the implementing classes must
implement.
Download