Topics for week 3

1
The Object-oriented Paradigm and The Unified
Modeling Language (UML)
2
Problems of software development

• "problems" of software development (review)
• conceptual integrity
• incremental build, progressive refinement
• large projects "differ" from small ones
• programming paradigms (1950s-present) attempts
  to deal effectively with these problems, make
  software easier to develop and to maintain

3
Languages and design methodology
Computer Language / Design Methodology brief
history 1950'sunstructured, no information
hiding--spaghetti code, GOTO,
flowcharts --machine code --assembly lang.
--FORTRAN, LISP (Algol COBOL) 1980s
structured, top-down design (3 basic control
structures, no GOTO), modularity --Pascal --(C)
--Ada 1990s encapsulation,
information-hiding, reuse, hardware/software
codesign --C --Java 2000s info
hiding web languages environments encapsulating
multiple languages, styles --.NET --Python --MA
TLAB
4
OO class
Important basic OO concepts class
encapsulates data structure (object)
and associated methods (functions)
these may be declared public / private /
protected appropriate uses public pass info
to object or request info about object (use
"messages") (can be used by anyone) private
modify object (can be used in class or by
friends) protected for descendants (in class
or by derived class and friends)
5
Record/class
traditional record (struct) functions to use
or modify this record can be anywhere
in the program OO class concept supports
encapsulation, information hiding
OO Prog.
DATA
DATA
DATA
DATA
DATA
DATA
DATA
Procedural Prog.
6
Inheritance
Ex Object data structures A. Base class B.
Derived class
X Y Z W
X Y Z
A.
B.
Useful OO techniques Inheritance ex in a
program modeling an ecosystem, we might have the
relationships wolf is carnivore sheep is
herbivore grass is plant carnivore is animal
herbivore is animal animal is organism plant is
organism here the base class organism holds
data fields which apply to all organisms, e.g.,
amount of water needed to survive two derived
classes, plant and animal, hold information
specific to each of these types of organisms,
e.g., kind of soil preferred by plant the animal
class also has two derived classes, wolf and
sheep Inheritance allows the collection of
common attributes and methods in "base" class and
inclusion of more specific attributes and methods
in derived classes
7
Polymorphism and overloading
Polymorphism base class can define a
virtual function appropriate versions of this
function can be instantiated in each derived
class (e.g., "draw" in the base class of
graphical objects can have its own specific
meaning for rectangles, lines, ellipses) Overload
ing ex cin gtgt num1 gtgt is overloaded
"shift ex can be overloaded to allow the
addition of two vectors ex a function name can
be overloaded to apply to more than one
situation e.g., a constructor can be defined one
way if initial values are given and a different
way if initial values are not given
8
Templates
Templates example template ltclass Tgt T
method1 (T x) .. can be specialized int
method1 (int x) float method1 (float
y) usertype method1 (usertype a) templates
promote reuse
9
Separate compilation

• Separate compilation
• Typically, an object-oriented program can be
  broken into three sets of components
• definitions and prototypes (text files, header
  files)
• implementations (compiled--source code need not
  be available to user)
• application program--uses the classes defined in
  header files and supported by the implementation
  files
• This strategy promotes reuse and information
  hiding

10
Misuse of object-oriented paradigm
Note no paradigm is misuse-proof
11
Using OO UML in quarter project
Developing an OO project we will use UML
(subset) determine specifications use
cases determine classes and connections (static
behavior) ER or class diagrams CRC
cards model dynamic behavior interaction
(object message) diagrams activity
diagrams state diagrams sequence diagrams
12
UML a language for specifying and designing an
OO project
UML stands for "unified modeling
language unifies methods of Booch, Rumbaugh
(OMT or Object Modeling Technique), and Jacobson
(OOSE or Object-Oriented Software
Engineering) mainly a modeling language, not a
complete development method Early versions --
second half of the 90's Not all methods we will
use are officially part of the UML description
13
Use cases
USE CASES a part of the Unified Modeling
Language" (UML) which we will use for
requirements analysis and specification each
identifies a way the system will be used and the
"actors" (people or devices) that will use it (an
interaction between the user and the
system) each use case should capture some
user-visible function and achieve some discrete
goal for the user an actual user can have many
actor roles in these use cases an instance of a
use case is usually called a "scenario Use case
will typically have graphical verbal forms
14
Example use case
Example cellular network place and receive calls
use case (based on Booch, Rumbaugh, and
Jacobson, The Unified Modeling Language User
Guide)
Text description --Use case name (cellular
network place and receive calls) --Participat
ing actors (cellular network and human
user) --Flow of events (network or user
accesses network to use its
functionality) --Entry condition(s) (user
accesses network using device or password)
--Exit condition(s) (call completed lost
or network busy) --Quality requirements
(speed, service quality)
System boundary
Use case diagramsummarizes, provides system
overview
Text descriptiongives important details
15
use case
Text description Use case name Participating
actors Flow of events Entry condition(s) Exit
condition(s) Quality requirements
16
Use casedetailed example (Pressman)

