| Topic |
Reading |
Transparencies |
Assignment Due |
| Introduction |
1 |
1: 1-5 |
|
| OSM |
4.1 |
4: 1-9 * |
|
| OSM |
4.2 |
4: 1-12 |
|
| OSM |
4.3-5 |
4: 13-23 |
Homework 1 |
| Analysis |
7.1-2 |
7: 1-11 |
Homework 2 |
| Specification |
8.1 |
8: 1-11 |
Homework 3 |
| OSM-L |
8.2 |
8: 12-21 |
|
| Behavior Specification |
8.3-5 |
8: 22-29 |
Project (Analysis) |
| Hypergraphs and Red. Transformations |
9.1-3,5-6 |
9: 1-5,32-40 * |
Homework 4 |
| More Reduction Transformations |
9.7-10 |
9: 42-54 * |
Homework 5 |
| Flat Scheme Design |
10.1,4-5 |
10: 13-23 * |
Homework 6 |
| Nested Scheme Design |
10.8-10 |
10: 1-8 |
Homework 7 |
| Object Modules |
11.1 |
11: 1-5 |
|
| Methods & Types |
11.2-4 |
11: 6-15 |
Project (Specification) |
| State-Net Transformations |
11.5.1 |
11: 16-24 |
Homework 8 |
| State-Net Transformations |
11.5.2-4 |
11: 25-29 |
|
| Views & Inheritance |
11.6-9 |
11: 30-39 |
Project (Data Design) |
| Implementation (ODMG) |
12.1-3 |
12: 1-11 |
Homework 9 |
| Implementation (ODMG C++) |
12.4 |
12: 12-17 |
Homework 10 |
| Dev. Methodology (Case Studies) |
12.5-6, 14-17 |
12: 18 |
|
| Theoretical Foundation |
5.2.1, 6.1-2 |
|
Project (Object-Module Design) |
| Integration Tools |
7.3 |
7: 12-17 |
|
| Validation Tools |
7.4-5 |
7: 18-31 |
Homework 12 |
| Interface Generation Tools |
8.4 |
|
Homework 13 |
| Reduction Tools -- Semantic Eq. |
9.4.2, 9.5-7 |
|
|
| Reduction Tools -- Semantic Eq. |
9.8-10 |
|
|
| Synthesis Tools |
10.6 |
|
Project (Implementation) |
| Reports & Review |
|
|
Project (Documentation) |
Homework Assignments
Homework 1: 1.1, 1.2, 1.3, 1.4, and 1.5.
(Just make lists for discussion.)
Homework 2: 4.7, 4.8, 4.9, 4.10, 4.11 (use Allegro to do 4.11).
(Note: additional problems should be assigned for
students who have not taken the relational database
course from the book.)
Homework 3: 4.12, 4.15, 4.16, 4.18.
Homework 4: 7.1, 8.1, 8.2.
Homework 5: 8.4, 8.5, 8.7, 8.8.
Homework 6: 8.9, 8.10, 8.11, 8.12.
Homework 7: 8.14, 8.17, 8.18, 8.19.
Homework 8: 9.24, 9.47, 10.33, 10.37.
(Note: additional problems should be assigned for
students who have not taken the relational database
course from the book.)
Homework 9: 11.4, 11.5, 11.6, 11.8, 11.10.
Homework 10: 11.16, 11.17, 11.18.
Homework 11: 11.19, 11.20, 11.21, 11.22, 11.24.
Homework 12: 7.2, 7.3, 7.4b-f, 7.5.
Homework 13: 7.13, 7.14, 7.15, 7.16, 7.17.
Sample Project
``A Personal Travel Agent''
Context and Motivation
Many people would like to have a personal travel agent.
Can we provide an automated, individually-tailored agent who knows
the desires of its client and adjusts as those desires change
and who functions on behalf of its client to provide information,
make reservations, and purchase tickets needed for a trip?
Can we also enable this agent to glean information from
the web and adjust its understanding of the travel world as new
information becomes available?
More down-to-earth, can we do some interesting subpart of this problem?
Can we create a personal travel agent for helping a client plan a single
trip? Suppose we give the agent an ORM application model that
describes how a client would like to see the world of travel and hand
populate this application model with made-up data as if we had gleaned
it from multiple sites on the web.
Further suppose that we give the agent a state net representing the
workflow that describes how the client would like to interact with
the agent and how the agent interacts with the ORM application model.
For the sake of making this workflow a little more concrete, let's further
suppose that the trip is a business trip and thus that a travel-request
form (see below) needs to be filled out and routed and that a cash advance may
also be requested and received.
TRAVEL APPLICATION FORM
FORM ID# __________ DESTINATION ____________________
NAME ____________________ DEPARTMENT ____________________
DEPARTURE DATE __________ RETURN DATE __________
EXPENDITURES: ESTIMATED COSTS REQUESTED ADVANCE
AIR FARE _______________ N/A
LODGING _______________ _________________
MEALS _______________ _________________
TOTALS: _______________ _________________
APPROVAL SIGNATURES:
DEPARTMENT CHAIR _____________________
DIRECTOR _____________________
Objectives
- Develop a small OSM application model for a specialized personal
travel agent to aid in planning and receiving approval for a business trip.
- Use the OSM development methodology to transform this application model
into an OODBMS implementation.
- Observe the development process and make adjustments as necessary so
that analysis, specification, design, and implementation documents all
reflect the same application definition and provide a smooth transition
from analysis through implementation.
Analysis
Use the techniques discussed in the first part of Chapter 7 to do an
analysis as follows.
- Become familiar with the application. Visit some web sites for airlines
and hotels. Look over the travel-application form above.
- Use
Allegro
to create an ORM diagram that describes the essential
features of airlines, hotels, and travel applications.
Be sure to include (1) available flights, (2) available
rooms at hotels, (3) specific flight and hotel reservations, when
held/made, (4) estimated costs and totals, (5) cash advance costs and totals,
and (6) basic information on the form.
- Use
Allegro
to develop OBM/OIM diagrams for determining and booking
flights and hotel reservations and for processing a travel application.
Give your client a choice among
a small number of alternative flights and hotel/room selections. Get
these choices from your database of all possibilities. Have your
travel-application agent get basic information from your client, get
flight and hotel information from your airline and hotel agent and present
it to your client for making final selections, instruct flight agents to
book flights and hotel agents to book rooms, compute totals for estimates
and advance amounts, and route the information as needed to obtain signatures.
If the trip is denied, cancel flights and hotel reservations.
If the trip is approved, store final information -- flights, hotel
reservations, and travel-application form information
so that it can be displayed on demand.
Specification
Use the techniques discussed in Chapter 8 to do a specification as follows.
-
Rework your ORM model instance as may be necessary.
-
Add a system boundary to your ORM model instance. (You may put this on the
diagram by hand.)
-
Write the ORM model instance within your system boundary in OSM-L. Use the
latest OSM-L
grammar, and check your OSM-L code by executing the
OSM-L parser.
-
Rework your OBM/OIM model instances as may be necessary.
-
Use OSM-L to give a fully formal OBM/OIM for your hotel agent.
Check your OSM-L code by executing the
OSM-L parser.
-
Use mixed OSM-L and graphical notation to give a fully formal specification
for your airline agent. The graphical notation should retain the basic flow
of activities. Use
Allegro to provide
this specification.
-
Partially formalize your travel-application agent. The partial formalization
should graphically show the basic flow of activities. The triggers and
actions may be informal, but should contain enough explanation/formalism
that a person (other than yourself) could code your specification without
having to return to you for further clarification. Use
Allegro to provide
this specification.
-
Use interface forms to fully formalize client input to the travel-application
agent. (Other interfaces need not be formalized with interface forms.)
Data Design
Use the techniques in Chapters 9 and 10 to convert the data part of your
ORM diagram that falls within the implementation boundary as follows.
-
Produce a flat relational database scheme that has no potential redundancy and
no potential nulls. Include a specification of the inclusion dependencies and
keys.
-
Produce a nested relational database scheme in NNF. Select good roots for your
scheme trees.
-
Do any needed basic structural adjustments to your NNF schemes,
so that they will be cost effective for your application. Justify any
adjustments you make. (Adjustments
for computed relationship sets and data structures come later.)
Object-Module Design
Use the techniques in Chapter 11 to convert your specification into a design
as follows.
-
Adjust your cost-effective NNF schemes by adding methods for any computed
relationships such as total estimated cost and total advance requested.
Add types, including bulk types such as arrays and lists where appropriate.
(You may rework your initial ORM diagrams based on what you've learned
and on the feedback you've received.)
-
Transform every state net to a zero-state state net. Add transaction
processing where appropriate.
(You may rework your initial OBM diagrams based on what you've learned
and on the feedback you've received.)
-
Specify object modules for your design. Integrate your data and behavior
designs by creating object modules that appropriately contain both data
and behavior. That is, data for the airline agent should be with the behavior
of the airline agent, and so forth, for the other agents.
If appropriate, properly designate visibility, views, and inheritance.
Implementation
Implement your design. Translate your object modules into the syntax of a
target OODBMS (the correspondence must be clear). Provide "ad hoc" queries
to display hotel and airline reservations and stored travel-application
information.
Documentation
Make adjustments to your analysis, specification, design, and implementation
as may be necessary so that everything works smoothly together and
corresponds as it should. This becomes your final documentation for your
project. Also, write comments (a page or so) about the
development process. Answer questions such as what worked well, what worked
poorly, and why.