The design documentation is a complete clear description of how the program is organized. It is language$-$independent

describing the overall program structure. The more time spent designing, the less time changing and debugging.

Class diagrams pictorially describe the classes and their static relationships from which a system is built. Often high$-$

level pseudocode is included for the algorithms used by methods which show the flow of the program. All other

functions clearly define the task they perform $($a function performs one task$).$ Class diagrams include descriptions of

$--$ Generalization$/$Inheritance $($parent$/$child classes$),$

$--$ Aggregation$/$Composition $($construction of complex objects from simpler ones$)$

Besides class diagrams and class descriptions $($see below$),$ show data structures, actual memory used. Give each

piece context $($how it fits, object that owns it$)$ so that it makes sense. Additionally, describe interaction of objects via

pseudocode for essential use cases. Describe instantiations, actual objects and the methods called to accomplish the

task. Imagine that someone other than you will implement it$,$ and then extend your program; or you will have to

implement someone else's design. This must be a good object$-$oriented design. This means everything except very

basic data is an object. Do NOT store data as long concatenated strings, violating good OO design. Strings are not

parameters in any methods. Use strings for only one item such as one name. Do NOT concatenate strings anywhere.

Design beyond the specifications $($in the UML you turn in$).$ Design so that the answer to all these questions is yes

$($maintaining good design principles$).$ Could you easily add more hard copies to your design? Can you easily add

other categories of books? Could you easily add other kinds of formats, for example, digital? Could you easily add new

media to your design, for example, music? Could you expand to check out other kinds of items, for example, digital

players? Could you easily add new operations to your design, for example, buy? Could you incorporate time, for

example, a due date for checked out items? Could you easily add an additional library, or handle a library system?

You must make your design more extensive $($show in just the UML you turn in$)$ than the assignment $($the specs$),$ as

extensive as you would like. Include extensions and additions, actual classes, in the UML of the design turned in$.$ You

do not have to implement all the additions of your design, only assignment specifications. Incorporating as much as

you can think of in the design phase helps you design a better, more extensible application.

UML symbols you will use include the inheritance open arrow $($is$-$a$)$ and composition line with diamond $($has$-$a or

part$-$of$)..$ Some things in the UML of the design are best shown as classes. For example, a List class may be

implemented as an STL list, vector, or even as an array, but in the design, it is critical the reader knows it is a

collection, so show a class for it$.$ For typical attributes, say the amount of something, you would not show a class. Do

not show in the UML something used for implementation, such as Node for BinTree. And while you might want to use

the STL often, do NOT. The focus is on inheritance. No STL for Books. Run any template use by me$.$

Content of the Design Spec

Since you are totally designing this program, clear documentation is essential. Hardcopy turn$-$in order:

$--$ System design including $($Use software for creating diagrams, e$.$g$.,$ Visio, draw.io$,$ etc.$)$

$1.$ UML class diagram $($only class names must be included in diagram, although more is fine$).$

$2.$ Data structures picture $($visual of memory organization, actual memory of your primary data structures $$

boxes and arrows$).$ Include overview context. $($Uncommon in a real$-$world design spec.$)($Hand$-$drawn is best.$)$

$3.$ Show how classes interact via pseudocode $($objects$/$methods leading to the Use Cases of insert and check out.$)$

E$.$g$.,$ Insert an item into your database $($from book data file$)$: C Seuss Dr$.,$ Yertle the Turtle, $1950$

E$.$g$.,$ Check out a item $($from commands data file$)$: C $1234$ F H Walker Alice, The Color Purple,

$($On a high level, check out would entail: find the patron; find the book; associate patron with book so it

becomes part of the patron's history; associate book with patron so it$$s known that the book is checked out and

by the patron.$)$ Give objects with methods called, i$.$e$.,$ high$-$level pseudocode, so the functionality can be easily

implemented later. Give pseudocode for calls leading up to where insert and check$-$out are done. What object

does insert$()?$ Does the checking out? Where are the loops doing the reading, leading to insert? Leading to

checking out? Note that conciseness is as important as clarity, i$.$e$.,$ do not burden the reader with low$-$level

coding details.

$--$ Then main: What objects do you have? It is usually very short as all the actual work is done in class functions.

$--$ The $.$h files, with clear$/$complete descriptions of all base$/$derived clas