• Example SAFEHOME system (Pressman)
• Use case InitiateMonitoring
• (Pressman text categories
• Primary actor (1)
• Goal in context (2)
• Preconditions (3)
• Trigger (4)
• Scenario (5)
• Exceptions (6)
• Priority (system development) (7)
• When available (8)
• Frequency of use (9)
• Channel to actor (10)
• Secondary actors (11)
• Channels to secondary actors (12)
• Open issues (13) )

Homeowner
Accesses system via internet
Sensors
System administrator
Reconfigures sensors and related system
features
Pressman, p. 163, Figure 7.3
17
Use casedetailed example (Pressman)
Example SAFEHOME system (Pressman) Use case
name InitiateMonitoring Participating actors
homeowner, technicians, sensors Flow of events
(homeowner) --Homeowner wants to set the system
when the homeowner leaves house or remains in
house --Homeowner observes control
panel --Homeowner enters password --Homeowner
selects stay or away --Homeowner observes
that read alarm light has come on, indicating the
system is armed
18
Use detailed example (Pressman)--continued
Entry condition(s) Homeowner decides to set
control panel Exit condition(s) Control panel
is not ready homeowner must check all sensors
and reset them if necessary Control panel
indicates incorrect password (one beep)homeowner
enters correct password Password not
recognizedmust contact monitoring and response
subsystem to reprogram password Stay selected
control panel beeps twice and lights stay light
perimeter sensors are activated Away selected
control panel beeps three times and lights away
light all sensors are activated
19
Use casedetailed example (Pressman)

• Quality requirements
• Control panel may display additional text
  messages
• time the homeowner has to enter the password
  from the time the first key is pressed
• Ability to activate the system without the use
  of a password or with an abbreviated password
• Ability to deactivate the system before it
  actually activates

20
Use case additionssimplifications of use case
descriptions

• A. Include one use case includes another in its
  flow of events (cases A and B both include case
  C)
• Extend extend one use case to include
  additional behavior (cases D and E are extensions
  of case F)

ltltincludegtgt
A
C
B
ltltincludegtgt
ltltextendgtgt
D
F
E
ltltextendgtgt
21
Use case additions
C. Inheritance one use case specializes the
more general behavior of another G and H
specialize behavior of J)
G
J
Authenticate with password
authenticate
H
Authenticate with card
22
Use case continued
Examples what would be a use case for
vending machine user university student
management system (e.g., student changes
registration)
Use case name Participating actors Flow of
events Entry condition Exit condition Quality
requirements
23
System Tests

• Note
• Use cases can form a basis for system acceptance
  tests
• For each use case
• Develop one or more system tests to confirm that
  the use case requirements will be satisfied
• Add explicit test values as soon as possible
  during design phase
• These tests are now specifically tied to the use
  case and will be used as the top level acceptance
  tests
• Do not forget use cases / tests for performance
  and usability requirements (these may be
  qualitative as well as quantitative)

24
Examplebank simulation (Horstmann)
Horstmann, Mastering Object-Oriented Design in
C, Wiley, 1995
Teller 1
Teller 2
Customer 1
Customer 3
Customer 2
Teller 3
Teller 4
25
Use Cases--Bank
Goal Develop a tool to simulate the bank to
decide on optimal values for number of tellers,
number of customer queues, etc. Use cases?