SAOD starts with the user, not the database

Most people begin system design by drawing class diagrams and entity relationship models. That is the wrong order. Oriented Systems Analysis And Design Using Uml flips the whole process. You start by figuring out what users are actually trying to accomplish, then you model those goals with use cases before you touch a single class or table. The approach came out of Brazil in the late 1980s at the University of PUC-RS. It is rooted in object-oriented thinking but it refuses to let the object model dictate what the system does. The goal model comes first. Everything else follows.

Oriented Systems Analysis And Design Using Uml: the Methodology

The core idea is simple enough that it sounds almost naive. You identify actors, you describe the use cases those actors perform, you build a goal model that ties everything together, and only after that do you move into structural and behavioral design. The UML portion of this is mostly use case diagrams, sequence diagrams, and class diagrams. But the order matters more than the diagrams themselves. If you draw the class diagram before the use case diagram, you have already lost. You will model the wrong boundaries and you will spend weeks refactoring. I worked on a hospital scheduling platform a few years ago where the client gave us a list of features and expected us to just build it. The traditional waterfall path would have been to jump straight into ER diagrams and start generating code. Instead we spent two solid weeks just on use cases and goal models. The first use case we wrote was called "Schedule emergency override appointment." The client had never mentioned emergency overrides. They had never even thought about them. But nurses needed a way to break the queue when an ambulance arrived. If we had started coding from the feature list, that functionality would have been bolted on as an afterthought six months into development, probably poorly integrated and full of edge cases. The goal model forced us to see that need early.

How the Goal Model Actually Works in Practice

The goal model is the piece that most people skip or treat as an academic exercise. It should not be skipped. In SAOD, goals are broken down using AND and OR refinements. An AND refinement means all subgoals must be satisfied. An OR refinement means at least one path must work. This creates a tree structure that maps directly onto your use cases. When you hit a dead end in the goal model, you know exactly where the requirements are incomplete before you write a single line of code. There is a specific trick here that beginners miss. A lot of people model the same use case multiple times under different goals because they think they are being thorough. They are not. Each use case should map to exactly one primary goal. If you find yourself duplicating use cases, your goal model is wrong, not your use cases. Go back and restructure the goals. This usually takes ten minutes and saves you from having three variants of the same "Cancel Registration" use case that all conflict with each other in the design phase.

Use Case Diagrams in SAOD vs Standard UML

A standard UML use case diagram lists actors and use cases. SAOD does that too but it adds another layer. You annotate which goals drive each use case and you track refinements through the whole diagram. The diagram becomes a living document rather than a static picture you draw once and forget. I use a simple tagging system in my diagrams where each use case has a goal ID attached to it. When the goal changes, the ID flags it and I know exactly which diagrams and sequence specs need updating. This cuts revision time from hours to minutes when a stakeholder says something like "actually, doctors can only cancel appointments within forty-eight hours." The relationship between actors and use cases is where most teams struggle with SAOD. Actors in SAOD are not just humans. A cron job that runs nightly backups is an actor. A payment gateway API is an actor. People often leave these out because they think actors mean people at keyboards. That mistake creates systems that break in production when automated processes try to interact with the boundaries nobody designed for.

Moving From Goals to Class Design

Once the goal model and use case model are stable, you move to the structural model. This is where class diagrams come in. The key principle here is that classes emerge from use cases, not from domain intuition. You look at each use case and ask what objects are responsible for making it happen. You assign responsibilities using the GRASP patterns if you want to be formal about it, but even a basic version of this works far better than guessing at classes upfront. I found this out the hard way on a logistics tracking system. We modeled twenty-three classes before running the use cases through a full traceability check. The use case review revealed that six of those classes had no responsible use case and three use cases had no corresponding class at all. We spent three days deleting the phantom classes and redesigning the missing ones. If we had caught this at the use case stage, it would have been a five-minute adjustment. The cost of catching modeling errors grows exponentially the later you find them.

Common Pitfalls That Waste Weeks

