June 8, 2005

...Learn TDD with Codemanship

The Object Oriented Analysis & Design Process - Part I

Designing object oriented software is, for many, a mysterious process by which functional requirements are magically transformed into .NET or Java classes. It's by far the most common question I get asked: how do I get from use cases to OO code?

On my travels, I've come across many variations of object oriented analysis and design, but most of them follow a similar thought process. I'm a great believer that analysis and design is not something developers should do by themselves. Scott Ambler, author of The Object Primer and Agile Modeling, recommends the practice of Modeling With Others. Without going into esoteric arguments about why this is a good thing, I assure you that my own experiences have convinced me of the benefits. The resulting designs are usually better, for exactly the same reason that pair programming - when done effectively - usually leads to better code.

When we analyse a problem and design a solution, we go through a thought process, and when we're working with other people, it's useful to be able to externalise our thoughts to help better understand them and to help other people understand what we're talking about.

OOA/D using UML is the practice of following an object oriented problem solving process and externalising your thoughts using UML diagrams. Each diagram is designed to represent different kinds of thoughts.

The OO analysis and design process is actually pretty straightforward - though it takes practice to build an instinct for good design:


    * Identify the users of the system and their functional goals
    * Identify usage scenarios relating to each functional goal
    * Describe the interactions between users and the system during the course of a scenario
    * Identify the objects, attributes, states and relationships involved, and identify what the effects of each interaction are on them
    * Assign responsibility for the effects of interactions to the most appropriate objects
    * Apply the technical architecture & implement the design model in code


In much simpler terms, the goal of OO analysis and design is to describe how users can execute useful tasks in object terms.

How can UML help in each of these thought processes?

Users & Functional Goals

The obvious candidate for visually depicting types of users and the things they can achieve using the system is use case diagrams. Use case diagrams are probably the simplest of the UML diagrams, but it's still easy to go overboard with them. Keep use case diagrams simple - don't cram them full of extend and include relationships, for example.



Usage Scenarios

These are instances of use cases. As far as I'm aware, UML does not include a notation for use case instances. In the UML metamodel, a use case is a classifier - it represents a set of scenarios relating to the same functional goal. For example, the use case withdraw cash might have scenarios like withdraw cash when funds are available and withdraw cash when there are insufficient funds. There is always some condition that defines a usage scenario, so the set of distinct scenarios should be defined by the set of possible conditions that relate to the use case. In that respect, usage scenarios are essentially the same thing as test scenarios. It's a good idea to involve testers in this part of the analysis and design process.

As I mentioned, UML doesn't have a built-in notation for modeling instances of use cases - as far as I know. If you're not constrained by a specific modeling tool - which I recommend you shouldn't be at this stage in the process because the best way to model this kind of stuff is at a whiteboard with other people - then I suggest borrowing the object notation and applying it to use cases, like I've done in this example:



Interactions

By far my favourite way to describe interactions in a usage scenario is with essential use cases. An essential use case describe the flow of that scenario in terms of "actor does this", "system does that". You can easily split your whiteboard up into two columns (or more if more than one actor is involved) and write down the sequence of interactions in the usage scenario:



Alternatively, you could model the same sequence of interactions using a sequence diagram:



You could also, at a pinch, use an activity diagram with swim lanes to show which actions are carried out by the user, and which by the system. The problem with that approach is the actual interactions can be less clear, and an activity diagram can model more than one scenario - which is a mixed metaphor at this stage, since we are considering just the one scenario at a time in our approach.

In the next post, we’ll continue our object oriented thought process by identifying the objects involved in a scenario and describing the interactions in object terms.

Posted 15 years, 8 months ago on June 8, 2005