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 (1950’s-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's:unstructured, no information hiding--”spaghetti” code, GOTO, flowcharts
--machine code
--assembly lang.
--FORTRAN, LISP
(Algol; COBOL)
1980’s: structured, top-down design (“3 basic control structures, no GOTO”), modularity
--Pascal
--(C)
--Ada
1990’s: encapsulation, information-hiding, reuse, hardware/software codesign
--C++
--Java
2000’s: info hiding; web languages; environments encapsulating multiple languages, styles
--.NET
--Python
--MATLAB

4. Important basic OO concepts: class: encapsulates data
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. OO: class concept supports encapsulation, information hiding
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. wolf is carnivore; sheep is herbivore; grass is plant
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
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)
Overloading:
ex: cin >> num1;
>> 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. template <class T> T method1 (T x) …..
Templates
Templates:
example:
template <class T>
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:
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. an actual user can have many actor roles in these 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)
--Participating 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 diagram—summarizes,
provides system overview
Text description—gives important details

15. Text description: Use case name Participating actors Flow of events
Entry condition(s)
Exit condition(s)
Quality requirements

16. Use case—detailed 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) )
Arms/disarms
system
Homeowner
Accesses system
via internet
Sensors
Responds to
alarm event
Encounters an
error condition
System administrator
Reconfigures
sensors
and related
system features
Pressman,
p. 163,
Figure 7.3

17. Use case—detailed 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 recognized—must 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 case—detailed 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 additions—simplifications 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)
<<include>> A C B
<<include>>
<<extend>> D F E
<<extend>>

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. Examples: what would be a use case for:
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. Use cases can form a basis for system acceptance tests
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. Additional useful uml constructs

25. Question: How do you start an OO design?
--components?
--objects?
--how will they interact?
Answer: One common method is to start with components, along with any design patterns which can be identified.
In general:
design is an iterative process
all team members should take an active part in exploring possible designs
simple designs are preferable to complex designs--but it may take several iterations to develop a simple design which meets the project requirements
we will look at a subset of UML to do project design.

26. Analysis model (UML version):
--functional model (use cases and scenarios)
--analysis object model (static: class and object diagrams)
--dynamic model (state and sequence diagrams)
As system is analyzed, specifications are refined and made more explicit; if necessary, requirements are also updated

27. Example: an activity diagram for analyzing a system you are building:

28. “Review”: use case: Graphical description:
Text description:
Use case name
Participating actors
Flow of events
Entry condition(s)
Exit condition(s)
Quality requirements
Arms/disarms
system
Homeowner
Accesses system
via internet
Sensors
Responds to
alarm event
Encounters an
error condition
System administrator
Reconfigures
sensors
and related
system features
Pressman,
p. 163,
Figure 7.3

29. “Review”: Use case writing guide:
--each use case should be traceable to requirements
--name should be a verb phrase to indicate user goal
--actor names should be noun phrases
--system boundary needs to be clearly defined
--use active voice in describing flow of events, to make clear who does what
--make sure the flow of events describes a complete user transaction
---if there is a dependence among steps, this needs to be made clear
--describe exceptions separately
--DO NOT describe the user interface to the system, only functions
--DO NOT make the use case too long—use extends, includes instead
--as you develop use cases, develop associated tests

30. “Review”: Use case additions—simplifications 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)
<<include>> A C B
<<include>>
<<extend>> D F E
<<extend>>

31. “Review”: 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