The first pitfall is premature decomposition. People break use cases into too many tiny fragments. A use case called "Place Order" should stay as one use case even if placing an order involves validation, payment processing, and inventory check. Those are sub-flows inside the use case, not separate use cases. Splitting them up creates artificial complexity and makes traceability nearly impossible. Keep use cases at the level of one coherent user goal. The second pitfall is treating the goal model as finished too early. Goals evolve as you uncover edge cases during sequence diagram design. I had a project where the sequence diagrams revealed that the "Refund Payment" goal had an orphan sub-scenario involving partial refunds for split shipments. We added a new goal node and immediately had to update three use case descriptions and two sequence diagrams. That is normal. The goal model should be the last thing you finalize, not the first.

Where SAOD Breaks Down Completely

SAOD is not a universal solution. It struggles with projects where the requirements are genuinely unknown or where the client cannot articulate what they want. The methodology assumes you can sit down with stakeholders and extract clear goals. If you are building a machine learning system where the behavior is probabilistic rather than deterministic, use case models become misleading because the same input can produce different valid outputs. For those cases, agile prototyping with iterative feedback loops works better. It also does not handle legacy system integration well. If you are wrapping an old mainframe in a modern interface, the goal model might look clean but the constraint reality will bite you hard. The old system has its own actors, its own use cases, and its own broken boundaries. SAOD will model what you wish the system could do, not what it actually can do. You need a separate constraint analysis layer for that, usually in the form of interface specifications and adapter patterns that sit outside the SAOD model entirely.

A Practical Walkthrough: Building a Booking System

Let us walk through a concrete example. A regional gym chain wants a membership booking system. The first step is identifying actors. Members, front desk staff, maintenance staff, and a billing service API are the actors. Members book classes. Front desk staff check in members and handle walk-ins. Maintenance staff mark classes as unavailable. The billing service processes payments and triggers cancellations for non-payment. The goal model starts with "Maintain membership access" as the root goal. That refines into OR branches for "New membership registration," "Renewal processing," and "Cancellation handling." Each of those branches has AND subgoals. "Cancellation handling" AND-refines into "Process cancellation request," "Revoke booking access," and "Issue refund if applicable." Now you have three use cases mapped to that goal cluster. The sequence diagram for "Process cancellation request" involves the Member actor sending a cancellation command, the BookingService validating membership status, the PaymentGateway checking refund eligibility, and the MembershipRepository updating the record. That is four classes emerging from one sequence. You do not guess those classes. They appear from the interaction model. I once ran into a weird edge case with a similar system where the billing service API had a thirty-day lag on refund processing. Our model assumed synchronous refunds. When we traced the sequence diagram against the real API contract, we discovered that "Issue refund if applicable" was not actually atomic. It was a two-phase process with a pending state. We added a new ActorState class to track pending refunds and updated the state machine diagram accordingly. Without that traceability pass, the refund feature would have been coded as synchronous and failed silently in production for months.

Tools and Downloadable Resources

You can implement SAOD with standard UML tools. Visual Paradigm, Enterprise Architect, and even draw.io all support use case diagrams, sequence diagrams, and class diagrams. For the goal model specifically, I recommend using a dedicated tool or a spreadsheet with hierarchical rows because most UML tools do not have native goal model support. Lucidchart has basic goal modeling templates if you want something quick. The open-source option is Umbrello on Linux or Modelio which runs on any platform. Both are free and support the full set of UML diagrams you need for SAOD. I use Modelio because it handles traceability matrices well, which means you can export a matrix showing which use cases map to which classes and which goals map to which use cases. That matrix is worth more than any diagram when you are doing a design review.

The Real Takeaway

SAOD is not complicated in theory but it demands discipline in practice. The methodology forces you to answer the question "what are we actually building and why?" before you start answering "how will we build it?" Most projects skip that discipline and pay for it later. The traceability between goals, use cases, and classes is what makes this approach valuable. It is not the diagrams themselves. It is the ability to track every design decision back to a user goal and forward to a concrete implementation element. When that traceability breaks, the project breaks.