COMS W4156: Advanced
Software Engineering
Prof. Gail Kaiser
Kaiser+4156@cs.columbia.edu
http://york.cs.columbia.edu/classes/cs4156/
01 November 2007
Kaiser: COMS W4156 Fall 2007
1
Reprise: What is UML?
• UML = Unified Modeling Language
• A standard language for specifying, visualizing,
constructing and documenting software artifacts
• Standardized by Object Management Group
(OMG)
• Uses mostly graphical notations (blueprints)
• Helps project teams communicate, explore
potential designs, and validate the requirements
and architectural design of the software system
01 November 2007
Kaiser: COMS W4156 Fall 2007
2
Our Focus: the Language
Unified Modeling Language
• Language = syntax + semantics
– Syntax = rules by which language
elements (e.g., words) are assembled into
expressions (e.g., phrases, clauses)
– Semantics = rules by which syntactic
expressions are assigned meanings
01 November 2007
Kaiser: COMS W4156 Fall 2007
3
Building Blocks
• The basic building blocks (syntax) of
UML are:
– Model elements (classes, interfaces,
components, use cases)
– Relationships (associations, generalization,
dependencies)
– Diagrams (class diagrams, use case
diagrams, interaction diagrams)
• Simple building blocks are used to create
large, complex structures
01 November 2007
Kaiser: COMS W4156 Fall 2007
4
Types of UML Diagrams
• Each UML diagram is designed to let
developers and customers view a software
system from a different perspective and in
varying degrees of abstraction
– Use Case
– Interaction
– State
– Structural
– Implementation
01 November 2007
Kaiser: COMS W4156 Fall 2007
5
Structural Modeling
• Define the architecture
• Used to model the “things” that make up
the system
• Model class structure and contents
• Emphasizes the structure of objects,
including their classifiers, attributes,
operations, and relationships including
dependencies
01 November 2007
Kaiser: COMS W4156 Fall 2007
6
Structural Diagrams
• Show a graph of elements connected
by relationships
• Kinds
– Class diagram: classifier view
– Object diagram: instance view
• Shows the static structures of the
system (not dynamic or temporal)
01 November 2007
Kaiser: COMS W4156 Fall 2007
7
Class Diagrams
• Shows how the different entities
(people, things and data) relate to each
other
• A class diagram can be used to display
logical classes, not necessarily code
classes, which are typically the kinds of
things the business people in an
organization talk about — rock bands,
CDs, radio play; or home mortgages,
car loans, interest rates
• Use domain vocabulary
01 November 2007
Kaiser: COMS W4156 Fall 2007
8
Class Diagram Example
01 November 2007
Kaiser: COMS W4156 Fall 2007
9
Class Notation
•
•
•
•
•
A class is depicted on the class diagram as a
rectangle with three horizontal sections
(compartments)
The upper section shows the class's name
The middle section contains the class's
structure or attributes, optionally with initial
values
The lower section contains the class's
operations or behaviors (or "methods")
May be abbreviated to show just name, or just
name and attributes
01 November 2007
Kaiser: COMS W4156 Fall 2007
10
Class Example
01 November 2007
Kaiser: COMS W4156 Fall 2007
11
Class Diagram
• Draw a generalization relationship using a line
with an arrowhead at the top pointing to the
super class, where the arrowhead should a
completed triangle
• Associations
– A solid line if both classes are aware of each other
– A line with an open arrowhead if the association is
known by only one of the classes (pointing to the
class known by the other one, i.e., direction of
potential navigation)
– Optionally label with multiplicity
01 November 2007
Kaiser: COMS W4156 Fall 2007
12
Example Class Diagram
Generalization
One-way
association
01 November 2007
Kaiser: COMS W4156 Fall 2007
Two-way
association
13
Association Example
01 November 2007
Kaiser: COMS W4156 Fall 2007
14
Generalization Example
01 November 2007
Kaiser: COMS W4156 Fall 2007
15
Core Elements
Construct
Description
class
a description of a set of objects
that share the same attributes,
operations, methods, relationships
and semantics.
a named set of operations that
characterize the behavior of an
element.
a modular, replaceable and
significant part of a system that
packages implementation and
exposes a set of interfaces.
a run-time physical object that
represents a computational
resource.
a semantic condition or restriction.
interface
component
node
constraint
Syntax
«interface»
{constraint}
01 November 2007
Kaiser: COMS W4156 Fall 2007
16
Core Relationships
Construct
Description
association
a relationship between two or more
classifiers that involves connections
among their instances.
A special form of association that
specifies a whole-part relationship
between the aggregate (whole) and
the component part.
a taxonomic relationship between a
more general and a more specific
element.
a relationship between two modeling
elements, in which a change to one
modeling element (the independent
element) will affect the other modeling
element (the dependent element).
a relationship between a specification
and its implementation.
aggregation
generalization
dependency
realization
01 November 2007
Kaiser: COMS W4156 Fall 2007
Syntax
17
Implementation Class Diagrams
• Can also be used to show implementation classes,
which are the things that programmers typically deal with
• An implementation class diagram will probably show
some of the same classes as the logical classes diagram
• The implementation class diagram won't be drawn with
the same attributes, however, because it will most likely
have references to things like Vectors and HashMaps
• May add compartments such as responsibilities and
exceptions, even gist of method body
• May indicate attribute and operation visibility: public,
private, protected, package
01 November 2007
Kaiser: COMS W4156 Fall 2007
18
Example Implementation
Class
Reservation
operations
guarantee()
cancel ()
change (newDate: Date)
responsibilities
bill no-shows
match to available rooms
exceptions
invalid credit card
01 November 2007
Kaiser: COMS W4156 Fall 2007
19
Example Class Detail
Window
Window
size: Area
visibility: Boolean
display ()
hide ()
Window
{abstract,
author=Joe,
status=tested}
+size: Area = (100,100)
#visibility: Boolean = true
+default-size: Rectangle
#maximum-size: Rectangle
-xptr: XWindow*
+display ()
+hide ()
+create ()
-attachXWindow(xwin:Xwindow*)
+ = public
- = private
# = protected
~ = package visibility
01 November 2007
Kaiser: COMS W4156 Fall 2007
20
Method Body Example
PoliceStation
alert (Alarm)
1 station
*
BurglarAlarm
isTripped: Boolean = false
{ if isTripped
then station.alert(self)}
report ()
01 November 2007
Kaiser: COMS W4156 Fall 2007
21
Generalization
• Often represents inheritance at
implementation class level
• Abstract class names given in italics
• Possibly multiple inheritance
• Possibly multiple inheritance hierarchies
emanating from same base class
• Separate vs. shared target formats
01 November 2007
Kaiser: COMS W4156 Fall 2007
22
Generalization Example
Equivalent Forms
01 November 2007
Kaiser: COMS W4156 Fall 2007
23
Generalization Example
Shape
Separate Target Style
Polygon
Ellipse
Spline
. ..
Shape
Polygon
01 November 2007
Ellipse
Shared Target Style
Spline
Kaiser: COMS W4156 Fall 2007
...
24
Multiple Level Generalization
Example
Vehicle
venue
power
power
{overlapping}
WindPowered
Vehicle
Truck
01 November 2007
venue
MotorPowered
Vehicle
{overlapping}
Land
Vehicle
Water
Vehicle
Sailboat
Kaiser: COMS W4156 Fall 2007
25
Associations
• Reflect connections, usually implemented as an
instance variable in one class
• Connector may include named roles at each
end, cardinality, direction and constraints
• Self-associations permitted
• May indicate choice (xor)
• May be N-ary (not just binary)
• Association classes allow an association
connection to have operations and attributes
01 November 2007
Kaiser: COMS W4156 Fall 2007
26
Association Example
01 November 2007
Kaiser: COMS W4156 Fall 2007
27
Association Examples
Job


