How to identify entities and model relationships

Every OOD prompt arrives as a paragraph of English. The mechanical move that turns it into a class diagram is the same one you were taught for grammar, applied to design: underline the nouns, underline the verbs, then decide which nouns actually deserve to be classes.

Nouns become candidate entities

Read the prompt and mark every noun. "A library lets members check out books. Each book has a limited number of copies. A member can have at most five books checked out at once, and each checkout is due back in three weeks." That sentence hands you Library, Member, Book, Copy, Checkout - five candidates before you've designed anything.

Not every noun clears the bar to become its own class, though. The filter is:

Does this noun have its own identity and lifecycle, or is it just a property of another noun?

A Book's title and isbn are properties - they don't exist independently of the book and nothing needs to track one on its own. A Copy, on the other hand, has its own identity even though it's "just" a physical instance of a Book: two copies of the same title can have different conditions, different current locations, and one can be checked out while the other sits on the shelf. That's the test that promotes Copy from "field on Book" to "class of its own."

Verbs become candidate methods

Now underline the verbs: "lets members check out books", "check out at most five", "due back in three weeks". Each verb becomes a method on whichever entity owns the data it needs. checkOut(member, copy) needs to touch both a member's current loan count and a copy's availability, which is usually a sign it belongs on whichever entity is the natural coordinator - here, something like a Library or a CheckoutService, not on Copy itself, since a Copy shouldn't need to know the library-wide five-book rule to answer "am I available".

Try it yourself: take "a restaurant lets customers place an order for one or more dishes from the menu, and a chef marks each dish as prepared once it's cooked" - underline the nouns and verbs yourself, decide which nouns are entities versus fields (does a Dish on an order need its own identity separate from the Dish on the menu?), before reading any further.

Tag every word in that same sentence below - click a word to cycle it through Entity, Field, Method and Skip, then check your tags against the identity-and-lifecycle reasoning from this page:

Tag it yourself

Wire the entities together with the relationship vocabulary

Once you have entities and methods, the class relationships page's four flavors - association, dependency, composition, aggregation - tell you how to connect them. Walk the worked example through all four:

• Library and Book: composition. A book catalog entry has no reason to exist outside some library's catalog in this design - delete the library, the catalog goes with it.
• Book and Copy: aggregation. A book's copies can be added or withdrawn from circulation independently of the book entity's own record continuing to exist; the copy's lifecycle isn't strictly tied to the book's.
• Member and Checkout: association. A member accumulates checkouts over time, but neither owns the other's lifecycle - a member exists before their first checkout and after their last one.
• Checkout and Copy: association, time-bounded. A Checkout references a specific Copy for the loan period without owning it; when the loan ends, the copy simply becomes available again, unaffected.
• CheckoutService and Book/Member: dependency. The service takes them as parameters to do its work but holds no permanent reference to either.

Run it end to end

Trace one scenario through the result: a member checks out a copy. CheckoutService.checkOut looks up the member's current loan count (a Member responsibility), finds an available Copy of the requested Book (a Book/Copy responsibility), and creates a Checkout linking them with today's date and a due date three weeks out. If any of those lookups can't find what it needs, that's where you decide what "the library is fully booked out" actually returns - and that decision only becomes visible once you've done the noun/verb extraction and traced a real case through it, which is exactly why step 6 of approaching OOD interviews - walking use cases against the diagram - catches gaps that staring at the diagram alone never will.

Check yourself

Question 1 of 3

"A Librarian checks out a Book to a Member" - which word is most likely to become a class rather than a method?