Software systems are very complex and hard to understand
Models are abstractions of systems:
They express certain aspects of the system and ignore
others
They are less complex and easier to understand
Models can make certain aspects more clearly visible than in
the real system
What can you do with models?
Express your ideas and communicate with other engineers
Reason about the system: detect errors, predict qualities
Generate parts of the real system: code, schemas
Reverse-engineer the real system to make a model
What is UML?
UML was standardized between 1995 and 1997 by Rational, IBM, HP,
Microsoft, Oracle, MCI, Unisys, DEC, and others
UML is the Unified Modeling Language:
Unified existing approaches to OO design notations: Booch, OMT,
Objectory, and Statecharts
Unified notation used in multiple phases of development:
Requirements, design, and implementation
Unified industry interest, training, and skills/job market
The UML notation consists of:
Class diagrams
Object diagrams
Use case diagrams
Collaboration diagrams
Sequence diagrams
Statechart diagrams
Activity diagrams
Component and deployment diagrams
UML Modeling Levels:
User data: Instances of objects in your running program
Model: Diagrams that we will learn
Metamodel: The data structure inside UML tools
Meta-metamodel: Language used to define metamodel
When to Use Each Type of UML Diagram
Abstract
Concrete
Interaction w/ actors
Activity
Use cases
Structure
Class
Object
Behavior
Statechart
Collaboration, Sequence
Deployment
Component
Deployment
What are Structural Diagrams?
Structural diagrams are the most important and widely used part
of UML. If you say "UML", most people think of structural diagrams
first.
Structural diagrams are class diagrams and object diagrams
Class diagrams represent the object-oriented code in your
system. They define all possible runs of the program.
Object diagrams give specific examples of one possible run of
the program with specific data.
Class diagrams can be used in requirements to express your
understanding of the real-world problem and to define the meaning of
words you use in your proposed solution. These diagrams do not use
many of the details of the UML notation.
In design, class diagrams often have more detail and use more
aspects of the UML notation.
Implementation may still diverge from design by adding more
detailed information. Not every detail of the implementation needs
to be shown in the design, but important aspects should be.
Elements > Classes and Interfaces
A UML class corresponds to a Java class. A UML Interface
corresponds to a Java Interface. Every operation in an interface
must be abstract.
Classes and interfaces are drawn as boxes.
The box can have up to three compartments
The top compartment has the name of the class or interface
Names of interfaces are marked "<<interface>>"
Names of abstract classes are written in italics
The lower to compartments are optional and contain attributes
and operations
Each class can have instances when the program is run. The
values of variables in those instances must fit the types defined in
the class.
Regular class:
ClassName
Attrbutes
Operations
Abstract class:
ClassName
Attrbutes
Operations
Interface:
<<interface>>
InterfaceName
Attrbutes
Operations
Elements > Attributes
Attributes correspond to instance variables in Java.
Use attributes for simple data types that are predefined, e.g.,
String, int, Integer, boolean, Boolean, Date, float, or arrays of
these.
Generalizations correspond to the Java keyword "extends"
Generalizations are drawn with a solid line and a white
triangular arrow touching the superclass.
Realizations correspond to the Java keyword "implements"
Realizations are drawn with a dashed line and a white triangular
arrow touching the interface.
It is common practice to arrange the diagram so that:
Generalization and Realization arrows point upward
If one class has many subclasses, the Generalization arrows overlap
UML itself is not restricted to single inheritance. However,
you would not use multiple inheritance if you plan to implement in
Java.
Elements > Associations
Associations denote possible relationships between instances of
classes. One way to implement associations is with variables in
instances of one class that point to instances of another
class.
Associations are drawn as a solid line between classes. A class
may also have an association with itself. Associations can be
labeled with a meaningful name in the center of the line.
At each end of an Association, there can be specific information
about the role that class or interface plays in the relationship:
Role: the role this class plays in the relationship. E.g., in
a "marriage" relationship, one Person plays the role of "husband"
and one is "wife."
Multiplicity: Determines the number of instances of this class
that are in one relationship.
* means any number
0..1 means zero or one
1..4 means one to four
4..* means four or more
25,50 means exactly twenty-five or fifty
When multiplicity is more than 1, the system must be
implemented using arrays, List, Set, etc.
Aggregation: Some relationships imply containment (a whole-part
relationship).
Some operations will be recursively applied to the parts of a
whole
Aggregate = White diamond: parts can join the whole and later leave; one
part could be part of more than one whole.
Composite = Black diamond: parts are created with the whole
and stay with exactly one whole until both are destroyed together.
To remember the difference: think of your hand being composed
of fingers, and your hand holding rings. Your finger could have a
tattoo of a black diamond. A ring has white diamond stone. You
can buy and sell rings, and you can hold one ring in both hands.
A hand always has the same fingers. If I raise my hand, the
fingers and rings are also raised (this is recursion).
Navigability: Shows which direction operations may follow the
association.
No arrow heads or double arrow: bidirectional
Stick arrowhead at one end: operations can follow association
toward that class, but not the other way
Elements > Dependencies
A dependency corresponds to one Java class mentioning the name
of another Java class. E.g., to call a static method in that
class.
A dependency is drawn as a dashed line with a stick arrowhead.
You do not need to show all dependencies between classes. Just
show the ones that are important, and not already implied by
associations.
Elements > Constraints
Some important meaning is already built into the UML syntax:
type names, multiplicity, aggregation. E.g., a truck has 4..18
wheels.
You can make your models more precise by writing conditions that
constrain the system to only be what you want it to be.
We will talk about constraints and OCL later
Elements > Objects and Links
Object diagrams show actual instances of classes, not the classes
themselves.
Object instances are boxes with one or two compartments:
name: Class
attribute = value
Links are pointers between objects.
Links are drawn as solid lines.
Examples
See demonstration in lecture or diagrams in books or on the Internet.