Company
employer employee
Job
salary
Person
boss
worker 
0..1
Manages
Person
Account
{X or}
Corporation
01 November 2007
Kaiser: COMS W4156 Fall 2007
28
Association Class Example
01 November 2007
Kaiser: COMS W4156 Fall 2007
29
Ternary Association Class
Example
Year
season 
Team


goalkeeper
team
Player
Record
goals for
goals against
wins
losses
ties
01 November 2007
Kaiser: COMS W4156 Fall 2007
30
Aggregations
• Aggregations are a stronger form of association
between a whole and its parts
• Drawn with a diamond next to the class
representing the target or whole (parent)
• open vs. closed diamond indicates usage vs.
containment semantics
• Containment may be indicated by composition
rather than relationship lines
01 November 2007
Kaiser: COMS W4156 Fall 2007
31
Aggregation Example
01 November 2007
Kaiser: COMS W4156 Fall 2007
32
Aggregation Example
1
Polygon
+vertex
3..
Contains
Point
{ordered}
1
GraphicsBundle
1
-bundle
01 November 2007
color
texture
density
Kaiser: COMS W4156 Fall 2007
33
Composition Example
Window
Window
scrollbar [2]: Slider
title: Header
body: Panel
scrollbar:Slider
1
title:Header
Window
1
scrollbar
Slider
01 November 2007
2
1
1
1
title
2
body:Panel
1
Header
body
1
Panel
Kaiser: COMS W4156 Fall 2007
34
Dependencies
• Dependencies are a weaker form of association without
semantic knowledge
• Often used early in the design process where it is known
that there is some kind of link between two elements, but
it is too early to know exactly what the relationship is
• Later in the design process, dependencies may be
replaced with a more specific type of connector
• Shown with a dashed line (e.g., from client to supplier)
• <<label>> on line specifies kind (stereotype) of
dependency, e.g., <<instantiate>>, <<import>>,
etc.
01 November 2007
Kaiser: COMS W4156 Fall 2007
35
Dependencies Example
ClassA
ClassD
ClassB
«friend»
«friend»
operationZ()
«instantiate»
«call»
ClassC
«refine»
ClassD
01 November 2007
Kaiser: COMS W4156 Fall 2007
ClassC combines
two logical classes
ClassE
36
Dependencies Example
Controller
«access»
«access»
«access»
Diagram
Elements
«access»
«access»
Domain
Elements
01 November 2007
Graphics
Core
Kaiser: COMS W4156 Fall 2007
37
Interfaces
• All interface operations are public and abstract, and all
interface attributes must be constants
• By realizing an interface, classes are guaranteed to
support a required behavior, which allows the system to
treat non-related elements in the same way – that is,
through the common interface
• While a class may only inherit from a single super-class,
it may implement multiple interfaces
• May be drawn in a similar style to a class, with
operations specified
• Or may be drawn as a circle with no explicit operations
detailed (when drawn as a circle, realization links to the
circle form of notation are drawn without target arrows)
01 November 2007
Kaiser: COMS W4156 Fall 2007
38
Interface Example
01 November 2007
Kaiser: COMS W4156 Fall 2007
39
Interface Realization Example
01 November 2007
Kaiser: COMS W4156 Fall 2007
40
Interface
Example
CreditCard
{abstract}
OrderBean
{abstract}
<<interface>>
EntityBean
+getOrderStatus
+setOrderStatus
+getLineItems
+setLineItems
+getCreditApproved
+setCreditApproved
order
*
buyer
Customer
1
PMCreditCard
PMOrder
...
1
order
*
item
LineItem
{abstract}
PMLineItem
*
01 November 2007
*
item
1
commodity
Product
Kaiser: COMS W4156 Fall 2007
Adapted from Fig. 23 [EJB 2.0].
41
Types and Implementation
Classes Example
«type»
Object
«implementationClass»
HashTable
* elements
1 body
«type»
Set
«implementationClass»
HashTableSet
addElement(Object)
removeElement(Object)
testElement(Object):Boolean
01 November 2007
addElement(Object)
removeElement(Object)
testElement(Object):Boolean
setTableSize(Integer)
Kaiser: COMS W4156 Fall 2007
42
Object Diagrams
• Refer to a specific instance
• Special case of a class diagram
• Does not show operations but may show
runtime state
• Object names are underlined and may
show the name of the classifier from which
the object is instantiated
• May compose multiple specific instances
• May be drawn as glyphs
01 November 2007
Kaiser: COMS W4156 Fall 2007
43
Class vs. Object Diagram Example
01 November 2007
Kaiser: COMS W4156 Fall 2007
44
Run-time State Example
01 November 2007
Kaiser: COMS W4156 Fall 2007
45
More Object Examples
triang le : Polygon
cen te r = (0 ,0 )
vertice s = ( (0 ,0 ),(4 ,0) ,( 4,3 ))
bo rd erC olo r = bla ck
fi llCo lo r = wh ite
triangle
:Polygon
tria ng le: Po lygo n
scheduler
01 November 2007
Kaiser: COMS W4156 Fall 2007
46
Composite Objects Example
awindow : Window
horizontalBar:ScrollBar
verticalBar:ScrollBar
moves
surface:Pane
moves
title:TitleBar
01 November 2007
Kaiser: COMS W4156 Fall 2007
47
When to Model Structure
• Adopt an opportunistic top-down
interleaved with bottom-up approach to
modeling structure
– Specify the top-level structure using
“architecturally significant” classifiers and
model management constructs (subsystems)
– Specify lower-level structure as you discover
detail wrt classifiers and relationships
01 November 2007
Kaiser: COMS W4156 Fall 2007
48
Implementation Diagrams
• Additional structural modeling (beyond
classes, interfaces and objects)
• Show aspects of model implementation,
including source code structure and runtime implementation structure
• Kinds
– Package diagram
– Component diagram
– Deployment diagram
01 November 2007
Kaiser: COMS W4156 Fall 2007
49
Package Diagrams
• Used to reflect the organization of packages and
their elements
• Provide a visualization of the namespaces
• Elements contained in a package share the
same namespace, therefore must have unique
names
• Drawn as folders, with tabs at the top; the
package name is on the tab or inside the
rectangle
• Dotted arrows show dependencies - one
package depends on another if changes in the
other could possibly force changes in the first
01 November 2007
Kaiser: COMS W4156 Fall 2007
50
Package Diagrams
• Packages may be imported or nested
• A <<merge>> connector between two
packages defines an implicit
generalization between elements in the
source package and elements with the
same name in the target package
• The target package need not contain
elements with same names as all source
package elements
01 November 2007
Kaiser: COMS W4156 Fall 2007
51
Package Diagram Example
nested
package
01 November 2007
Kaiser: COMS W4156 Fall 2007
52
Component Diagrams
• Describes the software components that make
up the system
• Provides a physical view of the system
• Shows the dependencies that the software has
on the other software components (e.g.,
software libraries) in the system
• A component is illustrated as a large rectangle
with two smaller rectangles on the side, lollipops
represent interfaces
• Dashed lines with arrows between components indicate
dependencies
01 November 2007
Kaiser: COMS W4156 Fall 2007
53
Component Examples
ShoppingSessionHome
<<Session>>
ShoppingSession
ShoppingSession
<<Entity>>
030303zak:Order
OrderHome
<<auxiliary>>
:OrderPK
OrderHome
<<focus>>
:Order
Order
OrderPK
OrderInfo
<<auxiliary>>
:OrderInfo
Order
01 November 2007
Kaiser: COMS W4156 Fall 2007
54
Component Diagram Example
ShoppingSessionHome
ShoppingSession
<<EJBSession>>
ShoppingSession
<<EJBEntity>>
Catalog
CatalogHome
CatalogPK
<<auxiliary>>
CatalogPK
CatalogHome
<<focus>>
Catalog
CatalogInfo
<<auxiliary>>
CatalogInfo
Catalog
Catalog
<<file>>
CatalogJAR
ShoppingCartHome
ShoppingCart
<<EJBEntity>>
ShoppingCart
01 November 2007
Kaiser: COMS W4156 Fall 2007
55
Component Diagram Example with
Labeled Dependencies
01 November 2007
Kaiser: COMS W4156 Fall 2007
56
Deployment Diagram
• Visualizes the physical architecture and the
deployment of components on that hardware
architecture
• Shows how a system will be physically deployed
in the hardware environment, distribution of
components across the enterprise
• Its purpose is to show where the different
components of the system will physically run and
how they will communicate with each other
01 November 2007
Kaiser: COMS W4156 Fall 2007
57
Deployment Diagram Notation
• Includes the notation elements used in a
component diagram, plus adds the concept of a
node
• A node represents either a physical machine or
a virtual machine node (e.g., a mainframe node)
• To model a node, simply draw a threedimensional cube (or box) with the name of the
node at the top of the cube
• Use the naming convention
[instance name] : [instance type]
(e.g., "w3reporting.myco.com : Application
Server")
01 November 2007
Kaiser: COMS W4156 Fall 2007
58
Deployment Diagram Example
01 November 2007
Kaiser: COMS W4156 Fall 2007
59
Summary
• UML is effective for modeling large, complex software
systems
• It is simple to learn for most developers, but provides
advanced features for expert analysts, designers and
architects
• It can specify systems in an implementationindependent manner
• 10-20% of the constructs are used 80-90% of the
time
• Structural modeling specifies a skeleton for the
structural elements that supply the behavior
(sequence, state, activity diagrams) and implement
the use cases (use case diagrams)
• Implementation diagrams extend structural modeling
to source code and run-time structure
01 November 2007
Kaiser: COMS W4156 Fall 2007
60
Resources
• http://www.uml.org/ — The official UML Web site
• http://argouml.tigris.org/ — Information on Argo
UML, an open source UML modeling tool built in
Java
• http://uml.sourceforge.net/index.php —
Information on Umbrello UML Modeller, an open
source UML modeling tool for KDE
• http://www-306.ibm.com/software/rational/uml/ IBM’s UML resource center (IBM bought
Rational in 2002)
01 November 2007
Kaiser: COMS W4156 Fall 2007
61
First Iteration Demos
Due!
• October 30th – November 8th
• Extra credit on per-day-early sliding scale
• Only team members present for the demo
(for CVN virtually present) will receive
credit – 10% of final grade
• No “presentation” needed, but be prepared
to answer questions, show your code, and
let the TA enter input to your system
01 November 2007
Kaiser: COMS W4156 Fall 2007
62
Upcoming Deadlines
• First iteration final report due Friday
November 9th, must respond to any
“issues” that arose during demo
• Midterm Individual Assessment posted
Friday November 9th
• Midterm Individual Assessment due Friday
November 16th
• 2nd iteration starts
01 November 2007
Kaiser: COMS W4156 Fall 2007
63
Second Iteration
• Add extensive error checking and exception
handling
• Black box unit testing and white box statement
coverage
• Semi-formal code inspection
• Security and stress testing
• Seeking volunteer teams to do code inspections
(Tue 27 Nov and Thu 29 Nov) and final demos
(Tue 4 Dec and Thu 6 Dec) in class
01 November 2007
Kaiser: COMS W4156 Fall 2007
64
COMS W4156: Advanced
Software Engineering
Prof. Gail Kaiser
Kaiser+4156@cs.columbia.edu
http://york.cs.columbia.edu/classes/cs4156/
01 November 2007
Kaiser: COMS W4156 Fall 2007
65