AddressBookExample/ 000755 000770 000024 00000000000 11540727001 015035 5 ustar 00bjork staff 000000 000000 AddressBookExample/._.DS_Store 000755 000770 000024 00000000122 11542137350 016737 0 ustar 00bjork staff 000000 000000 Mac OS X 2 R TEXTLMAN AddressBookExample/PaxHeader/.DS_Store 000755 000770 000024 00000000201 11542137350 020471 x ustar 00bjork staff 000000 000000 20 ctime=1300813522
20 atime=1358863241
22 SCHILY.fflags=arch
24 SCHILY.dev=771751956
25 SCHILY.ino=7294054661
18 SCHILY.nlink=1
AddressBookExample/.DS_Store 000755 000770 000024 00000036004 11542137350 016532 0 ustar 00bjork staff 000000 000000 Bud1
s D i a g r C l a s s D i a g r a m . h t m lIlocblob K "џџџџџџ C l a s s L i n k s . h t m lIlocblob K Ђџџџџџџ C o d edsclbool C o d efwi0blob |clmv C o d efwswlong C o d efwvhshor I m a g e sfwi0blob icnv I m a g e sfwswlong b
i n d e x . h t m lIlocblob K Ђџџџџџџ J a v a d o cIlocblob K bџџџџџџ J a v a d o cdilcblob џџўKџџџb пь 3фџџџџџџ J a v a d o cdsclbool J a v a d o cfwi0blob | g§Lclmv J a v a d o cfwswlong b J a v a d o cfwvhshor R e q u i r e m e n t s . h t m lIlocblob Ы тџџџџџџ S e q u e n c e s . h t m lIlocblob K тџџџџџџ @ @ @ @ E
DSDB ` @ @ @ E DSDB ` @ @ @ AddressBookExample/._Maintenance.html 000755 000770 000024 00000000122 11540471450 020364 0 ustar 00bjork staff 000000 000000 Mac OS X 2 R TEXT џџџџ AddressBookExample/PaxHeader/Maintenance.html 000755 000770 000024 00000000202 11540471450 022117 x ustar 00bjork staff 000000 000000 20 ctime=1300813522
20 atime=1358754721
22 SCHILY.fflags=arch
24 SCHILY.dev=771751956
26 SCHILY.ino=10943358660
18 SCHILY.nlink=1
AddressBookExample/Maintenance.html 000755 000770 000024 00000011274 11540471450 020161 0 ustar 00bjork staff 000000 000000
Maintenance
Maintenance
This page lists various changes that might be made to the system. Modifying the
various documents and program to incorporate one or more of these changes would
make an interesting exercise for the reader. They are listed in order of estimated
increasing difficulty.
The Print Mailing Labels Use Case prints all the information about a
person in "mailing label" format. Of course, a phone number doesn't
appear on a mailing label. A new use case (perhaps called Print All) might be
added that prints all information.
Another piece of information that might be valuable to store about a
person is the individual's email address. Adding this would require
including this information in the relevant use cases (Add, Edit, Print All,
Find/Find Again). (Of course, if a Labels Use Case were added, the email
address would not be included in it.)
It was noted in the orginal requirements that the program might be modified
to allow multiple address books to be open at the same time - each in its
own window. This might entail the following changes:
The Create New Address Book and Open Existing Address Book Use Cases
would no longer close the current address book. Instead, they
would create a new copy of the GUI, with its own address book
(either a newly created, empty one, or one read from a file
specified by the user.) There would thus be two (or more) windows
visible on the screen.
A new Close Address Book Use Case would be added to allow the
user to close a single window (and its associated address book).
This could be initiated by a new Close option in the File menu,
or by clicking the close box for the window.
It would offer to save changes, if necessary, and then close
the window. If the window that is closed is the last open
window in the program, then the program should be terminated as
well; otherwise, the program would continue running
with the remaining window(s) visible.
The code that is activated when the close box for the window
is clicked would be the Close Address Book Use Case described
above, instead of the Quit Program Use Case.
The Quit Program Use Case (activated from the Quit item in the
File menu) would need to cause all open windows
to be closed, with appropriate offers to save changes, unless
the user cancels the operation for any window.
If the user cancels the save for any window, the entire use
case would terminate at once, without attempting to close
additional windows.
The existing searching facility looks for persons that contain a
given value in one of their fields - e.g. a search for "son" would find
persons named Johnson, Peterson, ... as well as individuals living in
Johnson City, Tennessee ... An alternative would be a search that looks for
an exact match between the search criterion and the value contained
in some field - e.g. a search for "Johnson" would find a person named "Johnson"
but not person living in "Johnson City", though a search for "Buffalo" would
find both Bill Buffalo and a person living in Buffalo, NY, since in the
first case the last name field contains an exact match for the desired value,
and in the second case the city field does. A facility might be added that
allows a user request such searches; in this case "Find Text Again" might
continue the last type of search that was requested (contains or exact match.)
Some good practice in working with UML might come by modifying the various design
documents (beginning with the use cases), not just changing the code.
AddressBookExample/._index.html 000755 000770 000024 00000002614 11540413731 017257 0 ustar 00bjork staff 000000 000000 Mac OS X 2 R :TEXTLMAN 2 /Applications/Safari.app r.app 2 Й 2 usro
џџ A AddressBookExample/PaxHeader/index.html 000755 000770 000024 00000000201 11540413731 021001 x ustar 00bjork staff 000000 000000 20 ctime=1300813522
20 atime=1358862071
22 SCHILY.fflags=arch
24 SCHILY.dev=771751956
25 SCHILY.ino=6891831277
18 SCHILY.nlink=1
AddressBookExample/index.html 000755 000770 000024 00000001352 11540413731 017040 0 ustar 00bjork staff 000000 000000
A Simple Example of Object-Oriented Design: An Address Book
AddressBookExample/._UseCases.html 000755 000770 000024 00000000253 11756512242 017666 0 ustar 00bjork staff 000000 000000 Mac OS X 2 y Ћ TEXT џџџџ ATTR-5з Ћ com.apple.TextEncoding UTF-8;134217984 AddressBookExample/PaxHeader/UseCases.html 000755 000770 000024 00000000201 11756512242 021413 x ustar 00bjork staff 000000 000000 20 ctime=1337627810
20 atime=1358865527
22 SCHILY.fflags=arch
24 SCHILY.dev=771751956
25 SCHILY.ino=9348416215
18 SCHILY.nlink=1
AddressBookExample/UseCases.html 000755 000770 000024 00000035671 11756512242 017465 0 ustar 00bjork staff 000000 000000
Use Cases for a Simple Address Book
Use Cases for a Simple Address Book
In the following, use cases are listed in the natural order that a user would
think of them. In the actual File menu, items that correspond to the various
use cases will be listed in the traditional order, which is slightly different.
(Click on a use case above to go to the flow of events for that use case)
Flows of Events for Individual Use Cases
Add a Person Use Case
The Add a Person use case is initiated when the user clicks the "Add" button in the main window.
A dialog box appears, with title "Enter new Person", containing fields for the user to fill in the
new person's first and last names and other information. The box can be dismissed by clicking
either "OK" or "Cancel". If the "OK" button is clicked, a new person is added to the end of the
address book, and the person's name is added to the end of the list of names in the main window,
and the "Save" option in the File menu is enabled. If the "Cancel" button is clicked, no changes
are made either to the address book or to list of names in the window or its File menu "Save" option.
An attempt to add a person with the exact same first and last name as that of an existing person
(case-sensitive) will result in an error dialog instead.
Edit a Person Use Case
The Edit a Person use case is initiated when the user either highlights a name in the list of names
in the main window and then clicks the "Edit" button, or the user double-clicks a name. In either
case, a dialog box, with title "Editing person's name", appears containing current information
about the person selected, (except the person's name, which appears only in the title). The user can
then edit the individual fields. The box can be dismissed by clicking either "OK" or "Cancel".
If the "OK" button is clicked, the entry in the address book for the selected person is
updated to reflect any changes made by the user,
and the "Save" option in the File menu is enabled. If the "Cancel" button is clicked, no changes
are made to the address book or to the File menu "Save" option.
Delete a Person Use Case
The Delete a Person use case is initiated when the user highlights a name in the list of names
in the main window and then clicks the "Delete" button. A dialog box appears, asking the user
to confirm deleting this particular individual. The box can be dismissed by clicking either "Yes"
or "No". If the "Yes" button is clicked, the entry in the address book for the selected person
is deleted, and the person's name is deleted from the list of names in the main window,
and the "Save" option in the File menu is enabled. If the "No" button is clicked, no changes are
made either to the address book or to the window or its File menu "Save" option.
Sort Entries by Name Use Case
The Sort Entries by Name use case is initiated when the user selects the Sort by Name option in
the Sort menu. The entries in the address book are sorted in ascending order by last name, and the
list in the main window is updated to reflect this order as well. (In the case of two individuals
with the same last name, the order is determined by ascending order of their first names.)
Also, the "Save" option in the File menu is enabled.
Sort Entries by ZIP Use Case
The Sort Entries by ZIP use case is initiated when the user selects the Sort by ZIP option in the
Sort menu. The entries in the address book are sorted in ascending order by ZIP code, and the
list in the main window is updated to reflect this order as well. (In the case of two individuals with
the same ZIP code, the order is determined by name order as in the "Sort Entries by Name" use case.)
Also, the "Save" option in the File menu is enabled.
Find Text Use Case
The Find use case is initiated when the user selects the Find option in the Search menu.
A dialog box appears, asking the user to specify text to search for. The box can
be dismissed by clicking either "OK" or "Cancel". If the "OK" button is clicked, the program
begins searching for the specified text either just after the highlighted
individual, or at the beginning of the address book if there if no highlighted individual.
The program highlights the first person it finds for which the desired text is a
substring of the person's name or any other field, and the "Find Again" option is
enabled. (If no such person is found before the end of the address book, the program pops
up a dialog indicating that no match was found.)
If the "Cancel" button is clicked instead, nothing further is done.
Find Text Again Use Case
The Find Again use case is initiated when the user selects the Find Again option in the Search menu.
(The Find Again option is disabled (grayed out) at program startup, or when an address book is
first created or read from disk, or is changed by an Add, Edit, or Delete operation, or when the
most recent Find or Find Again was unsuccessful.
It is enabled when a Find succeeds and remains enabled through successive Find Again operations
that succeed.) The program begins searching for the text specified for the most recent
Find, just after the last individual found by the most recent Find or Find Again. The
program highlights the first person it finds for which the desired text is a substring of the
person's name or any other field. (If no such person is found before the end of the address
book, the program pops up a dialog indicating that no match was found, and the "Find Again"
option is disabled.)
Print Mailing Labels Use Case
The Print Mailing Labels use case is initiated when the user chooses "Print Mailing Labels" from the File menu.
A file chooser dialog is popped up, which allows the user to specify a file to write the
address book to. If the user specifies a file and clicks "Print", the name and
complete address for each
person in the address book is written out to this file (in their current order) in "mailing label"
format. [ Recall that mailing label format includes the full name and complete address but
not the phone number. ] (If attempting to write the file results in an error, a dialog box is displayed warning
the user of the error.) If the user cancels the dialog or closes it without specifying a file,
nothing is written. In any case, no information maintained by the program is changed.
Create New Address Book Use Case
The Create a New Address Book use case is initiated when the user chooses "New" from the File menu.
If the "Save" option in the File menu is enabled, the Offer to Save Changes extension is executed
first. Unless the user cancels the operation, or if the extension is not needed, a new empty address
book is then created and replaces the current address book. This results in the list of names
in the main window being cleared, the current file becoming undefined, the title of the window
becoming "Untitled", and the "Save" option in the File menu being disabled. (NOTE: These conditions
will also be in effect when the program initially starts up.)
Open Existing Address Book Use Case
The Open Existing Address Book use case is initiated when the user chooses "Open" from the File menu.
If the "Save" option in the File menu is enabled, the Offer to Save Changes extension is executed
first. Unless the user cancels the operation, or if the extension is not needed, a load file dialog
is displayed and the user is allowed to choose a file to open. Once the user chooses a file,
the current address book is replaced by the result of reading in the specified address book.
This results in the list of names in the main window being replaced by the names in the
address book that was read, the file that was opened becoming the current file, its
name being displayed as the title of the main window, and the "Save" option in the File menu
being disabled. (If the user cancels the file dialog, or attempting to read the file results in an
error, the current address book, window, and "Save" option in the File menu are left unchanged.
If the cancellation results from an error reading the file, a dialog box is also displayed warning
the user of the error.)
Save Address Book Use Case
The Save Address Book use case is initiated when the user chooses "Save" from the File menu.
If there is a current file, the current address book is saved to this file, and the "Save"
option in the File menu is disabled, but the current address book and window list are left
unchanged. (If attempting to write the file results in an error, a dialog box is displayed
warning the user of the error, and the "Save" option is not disabled.) However, if there is
no current file, the Save Address Book As .. use case is invoked in place of this use case.
Save Address Book As ... Use Case
The Save Address Book As ... use case is initiated when the user chooses "Save As ..." from the File
menu, or when the user attempts to Save an address book for which there is no current file.
A save file dialog is displayed and the user is allowed to choose the name of a file in which to
save the address book. The current address book is saved to this file, the file to which it was
saved becomes the current file for future "Save" operations, its name is displayed as the title
of the main window, and the "Save" option in the File menu is disabled, but the current address book
and window list are left unchanged. (If the user cancels the file dialog, or there is an error
writing the file, the Save As ... operation is canceled, and no changes are made; if
attempting to write the file results in an error, a dialog box is displayed warning the user of the
error as well.)
Quit Program Use Case
The Quit Program use case is initiated when the user chooses "Quit" from the File menu, or clicks
the close box for the main window. In either case, if the "Save" option in the File menu is enabled,
the Offer to Save Changes extension is executed first. Unless the user cancels the operation, or
if the extension is not needed, the program is terminated. (If the user chooses to save changes and
then cancels this operation or it fails due to an error writing a file, the quit operation is
cancelled as well.)
Offer to Save Changes Extension
The Offer to Save Changes extension is initiated from within the Create New Address Book, Open Existing
Address Book, or Quit program use cases, if the "Save" option in the File menu is enabled (indicating
that the current address book has been changed since the last successful
New, Open, Save, or Save As ... operation was done). A dialog box is displayed, informing the user
that there are unsaved changes, and asking the user whether to save changes, not save changes, or
cancel the operation. If the user chooses to save changes, the Save Address Book Use Case is executed
(which may result in executing the Save Address Book As ... Use Case if there is no current file).
If the user chooses not to save changes, the original operation is simply resumed. If the user chooses
to cancel, or cancels the save file dialog if one is needed, or there is an error writing a
file, the original operation that initiated this extension is canceled as well.
Though the pages are copyrighted, I hereby freely give permission for their
reproduction for non commercial educational purposes. I hope they will prove useful
to other faculty who are teaching OO methods.
I would also really welcome suggestions and
feedback - either about the design itself or the way it is presented. Input
from UML guru's would especially be appreciated, as I am revising these pages in part
as a way to learn UML myself!
Russell C. Bjork
Professor of Computer Science Gordon College
255 Grapevine Road
Wenham, MA 01984
(978) 927-2300 x 4377
russell.bjork at gordon dot edu
An initial reading of the use cases suggests that the following will be
part of the system.
A single entity object representing the current address book that the program
is working with (AddressBook).
An arbitrary number of entity objects, each representing one of the people that
is in the current address book (Person).
A boundary object representing the interface between the address book system
and the human user (AddressBookGUI).
A boundary object representing the interface between the address book system
and the file system on disk (FileSystem).
A controller object that carries out the use cases in response to user
gestures on the GUI (AddressBookController). (For a problem
of this small size, a single controller is sufficient.)
The various use cases work with these objects, as follows:
The Add a Person Use Case involves getting the new information from the
user, and then telling the AddressBook object to add a new person with this
information to its collection
The Edit a Person Use Case involves displaying the current information about the
desired person (obtained from the AddressBook), then allowing the user
to enter new information for the various fields, then telling the AddressBook
object to make the changes.
The Delete a Person Use Case involves asking the user to confirm deletion, and then
telling the AddressBook object to remove this person from its collection.
The Sort Entries by Name Use Case involves telling the AddressBook object to
rearrange its collection in order of name.
The Sort Entries by ZIP Use Case involves telling the AddressBook object to
rearrange its collection in order of ZIP.
The Find Text Use Case involves the GUI getting text to search for, asking
the AddressBook object to find the next matching Person, and then highlighting
that person (or displaying a not found dialog).
The Find Text Again Use Case involves the GUI asking the AddressBook object to find
the next Person matching the previously-entered text, and then highlighting
that person (or displaying a not found dialog).
The Create New Address Book Use Case involves creating a new AddressBook object.
The Open Existing Address Book Use Case involves getting a file specification
from the user, and then telling the FileSystem object to read in an AddressBook object
from this file.
The Save Address Book Use Case involves determining whether or not the current
AddressBook object has a file it was last read from / saved to; if so, telling
the FileSystem object to save the current AddressBook object to this file. (If not,
the Save Address Book As ... Use Case is done instead.)
The Save Address Book As ... Use Case involves getting a file specification from
the user, and then telling the FileSystem object to save the current AddressBook object
to this file.
The Print Address Book Use Case involves telling the AddressBook object to
print out its collection in order.
(The Quit Program Use Case does not involve any of the other objects)
(The Offer to Save Changes Extension may involve performing the Save Address Book
Use Case.)
AddressBookExample/._ClassDiagram.html 000755 000770 000024 00000000122 10226575272 020503 0 ustar 00bjork staff 000000 000000 Mac OS X 2 R TEXTLMAN AddressBookExample/PaxHeader/ClassDiagram.html 000755 000770 000024 00000000201 10226575272 022235 x ustar 00bjork staff 000000 000000 20 ctime=1300813522
20 atime=1358753440
22 SCHILY.fflags=arch
24 SCHILY.dev=771751956
25 SCHILY.ino=7357436768
18 SCHILY.nlink=1
AddressBookExample/ClassDiagram.html 000755 000770 000024 00000011631 10226575272 020275 0 ustar 00bjork staff 000000 000000
Class Diagram for the Address Book Example
Class Diagram for the Address Book Example
Shown below is the class diagram for the Address Book Example. To prevent the diagram from
becoming overly large, only the name of each class is shown - the attribute and
behavior "compartments" are shown in the detailed design, but are omitted here.
The diagram includes the classes discovered during analysis, plus
some additional classes discovered during design. (In a more significant system,
the total number of classes may be about five times as great as the number
of classes uncovered during analysis.)
AddressBookApplication - main class for the application; responsible for
creating the FileSystem and GUI objects and starting up the application.
MultiInputPane - a utility class for reading multiple values at a single
time. (Design not further documented, but javadoc is included.)
Person.CompareByName - Comparator for comparing two Person objects by
name (used for sorting by name).
Person.CompareByZip - Comparator for comparing two Person objects by
zip (used for sorting by name).
The following relationships hold between the objects:
The main application object is responsible for creating a single file system
object and a single controller object.
The file system object is responsible for saving and re-loading address books
The controller object is responsible for creating a single GUI object.
The controller object is responsible for initially creating an address book
object, but the GUI is henceforth responsible for keeping track of its
current address book - of which it only has one at any time.
The GUI object and the address object are related by an observer-observable
relationship, so that changes to the address book content lead to
corresponding changes in the display
The address book object is responsible for creating and keeping track of
person objects, of which there can be many in any given address book.
A MultiInputPane object is used by the controller to allow the user to
enter multiple items of data about a person.
A comparator object of the appropriate kind is used by the address book
object when sorting itself.
Click on a class icon for links to further information about it
AddressBookExample/Code/ 000755 000770 000024 00000000000 11540741455 015720 5 ustar 00bjork staff 000000 000000 AddressBookExample/._CRCCards.html 000755 000770 000024 00000000122 11540464360 017530 0 ustar 00bjork staff 000000 000000 Mac OS X 2 R TEXT џџџџ AddressBookExample/PaxHeader/CRCCards.html 000755 000770 000024 00000000201 11540464360 021262 x ustar 00bjork staff 000000 000000 20 ctime=1300813522
20 atime=1358753357
22 SCHILY.fflags=arch
24 SCHILY.dev=771751956
25 SCHILY.ino=7956315748
18 SCHILY.nlink=1
AddressBookExample/CRCCards.html 000755 000770 000024 00000021031 11540464360 017315 0 ustar 00bjork staff 000000 000000
CRC Cards for the Address Book Example
CRC Cards for the Address Book Example
Responsibilities are assigned to the various classes based on the use of the
model-view-controller design pattern. The two entity classes (AddressBook
and Person) serve as the model. The GUI class (AddressBookGUI) serves as the
view. The controller class (AddressBookController) serves, of course, as
the controller.
The view (AddressBookGUI) needs to be made an observer of the model
(specifically, AddressBook) so that it always reflects the current state of
the model - specifically, the list of names, the title, and its saved/needs to
be saved status.
Using CRC cards to assign responsibilities to various classes for the tasks required by the
various use cases leads to the creation of the following cards.
Maintain the state of the "Save" menu option - usable only when
the address book has been changed since the last time it was opened / saved.
Maintain the state of the "Find Again" menu option - usable only when
the last Find operation was successful and the address book has not been
change subsequently
Allow the user to request the performance of a use case
The Java mechanisms to protect against malicious code limit access to the file
system on the host computer. For this reason, it is not possible to use the
"Open", "Save", "Save As" or "Print Mailing Labels" features of this
demonstration - attempting to do so will result in an error dialog.
(This will also happen if an attempt
is made to save a file when performing a GUI window close or "Quit" operation.)
What happens upon Closing the window or choosing the "Quit" is browser
dependent. Reloading the page should restart the program - though
this also may be browser dependent.
Requirements and User Interface for a Simple Address Book
Requirements Statement
The software to be designed is a program that can be used to maintain an address book.
An address book holds a collection of entries, each recording a person's first and
last names, address, city, state, zip, and phone number.
It must be possible to add a new person to an address book, to edit existing
information about a person (except the person's name), and to delete a person.
It must be possible to sort the entries in the address book alphabetically by
last name (with ties broken by first name if necessary), or by ZIP code (with
ties broken by name if necessary).
It must be possible to search for an entry containing a given text in the
person's name or other information about the person.
It must be possible to print out all the entries in the address book in
"mailing label" format.
It must be possible to create a new address book, to open a disk file containing
an existing address book to close an address book, and to save an address book to
a disk file, using standard New, Open, Close, Save and Save As ... File menu options.
The program's File menu will also have a Quit option to allow closing all open
address books and terminating the program.
The initial requirements call for the program to only be able to work with a single
address book at a time; therefore, if the user chooses the New or Open menu option,
any current address book will be closed before creating/opening a new one. A later
extension might allow for multiple address books to be open, each with its own
window which can be closed separately, with closing the last open window resulting
in terminating the program. In this case, New and Open will result in creating
a new window, without affecting the current window.
The program will keep track of whether any changes have been made to an address book
since it was last saved, and will offer the user the opportunity to save changes
when an address book is closed either explicitly or as a result of choosing
to create/open another or to quit the program.
The program will keep track of the file that the current address book was
read from or most recently saved to, will display the file's name as the title of the
main window, and will use that file when executing the Save option. When a
New address book is initially created, its window will be titled "Untitled", and
a Save operation will be converted to Save As ... - i.e. the user will be required
to specify a file.
User Interface
Because this is to be a "standard GUI" style application, some attention needs to be
given to the user interface at this point. A user interface like the following might
be adopted. Not shown in the screen shot are the options in the "File" menu (New,
Open, Save, Save As ..., Print, and Quit), the "Sort" menu (Sort by Name
and Sort by ZIP) and the "Search" menu (Find and Find Again). For the "Edit" and
"Delete" buttons, the user must first select a person in the scrolling list of
names, and then can click the appropriate button to edit/delete that person.
This page is the starting point into a series of pages that attempt to give a
complete example of object-oriented analysis, design, and programming applied to
a small size problem: a simple address book. These pages are similar in style to
another, more complicated set of pages I developed earlier:
A Simulation of an Automated Teller Machine (ATM).
I developed both that set of pages and this in the belief that students would benefit
from seeing a complete example of OO methodology applied to a single problem.
The problem documented by this set of pages is much simpler than the ATM
Example, and so is more accessible to undergraduate students seeing OO methodology
and UML for the first time.
Beginning with a statement of requirements, the process proceeds through analysis,
overall design, detailed design, and implementation in code.
Background
The original idea for this example came from a textbook example in the book I used
for my Introduction
to Programming course - An Introduction to Object-Oriented Programming
with Java by C. Thomas Wu. (This particular course was replaced by a
different course in a recent revision of our curriculum.)
The first time I taught that course (in the spring of 2000), I turned this example
into a set of labs and a project which culminated in having students develop a fairly
complete GUI for the address book (which went far beyond the example in Wu's book).
In subsequent years, I have improved the labs and the project, giving my students some
design information in the form of various UML diagrams. More recently, I decided
that working this up into a complete example of the design process, using UML, could
be a valuable teaching tool in my Object-Oriented Software Development course, which many of
the students who take the new
version of our Introduction to Programming course take the following semester.
This example also illustrates the Model-View-Controller and Observer design patterns.
In the past I used a
vastly-simplified version of these pages for a project in the
old Introduction to Programming course. I currently use an intentionally
"broken" version of this program in a lab on Testing in the Object-Oriented
Software Development course. This version of these pages is a revision that
incorporates some ideas from both the project and the lab. (The previous
version is available at a site for a course from our previous curriculum.)
It may be argued that more diagrams have been used than are really necessary for
a project of this size. I wanted to give an example of using a variety of
different UML diagrams. Even so, this example does not include any
statechart, collaboration, package, activity, component, or deployment diagrams.
Note: Some of the diagrams have been deliberately omitted from the various pages.
Students taking my course will no doubt come to understand the phrase "... has been
left as an exercise for the reader"!
Using these Pages
Probably the best way to start using these pages is to begin with the requirements
and work through the entire analysis, high-level design, and detailed design process.
Begin with the Requirements and User Interface document.
The first task that must be performed in any project is clearly understanding
the requirements. This series of pages starts with a statement of the overall
requirements for the software, without attempting to discuss the process of
actually arriving at them. For a problem of this size, identifying
the requirements is fairly straightforward. In a real system, however,
identifying the requirements will generally be a non-trivial task. That,
however, is not the focus of this set of pages.
Then view the Use Cases and Further Analysis.
Analysis is begun by identifying the use cases that follow from the requirements,
and detailing a flow of events for each. Further analysis identifies the key
classes that are suggested by the use cases, and considers how each use case
can be carried out by an interaction between objects belonging to these classes.
The Use Case document has a Use Case Diagram and a series of flows of events,
one for each use case. Each use case also has a link to a Sequence Diagram
(part of the Design phase) which shows how it is realized; these links can
be followed while studying the design phase to see how the analysis phase
flows into the design phase.
The Further Analysis document deals with both the "big picture" and the
details of the various use cases. The former is provided by an Analysis
Class Diagram, with each class having a link to its CRC card; the latter
by a discussion of how the key objects objects would need to interact in
order to implement the use case.
These two documents represent two different ways of viewing the overall system,
which continue into the next phase. The Use Case document presents a
use-case centric view of the system, focussing on the specific functions it
provides. The Further Analysis document presents a class centric view of
the system, focussing on how will be built.
This example uses CRC Cards and Sequence Diagrams for high level Design. There
are certainly other tools that might be used - e.g. the ATM Example referred
to above makes use of Collaboration Diagrams and State Charts as well.
The responsibilities of each class that arise from the use cases are
recorded on a CRC card for each class. The CRC cards could be created
by "walking through" each use case, assigning the responsibility for each
task to some class.
There is a Sequence Diagram for each use case, showing how the use case
is realized by interaction of the major objects.
A Class Diagram shows how the various classes are related to one another.
It also shows several additional classes that were "discovered" during
the process of creating the Sequence Diagrams - i.e. classes needed to
actually build the system, though not evident in the original analysis.
On this diagram, the class icon is linked to a detailed design for that class.
Detailed design is done by using a detailed UML diagram for each class, showing
its attributes and operations.
Both source code and "Javadoc" documentation is available for all classes.
A demonstration executable version of the the system is available, in the
form of a Java Applet. This version is limited, because the Java mechanisms
to protect against malicious code limit access to the file system on the
host computer. For this reason, it is not possible to use the "Open", "Save",
or "Save As" features of the demonstration - attempting to do so will result
in an error dialog.
A page of maintenance ideas suggests changes that might be made to improve
the system. These changes would necessarily involve modifying many of
the sample documents, not just modifying code.
Author and Copyright Information
Though the pages are copyrighted, I hereby freely give permission for their
reproduction for non commercial educational purposes. I hope they will prove useful
to other faculty who are teaching OO methods.
I would also really welcome suggestions and
feedback - either about the design itself or the way it is presented. Input
from UML guru's would especially be appreciated, as I am revising these pages in part
as a way to learn UML myself!
Russell C. Bjork
Professor of Computer Science Gordon College
255 Grapevine Road
Wenham, MA 01984
(978) 927-2300 x 4377
russell.bjork at gordon dot edu
AddressBookExample/._Sequences.html 000755 000770 000024 00000000122 11540465070 020076 0 ustar 00bjork staff 000000 000000 Mac OS X 2 R TEXT џџџџ AddressBookExample/PaxHeader/Sequences.html 000755 000770 000024 00000000202 11540465070 021631 x ustar 00bjork staff 000000 000000 20 ctime=1300813522
20 atime=1358763122
22 SCHILY.fflags=arch
24 SCHILY.dev=771751956
26 SCHILY.ino=10864409343
18 SCHILY.nlink=1
AddressBookExample/Sequences.html 000755 000770 000024 00000011364 11540465070 017673 0 ustar 00bjork staff 000000 000000
Sequence Diagrams for the Address Book Example
Sequence Diagrams for the Address Book Example
Each of the use cases discovered in the analysis of the system will be
realized by a sequence of operations involving the various objects comprising
the system.
AddressBookExample/._ClassDesign.html 000755 000770 000024 00000000122 10226575053 020345 0 ustar 00bjork staff 000000 000000 Mac OS X 2 R TEXTLMAN AddressBookExample/PaxHeader/ClassDesign.html 000755 000770 000024 00000000201 10226575053 022077 x ustar 00bjork staff 000000 000000 20 ctime=1300813522
20 atime=1358754157
22 SCHILY.fflags=arch
24 SCHILY.dev=771751956
25 SCHILY.ino=9677940795
18 SCHILY.nlink=1
AddressBookExample/ClassDesign.html 000755 000770 000024 00000005555 10226575053 020147 0 ustar 00bjork staff 000000 000000
Detailed Class Design for the Address Book Example
Detailed Class Design for the Address Book Example
Given below is a "three compartment" design for the classes appearing in the
class diagram. This information was not included in that diagram due
to size considerations; however, it could have been - in which case this
document would have been unnecessary.