CS 501: Software Engineering
Fall 2000
Lecture 11
Object-Oriented Design I
Administration
• Preparation for presentation
-- Recitation Section, Monday October 2
-- Not all members of team need be present
• Fall Programming Contest for this year will be on
October 14th, organized by the ACSU and David Kempe.
http://www.cs.cornell.edu/kempe/contest/default.html
2
What is in a Requirements Document?
Example (Web Butler and Web Site Profiler)
• Run web data collection in real time or batch mode
How are jobs started?
• Job parameters
How are the parameters set up (interactive, edit file, ...)?
What are the parameters (specify)?
Can job parameters be stored and used again? If so, how?
• Job monitoring
What feedback is given while job is running?
Can the user pause or break a job? If so, are the results retained?
3
What is in a Requirements Document?
Remember
• The requirements document specifies the functionality that
you plan to deliver to the client
•
It must be comprehensive and detailed. Everything must be
written out -- no hand waving!
The requirements document is likely to be several times as long
as Assignment 1.
4
Assignment 2 -- Individual Parts
One approach:
With your document, include a list of who contributed what
part to the Requirements study, e.g.,
Person A
Requirements analysis for database design (member of team of
3), wrote Section 3.1 of document, worked with client to
identify software needs.
Person B
Prepared visual aids for presentation, edited entire document,
specified the security needs and wrote Section 4.2.
5
The Waterfall Model
Requirements
Definition
System and
Software design
Implementation
and Unit Testing
Integration and
System Testing
6
Operation and
Maintenance
Useful Texts
Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified
Modeling Language. Addison-Wesley 1999.
Grady Booch, Object-Oriented Analysis and Design with
Applications, second edition. Benjamin/Cummings 1994.
Rob Pooley, Perdita Stevens, Using UML Software
Engineering with Objects and Components. Addison-Wesley
1999.
7
The Importance of Modeling
• A model is a simplification of reality.
• We build models so that we can better understand the
system we are developing.
• We build models of complex system because we cannot
comprehend such a system in its entirety.
Models can be informal or formal. The more complex the
project the more valuable a formal model becomes.
BRJ
8
Principles of Modeling
• The choice of what models to create has a profound
influence on how a problem is attacked and how a
solution is shaped.
• Every model can be expressed at different levels of
precision.
• The best models are connected to reality.
• No single model is sufficient. Every nontrivial
system is best approached through a small set of
nearly independent models.
9
BRJ
The Unified Modeling Language
UML is a standard language for modeling software systems.
• Serves as a bridge between the requirements specification
and the implementation.
• Provides a means to specify and document the design of a
software system.
• Is process and programming language independent.
• Is particularly suited to object-oriented program
development.
10
Notation: Classes
Window
origin
size
open()
close()
move()
display()
name
attributes
operations
A class is a description of a set of objects that share the same
attributes, operations, relationships and semantics.
11
Notation: Interface
ISpelling
An interface is a collection of operations that specify a
service of a class or component, i.e., the externally
visible behavior of that element.
12
Notation: Collaboration & Use Case
Chain of
responsibility
A collaboration defines an interaction, i.e., a society of
roles and other elements that work together to provide some
cooperative behavior.
Place order
A use case is a description of a set of sequence of actions
that a system performs that yields an observable result.
13
Notation: Active Class
EventManager
eventlist
suspend()
flush()
An active class is a class whose objects own one or
more processes or threads and therefore can initiate
control activity.
14
Notation: Component & Node
orderform.java
A component is a physical and replaceable
part of a system that conforms to and provides
the realization of a set of interfaces.
Server
15
A node is a physical element that exists at run
time and represents a computational resource.
Notation: Behavioral Things:
Messages & States
display
An interaction is a behavior that comprises a set of messages
exchanged among a set of objects within a particular context to
accomplish a specific purpose.
Waiting
A state machine is a behavior that specifies the sequence of
states an object or an interaction goes through during its
lifetime in response to events.
16
Notation: Grouping and Annotation
Business rules
A package is a general-purpose mechanism for organizing
elements into groups.
return copy
of self
17
A note is a symbol for rendering constraints and
comments attached to an element or a collection of
elements.
Notation: Relationships
A dependency is a semantic relationship between two things in
which a change to one may effect the semantics of the other.
0..1
employer
*
employee
An association is a structural relationship that describes
a set of links, a link being a connection among objects.
18
Notation: Relationships (continued)
child
parent
A generalization is a specialization/generalization
relationship is which objects of the specialized
element (child) are substitutable for objects of the
generalized element (parent).
A realization is a semantic relationship between
classifiers, wherein one classifier specifies a
contract that another classifier guarantees to carry
out.
19
Diagrams in UML
A diagram is the graphical representation of a set of
elements, usually rendered as a connected graph of vertices
(things) and arcs (relationships).
• Class diagram shows a set of classes, interfaces, and
collaborations with their relationships.
• Object diagram shows a set of objects and their
relationships.
• Use case diagram shows a set of use cases and actors (a
special kind of class) and their relationships.
20
Diagrams in UML (continued)
• Interaction diagram shows an interaction, consisting
of a set of objects and the relationships, including the
messages that may be dispatched among them.
=> A sequence diagram emphasizes the time ordering.
=> A collaboration diagram emphasizes the structural
organization of the objects that send and receive messages.
21
Diagrams in UML (continued)
• Statechart diagram shows a state machine consisting
of states, transitions, events, and activities.
• Activity diagram is a statechart diagram that shows the
flow from activity to activity within a system.
• Component diagram shows the organization and
dependencies among a set of components.
• Deployment diagram shows the configuration of
processing nodes and the components that live on them.
22
The HelloWorld Example
class
name
HelloWorld
operations paint()
23
Abstraction for HelloWorld
class
name
HelloWorld
annotation
operations paint()
24
g.drawString
("HelloWorld", 0, 10)"
The "Hello, World" Example
import java.awt.Graphics;
class HelloWorld extends java.applet.Applet {
public void paint (Graphics g) {
g.drawString ("Hello, World!", 10, 10);
}
}
Example from: BJR
25
Class Diagram
Applet
generalization
Note that the Applet
and Graphics classes
are shown elided.
HelloWorld
paint()
26
dependency
Graphics
Class Inheritance Diagram
Object
Panel
interface
Component
ImageObserver
Applet
Container
HelloWorld
27
Packaging Classes
java
HelloWorld
applet
Graphics
awt
lang
28
package
Notation for Classes and Objects
Classes
AnyClass
attribute1
attribute2
operation1()
operation2()
or
AnyClass
29
Objects
anObject:AnyClass
or
:AnyClass
or
anObject
The names of objects are
underlined.