Tag Archives: OOP

USE CASES IN UML AND OBJECT ORIENTED PROGRAMMING

When I took a Object Oriented Programming Class in my second semester in college, I was not able to understand a lot of concepts essential to software design and architecture. I was new to the concept of Classes, relationships between classes, API and exposing methods and attributes. Of course, that’s why I was taking the class. I could program some fundamental programs in pascal before this and i loved global variables (the fact of the matter is I still love them but probably somebody who is debugging a problem or a bug in my code, probably would not like them). So coming back to the point, the first concept in any Software development methodology is a requirement. Business Analysts would talk to the potential customers and figure out a bunch of requirements. Software Architects or Software Designers would view the requirements and model the requirements in a way that would make sense to a Software Developer. Sometimes a business analyst would be talking to the customer and doing a design, there are no hard and fast rules. The main purpose of UML is to specify requirements and design in a standard format so in a team other people can relate to the requirements and design and write efficient code. In my software development experience, good requirements mean 50% less work and also it would save the rework and costs in terms of testing time, and no hacks in code. Overtime a piece of code gets modified multiple times by different people who like to code differently, so more clear the requirement is, most relevant
code you can write to begin with.

What is a use case ?
I would not go too much technical detail on exactly how it is defined. To me its a functional requirement and that’s what I have read in books as well. Functional requirements of a system can be described using Use cases and Use Case Models.By functional requirement I mean that we would use a USE CASE to describe a feature of the system we are trying to design. It will usually involve describing an event that will happen as a result of user or system doing something.
If Use case defines a requirement then a Use Case Model pretty much describe the overall working of the system by showing a collection of requirements and the relationships that exists between them. Lets say we are designing

Let me give you an example, you love Facebook right ? Right or wrong ?? he-he, lets say you have to describe the event of “Sending a friendship request to another member” how that will happen ? There are some business rules that will govern how. First thing is the person browsing Facebook needs to be logged in, second thing is you should be able to find the profile where you want to send the friendship request to. Then there should be a button or a link or some User Interface that the person would be able to click to be able to send a friendship request. After the button or link is clicked, Facebook will do its thing and display if it was able to send your friendship request or “Sorry No Donuts for You”, I guess ORKUT did that, not guessing I am pretty sure ! So in the scenario I just described there are a bunch of components that will make up the use case and I will describe them as I go.

The Aim or Goal or Description of the Use case is to be able to send a friendship request to another member of Facebook. You can give it a short and sweet name and be fancy like “Sending a Friendship request”. So the name/title of the USE CASE would be “sending a friendship request” and the goal/aim/description would be “The system/website/Facebook should be able to send friendship requests to other members with a profile on the system/website/Facebook. So now you know what is the title and description (description is a wordy extension of the title). Next thing would be to identify who is initiating this behavior of the system and by doing what ? A user is initiating the action by clicking on a link. The Primary actor/stake holder of the use case is the “USER” and “Clicking the Send Friendship Request Link” is the Trigger. After clicking since the system/Facebook will do something and say whether it was successful or not and actually send the request “SYSTEM” can be thought of as Secondary actor. So now we are down 5 trashy terms (Title,Description, Primary Actor,Secondary Actor and Trigger). Now there are some conditions that should be fulfilled before the Action/Description can happen like the person sending the friendship request should be signed in to Facebook and be able to locate the profile of the person where the request would be sent and be able to click on the correct link. These are the Preconditions of the Use Case. So the conditions that should be fulfilled before the scenario described in the use case are its preconditions. Usually they can be represented as a numbered list on a Use Case. Similarly after the scenario described in the USE CASE is completed, something will happen that would be the POST CONDITION. Either the friendship request is sent or Sorry No Donuts for you :P. Now comes the main flow or happy scenario or the USE CASE which would define a sequence of events and action that would describe the Use Case. For example

1. User A found User B on Facebook and is able to stalk
2. User A clicks on the “Send Friendship Request” link
3. System sends a friendship request to User B and also sends a notification email

This scenario is happy because whatever we are trying to achieve we did so successfully. Similarly since the system will not be happy all the time, you can have an alternate scenario. Alternate scenarios are also called USE CASE Extensions

1. User A found User B on Facebook and is able to stalk
2. User A Clicks on the “Send Friendship Request” link
3. System was unable to send a friendship request due to some error and displays a message “Sorry No donuts for you since cookies are disabled in the browser !”

I would recommend text from UML Distilled and anything written by Martin Fowler on this subject.

Advertisements

Leave a comment

Filed under Software Design