Banking Management System — Beatriz Marques

Site under construction — some sections are still being finishedSite under construction — some sections are still being finishedSite under construction — some sections are still being finishedSite under construction — some sections are still being finishedSite under construction — some sections are still being finishedSite under construction — some sections are still being finishedSite under construction — some sections are still being finishedSite under construction — some sections are still being finishedSite under construction — some sections are still being finishedSite under construction — some sections are still being finished

Back to Projects

A console banking application for a first-year OOP unit. Three user roles, six account types, an in-memory data layer. The class diagram came first, the code came second, and they stopped agreeing somewhere in the middle.

Built — 7 Diagram only — 6

Click a class to see what it became.

Nouns survived, verbs didn’t

Seven classes were built. Six stayed on the diagram. The gap is not random: everything that survived is an entity — a thing the system stores. Everything that died is an operation — a thing the system does. We built the nouns and ran out of time on the verbs, so the verbs became static methods with nowhere to live.

That is why the transfer function prints a success message and moves no money. There is no object to hold the transaction, so there is nothing to validate against.

What I would do differently

Building the transaction model first would have forced the menus to be written around it. The order you implement a model in decides how much of it survives.

The diagram as drawn

UML class diagram with thirteen classes, including the Movimento hierarchy that was never implemented — The model as designed, before implementation. The Movimento cluster at the centre is the part that never got written.