Object-Oriented Design
Without understanding
programming in the large, one cannot
appreciate the importance of OOP
33
re
fe
no ior
er
nt
v
ha
ti
Responsibility
be
in
o
,d
nd rta
ce
ce
en
de t a
c
pe
pe
Ex
in
e
A two-way
iv
G
sword
88
Programming in the Small and
Programming in the Large
One programmer
understands everything from top to bottom.
System is developed by a
large teams of programmers
Data Structures ?
Functions ?
A Formal Specification ?
Behavior ?
Directed Evolution
Imprecise
Ambiguous
Unclear
Evolution of Specifications
Briefly, the
Interactive Intelligent Kitchen Helper
will replace the box of index cards of recipes in the
average kitchen
15
15
Your Job
Your job is to develop the software that will
implement the IIKH:
16
16
Generate a grocery list that includes all the items in all the
menus for a period
17
17
Characterization by Behavior
Just as an Abstract Data Type (ADT) is characterized
more by behavior than by representation
11. Examining this dish, Alice decides this is the one she had in mind. She requests a
printing of the recipe, and the output is spooled to her printer
12. Alice selects “quit" from a program menu, and the application quits
21
21
Software Components
A software component is an abstract design entity with
which we can associate responsibilities for different tasks
CRC Cards
Components are most easily described using CRC cards. A CRC
card records the name of a candidate component, its
responsibilities, and collaborators :
Component Name
Collaborators
to this component
23
23
Postponing Decisions
Many decisions, such as the method of browsing, can be
ignored for the moment,
Only need to note that somehow the user can manipulate the
database to select a specific recipe
27
27
Responsibilities of a Recipe
We can make the recipe itself into an active data structure
Greeter
Recipe
Plan Database
Manager
Interaction Diagrams
The picture on the previous slide captures static relationships, but
not the dynamic flow of messages in a scenario.
makePkan()
33
33
Characteristics of Components
Let us return to the idea of a software component
There are likely many instances of recipe, but they will all behave
in the same way.
Recipe Behavior:
Recipe class: Edit
Display
Parnas' Principles
Documentation
User Manual
Quality
You should always remember that the primary
measure of quality is the degree to which
your customers (clients) are satisfied with your
product
Try to predict the most likely sources of change, and isolate the effect
Too Much Responsibility: Components with too much responsibility are difficult
to understand and to use.
Responsibility should be broken into smaller meaningful packages and distributed.
Often arise when designers equate physical existence with logical design existence.
“Money is no object”
Usually the result of designing software components without thinking about how they
will be used.
Misleading Names:
Names should be short and unambiguously indicate what the responsibilities of the
component involve.