5.1 Object-Oriented Design
Object-oriented thinking begins with object-oriented design
Let there be no doubt that Object-Oriented Design (OOD) is fundamentally different from traditional structured design approaches: it requires a different way of thinking about decomposition and it produces software architectures that are largely outside the realm of the structured design culture.Grady Booch, 1994SE guru (UML luminary and author) Object-Oriented Analysis and Design with Applications
Where to start?
As emphasized previously, the most important aspect of O-OP is the creation of a universe of largely autonomous (i.e. independent), but still yet interacting objects.
But how does one come up with such a system?
One answer is a design technique driven by the determination and delegation of responsibilities.
The technique described is termed Responsibility-Driven Design (RDD).
Other techniques are available see COS 315 Software Engineering
Programming in the Small and Programming in the Large
The difference between the development of individual projects and more sizable (real-world) software systems is often described as programming in the small versus programming in the large.
Programming in the Small
One programmer understands everything from top to bottom.
Major problem is the development of algorithms.
Programming in the Large
System is developed by large team of programmers
Major problems are management of details and communication between programmers and between their respective software subsystems.
Really good design methodologies are required for large, complex real-world problems.
Basis for Design
Early software development methodologies (those popular before the advent of object-oriented techniques) concentrated on ideas such as characterizing the basic data structures, and/or the overall structure of function calls, often within the creation of a formal specification of the desired application.
But structural elements (data structures and functions) of the application can be identified only after a considerable amount of problem analysis.
However, a design technique based on behaviour can be applied from the very beginning of a problem analysis.
Responsibility-Driven Design (RDD), developed by Wirfs-Brock, is an object-oriented design technique that is driven by an emphasis on behaviour at all levels of development.
A low-tech approach to identifying object responsibilities.
Software development with RDD:
Analyze problem use scenarios to capture behaviour of real-world objects.Record behaviour on CRC cards.Design software objects.CodeTest program
A design technique that has the following properties:
- Can deal with an ambiguous and incomplete specification (Description of what functionality is required from the program to be developed).
- Naturally flows from analysis to solution.
- Easily integrates with various aspects of software development.
An Simple Example - the IIKH
Imagine you are the chief software engineer in a major computing firm.
The president of the firm rushes into your office with a specification for the firms next PC-based product. It is drawn on the back of a dinner napkin (as all the best designs are. Not!)
Briefly, the Intelligent Interactive Kitchen Helper (IIKH) will replace the box of index cards of recipes that may be used in a kitchen.
Abilities of the IIKH
Here are some of the things a user can do with the IIKH:
Browse a database of recipes
Add a new recipe to the database
Edit or annotate an existing recipe
Plan a meal consisting of several courses
Scale a recipe for some number of users
Plan a longer period of meals, say a week
Generate a grocery list that includes all the items in all the menus for a period
Characterization by Behaviour
Just as an class is characterized more by behaviour than by representation, the goal in using Responsibility-Driven Design is to first characterize the application by its behaviour analysis of problem domain.
First capture the behaviour of the entire application.
Then refine this into behavioural descriptions of the individual parts (We capture the functionality of the software).
Then map the behavioural descriptions into code.
At first sight, from the problem description, we can see the need for
- something to manage a recipe database
- something to plan meals
However, we need to analyze the problem in more detail to see if we have missed anything we usually have!
E.g. from experience, we can see that the user will need some form of menu screen to choose one of the various options.
Working Through Scenarios
A major technique we use to uncover the desired behaviour is to walk through application scenarios.
Pretend we have already a working application and walk through the various uses of the system.
Establish the look and feel of the system.
Make sure we have uncovered all the intended uses.
Develop descriptive documentation.
Create the high-level software design.
Example: Simple Browsing Scenario Walkthrough
Alice Smith sits down at her computer and starts the IIKH. When the program begins, it displays a graphical image of a recipe box, and identifies itself as the IIKH, product of IIKH Inc. Alice presses the Enter button to begin.
In response to the key press, Alice is given a choice of a number of options. She selects to browse the recipe index, looking for a recipe for salmon that she wishes to prepare for dinner the next day. She enters the keyword salmon, and is shown in response a list of various recipes. She remembers seeing an interesting recipe that used the herb dill as a flavouring. She refines the search, entering the words salmon and dill. This narrows the search to two recipes.
She selects the first. This brings up a new window in which an attractive picture of the finished dish is displayed, along with the list of ingredients, preparation steps, and expected preparation time. After examining the recipe, Alice decides it is not the recipe she had in mind. She returns to the search result page, and selects the second alternative.
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. Alice selects quit from a program menu, and the application quits.
A software component is simply an abstract design entity with which we can associate responsibilities for different tasks.
May eventually be turned into a class, a method, or something else.
Any component should have a small well-defined set of responsibilities - called cohesion
Any component should interact with other components to the minimal extent possible - called coupling
Various types of cohesion and coupling have been identified see COS 315.
Cohesion and coupling are two good measures of the quality of a program. (Later!)
Having identified components, we need to document them.
Components are most easily described using CRC cards.
CRC = Component, Responsibility, Collaborator
A CRC card records the name, responsibilities, and collaborators (i.e. interactions) of an component.
A CRC card is inexpensive, erasable, physical
A CRC card is nothing more than a 3x5 index card, on which the analyst writesin pencilthe name of a class (at the top of the card), its responsibilities (on one half of the card), and its collaborators (on the other half of the card).
One card is created for each class identified as relevant to the scenario.
As the team members walk through the scenario, they may assign new responsibilities to an existing class, group certain responsibilities to form a new class, or (most commonly) divide the responsibilities of one class into more fine-grained ones and perhaps distribute these responsibilities to a different class.
What/Who Cycle Identifying Components
First identify what activity needs to be performed next.
Then answer the question who (i.e. which component) performs that action.
Any activity to be performed by the program must be assigned as a responsibility to some component.
Start with high-level design general overview of how software should function.
Then, step-by-step, add more details Stepwise Refinement
Development of the IIKH - The Greeter Component
The first component is the Greeter component.
When the application is started, the Greeter puts an informative, friendly welcome window (the greeting) on the screen.
And offers the user the choice of several different actions
- Browse the database of recipes. - Add a new recipe. - Edit or annotate a recipe. - Review a plan for several meals. - Create a plan of meals.
Many of the details concerning exactly how this is to be done can be ignored for the moment.
Activities are associated with the recipe database and amenu plan need to create components for these.
The Recipe Database Component
Ignoring the planning of meals for the moment, next explore the Recipe Database component.
- Must maintain the database of recipes.
- Must allow the user to browse the database.
- Must permit the