Three OOD Tricks You Probably Don't Use, But Should
Most of you probably don’t use UML (kudos if you do). If you think UML seems old and complicated, you’re absolutely right. BUT, trust us that it’s still worth your time. It’s similar to how vinyl records are coming back because, let’s face it, you just can’t get the same rich sound with an mp3. UML definitely has it’s limitations (much like vinyl records), but there are a few things it’s still good for. Below are some instances when you should consider using UML.
You should use UML:
-
When creating large, complicated projects.
-
When you need to communicate how the system is going to work to non-developers
Complex systems require extensive planning so you'll want to use the diagrams below to help you prepare for development. Some of you may be thinking "But I'm an Agile developer; I don't need to use UML." I'm not sure where the rumor started, but Agile and UML are not mutually exclusive, so feel free to use UML to plan ahead before starting your first iteration. And sure, you may already know all the information required to develop the system, but skipping these diagrams would be like trying to put together a piece of Ikea furniture without using the directions. Your chair may turn out fine, or you may finish it only to find out that you put a piece on backwards and have to take it apart again (it’s ok, we’ve all been there).
-
Use Case Diagram
Before you get started designing a system, you’ll want to create a use case diagram so you can better understand the users and how they’ll be interacting with the system.
It’s better to be safe than sorry, so take the extra couple minutes to create this diagram. The most important reason you’ll want to create a use case diagram is because it communicates the steps/processes/requirements of the application to both the developer and the BA. Honestly, it will make your job so much easier. Here's a great example to get you started:
-
Class Diagrams
This diagram is one of the most powerful tools used in OOD with UML. Think of this diagram as the blueprints for the application; it illustrates the system structure by outlining the classes, attributes, operations, and relationships among the various objects. Once you have this diagram, developing the application will be a breeze. Yes, it's a pain in the butt to create the diagram, but you'll thank us when it cuts days off of your sprint.
-
State Machine Diagrams (aka Statechart)
This diagram takes the place of a procedural flow chart. Statecharts help you map out how each entity should respond to various internal and external “events.” You probably don’t need to map out the behavior of every single entity (unless you just happen to like tedious, unnecessary work), but there’s guaranteed to be at least be a handful that will require more careful planning. Check out the toaster oven statechart below.
Mirosamek at English Wikipedia
Now you know some tricks to help you plan out your next project. So remember, shortcuts are for suckers. It may seem daunting, but it will actually save you time in the long run.
If you don't know UML, ProTech offers a few different classes that can teach you the essentials. Check out the courses linked below:
Object Oriented Analysis & Design with UML
UML, OO, Java and RUP Fundamentals