Quick picks:
[
outside
]
[
hide details
]
[
details
]
In the year |
Software is |
1960 | Small |
1970 | Cheap |
1980 | Efficient |
1990 | Understandable |
2000 | Reusable |
Observation:
When a company produces software, the organization of that
software reflects the organization of the company.
Corollary:
Software systems are designed with real-world analogies in mind.
Resulting systems are more
- intuitive
- self-documenting
- extensible
Idea:
- Design software as a collection of objects
- Objects interact by sending each other messages
Example: Doctors and Patients
- What do we find in a Doctor's office?
- Receptionist
- Nurse(s)
- Doctor(s)
- Account manager
- What is the behavior of a receptionist?
- Schedule appointments on master calendar
- Log patients in
- Accept patients into office
- Schedule with nurse and doctor
- Pass patient to account manager
- Log patient out
- What is the behavior of a nurse?
- Take vital signs
- Prep patient for doctor
- What is the behavior of a doctor?
- Examine vital signs
- Examine patient history
- Diagnose problem
- Prescribe mediciation
- What is the behavior of an account manager?
- Assess charges
- Collect payment
We seek to understand the behavior of the components
- How do they interact?
- What are their requirements?
- What exceptional things can happen?
so we can design the system
before we understand the components' implementation
- How does the receptionist keep track of appointments?
- What kind of pencil does the doctor use?
- Who makes the sphygmomanometer?
- Who answers the phone at the pharmacy?
Thus, in this course, we study both design and implementation.
Ideally, a program's design segues to implementation in a number of carefully
taken steps.
|
A good analogy is structural architecture
|
- Initial design -- sketch the objects
- Design object behavior -- how they interact
- Implement a little of each kind of object
- Piece a rudimentary system together from the pieces.
- Test the prototype
- Add detail, test
- Keep going until done
|
- Determine the scope of the building
- Sketch footprint
- Sketch floors and rooms
- Interconnect floors and rooms
- Build outer shell
- Fill in a floor
- Fill in the rooms
- Add furniture and people
|
This approach to design can be thought of as
- Outside-in
- Top-down
- Stepwise refinement
- Taking little steps
- Proceeding from confidence to confidence
- A really good idea
- Decomposition -- breaking a large problem down into
tractable pieces
You probably have an area of interest outside of computer science. Think
about how the principle of decomposition is used in that area.
The hard part is arriving at a design that can be extended or reused in
the future. It's a matter of taste and aestetics.
Examples (from the doctor's office):
- Can we determine how long since a patient's last visit?
- What happened as we move from 1999 to 2000 (Y2K issues)?
- Is the doctor scenario sufficiently general to handle a dentist's office?
- If the office gets busy, could we implement two receptionists instead
of one?
- How could we handle emergency admission?
- More generally, can patients in the waiting room have priorities?
This is why a large software project begins with a set of
requirements, so it is clear what is expected of the software.
In Java, each kind of object becomes a class. This is shown below
for Patient and Doctor.
Doctor | Patient |
Return Type | Method Name | Parameters |
Diagnosis | visit |
|
|
Return Type | Method Name | Parameters |
String | getName | |
|
|
Return Type | Method Name | Parameters |
boolean | isBusy | |
int | numSeen | |
|
Return Type | Method Name | Parameters |
boolean | isAllergic | Medicine m |
Symptoms | getSymptoms | |
|
Note the conventions about
upper and lower case.
- Types (Class names) begin with upper case characters.
- Variable names begin with lower case characters.
- Where a name comprises a string of separate words, these are run
together without spaces. A capital letter distinguishes the beginning of
the next word from the end of the previous one.
In the above, note how
digging into the design reveals the need for more kinds of objects. The
method definitions above the line are from the initial thinking. But
as we proceed, we find we need the methods below the line.
-
Why do we make a big deal about Symptoms? Couldn't these just
be Strings in the Patient object?
- How would we compare if two patients have the same symptoms?
- How would we keep track of the history of a patient's symptoms?
- What would a set of symptoms look like without the
Symptoms object?
- Based on what we've seen so far, how would we define
Patient.isSick()?
The decomposition of this problem led to abstraction
about symptoms.
This course is largely about using decomposition and abstraction to
solve computational problems.
Recall the notion of an algorithm -- a recipe for computing
something. In Java and other OO languages, each object contains pieces
of the recipe---ideally the pieces that deal with the object.
In the doctor's office:
- Account manager can compute a patient's bill based on the doctor's
diagnosis and the cost of obtaining vital signs. The nurse does not
participate in this computation, so the algorithmic pieces are kept in
the account manager, VitalSigns, and Diagnosis
objects.
- Account manager keeps the patient's balance.
Last modified 09:31:03 CST 21 January 2000
by Ron K. Cytron