32. Class and object diagrams:
Identify Objects from Use Case Specifications:
USE ENDUSER’s TERMS AS MUCH AS POSSIBLE
Entity objects: “things”, for example:
--nouns (customer, hospital, infection)
--real-world entities (resource, dispatcher)
--real-world activities to be tracked (evacuation_plan)
--data sources or sinks (printer)
Boundary objects: system interfaces, for example:
--controls (report(emergencybutton)
--forms (savings_deposit_form)
--messages (notify_of_error)
Control objects: usually one per use case
--coordinate boundary and entity objects in the use case
Use the identified objects in a sequence diagram to carry out the use case

33. tangible things, e.g., Mailbox, Document
Common classes
Other common types of classes which the developer can look for include:
tangible things, e.g., Mailbox, Document
system interfaces and devices, e.g., DisplayWindow, Input Reader
agents, e.g., Paginator, which computes document page breaks, or InputReader
events and transactions, e.g., MouseEvent,CustomerArrival
users and roles, e.g., Administrator, User
systems, e.g., mailsystem (overall), InitializationSystem (initializes)
containers, e.g., Mailbox, Invoice, Event
foundation classes, e.g., String, Date, Vector, etc.

34. a sequence diagram also models dynamic behavior
typically a sequence diagram shows how objects act together to implement a single use case
messages passed between the objects are also shown
sequence diagrams help to show the overall flow of control in the part of the program being modeled
they can also be used to show:
concurrent processes
asynchronous behavior

35. Sequence Diagram--Syntax
Objects in the sequence diagram are shown as boxes at the top
below each object is a dashed vertical line--the object’s “lifeline”
an arrow between two lifelines represents each message
arrows are labeled with message names and can also include information on arguments and control information
two types of control:
condition, e.g., [is greaterthan zero]
iteration, e.g., *[for all array items]
“return” arrows can also be included

36. Sequence Diagram Example

37. Useful object relationships
ER diagrams
Useful object relationships
These diagrams represent the relationships between the classes in the system. These represent a static view of the system.
There are three basic types of relationship:
inheritance ("is-a")
aggregation ("has-a”)
association ("uses")
These are commonly diagrammed as follows:

38. is-a: draw an arrow from the derived to the base class:
ER diagram: is-a
is-a: draw an arrow from the derived to the base class:
manager
employee

39. ER diagram--has-a
has-a: draw a line with a diamond on the end at the "container" class. Cardinalities may also be shown (1:1, 1:n, 1:0…m; 1:*, i.e., any number > 0, 1:1…*, i.e., any number > 1):
car
tire
tire & car can exist independently—shared aggregation
person
arm is part of the person– composition aggregation
arm

40. ER diagram--uses
uses or association: there are many ways to represent this relationship, e.g.,
employs 1
company
car
gasstation * * * n
employee 1
works for

41. CRC cards: class--responsibilities--collaborators cards
"responsibilities" = operators, methods
"collaborators" = related classes (for a particular
operator or method)
Make one actual card for each discovered class, with responsibilities and collaborators on the front, data fields on the back. CRC cards are not really part of UML, but are often used in conjunction with it.

42. CRC card--example
Example (based on Horstmann, Practical Object-Oriented Development in C++ and Java):
front back
Class Mailbox
Operations Relationships
(Responsibilities) (Collaborators)
get current message Message,
Messagequeue
play greeting
Class Mailbox
Queue of new messages
Queue of kept messages
Greeting
Extension number
Passcode

43. another way of adding detail to the design--models dynamic behavior
State Diagram
State Diagram:
another way of adding detail to the design--models dynamic behavior
describes all the possible states a particular object can be in and how that object's state changes as a result of events that affect that object
usually drawn for a single class to show behavior of a single object
used to clarify dynamic behavior within the system, as needed

44. State Diagram--Properties
A state diagram contains a "start" point, states, and transitions from one state to another.
Each state is labeled by its name and by the activities which occur when in that state.
Transitions can have three optional labels: Event [Guard] / Action.
A transition is triggered by an Event.
If there is no Event, then the transition is triggered as soon as the state activities are completed.
A Guard can be true or false. If the Guard is false, the transition is not taken.
An Action is completed during the transition.

45. State Diagram--Example
Example: this state diagram example for an "order" in an order-processing system is from Fowler and Scott, UML Distilled (Addison-Wesley, 1997):
start
/get first item
[not all items checked]
/get next item
[all items
checked &&
all items available]
Dispatching
Checking
initiate delivery
check item
[all items
checked &&
some items not in
stock]
delivered
item received
[all items in stock]
Delivered
Waiting
item received
[some items not in stock]

46. Example—bank simulation (Horstmann)
Horstmann, Mastering Object-Oriented Design in C++, Wiley, 1995
Teller 1
Teller 2
Customer 3
Customer 2
Customer 1
Teller 3
Teller 4

47. Example—bank simulation (Horstmann), cont.
An initial solution (Horstmann, p. 388):
Event
Departure
Arrival
Customer
Bank
EventQueue
Application
Bank Statistics

48. Example—bank simulation (Horstmann), cont.
An improved solution (Horstmann, p. 391):
Event
Departure
Arrival
Customer
Bank
EventQueue
Simulation
Bank Statistics

49. What simplifications have been made? Why? Comparison Bank Statistics
Event
Departure
Arrival
Customer
Bank
EventQueue
Application
Bank Statistics
What simplifications
have been made?
Why?
Event
Departure
Arrival
Customer
Bank
EventQueue
Simulation
Bank Statistics

50. Example:
How would we use the tools described so far to design a “smart” vending machine? How would we develop test cases at each stage?
Use cases?
Class diagram?
Sequence diagram?
Classes / CRC cards?