CS 501: Software Engineering Fall 2000

1
CS 501 Software EngineeringFall 2000
Lecture 11 Object-Oriented Design I
2
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/def
ault.html
3
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?
4
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.
5
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.
6
The Waterfall Model
Requirements Definition
System and Software design
Implementation and Unit Testing
Integration and System Testing
Operation and Maintenance
7
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.
8
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

9
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. BRJ
10
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.
11
Notation Classes
name attributes operations
Window origin size open() close() move() display()
A class is a description of a set of objects that
share the same attributes, operations,
relationships and semantics.
12
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.
13
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.
14
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.
15
Notation Component Node
A component is a physical and replaceable part of
a system that conforms to and provides the
realization of a set of interfaces.
Server
A node is a physical element that exists at run
time and represents a computational resource.
16
Notation Behavioral ThingsMessages 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.
17
Notation Grouping and Annotation
Business rules
A package is a general-purpose mechanism for
organizing elements into groups.
return copy of self
A note is a symbol for rendering constraints and
comments attached to an element or a collection
of elements.
18
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.
19
Notation Relationships (continued)
child
parent
A generalization is a specialization/generalizatio
n 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.
20
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.
21
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. gt A sequence diagram
emphasizes the time ordering. gt A
collaboration diagram emphasizes the structural
organization of the objects that send and receive
messages.
22
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.
23
The HelloWorld Example
class
HelloWorld paint()
name
operations
24
Abstraction for HelloWorld
class
HelloWorld paint()
name
annotation
operations
25
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
26
Class Diagram
Applet
Note that the Applet and Graphics classes are
shown elided.
generalization
dependency
Graphics
27
Class Inheritance Diagram
Object
Panel
interface
Component
ImageObserver
Applet
Container
HelloWorld
28
Packaging Classes
java
HelloWorld
package
Graphics
29
Notation for Classes and Objects
Objects
Classes
anObjectAnyClass
AnyClass attribute1 attribute2 operation1() operat
ion2()
or
AnyClass
or
anObject
or
The names of objects are underlined.
AnyClass