Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2012/ch2b 1w70 nl

2012-11-20T01:16:54Z

Nloya: /* Conclusion */

SaaS - 4.2 - SMART User Stories

==Introduction==
User stories are the basis for defining the functionality of any given system. They are a short description of the system that capture what the system does and gives the expectation of how the system should behave.
When we say User Stories, we don’t define any particular criteria as to how a user story should be written. A user story can be “Customer should have a good UI experience” or “When a customer logs in he/she should be able to see all the technical details of the product he/she has selected, with the reviews, price displayed alongside and an option of ‘Add to Cart’ to go along with it.”
Both the user stories described above are correct but one leaves too much for one to assume and the other gives one specific information in terms of display and functionality. The problem with the first user story is it is not restricted to any particular guideline, its just a user story but has no scope and hence can be either very short or very long. The advantage with the second user story is that it has been written based on a given set of goals which can be acronymed as SMART and will be explained below.

==SMART User Stories==

SMART is a mnemonic for 
*S - Specific
*M - Measurable
*A - Achievable
*R - Relevant
*T- Timeboxed

===S -Specific/ M - Measurable===
The user story should be specific enough to capture the requirements of the user. The user can be the customer who requires the software or the end user who will be using the software. Many times the user stories are vague or ambiguous leading to a lot of loss in time and energy spent in development.
User stories can be made specific by using the terms 'Given, When and Then' which describe the user story. The term “Given” specifies the background scenarios. It specifies all the preconditions.
“When” specifies the input to the system. “Then” specifies the desired result/s. 
Example: 
Given I am at www.google.com
When I click on the button Gmail
Then I should be redirected to Gmail.
Each scenario should be testable i.e its progress should be measurable. There should be known good output for every input. Every project needs concrete criteria for measuring progress toward its completion. The reason behind this is that if the scenarios are not measurable, it is not possible to know whether a team is making progress toward successful completion. Measuring progress is supposed to help a team stay on track, reach its target dates, and experience the exhilaration of achievement that spurs it on to continued effort required to reach the ultimate goal.

===A - Achievable / T - Timeboxed===
Goals should be set in such a way that it is achievable or at least a working model of it is achievable within a single iteration i.e. within a given time period. The reason for this is that Agile methodologies always aim for working models at the end of iteration, it doesn’t necessarily have to be a complete feature but a run-down version of it which is working partially and is able to provide a minimal set of functionality is also accepted.
If the feature is such that it may span over multiple iterations then it is a good idea to break it up into subset of stories such that each implemented subset provides a working model of the feature, however small it may be, so that constant progress is made to implement the feature and also a working code is provided at the end of each iteration.

While its a good idea to divide a feature into sub-features and have user stories for each iteration, the question arises of how to decide on the number of user stories for each iteration and the number of iterations that may require for the complete feature to be implemented. This is usually accomplished using velocity which is an estimate of the kind of progress made in the past based on the difficulty of the user stories and the kind of progress that can be made by taking into consideration the difficulty of the user stories that are yet to be implemented.

As features are broken down to sub-features and stories are written for the sub-feature, which is to be completed within the iteration, points should be assigned to each of the stories based on the difficulty level of the story and how fine grained approach for point-assignment does an assigner want. Say for example an assigner wants just a simple approach for point-assignment then he/she can assign from a range of 1-3 (where 1 being easy, 2 being medium and 3 being hard) and if a more fine grained approach is required then the range can be increased to 1-5 or 1-10. Whatever the approach is followed the important thing is to allocate points to each of the stories based on one’s estimate. At the end of each iteration, Velocity is calculated, which is nothing but the total number of points completed per iteration. As Velocity is not just the total of the stories but the total based on the difficulty level of the stories, it acts as an important guiding tool which can be leveraged by anyone to get to know details about the project as is shown below.

Uses of Velocity:

*Velocity can be used to plan future iterations
*It gives an estimate of how much time or iterations would be required to completely implement the feature
*It gives an idea of whether the team is on track as the velocity is expected to remain constant if all other variables are unchanged (other variables such as number of team members or replacement of an experienced team member with a new team member, etc.)
*It can provide an estimate if a change is requested by customers and based on the time required to implement the change and the importance level of the change the decision can be made whether to implement it or not.

Following this approach allows a task to be timeboxed, i.e. limited to a specific duration. It provides a kind of expectation which makes the team-members aware that if something is not working out its time to seek help, split the task, change teams or do anything that will help in the completion of the task.

At the initial phase, the task of assigning points to stories may seem a bit daunting and a bit like second guessing oneself but as the iterations pass on and based on the understanding of the feature and the experience one has in assigning points to user-stories, the estimation will always improve and at the end will be very close to the actual statistics. Also estimates can be changed if one feels an incorrect estimation was done but care should be taken that the variation is not too much.

===R- business Relevant===
A user story should be of business value, i.e it should generate additional income or protect revenue. The software defined by the user story can increase the value of the product by generating interest among new users and thereby generating potential new customers.A software can also protect revenue by streamlining processes to cut costs.
One way of determining the business relevance of a product is by asking the question “why” recursively. This is similar to a problem solving technique called “5 Whys” where questions asked recursively for root cause analysis. The methodology can be extended here to recursively ask why developing a software is of business relevance to that company. It is assumed that after asking multiple times the reason will have some business relevance (for eg “To increase in revenue for the company”) or there is no valid reason justifying the software project.

==Example==
Let us understand SMART User Stories by taking an example:

I want an application that shows me the best deals.

There are all sorts of problems with the above user story. It doesn't fit any of the criterion we have set using our SMART User Stories approach. Let’s go over with each of the problems and try to improve our user story step-by-step.

S-Specific / M-Measurable 
The above example is anything but specific nor it seems measurable. Well it does say that there needs to be an application that shows the best deals but it doesn't mention to display the best deals from which all places or websites. Also it doesn't mention about what it wants the best deals on. Also as it doesn't mention about the websites it is difficult it to measure the story.

A much better user story would have been: 
I want an application that shows the user the best deals on a particular product, which is entered by the user before beginning the search, from the websites that preselected by the user.

This says specifically on what product the user wants the search on and from which all websites. This is a very specific goal as there is no scope of assumption here. Of course the search results will be based on the specific words the user enters, but that is true for any website. The more specific you are in your search the more fine grained your search will be. Also because of the modified story, now it is easy to measure the story, as we can go through each website and compare prices and check whether the application did indeed return the best deals from various websites.

A-Achievable 
Appropriate timelines and deadlines should be set for implementing and testing the application. Suppose the client wants the above application for the Thanksgiving sale and he comes and asks for it during midweek of November, then creating the above story at that time wouldn’t be useful or advisable as the time period is too short for the goal to achieve.

Assuming there is sufficient time for the application to be created and there are say 4 iterations possible. But the above story may not be practical for one iteration, one might need to break it down further to make it workable for 1 iteration as the target is to have a workable code at the end of each iteration. So the story for the particular iteration can be modified as:

Provide an interface for the user to provide the name of the product and the websites he/she wants to have a search in.

This would be achievable for the first iteration. For the second iteration more functionality may be added:

Look for the price of the product in all of the websites given by the user and fetch all the results.

This can be further modified in iteration 3 to give the best deal, based on price factor. This can be further modified to modify the result if any free goodies are being provided by any particular website. In this way the goal can be made achievable.

T-Timeboxed 
All of the above 4 iterations that we planned should have the deadlines appropriately. If we suppose till one particular date if the team-member responsible for developing one particular functionality is not able to reach the target goal, it might be a good idea for him/her to ask to someone else or for some senior member to help out or to swap teams itself so that someone who has knowledge can work on that and can complete it without affecting the deadlines and making sure that the product is still workable at the end of that particular iteration. This should be followed for all the iterations. This will also allow sufficient time for testing which is a very important part of the application development.

R-Relevant 
The story should be relevant so that the desired benefit can be obtained and maximized. Why would the client need it
*Probably because there are many websites which offer different deals and to get a single website which searches all the websites on behalf of the user or at least a subset of the websites would make it much easier for the user
*That will also lead to increase in the clicks the website gets
*Which will subsequently lead to increase in ads
*Which will lead to increase in revenue for the company

Now the above goals are relevant for the application that user wants but it may not be relevant for the Terms and Conditions page or the login page that application may have.

==Advantages/Disadvantages of SMART User stories==
===Advantages of SMART User stories===
Lets consider the advantages of SMART User stories by considering each letter of the mnemonic.
*Making a user story specific makes the objectives of the project clear and prevent confusion amongst teams
*Having a well defined input/output relation makes the project measurable/testable for bugs and defects.
*Having a specific user story helps breaking the project down to achievable goals. These goals can be accomplished in single or multiple iterations.
*Asking whether a project is business relevant helps in identifying the maximum potential of the project.
*A timeboxed project helps in monitoring the progress of the project. It is also possible to estimate the velocity of the project using timeboxing.

===Disadvantages/Limitations of SMART User Stories===

*Some people prefer other kind of mnemonics such as INVEST rather than SMART as they feel that the thing that SMART stands for is not the same for all people. S may stand for Specific for some, Significant for some, Stretching for others, similarly M may be Measurable or Meaningful, likewise each of the alphabet of SMART has different meaning for different people.
*It is important that points assignment to user stories is done by someone experienced enough to understand the features that customers require as well as the complexity and technical details required to implement it successfully otherwise the velocity will be far from what is expected.
==Conclusion==
SMART User stories are a great way of defining goals as they have parameters on which to base the decision but for some they are not too specific, primarily because each of the letter of the acronym holds different meaning for different people.

==References==
<references/>
[http://www.youtube.com/watch?v=XzV0dytYQq0 SaaS 4.2: SMART User stories] 
[http://uxdesign.smashingmagazine.com/2011/09/13/the-s-m-a-r-t-user-experience-strategy/ SMART User experience strategy] 
[http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ INVEST in good stories and SMART Tasks] 
[http://www.chiefsimplicityofficer.com/2010/04/user-stories-its-smart-to-invest/ User stories: Its SMART to INVEST] 

==See Also==

[http://en.wikipedia.org/wiki/User_story Information on user stories] 
[http://gigaom.com/2008/05/05/how-to-create-smart-tasks/ Information on SMART tasks] 
[http://www.uncommon-knowledge.co.uk/goal_setting/smart_4.html Information on SMART goals] 
[http://en.wikipedia.org/wiki/5_Whys Link for 5 Whys]

CSC/ECE 517 Fall 2012/ch2b 1w70 nl

2012-11-20T01:12:42Z

Nloya: /* Example */

SaaS - 4.2 - SMART User Stories

==Introduction==
User stories are the basis for defining the functionality of any given system. They are a short description of the system that capture what the system does and gives the expectation of how the system should behave.
When we say User Stories, we don’t define any particular criteria as to how a user story should be written. A user story can be “Customer should have a good UI experience” or “When a customer logs in he/she should be able to see all the technical details of the product he/she has selected, with the reviews, price displayed alongside and an option of ‘Add to Cart’ to go along with it.”
Both the user stories described above are correct but one leaves too much for one to assume and the other gives one specific information in terms of display and functionality. The problem with the first user story is it is not restricted to any particular guideline, its just a user story but has no scope and hence can be either very short or very long. The advantage with the second user story is that it has been written based on a given set of goals which can be acronymed as SMART and will be explained below.

==SMART User Stories==

SMART is a mnemonic for 
*S - Specific
*M - Measurable
*A - Achievable
*R - Relevant
*T- Timeboxed

===S -Specific/ M - Measurable===
The user story should be specific enough to capture the requirements of the user. The user can be the customer who requires the software or the end user who will be using the software. Many times the user stories are vague or ambiguous leading to a lot of loss in time and energy spent in development.
User stories can be made specific by using the terms 'Given, When and Then' which describe the user story. The term “Given” specifies the background scenarios. It specifies all the preconditions.
“When” specifies the input to the system. “Then” specifies the desired result/s. 
Example: 
Given I am at www.google.com
When I click on the button Gmail
Then I should be redirected to Gmail.
Each scenario should be testable i.e its progress should be measurable. There should be known good output for every input. Every project needs concrete criteria for measuring progress toward its completion. The reason behind this is that if the scenarios are not measurable, it is not possible to know whether a team is making progress toward successful completion. Measuring progress is supposed to help a team stay on track, reach its target dates, and experience the exhilaration of achievement that spurs it on to continued effort required to reach the ultimate goal.

===A - Achievable / T - Timeboxed===
Goals should be set in such a way that it is achievable or at least a working model of it is achievable within a single iteration i.e. within a given time period. The reason for this is that Agile methodologies always aim for working models at the end of iteration, it doesn’t necessarily have to be a complete feature but a run-down version of it which is working partially and is able to provide a minimal set of functionality is also accepted.
If the feature is such that it may span over multiple iterations then it is a good idea to break it up into subset of stories such that each implemented subset provides a working model of the feature, however small it may be, so that constant progress is made to implement the feature and also a working code is provided at the end of each iteration.

While its a good idea to divide a feature into sub-features and have user stories for each iteration, the question arises of how to decide on the number of user stories for each iteration and the number of iterations that may require for the complete feature to be implemented. This is usually accomplished using velocity which is an estimate of the kind of progress made in the past based on the difficulty of the user stories and the kind of progress that can be made by taking into consideration the difficulty of the user stories that are yet to be implemented.

As features are broken down to sub-features and stories are written for the sub-feature, which is to be completed within the iteration, points should be assigned to each of the stories based on the difficulty level of the story and how fine grained approach for point-assignment does an assigner want. Say for example an assigner wants just a simple approach for point-assignment then he/she can assign from a range of 1-3 (where 1 being easy, 2 being medium and 3 being hard) and if a more fine grained approach is required then the range can be increased to 1-5 or 1-10. Whatever the approach is followed the important thing is to allocate points to each of the stories based on one’s estimate. At the end of each iteration, Velocity is calculated, which is nothing but the total number of points completed per iteration. As Velocity is not just the total of the stories but the total based on the difficulty level of the stories, it acts as an important guiding tool which can be leveraged by anyone to get to know details about the project as is shown below.

Uses of Velocity:

*Velocity can be used to plan future iterations
*It gives an estimate of how much time or iterations would be required to completely implement the feature
*It gives an idea of whether the team is on track as the velocity is expected to remain constant if all other variables are unchanged (other variables such as number of team members or replacement of an experienced team member with a new team member, etc.)
*It can provide an estimate if a change is requested by customers and based on the time required to implement the change and the importance level of the change the decision can be made whether to implement it or not.

Following this approach allows a task to be timeboxed, i.e. limited to a specific duration. It provides a kind of expectation which makes the team-members aware that if something is not working out its time to seek help, split the task, change teams or do anything that will help in the completion of the task.

At the initial phase, the task of assigning points to stories may seem a bit daunting and a bit like second guessing oneself but as the iterations pass on and based on the understanding of the feature and the experience one has in assigning points to user-stories, the estimation will always improve and at the end will be very close to the actual statistics. Also estimates can be changed if one feels an incorrect estimation was done but care should be taken that the variation is not too much.

===R- business Relevant===
A user story should be of business value, i.e it should generate additional income or protect revenue. The software defined by the user story can increase the value of the product by generating interest among new users and thereby generating potential new customers.A software can also protect revenue by streamlining processes to cut costs.
One way of determining the business relevance of a product is by asking the question “why” recursively. This is similar to a problem solving technique called “5 Whys” where questions asked recursively for root cause analysis. The methodology can be extended here to recursively ask why developing a software is of business relevance to that company. It is assumed that after asking multiple times the reason will have some business relevance (for eg “To increase in revenue for the company”) or there is no valid reason justifying the software project.

==Example==
Let us understand SMART User Stories by taking an example:

I want an application that shows me the best deals.

There are all sorts of problems with the above user story. It doesn't fit any of the criterion we have set using our SMART User Stories approach. Let’s go over with each of the problems and try to improve our user story step-by-step.

S-Specific / M-Measurable 
The above example is anything but specific nor it seems measurable. Well it does say that there needs to be an application that shows the best deals but it doesn't mention to display the best deals from which all places or websites. Also it doesn't mention about what it wants the best deals on. Also as it doesn't mention about the websites it is difficult it to measure the story.

A much better user story would have been: 
I want an application that shows the user the best deals on a particular product, which is entered by the user before beginning the search, from the websites that preselected by the user.

This says specifically on what product the user wants the search on and from which all websites. This is a very specific goal as there is no scope of assumption here. Of course the search results will be based on the specific words the user enters, but that is true for any website. The more specific you are in your search the more fine grained your search will be. Also because of the modified story, now it is easy to measure the story, as we can go through each website and compare prices and check whether the application did indeed return the best deals from various websites.

A-Achievable 
Appropriate timelines and deadlines should be set for implementing and testing the application. Suppose the client wants the above application for the Thanksgiving sale and he comes and asks for it during midweek of November, then creating the above story at that time wouldn’t be useful or advisable as the time period is too short for the goal to achieve.

Assuming there is sufficient time for the application to be created and there are say 4 iterations possible. But the above story may not be practical for one iteration, one might need to break it down further to make it workable for 1 iteration as the target is to have a workable code at the end of each iteration. So the story for the particular iteration can be modified as:

Provide an interface for the user to provide the name of the product and the websites he/she wants to have a search in.

This would be achievable for the first iteration. For the second iteration more functionality may be added:

Look for the price of the product in all of the websites given by the user and fetch all the results.

This can be further modified in iteration 3 to give the best deal, based on price factor. This can be further modified to modify the result if any free goodies are being provided by any particular website. In this way the goal can be made achievable.

T-Timeboxed 
All of the above 4 iterations that we planned should have the deadlines appropriately. If we suppose till one particular date if the team-member responsible for developing one particular functionality is not able to reach the target goal, it might be a good idea for him/her to ask to someone else or for some senior member to help out or to swap teams itself so that someone who has knowledge can work on that and can complete it without affecting the deadlines and making sure that the product is still workable at the end of that particular iteration. This should be followed for all the iterations. This will also allow sufficient time for testing which is a very important part of the application development.

R-Relevant 
The story should be relevant so that the desired benefit can be obtained and maximized. Why would the client need it
*Probably because there are many websites which offer different deals and to get a single website which searches all the websites on behalf of the user or at least a subset of the websites would make it much easier for the user
*That will also lead to increase in the clicks the website gets
*Which will subsequently lead to increase in ads
*Which will lead to increase in revenue for the company

Now the above goals are relevant for the application that user wants but it may not be relevant for the Terms and Conditions page or the login page that application may have.

==Advantages/Disadvantages of SMART User stories==
===Advantages of SMART User stories===
Lets consider the advantages of SMART User stories by considering each letter of the mnemonic.
*Making a user story specific makes the objectives of the project clear and prevent confusion amongst teams
*Having a well defined input/output relation makes the project measurable/testable for bugs and defects.
*Having a specific user story helps breaking the project down to achievable goals. These goals can be accomplished in single or multiple iterations.
*Asking whether a project is business relevant helps in identifying the maximum potential of the project.
*A timeboxed project helps in monitoring the progress of the project. It is also possible to estimate the velocity of the project using timeboxing.

===Disadvantages/Limitations of SMART User Stories===

*Some people prefer other kind of mnemonics such as INVEST rather than SMART as they feel that the thing that SMART stands for is not the same for all people. S may stand for Specific for some, Significant for some, Stretching for others, similarly M may be Measurable or Meaningful, likewise each of the alphabet of SMART has different meaning for different people.
*It is important that points assignment to user stories is done by someone experienced enough to understand the features that customers require as well as the complexity and technical details required to implement it successfully otherwise the velocity will be far from what is expected.
==Conclusion==

==References==
<references/>
[http://www.youtube.com/watch?v=XzV0dytYQq0 SaaS 4.2: SMART User stories] 
[http://uxdesign.smashingmagazine.com/2011/09/13/the-s-m-a-r-t-user-experience-strategy/ SMART User experience strategy] 
[http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ INVEST in good stories and SMART Tasks] 
[http://www.chiefsimplicityofficer.com/2010/04/user-stories-its-smart-to-invest/ User stories: Its SMART to INVEST] 

==See Also==

[http://en.wikipedia.org/wiki/User_story Information on user stories] 
[http://gigaom.com/2008/05/05/how-to-create-smart-tasks/ Information on SMART tasks] 
[http://www.uncommon-knowledge.co.uk/goal_setting/smart_4.html Information on SMART goals] 
[http://en.wikipedia.org/wiki/5_Whys Link for 5 Whys]

CSC/ECE 517 Fall 2012/ch2b 1w70 nl

2012-11-20T01:11:06Z

Nloya: /* Example */

SaaS - 4.2 - SMART User Stories

==Introduction==
User stories are the basis for defining the functionality of any given system. They are a short description of the system that capture what the system does and gives the expectation of how the system should behave.
When we say User Stories, we don’t define any particular criteria as to how a user story should be written. A user story can be “Customer should have a good UI experience” or “When a customer logs in he/she should be able to see all the technical details of the product he/she has selected, with the reviews, price displayed alongside and an option of ‘Add to Cart’ to go along with it.”
Both the user stories described above are correct but one leaves too much for one to assume and the other gives one specific information in terms of display and functionality. The problem with the first user story is it is not restricted to any particular guideline, its just a user story but has no scope and hence can be either very short or very long. The advantage with the second user story is that it has been written based on a given set of goals which can be acronymed as SMART and will be explained below.

==SMART User Stories==

SMART is a mnemonic for 
*S - Specific
*M - Measurable
*A - Achievable
*R - Relevant
*T- Timeboxed

===S -Specific/ M - Measurable===
The user story should be specific enough to capture the requirements of the user. The user can be the customer who requires the software or the end user who will be using the software. Many times the user stories are vague or ambiguous leading to a lot of loss in time and energy spent in development.
User stories can be made specific by using the terms 'Given, When and Then' which describe the user story. The term “Given” specifies the background scenarios. It specifies all the preconditions.
“When” specifies the input to the system. “Then” specifies the desired result/s. 
Example: 
Given I am at www.google.com
When I click on the button Gmail
Then I should be redirected to Gmail.
Each scenario should be testable i.e its progress should be measurable. There should be known good output for every input. Every project needs concrete criteria for measuring progress toward its completion. The reason behind this is that if the scenarios are not measurable, it is not possible to know whether a team is making progress toward successful completion. Measuring progress is supposed to help a team stay on track, reach its target dates, and experience the exhilaration of achievement that spurs it on to continued effort required to reach the ultimate goal.

===A - Achievable / T - Timeboxed===
Goals should be set in such a way that it is achievable or at least a working model of it is achievable within a single iteration i.e. within a given time period. The reason for this is that Agile methodologies always aim for working models at the end of iteration, it doesn’t necessarily have to be a complete feature but a run-down version of it which is working partially and is able to provide a minimal set of functionality is also accepted.
If the feature is such that it may span over multiple iterations then it is a good idea to break it up into subset of stories such that each implemented subset provides a working model of the feature, however small it may be, so that constant progress is made to implement the feature and also a working code is provided at the end of each iteration.

While its a good idea to divide a feature into sub-features and have user stories for each iteration, the question arises of how to decide on the number of user stories for each iteration and the number of iterations that may require for the complete feature to be implemented. This is usually accomplished using velocity which is an estimate of the kind of progress made in the past based on the difficulty of the user stories and the kind of progress that can be made by taking into consideration the difficulty of the user stories that are yet to be implemented.

As features are broken down to sub-features and stories are written for the sub-feature, which is to be completed within the iteration, points should be assigned to each of the stories based on the difficulty level of the story and how fine grained approach for point-assignment does an assigner want. Say for example an assigner wants just a simple approach for point-assignment then he/she can assign from a range of 1-3 (where 1 being easy, 2 being medium and 3 being hard) and if a more fine grained approach is required then the range can be increased to 1-5 or 1-10. Whatever the approach is followed the important thing is to allocate points to each of the stories based on one’s estimate. At the end of each iteration, Velocity is calculated, which is nothing but the total number of points completed per iteration. As Velocity is not just the total of the stories but the total based on the difficulty level of the stories, it acts as an important guiding tool which can be leveraged by anyone to get to know details about the project as is shown below.

Uses of Velocity:

*Velocity can be used to plan future iterations
*It gives an estimate of how much time or iterations would be required to completely implement the feature
*It gives an idea of whether the team is on track as the velocity is expected to remain constant if all other variables are unchanged (other variables such as number of team members or replacement of an experienced team member with a new team member, etc.)
*It can provide an estimate if a change is requested by customers and based on the time required to implement the change and the importance level of the change the decision can be made whether to implement it or not.

Following this approach allows a task to be timeboxed, i.e. limited to a specific duration. It provides a kind of expectation which makes the team-members aware that if something is not working out its time to seek help, split the task, change teams or do anything that will help in the completion of the task.

At the initial phase, the task of assigning points to stories may seem a bit daunting and a bit like second guessing oneself but as the iterations pass on and based on the understanding of the feature and the experience one has in assigning points to user-stories, the estimation will always improve and at the end will be very close to the actual statistics. Also estimates can be changed if one feels an incorrect estimation was done but care should be taken that the variation is not too much.

===R- business Relevant===
A user story should be of business value, i.e it should generate additional income or protect revenue. The software defined by the user story can increase the value of the product by generating interest among new users and thereby generating potential new customers.A software can also protect revenue by streamlining processes to cut costs.
One way of determining the business relevance of a product is by asking the question “why” recursively. This is similar to a problem solving technique called “5 Whys” where questions asked recursively for root cause analysis. The methodology can be extended here to recursively ask why developing a software is of business relevance to that company. It is assumed that after asking multiple times the reason will have some business relevance (for eg “To increase in revenue for the company”) or there is no valid reason justifying the software project.

==Example==
Let us understand SMART User Stories by taking an example:

I want an application that shows me the best deals.

There are all sorts of problems with the above user story. It doesn't fit any of the criterion we have set using our SMART User Stories approach. Let’s go over with each of the problems and try to improve our user story step-by-step.

S-Specific / M-Measurable: 
The above example is anything but specific nor it seems measurable. Well it does say that there needs to be an application that shows the best deals but it doesn't mention to display the best deals from which all places or websites. Also it doesn't mention about what it wants the best deals on. Also as it doesn't mention about the websites it is difficult it to measure the story.

A much better user story would have been: 
I want an application that shows the user the best deals on a particular product, which is entered by the user before beginning the search, from the websites that preselected by the user.

This says specifically on what product the user wants the search on and from which all websites. This is a very specific goal as there is no scope of assumption here. Of course the search results will be based on the specific words the user enters, but that is true for any website. The more specific you are in your search the more fine grained your search will be. Also because of the modified story, now it is easy to measure the story, as we can go through each website and compare prices and check whether the application did indeed return the best deals from various websites.

A-Achievable: 
Appropriate timelines and deadlines should be set for implementing and testing the application. Suppose the client wants the above application for the Thanksgiving sale and he comes and asks for it during midweek of November, then creating the above story at that time wouldn’t be useful or advisable as the time period is too short for the goal to achieve.

Assuming there is sufficient time for the application to be created and there are say 4 iterations possible. But the above story may not be practical for one iteration, one might need to break it down further to make it workable for 1 iteration as the target is to have a workable code at the end of each iteration. So the story for the particular iteration can be modified as:

Provide an interface for the user to provide the name of the product and the websites he/she wants to have a search in.

This would be achievable for the first iteration. For the second iteration more functionality may be added:

Look for the price of the product in all of the websites given by the user and fetch all the results.

This can be further modified in iteration 3 to give the best deal, based on price factor. This can be further modified to modify the result if any free goodies are being provided by any particular website. In this way the goal can be made achievable.

T-Timeboxed 
All of the above 4 iterations that we planned should have the deadlines appropriately. If we suppose till one particular date if the team-member responsible for developing one particular functionality is not able to reach the target goal, it might be a good idea for him/her to ask to someone else or for some senior member to help out or to swap teams itself so that someone who has knowledge can work on that and can complete it without affecting the deadlines and making sure that the product is still workable at the end of that particular iteration. This should be followed for all the iterations. This will also allow sufficient time for testing which is a very important part of the application development.

R-Relevant 
The story should be relevant so that the desired benefit can be obtained and maximized. Why would the client need it
*Probably because there are many websites which offer different deals and to get a single website which searches all the websites on behalf of the user or at least a subset of the websites would make it much easier for the user
*That will also lead to increase in the clicks the website gets
*Which will subsequently lead to increase in ads
*Which will lead to increase in revenue for the company

Now the above goals are relevant for the application that user wants but it may not be relevant for the Terms and Conditions page or the login page that application may have.

==Advantages/Disadvantages of SMART User stories==
===Advantages of SMART User stories===
Lets consider the advantages of SMART User stories by considering each letter of the mnemonic.
*Making a user story specific makes the objectives of the project clear and prevent confusion amongst teams
*Having a well defined input/output relation makes the project measurable/testable for bugs and defects.
*Having a specific user story helps breaking the project down to achievable goals. These goals can be accomplished in single or multiple iterations.
*Asking whether a project is business relevant helps in identifying the maximum potential of the project.
*A timeboxed project helps in monitoring the progress of the project. It is also possible to estimate the velocity of the project using timeboxing.

===Disadvantages/Limitations of SMART User Stories===

*Some people prefer other kind of mnemonics such as INVEST rather than SMART as they feel that the thing that SMART stands for is not the same for all people. S may stand for Specific for some, Significant for some, Stretching for others, similarly M may be Measurable or Meaningful, likewise each of the alphabet of SMART has different meaning for different people.
*It is important that points assignment to user stories is done by someone experienced enough to understand the features that customers require as well as the complexity and technical details required to implement it successfully otherwise the velocity will be far from what is expected.
==Conclusion==

==References==
<references/>
[http://www.youtube.com/watch?v=XzV0dytYQq0 SaaS 4.2: SMART User stories] 
[http://uxdesign.smashingmagazine.com/2011/09/13/the-s-m-a-r-t-user-experience-strategy/ SMART User experience strategy] 
[http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ INVEST in good stories and SMART Tasks] 
[http://www.chiefsimplicityofficer.com/2010/04/user-stories-its-smart-to-invest/ User stories: Its SMART to INVEST] 

==See Also==

[http://en.wikipedia.org/wiki/User_story Information on user stories] 
[http://gigaom.com/2008/05/05/how-to-create-smart-tasks/ Information on SMART tasks] 
[http://www.uncommon-knowledge.co.uk/goal_setting/smart_4.html Information on SMART goals] 
[http://en.wikipedia.org/wiki/5_Whys Link for 5 Whys]

CSC/ECE 517 Fall 2012/ch2b 1w70 nl

2012-11-20T01:10:04Z

Nloya: /* Example */

SaaS - 4.2 - SMART User Stories

==Introduction==
User stories are the basis for defining the functionality of any given system. They are a short description of the system that capture what the system does and gives the expectation of how the system should behave.
When we say User Stories, we don’t define any particular criteria as to how a user story should be written. A user story can be “Customer should have a good UI experience” or “When a customer logs in he/she should be able to see all the technical details of the product he/she has selected, with the reviews, price displayed alongside and an option of ‘Add to Cart’ to go along with it.”
Both the user stories described above are correct but one leaves too much for one to assume and the other gives one specific information in terms of display and functionality. The problem with the first user story is it is not restricted to any particular guideline, its just a user story but has no scope and hence can be either very short or very long. The advantage with the second user story is that it has been written based on a given set of goals which can be acronymed as SMART and will be explained below.

==SMART User Stories==

SMART is a mnemonic for 
*S - Specific
*M - Measurable
*A - Achievable
*R - Relevant
*T- Timeboxed

===S -Specific/ M - Measurable===
The user story should be specific enough to capture the requirements of the user. The user can be the customer who requires the software or the end user who will be using the software. Many times the user stories are vague or ambiguous leading to a lot of loss in time and energy spent in development.
User stories can be made specific by using the terms 'Given, When and Then' which describe the user story. The term “Given” specifies the background scenarios. It specifies all the preconditions.
“When” specifies the input to the system. “Then” specifies the desired result/s. 
Example: 
Given I am at www.google.com
When I click on the button Gmail
Then I should be redirected to Gmail.
Each scenario should be testable i.e its progress should be measurable. There should be known good output for every input. Every project needs concrete criteria for measuring progress toward its completion. The reason behind this is that if the scenarios are not measurable, it is not possible to know whether a team is making progress toward successful completion. Measuring progress is supposed to help a team stay on track, reach its target dates, and experience the exhilaration of achievement that spurs it on to continued effort required to reach the ultimate goal.

===A - Achievable / T - Timeboxed===
Goals should be set in such a way that it is achievable or at least a working model of it is achievable within a single iteration i.e. within a given time period. The reason for this is that Agile methodologies always aim for working models at the end of iteration, it doesn’t necessarily have to be a complete feature but a run-down version of it which is working partially and is able to provide a minimal set of functionality is also accepted.
If the feature is such that it may span over multiple iterations then it is a good idea to break it up into subset of stories such that each implemented subset provides a working model of the feature, however small it may be, so that constant progress is made to implement the feature and also a working code is provided at the end of each iteration.

While its a good idea to divide a feature into sub-features and have user stories for each iteration, the question arises of how to decide on the number of user stories for each iteration and the number of iterations that may require for the complete feature to be implemented. This is usually accomplished using velocity which is an estimate of the kind of progress made in the past based on the difficulty of the user stories and the kind of progress that can be made by taking into consideration the difficulty of the user stories that are yet to be implemented.

As features are broken down to sub-features and stories are written for the sub-feature, which is to be completed within the iteration, points should be assigned to each of the stories based on the difficulty level of the story and how fine grained approach for point-assignment does an assigner want. Say for example an assigner wants just a simple approach for point-assignment then he/she can assign from a range of 1-3 (where 1 being easy, 2 being medium and 3 being hard) and if a more fine grained approach is required then the range can be increased to 1-5 or 1-10. Whatever the approach is followed the important thing is to allocate points to each of the stories based on one’s estimate. At the end of each iteration, Velocity is calculated, which is nothing but the total number of points completed per iteration. As Velocity is not just the total of the stories but the total based on the difficulty level of the stories, it acts as an important guiding tool which can be leveraged by anyone to get to know details about the project as is shown below.

Uses of Velocity:

*Velocity can be used to plan future iterations
*It gives an estimate of how much time or iterations would be required to completely implement the feature
*It gives an idea of whether the team is on track as the velocity is expected to remain constant if all other variables are unchanged (other variables such as number of team members or replacement of an experienced team member with a new team member, etc.)
*It can provide an estimate if a change is requested by customers and based on the time required to implement the change and the importance level of the change the decision can be made whether to implement it or not.

Following this approach allows a task to be timeboxed, i.e. limited to a specific duration. It provides a kind of expectation which makes the team-members aware that if something is not working out its time to seek help, split the task, change teams or do anything that will help in the completion of the task.

At the initial phase, the task of assigning points to stories may seem a bit daunting and a bit like second guessing oneself but as the iterations pass on and based on the understanding of the feature and the experience one has in assigning points to user-stories, the estimation will always improve and at the end will be very close to the actual statistics. Also estimates can be changed if one feels an incorrect estimation was done but care should be taken that the variation is not too much.

===R- business Relevant===
A user story should be of business value, i.e it should generate additional income or protect revenue. The software defined by the user story can increase the value of the product by generating interest among new users and thereby generating potential new customers.A software can also protect revenue by streamlining processes to cut costs.
One way of determining the business relevance of a product is by asking the question “why” recursively. This is similar to a problem solving technique called “5 Whys” where questions asked recursively for root cause analysis. The methodology can be extended here to recursively ask why developing a software is of business relevance to that company. It is assumed that after asking multiple times the reason will have some business relevance (for eg “To increase in revenue for the company”) or there is no valid reason justifying the software project.

==Example==
Let us understand SMART User Stories by taking an example:

I want an application that shows me the best deals.

There are all sorts of problems with the above user story. It doesn't fit any of the criterion we have set using our SMART User Stories approach. Let’s go over with each of the problems and try to improve our user story step-by-step.

S-Specific / M-Measurable: 
The above example is anything but specific nor it seems measurable. Well it does say that there needs to be an application that shows the best deals but it doesn't mention to display the best deals from which all places or websites. Also it doesn't mention about what it wants the best deals on. Also as it doesn't mention about the websites it is difficult it to measure the story.

A much better user story would have been: 
I want an application that shows the user the best deals on a particular product, which is entered by the user before beginning the search, from the websites that preselected by the user.

This says specifically on what product the user wants the search on and from which all websites. This is a very specific goal as there is no scope of assumption here. Of course the search results will be based on the specific words the user enters, but that is true for any website. The more specific you are in your search the more fine grained your search will be. Also because of the modified story, now it is easy to measure the story, as we can go through each website and compare prices and check whether the application did indeed return the best deals from various websites.

A-Achievable: 
Appropriate timelines and deadlines should be set for implementing and testing the application. Suppose the client wants the above application for the Thanksgiving sale and he comes and asks for it during midweek of November, then creating the above story at that time wouldn’t be useful or advisable as the time period is too short for the goal to achieve.

Assuming there is sufficient time for the application to be created and there are say 4 iterations possible. But the above story may not be practical for one iteration, one might need to break it down further to make it workable for 1 iteration as the target is to have a workable code at the end of each iteration. So the story for the particular iteration can be modified as:

Provide an interface for the user to provide the name of the product and the websites he/she wants to have a search in.

This would be achievable for the first iteration. For the second iteration more functionality may be added:

Look for the price of the product in all of the websites given by the user and fetch all the results.

This can be further modified in iteration 3 to give the best deal, based on price factor. This can be further modified to modify the result if any free goodies are being provided by any particular website. In this way the goal can be made achievable.

T-Timeboxed 
All of the above 4 iterations that we planned should have the deadlines appropriately. If we suppose till one particular date if the team-member responsible for developing one particular functionality is not able to reach the target goal, it might be a good idea for him/her to ask to someone else or for some senior member to help out or to swap teams itself so that someone who has knowledge can work on that and can complete it without affecting the deadlines and making sure that the product is still workable at the end of that particular iteration. This should be followed for all the iterations. This will also allow sufficient time for testing which is a very important part of the application development.

R-Relevant 
The story should be relevant so that the desired benefit can be obtained and maximized. Why would the client need it
*Probably because there are many websites which offer different deals and to get a single website which searches all the websites on behalf of the user or at least a subset of the websites would make it much easier for the user
*That will also lead to increase in the clicks the website gets
*Which will subsequently lead to increase in ads
*Which will lead to increase in revenue for the company

Now the above goals are relevant for the application that user wants but it may not be relevant for the Terms and Conditions page or the login page that application may have.

==Advantages/Disadvantages of SMART User stories==
===Advantages of SMART User stories===
Lets consider the advantages of SMART User stories by considering each letter of the mnemonic.
*Making a user story specific makes the objectives of the project clear and prevent confusion amongst teams
*Having a well defined input/output relation makes the project measurable/testable for bugs and defects.
*Having a specific user story helps breaking the project down to achievable goals. These goals can be accomplished in single or multiple iterations.
*Asking whether a project is business relevant helps in identifying the maximum potential of the project.
*A timeboxed project helps in monitoring the progress of the project. It is also possible to estimate the velocity of the project using timeboxing.

===Disadvantages/Limitations of SMART User Stories===

*Some people prefer other kind of mnemonics such as INVEST rather than SMART as they feel that the thing that SMART stands for is not the same for all people. S may stand for Specific for some, Significant for some, Stretching for others, similarly M may be Measurable or Meaningful, likewise each of the alphabet of SMART has different meaning for different people.
*It is important that points assignment to user stories is done by someone experienced enough to understand the features that customers require as well as the complexity and technical details required to implement it successfully otherwise the velocity will be far from what is expected.
==Conclusion==

==References==
<references/>
[http://www.youtube.com/watch?v=XzV0dytYQq0 SaaS 4.2: SMART User stories] 
[http://uxdesign.smashingmagazine.com/2011/09/13/the-s-m-a-r-t-user-experience-strategy/ SMART User experience strategy] 
[http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ INVEST in good stories and SMART Tasks] 
[http://www.chiefsimplicityofficer.com/2010/04/user-stories-its-smart-to-invest/ User stories: Its SMART to INVEST] 

==See Also==

[http://en.wikipedia.org/wiki/User_story Information on user stories] 
[http://gigaom.com/2008/05/05/how-to-create-smart-tasks/ Information on SMART tasks] 
[http://www.uncommon-knowledge.co.uk/goal_setting/smart_4.html Information on SMART goals] 
[http://en.wikipedia.org/wiki/5_Whys Link for 5 Whys]

CSC/ECE 517 Fall 2012/ch2b 1w70 nl

2012-11-20T01:09:39Z

Nloya: /* Example */

SaaS - 4.2 - SMART User Stories

==Introduction==
User stories are the basis for defining the functionality of any given system. They are a short description of the system that capture what the system does and gives the expectation of how the system should behave.
When we say User Stories, we don’t define any particular criteria as to how a user story should be written. A user story can be “Customer should have a good UI experience” or “When a customer logs in he/she should be able to see all the technical details of the product he/she has selected, with the reviews, price displayed alongside and an option of ‘Add to Cart’ to go along with it.”
Both the user stories described above are correct but one leaves too much for one to assume and the other gives one specific information in terms of display and functionality. The problem with the first user story is it is not restricted to any particular guideline, its just a user story but has no scope and hence can be either very short or very long. The advantage with the second user story is that it has been written based on a given set of goals which can be acronymed as SMART and will be explained below.

==SMART User Stories==

SMART is a mnemonic for 
*S - Specific
*M - Measurable
*A - Achievable
*R - Relevant
*T- Timeboxed

===S -Specific/ M - Measurable===
The user story should be specific enough to capture the requirements of the user. The user can be the customer who requires the software or the end user who will be using the software. Many times the user stories are vague or ambiguous leading to a lot of loss in time and energy spent in development.
User stories can be made specific by using the terms 'Given, When and Then' which describe the user story. The term “Given” specifies the background scenarios. It specifies all the preconditions.
“When” specifies the input to the system. “Then” specifies the desired result/s. 
Example: 
Given I am at www.google.com
When I click on the button Gmail
Then I should be redirected to Gmail.
Each scenario should be testable i.e its progress should be measurable. There should be known good output for every input. Every project needs concrete criteria for measuring progress toward its completion. The reason behind this is that if the scenarios are not measurable, it is not possible to know whether a team is making progress toward successful completion. Measuring progress is supposed to help a team stay on track, reach its target dates, and experience the exhilaration of achievement that spurs it on to continued effort required to reach the ultimate goal.

===A - Achievable / T - Timeboxed===
Goals should be set in such a way that it is achievable or at least a working model of it is achievable within a single iteration i.e. within a given time period. The reason for this is that Agile methodologies always aim for working models at the end of iteration, it doesn’t necessarily have to be a complete feature but a run-down version of it which is working partially and is able to provide a minimal set of functionality is also accepted.
If the feature is such that it may span over multiple iterations then it is a good idea to break it up into subset of stories such that each implemented subset provides a working model of the feature, however small it may be, so that constant progress is made to implement the feature and also a working code is provided at the end of each iteration.

While its a good idea to divide a feature into sub-features and have user stories for each iteration, the question arises of how to decide on the number of user stories for each iteration and the number of iterations that may require for the complete feature to be implemented. This is usually accomplished using velocity which is an estimate of the kind of progress made in the past based on the difficulty of the user stories and the kind of progress that can be made by taking into consideration the difficulty of the user stories that are yet to be implemented.

As features are broken down to sub-features and stories are written for the sub-feature, which is to be completed within the iteration, points should be assigned to each of the stories based on the difficulty level of the story and how fine grained approach for point-assignment does an assigner want. Say for example an assigner wants just a simple approach for point-assignment then he/she can assign from a range of 1-3 (where 1 being easy, 2 being medium and 3 being hard) and if a more fine grained approach is required then the range can be increased to 1-5 or 1-10. Whatever the approach is followed the important thing is to allocate points to each of the stories based on one’s estimate. At the end of each iteration, Velocity is calculated, which is nothing but the total number of points completed per iteration. As Velocity is not just the total of the stories but the total based on the difficulty level of the stories, it acts as an important guiding tool which can be leveraged by anyone to get to know details about the project as is shown below.

Uses of Velocity:

*Velocity can be used to plan future iterations
*It gives an estimate of how much time or iterations would be required to completely implement the feature
*It gives an idea of whether the team is on track as the velocity is expected to remain constant if all other variables are unchanged (other variables such as number of team members or replacement of an experienced team member with a new team member, etc.)
*It can provide an estimate if a change is requested by customers and based on the time required to implement the change and the importance level of the change the decision can be made whether to implement it or not.

Following this approach allows a task to be timeboxed, i.e. limited to a specific duration. It provides a kind of expectation which makes the team-members aware that if something is not working out its time to seek help, split the task, change teams or do anything that will help in the completion of the task.

At the initial phase, the task of assigning points to stories may seem a bit daunting and a bit like second guessing oneself but as the iterations pass on and based on the understanding of the feature and the experience one has in assigning points to user-stories, the estimation will always improve and at the end will be very close to the actual statistics. Also estimates can be changed if one feels an incorrect estimation was done but care should be taken that the variation is not too much.

===R- business Relevant===
A user story should be of business value, i.e it should generate additional income or protect revenue. The software defined by the user story can increase the value of the product by generating interest among new users and thereby generating potential new customers.A software can also protect revenue by streamlining processes to cut costs.
One way of determining the business relevance of a product is by asking the question “why” recursively. This is similar to a problem solving technique called “5 Whys” where questions asked recursively for root cause analysis. The methodology can be extended here to recursively ask why developing a software is of business relevance to that company. It is assumed that after asking multiple times the reason will have some business relevance (for eg “To increase in revenue for the company”) or there is no valid reason justifying the software project.

==Example==
Let us understand SMART User Stories by taking an example:

I want an application that shows me the best deals.

There are all sorts of problems with the above user story. It doesn't fit any of the criterion we have set using our SMART User Stories approach. Let’s go over with each of the problems and try to improve our user story step-by-step.

S-Specific / M-Measurable: 
The above example is anything but specific nor it seems measurable. Well it does say that there needs to be an application that shows the best deals but it doesn't mention to display the best deals from which all places or websites. Also it doesn't mention about what it wants the best deals on. Also as it doesn't mention about the websites it is difficult it to measure the story.

A much better user story would have been: 
I want an application that shows the user the best deals on a particular product, which is entered by the user before beginning the search, from the websites that preselected by the user.

This says specifically on what product the user wants the search on and from which all websites. This is a very specific goal as there is no scope of assumption here. Of course the search results will be based on the specific words the user enters, but that is true for any website. The more specific you are in your search the more fine grained your search will be. Also because of the modified story, now it is easy to measure the story, as we can go through each website and compare prices and check whether the application did indeed return the best deals from various websites.

A-Achievable: 
Appropriate timelines and deadlines should be set for implementing and testing the application. Suppose the client wants the above application for the Thanksgiving sale and he comes and asks for it during midweek of November, then creating the above story at that time wouldn’t be useful or advisable as the time period is too short for the goal to achieve.

Assuming there is sufficient time for the application to be created and there are say 4 iterations possible. But the above story may not be practical for one iteration, one might need to break it down further to make it workable for 1 iteration as the target is to have a workable code at the end of each iteration. So the story for the particular iteration can be modified as:

Provide an interface for the user to provide the name of the product and the websites he/she wants to have a search in.

This would be achievable for the first iteration. For the second iteration more functionality may be added:

Look for the price of the product in all of the websites given by the user and fetch all the results.

This can be further modified in iteration 3 to give the best deal, based on price factor. This can be further modified to modify the result if any free goodies are being provided by any particular website. In this way the goal can be made achievable.

T-Timeboxed 
All of the above 4 iterations that we planned should have the deadlines appropriately. If we suppose till one particular date if the team-member responsible for developing one particular functionality is not able to reach the target goal, it might be a good idea for him/her to ask to someone else or for some senior member to help out or to swap teams itself so that someone who has knowledge can work on that and can complete it without affecting the deadlines and making sure that the product is still workable at the end of that particular iteration. This should be followed for all the iterations. This will also allow sufficient time for testing which is a very important part of the application development.

R-Relevant 
The story should be relevant so that the desired benefit can be obtained and maximized. Why would the client need it
*Probably because there are many websites which offer different deals and to get a single website which searches all the websites on behalf of the user or at least a subset of the websites would make it much easier for the user
*That will also lead to increase in the clicks the website gets
*Which will subsequently lead to increase in ads
*Which will lead to increase in revenue for the company

Now the above goals are relevant for the application that user wants but it may not be relevant for the Terms and Conditions page or the login page that application may have.

==Advantages/Disadvantages of SMART User stories==
===Advantages of SMART User stories===
Lets consider the advantages of SMART User stories by considering each letter of the mnemonic.
*Making a user story specific makes the objectives of the project clear and prevent confusion amongst teams
*Having a well defined input/output relation makes the project measurable/testable for bugs and defects.
*Having a specific user story helps breaking the project down to achievable goals. These goals can be accomplished in single or multiple iterations.
*Asking whether a project is business relevant helps in identifying the maximum potential of the project.
*A timeboxed project helps in monitoring the progress of the project. It is also possible to estimate the velocity of the project using timeboxing.

===Disadvantages/Limitations of SMART User Stories===

*Some people prefer other kind of mnemonics such as INVEST rather than SMART as they feel that the thing that SMART stands for is not the same for all people. S may stand for Specific for some, Significant for some, Stretching for others, similarly M may be Measurable or Meaningful, likewise each of the alphabet of SMART has different meaning for different people.
*It is important that points assignment to user stories is done by someone experienced enough to understand the features that customers require as well as the complexity and technical details required to implement it successfully otherwise the velocity will be far from what is expected.
==Conclusion==

==References==
<references/>
[http://www.youtube.com/watch?v=XzV0dytYQq0 SaaS 4.2: SMART User stories] 
[http://uxdesign.smashingmagazine.com/2011/09/13/the-s-m-a-r-t-user-experience-strategy/ SMART User experience strategy] 
[http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ INVEST in good stories and SMART Tasks] 
[http://www.chiefsimplicityofficer.com/2010/04/user-stories-its-smart-to-invest/ User stories: Its SMART to INVEST] 

==See Also==

[http://en.wikipedia.org/wiki/User_story Information on user stories] 
[http://gigaom.com/2008/05/05/how-to-create-smart-tasks/ Information on SMART tasks] 
[http://www.uncommon-knowledge.co.uk/goal_setting/smart_4.html Information on SMART goals] 
[http://en.wikipedia.org/wiki/5_Whys Link for 5 Whys]

CSC/ECE 517 Fall 2012/ch2b 1w70 nl

2012-11-20T01:08:43Z

Nloya: /* Example */

SaaS - 4.2 - SMART User Stories

==Introduction==
User stories are the basis for defining the functionality of any given system. They are a short description of the system that capture what the system does and gives the expectation of how the system should behave.
When we say User Stories, we don’t define any particular criteria as to how a user story should be written. A user story can be “Customer should have a good UI experience” or “When a customer logs in he/she should be able to see all the technical details of the product he/she has selected, with the reviews, price displayed alongside and an option of ‘Add to Cart’ to go along with it.”
Both the user stories described above are correct but one leaves too much for one to assume and the other gives one specific information in terms of display and functionality. The problem with the first user story is it is not restricted to any particular guideline, its just a user story but has no scope and hence can be either very short or very long. The advantage with the second user story is that it has been written based on a given set of goals which can be acronymed as SMART and will be explained below.

==SMART User Stories==

SMART is a mnemonic for 
*S - Specific
*M - Measurable
*A - Achievable
*R - Relevant
*T- Timeboxed

===S -Specific/ M - Measurable===
The user story should be specific enough to capture the requirements of the user. The user can be the customer who requires the software or the end user who will be using the software. Many times the user stories are vague or ambiguous leading to a lot of loss in time and energy spent in development.
User stories can be made specific by using the terms 'Given, When and Then' which describe the user story. The term “Given” specifies the background scenarios. It specifies all the preconditions.
“When” specifies the input to the system. “Then” specifies the desired result/s. 
Example: 
Given I am at www.google.com
When I click on the button Gmail
Then I should be redirected to Gmail.
Each scenario should be testable i.e its progress should be measurable. There should be known good output for every input. Every project needs concrete criteria for measuring progress toward its completion. The reason behind this is that if the scenarios are not measurable, it is not possible to know whether a team is making progress toward successful completion. Measuring progress is supposed to help a team stay on track, reach its target dates, and experience the exhilaration of achievement that spurs it on to continued effort required to reach the ultimate goal.

===A - Achievable / T - Timeboxed===
Goals should be set in such a way that it is achievable or at least a working model of it is achievable within a single iteration i.e. within a given time period. The reason for this is that Agile methodologies always aim for working models at the end of iteration, it doesn’t necessarily have to be a complete feature but a run-down version of it which is working partially and is able to provide a minimal set of functionality is also accepted.
If the feature is such that it may span over multiple iterations then it is a good idea to break it up into subset of stories such that each implemented subset provides a working model of the feature, however small it may be, so that constant progress is made to implement the feature and also a working code is provided at the end of each iteration.

While its a good idea to divide a feature into sub-features and have user stories for each iteration, the question arises of how to decide on the number of user stories for each iteration and the number of iterations that may require for the complete feature to be implemented. This is usually accomplished using velocity which is an estimate of the kind of progress made in the past based on the difficulty of the user stories and the kind of progress that can be made by taking into consideration the difficulty of the user stories that are yet to be implemented.

As features are broken down to sub-features and stories are written for the sub-feature, which is to be completed within the iteration, points should be assigned to each of the stories based on the difficulty level of the story and how fine grained approach for point-assignment does an assigner want. Say for example an assigner wants just a simple approach for point-assignment then he/she can assign from a range of 1-3 (where 1 being easy, 2 being medium and 3 being hard) and if a more fine grained approach is required then the range can be increased to 1-5 or 1-10. Whatever the approach is followed the important thing is to allocate points to each of the stories based on one’s estimate. At the end of each iteration, Velocity is calculated, which is nothing but the total number of points completed per iteration. As Velocity is not just the total of the stories but the total based on the difficulty level of the stories, it acts as an important guiding tool which can be leveraged by anyone to get to know details about the project as is shown below.

Uses of Velocity:

*Velocity can be used to plan future iterations
*It gives an estimate of how much time or iterations would be required to completely implement the feature
*It gives an idea of whether the team is on track as the velocity is expected to remain constant if all other variables are unchanged (other variables such as number of team members or replacement of an experienced team member with a new team member, etc.)
*It can provide an estimate if a change is requested by customers and based on the time required to implement the change and the importance level of the change the decision can be made whether to implement it or not.

Following this approach allows a task to be timeboxed, i.e. limited to a specific duration. It provides a kind of expectation which makes the team-members aware that if something is not working out its time to seek help, split the task, change teams or do anything that will help in the completion of the task.

At the initial phase, the task of assigning points to stories may seem a bit daunting and a bit like second guessing oneself but as the iterations pass on and based on the understanding of the feature and the experience one has in assigning points to user-stories, the estimation will always improve and at the end will be very close to the actual statistics. Also estimates can be changed if one feels an incorrect estimation was done but care should be taken that the variation is not too much.

===R- business Relevant===
A user story should be of business value, i.e it should generate additional income or protect revenue. The software defined by the user story can increase the value of the product by generating interest among new users and thereby generating potential new customers.A software can also protect revenue by streamlining processes to cut costs.
One way of determining the business relevance of a product is by asking the question “why” recursively. This is similar to a problem solving technique called “5 Whys” where questions asked recursively for root cause analysis. The methodology can be extended here to recursively ask why developing a software is of business relevance to that company. It is assumed that after asking multiple times the reason will have some business relevance (for eg “To increase in revenue for the company”) or there is no valid reason justifying the software project.

==Example==
Let us understand SMART User Stories by taking an example:

I want an application that shows me the best deals.

There are all sorts of problems with the above user story. It doesn't fit any of the criterion we have set using our SMART User Stories approach. Let’s go over with each of the problems and try to improve our user story step-by-step.

S-Specific / M-Measurable: 
The above example is anything but specific nor it seems measurable. Well it does say that there needs to be an application that shows the best deals but it doesn't mention to display the best deals from which all places or websites. Also it doesn't mention about what it wants the best deals on. Also as it doesn't mention about the websites it is difficult it to measure the story.

A much better user story would have been: 
I want an application that shows the user the best deals on a particular product, which is entered by the user before beginning the search, from the websites that preselected by the user.

This says specifically on what product the user wants the search on and from which all websites. This is a very specific goal as there is no scope of assumption here. Of course the search results will be based on the specific words the user enters, but that is true for any website. The more specific you are in your search the more fine grained your search will be. Also because of the modified story, now it is easy to measure the story, as we can go through each website and compare prices and check whether the application did indeed return the best deals from various websites.

A-Achievable: 
Appropriate timelines and deadlines should be set for implementing and testing the application. Suppose the client wants the above application for the Thanksgiving sale and he comes and asks for it during midweek of November, then creating the above story at that time wouldn’t be useful or advisable as the time period is too short for the goal to achieve.

Assuming there is sufficient time for the application to be created and there are say 4 iterations possible. But the above story may not be practical for one iteration, one might need to break it down further to make it workable for 1 iteration as the target is to have a workable code at the end of each iteration. So the story for the particular iteration can be modified as:

Provide an interface for the user to provide the name of the product and the websites he/she wants to have a search in.

This would be achievable for the first iteration. For the second iteration more functionality may be added:

Look for the price of the product in all of the websites given by the user and fetch all the results.

This can be further modified in iteration 3 to give the best deal, based on price factor. This can be further modified to modify the result if any free goodies are being provided by any particular website. In this way the goal can be made achievable.

T-Timeboxed 
All of the above 4 iterations that we planned should have the deadlines appropriately. If we suppose till one particular date if the team-member responsible for developing one particular functionality is not able to reach the target goal, it might be a good idea for him/her to ask to someone else or for some senior member to help out or to swap teams itself so that someone who has knowledge can work on that and can complete it without affecting the deadlines and making sure that the product is still workable at the end of that particular iteration. This should be followed for all the iterations. This will also allow sufficient time for testing which is a very important part of the application development.

R-Relevant 
The story should be relevant so that the desired benefit can be obtained and maximized. Why would the client need it
*Probably because there are many websites which offer different deals and to get a single website which searches all the websites on behalf of the user or at least a subset of the websites would make it much easier for the user
*That will also lead to increase in the clicks the website gets
*Which will subsequently lead to increase in ads
*Which will lead to increase in revenue for the company

Now the above goals are relevant for the application that user wants but it may not be relevant for the Terms and Conditions page or the login page that application may have.

==Advantages/Disadvantages of SMART User stories==
===Advantages of SMART User stories===
Lets consider the advantages of SMART User stories by considering each letter of the mnemonic.
*Making a user story specific makes the objectives of the project clear and prevent confusion amongst teams
*Having a well defined input/output relation makes the project measurable/testable for bugs and defects.
*Having a specific user story helps breaking the project down to achievable goals. These goals can be accomplished in single or multiple iterations.
*Asking whether a project is business relevant helps in identifying the maximum potential of the project.
*A timeboxed project helps in monitoring the progress of the project. It is also possible to estimate the velocity of the project using timeboxing.

===Disadvantages/Limitations of SMART User Stories===

*Some people prefer other kind of mnemonics such as INVEST rather than SMART as they feel that the thing that SMART stands for is not the same for all people. S may stand for Specific for some, Significant for some, Stretching for others, similarly M may be Measurable or Meaningful, likewise each of the alphabet of SMART has different meaning for different people.
*It is important that points assignment to user stories is done by someone experienced enough to understand the features that customers require as well as the complexity and technical details required to implement it successfully otherwise the velocity will be far from what is expected.
==Conclusion==

==References==
<references/>
[http://www.youtube.com/watch?v=XzV0dytYQq0 SaaS 4.2: SMART User stories] 
[http://uxdesign.smashingmagazine.com/2011/09/13/the-s-m-a-r-t-user-experience-strategy/ SMART User experience strategy] 
[http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ INVEST in good stories and SMART Tasks] 
[http://www.chiefsimplicityofficer.com/2010/04/user-stories-its-smart-to-invest/ User stories: Its SMART to INVEST] 

==See Also==

[http://en.wikipedia.org/wiki/User_story Information on user stories] 
[http://gigaom.com/2008/05/05/how-to-create-smart-tasks/ Information on SMART tasks] 
[http://www.uncommon-knowledge.co.uk/goal_setting/smart_4.html Information on SMART goals] 
[http://en.wikipedia.org/wiki/5_Whys Link for 5 Whys]

CSC/ECE 517 Fall 2012/ch2b 1w70 nl

2012-11-20T01:06:39Z

Nloya: /* Advantages of SMART User stories */

SaaS - 4.2 - SMART User Stories

==Introduction==
User stories are the basis for defining the functionality of any given system. They are a short description of the system that capture what the system does and gives the expectation of how the system should behave.
When we say User Stories, we don’t define any particular criteria as to how a user story should be written. A user story can be “Customer should have a good UI experience” or “When a customer logs in he/she should be able to see all the technical details of the product he/she has selected, with the reviews, price displayed alongside and an option of ‘Add to Cart’ to go along with it.”
Both the user stories described above are correct but one leaves too much for one to assume and the other gives one specific information in terms of display and functionality. The problem with the first user story is it is not restricted to any particular guideline, its just a user story but has no scope and hence can be either very short or very long. The advantage with the second user story is that it has been written based on a given set of goals which can be acronymed as SMART and will be explained below.

==SMART User Stories==

SMART is a mnemonic for 
*S - Specific
*M - Measurable
*A - Achievable
*R - Relevant
*T- Timeboxed

===S -Specific/ M - Measurable===
The user story should be specific enough to capture the requirements of the user. The user can be the customer who requires the software or the end user who will be using the software. Many times the user stories are vague or ambiguous leading to a lot of loss in time and energy spent in development.
User stories can be made specific by using the terms 'Given, When and Then' which describe the user story. The term “Given” specifies the background scenarios. It specifies all the preconditions.
“When” specifies the input to the system. “Then” specifies the desired result/s. 
Example: 
Given I am at www.google.com
When I click on the button Gmail
Then I should be redirected to Gmail.
Each scenario should be testable i.e its progress should be measurable. There should be known good output for every input. Every project needs concrete criteria for measuring progress toward its completion. The reason behind this is that if the scenarios are not measurable, it is not possible to know whether a team is making progress toward successful completion. Measuring progress is supposed to help a team stay on track, reach its target dates, and experience the exhilaration of achievement that spurs it on to continued effort required to reach the ultimate goal.

===A - Achievable / T - Timeboxed===
Goals should be set in such a way that it is achievable or at least a working model of it is achievable within a single iteration i.e. it is achievable within a time period. The reason for this is that Agile methodologies always aim for working models at the end of iteration, it doesn’t necessarily have to be a complete feature but a run-down version of it which is working partially and is able to provide a minimal set of functionality is also accepted.
If the feature is such that it may span over multiple iterations then it is a good idea to break it up into subset of stories such that each implemented subset provides a working model of the feature, however small it may be, so that constant progress is made to implement the feature and also a working code is provided at the end of each iteration.

While its a good idea to divide a feature into sub-features and have user stories for each iteration, the question arises of how to decide on the number of user stories for each iteration and the number of iterations that may require for the complete feature to be implemented. This is usually accomplished using velocity which is an estimate of the kind of progress made in the past based on the difficulty of the user stories and the kind of progress that can be made by taking into consideration the difficulty of the user stories that are yet to be implemented.

As features are broken down to sub-features and stories are written for the sub-feature, which is to be completed within the iteration, points should be assigned to each of the stories based on the difficulty level of the story and how fine grained approach for point-assignment does an assigner want. Say for example an assigner wants just a simple approach for point-assignment then he/she can assign from a range of 1-3 (where 1 being easy, 2 being medium and 3 being hard) and if a more fine grained approach is required then the range can be increased to 1-5 or 1-10. Whatever the approach is followed the important thing is to allocate points to each of the stories based on one’s estimate. At the end of each iteration, Velocity is calculated, which is nothing but the total number of points completed per iteration. As Velocity is not just the total of the stories but the total based on the difficulty level of the stories, it acts as an important guiding tool which can be leveraged by anyone to get to know details about the project as is shown below.

Uses of Velocity:

*Velocity can be used to plan future iterations
*It gives an estimate of how much time or iterations would be required to completely implement the feature
*It gives an idea of whether the team is on track as the velocity is expected to remain constant if all other variables are unchanged (other variables such as number of team members or replacement of an experienced team member with a new team member, etc.)
*It can provide an estimate if a change is requested by customers and based on the time required to implement the change and the importance level of the change the decision can be made whether to implement it or not.

Following this approach allows a task to be timeboxed, i.e. limited to a specific duration. It provides a kind of expectation which makes the team-members aware that if something is not working out its time to seek help, split the task, change teams or do anything that will help in the completion of the task.

At the initial phase, the task of assigning points to stories may seem a bit daunting and a bit like second guessing oneself but as the iterations pass on and based on the understanding of the feature and the experience one has in assigning points to user-stories, the estimation will always improve and at the end will be very close to the actual statistics. Also estimates can be changed if one feels an incorrect estimation was done but care should be taken that the variation is not too much.

===R- business Relevant===
A user story should be of business value, i.e it should generate additional income or protect revenue. The software defined by the user story can increase the value of the product by generating interest among new users and thereby generating potential new customers.A software can also protect revenue by streamlining processes to cut costs.
One way of determining the business relevance of a product is by asking the question “why” recursively. This is similar to a problem solving technique called “5 Whys” where questions asked recursively for root cause analysis. The methodology can be extended here to recursively ask why developing a software is of business relevance to that company. It is assumed that after asking multiple times the reason will have some business relevance (for eg “To increase in revenue for the company”) or there is no valid reason justifying the software project.

==Example==
Let us understand SMART User Stories by taking an example:

I want an application that shows me the best deals.

There are all sorts of problems with the above user story. It doesn't fit any of the criterion we have set using our SMART User Stories approach. Let’s go over with each of the problems and try to improve our user story step-by-step.

S-Specific / M-Measurable: 
The above example is anything but specific nor it seems measurable. Well it does say that there needs to be an application that shows the best deals but it doesn't mention to display the best deals from which all places or websites. Also it doesn't mention about what it wants the best deals on. Also as it doesn't mention about the websites it is difficult it to measure the story.

A much better user story would have been: 
I want an application that shows me the best deals on a particular product, which is entered by me before beginning the search, from the websites that I preselect.

This says specifically on what product the user wants the search on and from which all websites. This is a very specific goal as there is no scope of assumption here. Of course the search results will be based on the specific words the user enters, but that is true for any website. The more specific you are in your search the more fine grained your search will be. Also because of the modified story, now it is easy to measure the story, as we can go through each website and compare prices and check whether the application did indeed return the best deals from various websites.

A-Achievable: 
Appropriate timelines and deadlines should be set for implementing and testing the application. Suppose the client wants the above application for the Thanksgiving sale and he comes and asks for it during midweek of November, then creating the above story at that time wouldn’t be useful or advisable as the time period is too short for the goal to achieve.

Assuming there is sufficient time for the application to be created and there are say 4 iterations possible. But the above story may not be practical for one iteration, one might need to break it down further to make it workable for 1 iteration as the target is to have a workable code at the end of each iteration. So the story for the particular iteration can be modified as:

Provide an interface for the user to provide the name of the product and the websites he/she wants to have a search in.

This would be achievable for the first iteration. For the second iteration more functionality may be added:

Look for the price of the product in all of the websites given by the user and fetch all the results.

This can be further modified in iteration 3 to give the best deal, based on price factor. This can be further modified to modify the result if any free goodies are being provided by any particular website. In this way the goal can be made achievable.

T-Timeboxed 
All of the above 4 iterations that we planned should have the deadlines appropriately. If we suppose till one particular date if the team-member responsible for developing one particular functionality is not able to reach the target goal, it might be a good idea for him/her to ask to someone else or for some senior member to help out or to swap teams itself so that someone who has knowledge can work on that and can complete it without affecting the deadlines and making sure that the product is still workable at the end of that particular iteration. This should be followed for all the iterations. This will also allow sufficient time for testing which is a very important part of the application development.

R-Relevant 
The story should be relevant so that the desired benefit can be obtained and maximized. Why would the client need it
*Probably because there are many websites which offer different deals and to get a single website which searches all the websites on behalf of the user or at least a subset of the websites would make it much easier for the user
*That will also lead to increase in the clicks the website gets
*Which will subsequently lead to increase in ads
*Which will lead to increase in revenue for the company

Now the above goals are relevant for the application that user wants but it may not be relevant for the Terms and Conditions page or the login page that application may have.

==Advantages/Disadvantages of SMART User stories==
===Advantages of SMART User stories===
Lets consider the advantages of SMART User stories by considering each letter of the mnemonic.
*Making a user story specific makes the objectives of the project clear and prevent confusion amongst teams
*Having a well defined input/output relation makes the project measurable/testable for bugs and defects.
*Having a specific user story helps breaking the project down to achievable goals. These goals can be accomplished in single or multiple iterations.
*Asking whether a project is business relevant helps in identifying the maximum potential of the project.
*A timeboxed project helps in monitoring the progress of the project. It is also possible to estimate the velocity of the project using timeboxing.

===Disadvantages/Limitations of SMART User Stories===

*Some people prefer other kind of mnemonics such as INVEST rather than SMART as they feel that the thing that SMART stands for is not the same for all people. S may stand for Specific for some, Significant for some, Stretching for others, similarly M may be Measurable or Meaningful, likewise each of the alphabet of SMART has different meaning for different people.
*It is important that points assignment to user stories is done by someone experienced enough to understand the features that customers require as well as the complexity and technical details required to implement it successfully otherwise the velocity will be far from what is expected.
==Conclusion==

==References==
<references/>
[http://www.youtube.com/watch?v=XzV0dytYQq0 SaaS 4.2: SMART User stories] 
[http://uxdesign.smashingmagazine.com/2011/09/13/the-s-m-a-r-t-user-experience-strategy/ SMART User experience strategy] 
[http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ INVEST in good stories and SMART Tasks] 
[http://www.chiefsimplicityofficer.com/2010/04/user-stories-its-smart-to-invest/ User stories: Its SMART to INVEST] 

==See Also==

[http://en.wikipedia.org/wiki/User_story Information on user stories] 
[http://gigaom.com/2008/05/05/how-to-create-smart-tasks/ Information on SMART tasks] 
[http://www.uncommon-knowledge.co.uk/goal_setting/smart_4.html Information on SMART goals] 
[http://en.wikipedia.org/wiki/5_Whys Link for 5 Whys]

CSC/ECE 517 Fall 2012/ch2b 1w70 nl

2012-11-20T01:05:55Z

Nloya: /* Advantages of SMART User stories */

SaaS - 4.2 - SMART User Stories

==Introduction==
User stories are the basis for defining the functionality of any given system. They are a short description of the system that capture what the system does and gives the expectation of how the system should behave.
When we say User Stories, we don’t define any particular criteria as to how a user story should be written. A user story can be “Customer should have a good UI experience” or “When a customer logs in he/she should be able to see all the technical details of the product he/she has selected, with the reviews, price displayed alongside and an option of ‘Add to Cart’ to go along with it.”
Both the user stories described above are correct but one leaves too much for one to assume and the other gives one specific information in terms of display and functionality. The problem with the first user story is it is not restricted to any particular guideline, its just a user story but has no scope and hence can be either very short or very long. The advantage with the second user story is that it has been written based on a given set of goals which can be acronymed as SMART and will be explained below.

==SMART User Stories==

SMART is a mnemonic for 
*S - Specific
*M - Measurable
*A - Achievable
*R - Relevant
*T- Timeboxed

===S -Specific/ M - Measurable===
The user story should be specific enough to capture the requirements of the user. The user can be the customer who requires the software or the end user who will be using the software. Many times the user stories are vague or ambiguous leading to a lot of loss in time and energy spent in development.
User stories can be made specific by using the terms 'Given, When and Then' which describe the user story. The term “Given” specifies the background scenarios. It specifies all the preconditions.
“When” specifies the input to the system. “Then” specifies the desired result/s. 
Example: 
Given I am at www.google.com
When I click on the button Gmail
Then I should be redirected to Gmail.
Each scenario should be testable i.e its progress should be measurable. There should be known good output for every input. Every project needs concrete criteria for measuring progress toward its completion. The reason behind this is that if the scenarios are not measurable, it is not possible to know whether a team is making progress toward successful completion. Measuring progress is supposed to help a team stay on track, reach its target dates, and experience the exhilaration of achievement that spurs it on to continued effort required to reach the ultimate goal.

===A - Achievable / T - Timeboxed===
Goals should be set in such a way that it is achievable or at least a working model of it is achievable within a single iteration i.e. it is achievable within a time period. The reason for this is that Agile methodologies always aim for working models at the end of iteration, it doesn’t necessarily have to be a complete feature but a run-down version of it which is working partially and is able to provide a minimal set of functionality is also accepted.
If the feature is such that it may span over multiple iterations then it is a good idea to break it up into subset of stories such that each implemented subset provides a working model of the feature, however small it may be, so that constant progress is made to implement the feature and also a working code is provided at the end of each iteration.

While its a good idea to divide a feature into sub-features and have user stories for each iteration, the question arises of how to decide on the number of user stories for each iteration and the number of iterations that may require for the complete feature to be implemented. This is usually accomplished using velocity which is an estimate of the kind of progress made in the past based on the difficulty of the user stories and the kind of progress that can be made by taking into consideration the difficulty of the user stories that are yet to be implemented.

As features are broken down to sub-features and stories are written for the sub-feature, which is to be completed within the iteration, points should be assigned to each of the stories based on the difficulty level of the story and how fine grained approach for point-assignment does an assigner want. Say for example an assigner wants just a simple approach for point-assignment then he/she can assign from a range of 1-3 (where 1 being easy, 2 being medium and 3 being hard) and if a more fine grained approach is required then the range can be increased to 1-5 or 1-10. Whatever the approach is followed the important thing is to allocate points to each of the stories based on one’s estimate. At the end of each iteration, Velocity is calculated, which is nothing but the total number of points completed per iteration. As Velocity is not just the total of the stories but the total based on the difficulty level of the stories, it acts as an important guiding tool which can be leveraged by anyone to get to know details about the project as is shown below.

Uses of Velocity:

*Velocity can be used to plan future iterations
*It gives an estimate of how much time or iterations would be required to completely implement the feature
*It gives an idea of whether the team is on track as the velocity is expected to remain constant if all other variables are unchanged (other variables such as number of team members or replacement of an experienced team member with a new team member, etc.)
*It can provide an estimate if a change is requested by customers and based on the time required to implement the change and the importance level of the change the decision can be made whether to implement it or not.

Following this approach allows a task to be timeboxed, i.e. limited to a specific duration. It provides a kind of expectation which makes the team-members aware that if something is not working out its time to seek help, split the task, change teams or do anything that will help in the completion of the task.

At the initial phase, the task of assigning points to stories may seem a bit daunting and a bit like second guessing oneself but as the iterations pass on and based on the understanding of the feature and the experience one has in assigning points to user-stories, the estimation will always improve and at the end will be very close to the actual statistics. Also estimates can be changed if one feels an incorrect estimation was done but care should be taken that the variation is not too much.

===R- business Relevant===
A user story should be of business value, i.e it should generate additional income or protect revenue. The software defined by the user story can increase the value of the product by generating interest among new users and thereby generating potential new customers.A software can also protect revenue by streamlining processes to cut costs.
One way of determining the business relevance of a product is by asking the question “why” recursively. This is similar to a problem solving technique called “5 Whys” where questions asked recursively for root cause analysis. The methodology can be extended here to recursively ask why developing a software is of business relevance to that company. It is assumed that after asking multiple times the reason will have some business relevance (for eg “To increase in revenue for the company”) or there is no valid reason justifying the software project.

==Example==
Let us understand SMART User Stories by taking an example:

I want an application that shows me the best deals.

There are all sorts of problems with the above user story. It doesn't fit any of the criterion we have set using our SMART User Stories approach. Let’s go over with each of the problems and try to improve our user story step-by-step.

S-Specific / M-Measurable: 
The above example is anything but specific nor it seems measurable. Well it does say that there needs to be an application that shows the best deals but it doesn't mention to display the best deals from which all places or websites. Also it doesn't mention about what it wants the best deals on. Also as it doesn't mention about the websites it is difficult it to measure the story.

A much better user story would have been: 
I want an application that shows me the best deals on a particular product, which is entered by me before beginning the search, from the websites that I preselect.

This says specifically on what product the user wants the search on and from which all websites. This is a very specific goal as there is no scope of assumption here. Of course the search results will be based on the specific words the user enters, but that is true for any website. The more specific you are in your search the more fine grained your search will be. Also because of the modified story, now it is easy to measure the story, as we can go through each website and compare prices and check whether the application did indeed return the best deals from various websites.

A-Achievable: 
Appropriate timelines and deadlines should be set for implementing and testing the application. Suppose the client wants the above application for the Thanksgiving sale and he comes and asks for it during midweek of November, then creating the above story at that time wouldn’t be useful or advisable as the time period is too short for the goal to achieve.

Assuming there is sufficient time for the application to be created and there are say 4 iterations possible. But the above story may not be practical for one iteration, one might need to break it down further to make it workable for 1 iteration as the target is to have a workable code at the end of each iteration. So the story for the particular iteration can be modified as:

Provide an interface for the user to provide the name of the product and the websites he/she wants to have a search in.

This would be achievable for the first iteration. For the second iteration more functionality may be added:

Look for the price of the product in all of the websites given by the user and fetch all the results.

This can be further modified in iteration 3 to give the best deal, based on price factor. This can be further modified to modify the result if any free goodies are being provided by any particular website. In this way the goal can be made achievable.

T-Timeboxed 
All of the above 4 iterations that we planned should have the deadlines appropriately. If we suppose till one particular date if the team-member responsible for developing one particular functionality is not able to reach the target goal, it might be a good idea for him/her to ask to someone else or for some senior member to help out or to swap teams itself so that someone who has knowledge can work on that and can complete it without affecting the deadlines and making sure that the product is still workable at the end of that particular iteration. This should be followed for all the iterations. This will also allow sufficient time for testing which is a very important part of the application development.

R-Relevant 
The story should be relevant so that the desired benefit can be obtained and maximized. Why would the client need it
*Probably because there are many websites which offer different deals and to get a single website which searches all the websites on behalf of the user or at least a subset of the websites would make it much easier for the user
*That will also lead to increase in the clicks the website gets
*Which will subsequently lead to increase in ads
*Which will lead to increase in revenue for the company

Now the above goals are relevant for the application that user wants but it may not be relevant for the Terms and Conditions page or the login page that application may have.

==Advantages/Disadvantages of SMART User stories==
===Advantages of SMART User stories===
Lets consider the advantages of SMART User stories by considering each letter of the mnemonic.
*Making a user story specific makes the objectives of the project clear and prevent confusion amongst teams
*Having a well defined input/output relation makes the project measurable/testable for bugs and defects.
*Having a specific user story helps breaking the project down to achievable goals These goals can be accomplished in single or multiple iterations.
*Asking whether a project is business relevant helps in identifying the maximum potential of the project.
*A timeboxed project helps in monitoring the progress of the project. It is also possible to estimate the velocity of the project using timeboxing.

===Disadvantages/Limitations of SMART User Stories===

*Some people prefer other kind of mnemonics such as INVEST rather than SMART as they feel that the thing that SMART stands for is not the same for all people. S may stand for Specific for some, Significant for some, Stretching for others, similarly M may be Measurable or Meaningful, likewise each of the alphabet of SMART has different meaning for different people.
*It is important that points assignment to user stories is done by someone experienced enough to understand the features that customers require as well as the complexity and technical details required to implement it successfully otherwise the velocity will be far from what is expected.
==Conclusion==

==References==
<references/>
[http://www.youtube.com/watch?v=XzV0dytYQq0 SaaS 4.2: SMART User stories] 
[http://uxdesign.smashingmagazine.com/2011/09/13/the-s-m-a-r-t-user-experience-strategy/ SMART User experience strategy] 
[http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ INVEST in good stories and SMART Tasks] 
[http://www.chiefsimplicityofficer.com/2010/04/user-stories-its-smart-to-invest/ User stories: Its SMART to INVEST] 

==See Also==

[http://en.wikipedia.org/wiki/User_story Information on user stories] 
[http://gigaom.com/2008/05/05/how-to-create-smart-tasks/ Information on SMART tasks] 
[http://www.uncommon-knowledge.co.uk/goal_setting/smart_4.html Information on SMART goals] 
[http://en.wikipedia.org/wiki/5_Whys Link for 5 Whys]

CSC/ECE 517 Fall 2012/ch2b 1w70 nl

2012-11-20T01:05:00Z

Nloya: /* Advantages of SMART User stories */

SaaS - 4.2 - SMART User Stories

==Introduction==
User stories are the basis for defining the functionality of any given system. They are a short description of the system that capture what the system does and gives the expectation of how the system should behave.
When we say User Stories, we don’t define any particular criteria as to how a user story should be written. A user story can be “Customer should have a good UI experience” or “When a customer logs in he/she should be able to see all the technical details of the product he/she has selected, with the reviews, price displayed alongside and an option of ‘Add to Cart’ to go along with it.”
Both the user stories described above are correct but one leaves too much for one to assume and the other gives one specific information in terms of display and functionality. The problem with the first user story is it is not restricted to any particular guideline, its just a user story but has no scope and hence can be either very short or very long. The advantage with the second user story is that it has been written based on a given set of goals which can be acronymed as SMART and will be explained below.

==SMART User Stories==

SMART is a mnemonic for 
*S - Specific
*M - Measurable
*A - Achievable
*R - Relevant
*T- Timeboxed

===S -Specific/ M - Measurable===
The user story should be specific enough to capture the requirements of the user. The user can be the customer who requires the software or the end user who will be using the software. Many times the user stories are vague or ambiguous leading to a lot of loss in time and energy spent in development.
User stories can be made specific by using the terms 'Given, When and Then' which describe the user story. The term “Given” specifies the background scenarios. It specifies all the preconditions.
“When” specifies the input to the system. “Then” specifies the desired result/s. 
Example: 
Given I am at www.google.com
When I click on the button Gmail
Then I should be redirected to Gmail.
Each scenario should be testable i.e its progress should be measurable. There should be known good output for every input. Every project needs concrete criteria for measuring progress toward its completion. The reason behind this is that if the scenarios are not measurable, it is not possible to know whether a team is making progress toward successful completion. Measuring progress is supposed to help a team stay on track, reach its target dates, and experience the exhilaration of achievement that spurs it on to continued effort required to reach the ultimate goal.

===A - Achievable / T - Timeboxed===
Goals should be set in such a way that it is achievable or at least a working model of it is achievable within a single iteration i.e. it is achievable within a time period. The reason for this is that Agile methodologies always aim for working models at the end of iteration, it doesn’t necessarily have to be a complete feature but a run-down version of it which is working partially and is able to provide a minimal set of functionality is also accepted.
If the feature is such that it may span over multiple iterations then it is a good idea to break it up into subset of stories such that each implemented subset provides a working model of the feature, however small it may be, so that constant progress is made to implement the feature and also a working code is provided at the end of each iteration.

While its a good idea to divide a feature into sub-features and have user stories for each iteration, the question arises of how to decide on the number of user stories for each iteration and the number of iterations that may require for the complete feature to be implemented. This is usually accomplished using velocity which is an estimate of the kind of progress made in the past based on the difficulty of the user stories and the kind of progress that can be made by taking into consideration the difficulty of the user stories that are yet to be implemented.

As features are broken down to sub-features and stories are written for the sub-feature, which is to be completed within the iteration, points should be assigned to each of the stories based on the difficulty level of the story and how fine grained approach for point-assignment does an assigner want. Say for example an assigner wants just a simple approach for point-assignment then he/she can assign from a range of 1-3 (where 1 being easy, 2 being medium and 3 being hard) and if a more fine grained approach is required then the range can be increased to 1-5 or 1-10. Whatever the approach is followed the important thing is to allocate points to each of the stories based on one’s estimate. At the end of each iteration, Velocity is calculated, which is nothing but the total number of points completed per iteration. As Velocity is not just the total of the stories but the total based on the difficulty level of the stories, it acts as an important guiding tool which can be leveraged by anyone to get to know details about the project as is shown below.

Uses of Velocity:

*Velocity can be used to plan future iterations
*It gives an estimate of how much time or iterations would be required to completely implement the feature
*It gives an idea of whether the team is on track as the velocity is expected to remain constant if all other variables are unchanged (other variables such as number of team members or replacement of an experienced team member with a new team member, etc.)
*It can provide an estimate if a change is requested by customers and based on the time required to implement the change and the importance level of the change the decision can be made whether to implement it or not.

Following this approach allows a task to be timeboxed, i.e. limited to a specific duration. It provides a kind of expectation which makes the team-members aware that if something is not working out its time to seek help, split the task, change teams or do anything that will help in the completion of the task.

At the initial phase, the task of assigning points to stories may seem a bit daunting and a bit like second guessing oneself but as the iterations pass on and based on the understanding of the feature and the experience one has in assigning points to user-stories, the estimation will always improve and at the end will be very close to the actual statistics. Also estimates can be changed if one feels an incorrect estimation was done but care should be taken that the variation is not too much.

===R- business Relevant===
A user story should be of business value, i.e it should generate additional income or protect revenue. The software defined by the user story can increase the value of the product by generating interest among new users and thereby generating potential new customers.A software can also protect revenue by streamlining processes to cut costs.
One way of determining the business relevance of a product is by asking the question “why” recursively. This is similar to a problem solving technique called “5 Whys” where questions asked recursively for root cause analysis. The methodology can be extended here to recursively ask why developing a software is of business relevance to that company. It is assumed that after asking multiple times the reason will have some business relevance (for eg “To increase in revenue for the company”) or there is no valid reason justifying the software project.

==Example==
Let us understand SMART User Stories by taking an example:

I want an application that shows me the best deals.

There are all sorts of problems with the above user story. It doesn't fit any of the criterion we have set using our SMART User Stories approach. Let’s go over with each of the problems and try to improve our user story step-by-step.

S-Specific / M-Measurable: 
The above example is anything but specific nor it seems measurable. Well it does say that there needs to be an application that shows the best deals but it doesn't mention to display the best deals from which all places or websites. Also it doesn't mention about what it wants the best deals on. Also as it doesn't mention about the websites it is difficult it to measure the story.

A much better user story would have been: 
I want an application that shows me the best deals on a particular product, which is entered by me before beginning the search, from the websites that I preselect.

This says specifically on what product the user wants the search on and from which all websites. This is a very specific goal as there is no scope of assumption here. Of course the search results will be based on the specific words the user enters, but that is true for any website. The more specific you are in your search the more fine grained your search will be. Also because of the modified story, now it is easy to measure the story, as we can go through each website and compare prices and check whether the application did indeed return the best deals from various websites.

A-Achievable: 
Appropriate timelines and deadlines should be set for implementing and testing the application. Suppose the client wants the above application for the Thanksgiving sale and he comes and asks for it during midweek of November, then creating the above story at that time wouldn’t be useful or advisable as the time period is too short for the goal to achieve.

Assuming there is sufficient time for the application to be created and there are say 4 iterations possible. But the above story may not be practical for one iteration, one might need to break it down further to make it workable for 1 iteration as the target is to have a workable code at the end of each iteration. So the story for the particular iteration can be modified as:

Provide an interface for the user to provide the name of the product and the websites he/she wants to have a search in.

This would be achievable for the first iteration. For the second iteration more functionality may be added:

Look for the price of the product in all of the websites given by the user and fetch all the results.

This can be further modified in iteration 3 to give the best deal, based on price factor. This can be further modified to modify the result if any free goodies are being provided by any particular website. In this way the goal can be made achievable.

T-Timeboxed 
All of the above 4 iterations that we planned should have the deadlines appropriately. If we suppose till one particular date if the team-member responsible for developing one particular functionality is not able to reach the target goal, it might be a good idea for him/her to ask to someone else or for some senior member to help out or to swap teams itself so that someone who has knowledge can work on that and can complete it without affecting the deadlines and making sure that the product is still workable at the end of that particular iteration. This should be followed for all the iterations. This will also allow sufficient time for testing which is a very important part of the application development.

R-Relevant 
The story should be relevant so that the desired benefit can be obtained and maximized. Why would the client need it
*Probably because there are many websites which offer different deals and to get a single website which searches all the websites on behalf of the user or at least a subset of the websites would make it much easier for the user
*That will also lead to increase in the clicks the website gets
*Which will subsequently lead to increase in ads
*Which will lead to increase in revenue for the company

Now the above goals are relevant for the application that user wants but it may not be relevant for the Terms and Conditions page or the login page that application may have.

==Advantages/Disadvantages of SMART User stories==
===Advantages of SMART User stories===
Lets consider the advantages of SMART User stories by considering each letter of the mnemonic.
*Making a user story specific makes the objectives of the project clear and prevent confusion amongst teams
*Having a well defined input /output relation makes the project measurable/testable for bugs and defects.
*Having a specific user story helps breaking the project down to achievable goals These goals can be accomplished in single or multiple iterations.
*Asking whether a project is business relevant helps in identifying the maximum potential of the project.
*A timeboxed project helps in monitoring the progress of the project. It is also possible to estimate the velocity of the project using timeboxing.

===Disadvantages/Limitations of SMART User Stories===

*Some people prefer other kind of mnemonics such as INVEST rather than SMART as they feel that the thing that SMART stands for is not the same for all people. S may stand for Specific for some, Significant for some, Stretching for others, similarly M may be Measurable or Meaningful, likewise each of the alphabet of SMART has different meaning for different people.
*It is important that points assignment to user stories is done by someone experienced enough to understand the features that customers require as well as the complexity and technical details required to implement it successfully otherwise the velocity will be far from what is expected.
==Conclusion==

==References==
<references/>
[http://www.youtube.com/watch?v=XzV0dytYQq0 SaaS 4.2: SMART User stories] 
[http://uxdesign.smashingmagazine.com/2011/09/13/the-s-m-a-r-t-user-experience-strategy/ SMART User experience strategy] 
[http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ INVEST in good stories and SMART Tasks] 
[http://www.chiefsimplicityofficer.com/2010/04/user-stories-its-smart-to-invest/ User stories: Its SMART to INVEST] 

==See Also==

[http://en.wikipedia.org/wiki/User_story Information on user stories] 
[http://gigaom.com/2008/05/05/how-to-create-smart-tasks/ Information on SMART tasks] 
[http://www.uncommon-knowledge.co.uk/goal_setting/smart_4.html Information on SMART goals] 
[http://en.wikipedia.org/wiki/5_Whys Link for 5 Whys]

CSC/ECE 517 Fall 2012/ch2b 1w70 nl

2012-11-20T01:04:14Z

Nloya: /* Example */

SaaS - 4.2 - SMART User Stories

==Introduction==
User stories are the basis for defining the functionality of any given system. They are a short description of the system that capture what the system does and gives the expectation of how the system should behave.
When we say User Stories, we don’t define any particular criteria as to how a user story should be written. A user story can be “Customer should have a good UI experience” or “When a customer logs in he/she should be able to see all the technical details of the product he/she has selected, with the reviews, price displayed alongside and an option of ‘Add to Cart’ to go along with it.”
Both the user stories described above are correct but one leaves too much for one to assume and the other gives one specific information in terms of display and functionality. The problem with the first user story is it is not restricted to any particular guideline, its just a user story but has no scope and hence can be either very short or very long. The advantage with the second user story is that it has been written based on a given set of goals which can be acronymed as SMART and will be explained below.

==SMART User Stories==

SMART is a mnemonic for 
*S - Specific
*M - Measurable
*A - Achievable
*R - Relevant
*T- Timeboxed

===S -Specific/ M - Measurable===
The user story should be specific enough to capture the requirements of the user. The user can be the customer who requires the software or the end user who will be using the software. Many times the user stories are vague or ambiguous leading to a lot of loss in time and energy spent in development.
User stories can be made specific by using the terms 'Given, When and Then' which describe the user story. The term “Given” specifies the background scenarios. It specifies all the preconditions.
“When” specifies the input to the system. “Then” specifies the desired result/s. 
Example: 
Given I am at www.google.com
When I click on the button Gmail
Then I should be redirected to Gmail.
Each scenario should be testable i.e its progress should be measurable. There should be known good output for every input. Every project needs concrete criteria for measuring progress toward its completion. The reason behind this is that if the scenarios are not measurable, it is not possible to know whether a team is making progress toward successful completion. Measuring progress is supposed to help a team stay on track, reach its target dates, and experience the exhilaration of achievement that spurs it on to continued effort required to reach the ultimate goal.

===A - Achievable / T - Timeboxed===
Goals should be set in such a way that it is achievable or at least a working model of it is achievable within a single iteration i.e. it is achievable within a time period. The reason for this is that Agile methodologies always aim for working models at the end of iteration, it doesn’t necessarily have to be a complete feature but a run-down version of it which is working partially and is able to provide a minimal set of functionality is also accepted.
If the feature is such that it may span over multiple iterations then it is a good idea to break it up into subset of stories such that each implemented subset provides a working model of the feature, however small it may be, so that constant progress is made to implement the feature and also a working code is provided at the end of each iteration.

While its a good idea to divide a feature into sub-features and have user stories for each iteration, the question arises of how to decide on the number of user stories for each iteration and the number of iterations that may require for the complete feature to be implemented. This is usually accomplished using velocity which is an estimate of the kind of progress made in the past based on the difficulty of the user stories and the kind of progress that can be made by taking into consideration the difficulty of the user stories that are yet to be implemented.

As features are broken down to sub-features and stories are written for the sub-feature, which is to be completed within the iteration, points should be assigned to each of the stories based on the difficulty level of the story and how fine grained approach for point-assignment does an assigner want. Say for example an assigner wants just a simple approach for point-assignment then he/she can assign from a range of 1-3 (where 1 being easy, 2 being medium and 3 being hard) and if a more fine grained approach is required then the range can be increased to 1-5 or 1-10. Whatever the approach is followed the important thing is to allocate points to each of the stories based on one’s estimate. At the end of each iteration, Velocity is calculated, which is nothing but the total number of points completed per iteration. As Velocity is not just the total of the stories but the total based on the difficulty level of the stories, it acts as an important guiding tool which can be leveraged by anyone to get to know details about the project as is shown below.

Uses of Velocity:

*Velocity can be used to plan future iterations
*It gives an estimate of how much time or iterations would be required to completely implement the feature
*It gives an idea of whether the team is on track as the velocity is expected to remain constant if all other variables are unchanged (other variables such as number of team members or replacement of an experienced team member with a new team member, etc.)
*It can provide an estimate if a change is requested by customers and based on the time required to implement the change and the importance level of the change the decision can be made whether to implement it or not.

Following this approach allows a task to be timeboxed, i.e. limited to a specific duration. It provides a kind of expectation which makes the team-members aware that if something is not working out its time to seek help, split the task, change teams or do anything that will help in the completion of the task.

At the initial phase, the task of assigning points to stories may seem a bit daunting and a bit like second guessing oneself but as the iterations pass on and based on the understanding of the feature and the experience one has in assigning points to user-stories, the estimation will always improve and at the end will be very close to the actual statistics. Also estimates can be changed if one feels an incorrect estimation was done but care should be taken that the variation is not too much.

===R- business Relevant===
A user story should be of business value, i.e it should generate additional income or protect revenue. The software defined by the user story can increase the value of the product by generating interest among new users and thereby generating potential new customers.A software can also protect revenue by streamlining processes to cut costs.
One way of determining the business relevance of a product is by asking the question “why” recursively. This is similar to a problem solving technique called “5 Whys” where questions asked recursively for root cause analysis. The methodology can be extended here to recursively ask why developing a software is of business relevance to that company. It is assumed that after asking multiple times the reason will have some business relevance (for eg “To increase in revenue for the company”) or there is no valid reason justifying the software project.

==Example==
Let us understand SMART User Stories by taking an example:

I want an application that shows me the best deals.

There are all sorts of problems with the above user story. It doesn't fit any of the criterion we have set using our SMART User Stories approach. Let’s go over with each of the problems and try to improve our user story step-by-step.

S-Specific / M-Measurable: 
The above example is anything but specific nor it seems measurable. Well it does say that there needs to be an application that shows the best deals but it doesn't mention to display the best deals from which all places or websites. Also it doesn't mention about what it wants the best deals on. Also as it doesn't mention about the websites it is difficult it to measure the story.

A much better user story would have been: 
I want an application that shows me the best deals on a particular product, which is entered by me before beginning the search, from the websites that I preselect.

This says specifically on what product the user wants the search on and from which all websites. This is a very specific goal as there is no scope of assumption here. Of course the search results will be based on the specific words the user enters, but that is true for any website. The more specific you are in your search the more fine grained your search will be. Also because of the modified story, now it is easy to measure the story, as we can go through each website and compare prices and check whether the application did indeed return the best deals from various websites.

A-Achievable: 
Appropriate timelines and deadlines should be set for implementing and testing the application. Suppose the client wants the above application for the Thanksgiving sale and he comes and asks for it during midweek of November, then creating the above story at that time wouldn’t be useful or advisable as the time period is too short for the goal to achieve.

Assuming there is sufficient time for the application to be created and there are say 4 iterations possible. But the above story may not be practical for one iteration, one might need to break it down further to make it workable for 1 iteration as the target is to have a workable code at the end of each iteration. So the story for the particular iteration can be modified as:

Provide an interface for the user to provide the name of the product and the websites he/she wants to have a search in.

This would be achievable for the first iteration. For the second iteration more functionality may be added:

Look for the price of the product in all of the websites given by the user and fetch all the results.

This can be further modified in iteration 3 to give the best deal, based on price factor. This can be further modified to modify the result if any free goodies are being provided by any particular website. In this way the goal can be made achievable.

T-Timeboxed 
All of the above 4 iterations that we planned should have the deadlines appropriately. If we suppose till one particular date if the team-member responsible for developing one particular functionality is not able to reach the target goal, it might be a good idea for him/her to ask to someone else or for some senior member to help out or to swap teams itself so that someone who has knowledge can work on that and can complete it without affecting the deadlines and making sure that the product is still workable at the end of that particular iteration. This should be followed for all the iterations. This will also allow sufficient time for testing which is a very important part of the application development.

R-Relevant 
The story should be relevant so that the desired benefit can be obtained and maximized. Why would the client need it
*Probably because there are many websites which offer different deals and to get a single website which searches all the websites on behalf of the user or at least a subset of the websites would make it much easier for the user
*That will also lead to increase in the clicks the website gets
*Which will subsequently lead to increase in ads
*Which will lead to increase in revenue for the company

Now the above goals are relevant for the application that user wants but it may not be relevant for the Terms and Conditions page or the login page that application may have.

==Advantages/Disadvantages of SMART User stories==
===Advantages of SMART User stories===
Lets consider the advantages of SMART User stories by considering each letter of the mnemonic.
*Making a user story specific makes the objectives of the project clear and prevent confusion amongst teams
*Having a well defined input /output relation makes the project measurable/ testable for bugs and defects.
*Having a specific user story helps breaking the project down to achievable goals These goals can be accomplished in single or multiple iterations.
*Asking whether a project is business relevant helps in identifying the maximum potential of the project.
*A timeboxed project helps in monitoring the progress of the project. It is also possible to estimate the velocity of the project using timeboxing.
===Disadvantages/Limitations of SMART User Stories===

*Some people prefer other kind of mnemonics such as INVEST rather than SMART as they feel that the thing that SMART stands for is not the same for all people. S may stand for Specific for some, Significant for some, Stretching for others, similarly M may be Measurable or Meaningful, likewise each of the alphabet of SMART has different meaning for different people.
*It is important that points assignment to user stories is done by someone experienced enough to understand the features that customers require as well as the complexity and technical details required to implement it successfully otherwise the velocity will be far from what is expected.
==Conclusion==

==References==
<references/>
[http://www.youtube.com/watch?v=XzV0dytYQq0 SaaS 4.2: SMART User stories] 
[http://uxdesign.smashingmagazine.com/2011/09/13/the-s-m-a-r-t-user-experience-strategy/ SMART User experience strategy] 
[http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ INVEST in good stories and SMART Tasks] 
[http://www.chiefsimplicityofficer.com/2010/04/user-stories-its-smart-to-invest/ User stories: Its SMART to INVEST] 

==See Also==

[http://en.wikipedia.org/wiki/User_story Information on user stories] 
[http://gigaom.com/2008/05/05/how-to-create-smart-tasks/ Information on SMART tasks] 
[http://www.uncommon-knowledge.co.uk/goal_setting/smart_4.html Information on SMART goals] 
[http://en.wikipedia.org/wiki/5_Whys Link for 5 Whys]

CSC/ECE 517 Fall 2012/ch2b 1w70 nl

2012-11-20T01:02:47Z

Nloya: /* A - Achievable / T - Timeboxed */

SaaS - 4.2 - SMART User Stories

==Introduction==
User stories are the basis for defining the functionality of any given system. They are a short description of the system that capture what the system does and gives the expectation of how the system should behave.
When we say User Stories, we don’t define any particular criteria as to how a user story should be written. A user story can be “Customer should have a good UI experience” or “When a customer logs in he/she should be able to see all the technical details of the product he/she has selected, with the reviews, price displayed alongside and an option of ‘Add to Cart’ to go along with it.”
Both the user stories described above are correct but one leaves too much for one to assume and the other gives one specific information in terms of display and functionality. The problem with the first user story is it is not restricted to any particular guideline, its just a user story but has no scope and hence can be either very short or very long. The advantage with the second user story is that it has been written based on a given set of goals which can be acronymed as SMART and will be explained below.

==SMART User Stories==

SMART is a mnemonic for 
*S - Specific
*M - Measurable
*A - Achievable
*R - Relevant
*T- Timeboxed

===S -Specific/ M - Measurable===
The user story should be specific enough to capture the requirements of the user. The user can be the customer who requires the software or the end user who will be using the software. Many times the user stories are vague or ambiguous leading to a lot of loss in time and energy spent in development.
User stories can be made specific by using the terms 'Given, When and Then' which describe the user story. The term “Given” specifies the background scenarios. It specifies all the preconditions.
“When” specifies the input to the system. “Then” specifies the desired result/s. 
Example: 
Given I am at www.google.com
When I click on the button Gmail
Then I should be redirected to Gmail.
Each scenario should be testable i.e its progress should be measurable. There should be known good output for every input. Every project needs concrete criteria for measuring progress toward its completion. The reason behind this is that if the scenarios are not measurable, it is not possible to know whether a team is making progress toward successful completion. Measuring progress is supposed to help a team stay on track, reach its target dates, and experience the exhilaration of achievement that spurs it on to continued effort required to reach the ultimate goal.

===A - Achievable / T - Timeboxed===
Goals should be set in such a way that it is achievable or at least a working model of it is achievable within a single iteration i.e. it is achievable within a time period. The reason for this is that Agile methodologies always aim for working models at the end of iteration, it doesn’t necessarily have to be a complete feature but a run-down version of it which is working partially and is able to provide a minimal set of functionality is also accepted.
If the feature is such that it may span over multiple iterations then it is a good idea to break it up into subset of stories such that each implemented subset provides a working model of the feature, however small it may be, so that constant progress is made to implement the feature and also a working code is provided at the end of each iteration.

While its a good idea to divide a feature into sub-features and have user stories for each iteration, the question arises of how to decide on the number of user stories for each iteration and the number of iterations that may require for the complete feature to be implemented. This is usually accomplished using velocity which is an estimate of the kind of progress made in the past based on the difficulty of the user stories and the kind of progress that can be made by taking into consideration the difficulty of the user stories that are yet to be implemented.

As features are broken down to sub-features and stories are written for the sub-feature, which is to be completed within the iteration, points should be assigned to each of the stories based on the difficulty level of the story and how fine grained approach for point-assignment does an assigner want. Say for example an assigner wants just a simple approach for point-assignment then he/she can assign from a range of 1-3 (where 1 being easy, 2 being medium and 3 being hard) and if a more fine grained approach is required then the range can be increased to 1-5 or 1-10. Whatever the approach is followed the important thing is to allocate points to each of the stories based on one’s estimate. At the end of each iteration, Velocity is calculated, which is nothing but the total number of points completed per iteration. As Velocity is not just the total of the stories but the total based on the difficulty level of the stories, it acts as an important guiding tool which can be leveraged by anyone to get to know details about the project as is shown below.

Uses of Velocity:

*Velocity can be used to plan future iterations
*It gives an estimate of how much time or iterations would be required to completely implement the feature
*It gives an idea of whether the team is on track as the velocity is expected to remain constant if all other variables are unchanged (other variables such as number of team members or replacement of an experienced team member with a new team member, etc.)
*It can provide an estimate if a change is requested by customers and based on the time required to implement the change and the importance level of the change the decision can be made whether to implement it or not.

Following this approach allows a task to be timeboxed, i.e. limited to a specific duration. It provides a kind of expectation which makes the team-members aware that if something is not working out its time to seek help, split the task, change teams or do anything that will help in the completion of the task.

At the initial phase, the task of assigning points to stories may seem a bit daunting and a bit like second guessing oneself but as the iterations pass on and based on the understanding of the feature and the experience one has in assigning points to user-stories, the estimation will always improve and at the end will be very close to the actual statistics. Also estimates can be changed if one feels an incorrect estimation was done but care should be taken that the variation is not too much.

===R- business Relevant===
A user story should be of business value, i.e it should generate additional income or protect revenue. The software defined by the user story can increase the value of the product by generating interest among new users and thereby generating potential new customers.A software can also protect revenue by streamlining processes to cut costs.
One way of determining the business relevance of a product is by asking the question “why” recursively. This is similar to a problem solving technique called “5 Whys” where questions asked recursively for root cause analysis. The methodology can be extended here to recursively ask why developing a software is of business relevance to that company. It is assumed that after asking multiple times the reason will have some business relevance (for eg “To increase in revenue for the company”) or there is no valid reason justifying the software project.

==Example==
Let us understand SMART User Stories by taking an example:

I want an application that shows me the best deals.

There all sorts of problems with the above user story. It doesn’t fit any of the criterion we have set using our SMART User Stories approach. Let’s go over with each of the problems and try to improve our user story step-by-step.

S-Specific / M-Measurable: 
The above example is anything but specific nor it seems measurable. Well it does say that there needs to be an application that shows the best deals but it doesn’t mention to display the best deals from which all places or websites. Also it doesn’t mention about what it wants the best deals on. Also as it doesn’t mention about the websites it is difficult it to measure the story.

A much better user story would have been: 
I want an application that shows me the best deals on a particular product, which is entered by me before beginning the search, from the websites that I preselect.

This says specifically on what product the user wants the search on and from which all websites. This is a very specific goal as there is no scope of assumption here. Of course the search results will be based on the specific words the user enters, but that is true for any website. The more specific you are in your search the more fine grained your search will be. Also because of the modified story, now it is easy to measure the story, as we can go through each website and compare prices and check whether the application did indeed return the best deals from various websites.

A-Achievable: 
Appropriate timelines and deadlines should be set for implementing and testing the application. Suppose the client wants the above application for the Thanksgiving sale and he comes and asks for it during midweek of November, then creating the above story at that time wouldn’t be useful or advisable as the time period is too short for the goal to achieve.

Assuming there is sufficient time for the application to be created and there are say 4 iterations possible. But the above story may not be practical for one iteration, one might need to break it down further to make it workable for 1 iteration as the target is to have a workable code at the end of each iteration. So the story for the particular iteration can be modified as:

Provide an interface for the user to provide the name of the product and the websites he/she wants to have a search in.

This would be achievable for the first iteration. For the second iteration more functionality may be added:

Look for the price of the product in all of the websites given by the user and fetch all the results.

This can be further modified in iteration 3 to give the best deal, based on price factor. This can be further modified to modify the result if any free goodies are being provided by any particular website. In this way the goal can be made achievable.

T-Timeboxed 
All of the above 4 iterations that we planned should have the deadlines appropriately. If we suppose till one particular date if the team-member responsible for developing one particular functionality is not able to reach the target goal, it might be a good idea for him/her to ask to someone else or for some senior member to help out or to swap teams itself so that someone who has knowledge can work on that and can complete it without affecting the deadlines and making sure that the product is still workable at the end of that particular iteration. This should be followed for all the iterations. This will also allow sufficient time for testing which is a very important part of the application development.

R-Relevant 
The story should be relevant so that the desired benefit can be obtained and maximized. Why would the client need it
*Probably because there are many websites which offer different deals and to get a single website which searches all the websites on behalf of the user or at least a subset of the websites would make it much easier for the user
*That will also lead to increase in the clicks the website gets
*Which will subsequently lead to increase in ads
*Which will lead to increase in revenue for the company

Now the above goals are relevant for the application that user wants but it may not be relevant for the Terms and Conditions page or the login page that application may have.

==Advantages/Disadvantages of SMART User stories==
===Advantages of SMART User stories===
Lets consider the advantages of SMART User stories by considering each letter of the mnemonic.
*Making a user story specific makes the objectives of the project clear and prevent confusion amongst teams
*Having a well defined input /output relation makes the project measurable/ testable for bugs and defects.
*Having a specific user story helps breaking the project down to achievable goals These goals can be accomplished in single or multiple iterations.
*Asking whether a project is business relevant helps in identifying the maximum potential of the project.
*A timeboxed project helps in monitoring the progress of the project. It is also possible to estimate the velocity of the project using timeboxing.
===Disadvantages/Limitations of SMART User Stories===

*Some people prefer other kind of mnemonics such as INVEST rather than SMART as they feel that the thing that SMART stands for is not the same for all people. S may stand for Specific for some, Significant for some, Stretching for others, similarly M may be Measurable or Meaningful, likewise each of the alphabet of SMART has different meaning for different people.
*It is important that points assignment to user stories is done by someone experienced enough to understand the features that customers require as well as the complexity and technical details required to implement it successfully otherwise the velocity will be far from what is expected.
==Conclusion==

==References==
<references/>
[http://www.youtube.com/watch?v=XzV0dytYQq0 SaaS 4.2: SMART User stories] 
[http://uxdesign.smashingmagazine.com/2011/09/13/the-s-m-a-r-t-user-experience-strategy/ SMART User experience strategy] 
[http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ INVEST in good stories and SMART Tasks] 
[http://www.chiefsimplicityofficer.com/2010/04/user-stories-its-smart-to-invest/ User stories: Its SMART to INVEST] 

==See Also==

[http://en.wikipedia.org/wiki/User_story Information on user stories] 
[http://gigaom.com/2008/05/05/how-to-create-smart-tasks/ Information on SMART tasks] 
[http://www.uncommon-knowledge.co.uk/goal_setting/smart_4.html Information on SMART goals] 
[http://en.wikipedia.org/wiki/5_Whys Link for 5 Whys]

CSC/ECE 517 Fall 2012/ch2b 1w70 nl

2012-11-20T00:59:24Z

Nloya: /* S -Specific/ M - Measurable */

SaaS - 4.2 - SMART User Stories

==Introduction==
User stories are the basis for defining the functionality of any given system. They are a short description of the system that capture what the system does and gives the expectation of how the system should behave.
When we say User Stories, we don’t define any particular criteria as to how a user story should be written. A user story can be “Customer should have a good UI experience” or “When a customer logs in he/she should be able to see all the technical details of the product he/she has selected, with the reviews, price displayed alongside and an option of ‘Add to Cart’ to go along with it.”
Both the user stories described above are correct but one leaves too much for one to assume and the other gives one specific information in terms of display and functionality. The problem with the first user story is it is not restricted to any particular guideline, its just a user story but has no scope and hence can be either very short or very long. The advantage with the second user story is that it has been written based on a given set of goals which can be acronymed as SMART and will be explained below.

==SMART User Stories==

SMART is a mnemonic for 
*S - Specific
*M - Measurable
*A - Achievable
*R - Relevant
*T- Timeboxed

===S -Specific/ M - Measurable===
The user story should be specific enough to capture the requirements of the user. The user can be the customer who requires the software or the end user who will be using the software. Many times the user stories are vague or ambiguous leading to a lot of loss in time and energy spent in development.
User stories can be made specific by using the terms 'Given, When and Then' which describe the user story. The term “Given” specifies the background scenarios. It specifies all the preconditions.
“When” specifies the input to the system. “Then” specifies the desired result/s. 
Example: 
Given I am at www.google.com
When I click on the button Gmail
Then I should be redirected to Gmail.
Each scenario should be testable i.e its progress should be measurable. There should be known good output for every input. Every project needs concrete criteria for measuring progress toward its completion. The reason behind this is that if the scenarios are not measurable, it is not possible to know whether a team is making progress toward successful completion. Measuring progress is supposed to help a team stay on track, reach its target dates, and experience the exhilaration of achievement that spurs it on to continued effort required to reach the ultimate goal.

===A - Achievable / T - Timeboxed===
Goals should be set in such a way that it is achievable or at least a working model of it is achievable within a single iteration i.e. it is achievable within a time period. The reason for this is that Agile methodologies always aim for working models at the end of iteration, it doesn’t necessarily have to be a complete feature but a run-down version of it which is working partially and is able to provide a minimal set of functionality is also accepted.
If the feature is such that it may span over multiple iterations then it is a good idea to break it up into subset of stories such that each implemented subset provides a working model of the feature, however small it may be so that constant progress is made to implement the feature and also a working code is provided at the end of each iteration.

While its a good idea to divide a feature into sub-features and have user stories for each iteration, the question arises of how to decide on the number of user stories for each iteration and the number of iterations that may require for the complete feature to be implemented. This is usually accomplished using velocity which is an estimate of the kind of progress made in the past based on the difficulty of the user stories and the kind of progress that can be made by taking into consideration the difficulty of the user stories that are yet to be implemented.

As features are broken down to sub-features and stories are written for the sub-feature, which is to be completed within the iteration, points should be assigned to each of the stories based on the difficulty level of the story and the how fine grained for point-assignment does an assignee want. Say for example an assignee wants just a simple approach for point-assignment then he/she can assign from a range of 1-3 (where 1 being easy, 2 being medium and 3 being hard) and if a more fine grained approach is required then the range can be increased to 1-5 or 1-10. Whatever the approach is followed the important thing is to allocate points to each of the stories based on one’s estimate. At the end of each iteration, Velocity is calculated, which is nothing but the total number of points completed per iteration. As Velocity is not just the total of the stories but the total based on the difficulty level of the stories, it acts as an important guiding tool which can be leveraged by anyone to get to know details about the project as is shown below.

Uses of Velocity:

*Velocity can be used to plan future iterations
*It gives an estimate of how much time or iterations would be required to completely implement the feature
*It gives an idea of whether the team is on track as the velocity is expected to remain constant if all other variables are unchanged (other variables such as number of team members or replacement of an experienced team member with a new team member, etc.)
*It can provide an estimate if a change is requested by customers and based on the time required to implement the change and the importance level of the change the decision can be made whether to implement it or not.

Following this approach allows a task to be timeboxed, i.e. limited to a specific duration. It provides a kind of expectation which makes the team-members aware that if something is not working out its time to seek help, split the task, change teams or do anything that will help in the completion of the task.

At the initial phase, the task of assigning points to stories may seem a bit daunting and a bit like second guessing oneself but as the iterations pass on and based on the understanding of the feature and the experience one has in assigning points to user-stories, the estimation will always improve and at the end will be very close to the actual statistics. Also estimates can be changed if one feels an incorrect estimation was done but care should be taken that the variation is not too much.

===R- business Relevant===
A user story should be of business value, i.e it should generate additional income or protect revenue. The software defined by the user story can increase the value of the product by generating interest among new users and thereby generating potential new customers.A software can also protect revenue by streamlining processes to cut costs.
One way of determining the business relevance of a product is by asking the question “why” recursively. This is similar to a problem solving technique called “5 Whys” where questions asked recursively for root cause analysis. The methodology can be extended here to recursively ask why developing a software is of business relevance to that company. It is assumed that after asking multiple times the reason will have some business relevance (for eg “To increase in revenue for the company”) or there is no valid reason justifying the software project.

==Example==
Let us understand SMART User Stories by taking an example:

I want an application that shows me the best deals.

There all sorts of problems with the above user story. It doesn’t fit any of the criterion we have set using our SMART User Stories approach. Let’s go over with each of the problems and try to improve our user story step-by-step.

S-Specific / M-Measurable: 
The above example is anything but specific nor it seems measurable. Well it does say that there needs to be an application that shows the best deals but it doesn’t mention to display the best deals from which all places or websites. Also it doesn’t mention about what it wants the best deals on. Also as it doesn’t mention about the websites it is difficult it to measure the story.

A much better user story would have been: 
I want an application that shows me the best deals on a particular product, which is entered by me before beginning the search, from the websites that I preselect.

This says specifically on what product the user wants the search on and from which all websites. This is a very specific goal as there is no scope of assumption here. Of course the search results will be based on the specific words the user enters, but that is true for any website. The more specific you are in your search the more fine grained your search will be. Also because of the modified story, now it is easy to measure the story, as we can go through each website and compare prices and check whether the application did indeed return the best deals from various websites.

A-Achievable: 
Appropriate timelines and deadlines should be set for implementing and testing the application. Suppose the client wants the above application for the Thanksgiving sale and he comes and asks for it during midweek of November, then creating the above story at that time wouldn’t be useful or advisable as the time period is too short for the goal to achieve.

Assuming there is sufficient time for the application to be created and there are say 4 iterations possible. But the above story may not be practical for one iteration, one might need to break it down further to make it workable for 1 iteration as the target is to have a workable code at the end of each iteration. So the story for the particular iteration can be modified as:

Provide an interface for the user to provide the name of the product and the websites he/she wants to have a search in.

This would be achievable for the first iteration. For the second iteration more functionality may be added:

Look for the price of the product in all of the websites given by the user and fetch all the results.

This can be further modified in iteration 3 to give the best deal, based on price factor. This can be further modified to modify the result if any free goodies are being provided by any particular website. In this way the goal can be made achievable.

T-Timeboxed 
All of the above 4 iterations that we planned should have the deadlines appropriately. If we suppose till one particular date if the team-member responsible for developing one particular functionality is not able to reach the target goal, it might be a good idea for him/her to ask to someone else or for some senior member to help out or to swap teams itself so that someone who has knowledge can work on that and can complete it without affecting the deadlines and making sure that the product is still workable at the end of that particular iteration. This should be followed for all the iterations. This will also allow sufficient time for testing which is a very important part of the application development.

R-Relevant 
The story should be relevant so that the desired benefit can be obtained and maximized. Why would the client need it
*Probably because there are many websites which offer different deals and to get a single website which searches all the websites on behalf of the user or at least a subset of the websites would make it much easier for the user
*That will also lead to increase in the clicks the website gets
*Which will subsequently lead to increase in ads
*Which will lead to increase in revenue for the company

Now the above goals are relevant for the application that user wants but it may not be relevant for the Terms and Conditions page or the login page that application may have.

==Advantages/Disadvantages of SMART User stories==
===Advantages of SMART User stories===
Lets consider the advantages of SMART User stories by considering each letter of the mnemonic.
*Making a user story specific makes the objectives of the project clear and prevent confusion amongst teams
*Having a well defined input /output relation makes the project measurable/ testable for bugs and defects.
*Having a specific user story helps breaking the project down to achievable goals These goals can be accomplished in single or multiple iterations.
*Asking whether a project is business relevant helps in identifying the maximum potential of the project.
*A timeboxed project helps in monitoring the progress of the project. It is also possible to estimate the velocity of the project using timeboxing.
===Disadvantages/Limitations of SMART User Stories===

*Some people prefer other kind of mnemonics such as INVEST rather than SMART as they feel that the thing that SMART stands for is not the same for all people. S may stand for Specific for some, Significant for some, Stretching for others, similarly M may be Measurable or Meaningful, likewise each of the alphabet of SMART has different meaning for different people.
*It is important that points assignment to user stories is done by someone experienced enough to understand the features that customers require as well as the complexity and technical details required to implement it successfully otherwise the velocity will be far from what is expected.
==Conclusion==

==References==
<references/>
[http://www.youtube.com/watch?v=XzV0dytYQq0 SaaS 4.2: SMART User stories] 
[http://uxdesign.smashingmagazine.com/2011/09/13/the-s-m-a-r-t-user-experience-strategy/ SMART User experience strategy] 
[http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ INVEST in good stories and SMART Tasks] 
[http://www.chiefsimplicityofficer.com/2010/04/user-stories-its-smart-to-invest/ User stories: Its SMART to INVEST] 

==See Also==

[http://en.wikipedia.org/wiki/User_story Information on user stories] 
[http://gigaom.com/2008/05/05/how-to-create-smart-tasks/ Information on SMART tasks] 
[http://www.uncommon-knowledge.co.uk/goal_setting/smart_4.html Information on SMART goals] 
[http://en.wikipedia.org/wiki/5_Whys Link for 5 Whys]

CSC/ECE 517 Fall 2012/ch1 1w22 an

2012-09-20T03:59:30Z

Nloya: /* Similar functionality in other languages */

=='''Introduction<ref>http://rubylearning.com/satishtalim/ruby_method_missing.html</ref>'''==
A method that belongs to a class is called by creating an object of the class and passing the method name to the object as a message. The object then looks up the [http://www.madebydna.com/all/code/2011/06/24/eigenclasses-demystified.html method lookup path] and tries to match the called method with the defined methods in the class. On success, the method is executed and the result is returned.

If the object does not find a match in its method lookup, in normal circumstances the [http://www.ruby-doc.org/core-1.9.3/NoMethodError.html NoMethodError Exception] is raised .

In cases where the user wants to handle the methods which are not defined but are still called, “method_missing” can be defined and the user can handle the methods as he/she sees fit.

=='''Format for Defining method_missing'''==

=> def method_missing(m,*args,&block)

(i) '''m->''' accepts the symbol/name of the undefined method (ii) '''*args->''' accepts the array of arguments passed in the method call (iii) '''&block->'''accepts a block passed to the method

=='''Ruby Method Lookup Flow'''==
When the object of a class receives a method name to be executed, the following steps are carried out for matching and executing the method:

*First, the object looks in its own [http://docs.oracle.com/javase/tutorial/java/javaOO/classvars.html instance methods].
*Second, it looks in the list of instance methods that all objects of that class share.
*Third, in each of the included [http://www.tutorialspoint.com/ruby/ruby_modules.html modules] of that class, in reverse order of inclusion.
*Fourth, it looks in that class’s superclass.
*Fifth, in the superclass’s included modules, all the way up until it reaches the class Object.
*Sixth, if it still can’t find a method, the very last place it looks is in the [http://linux.die.net/lkmpg/x40.html Kernel module], included in the class Object.
*Finally, it calls method_missing (if defined in the class), else throws up the NOMethodError exception.

This entire tracing that the object does is called the method lookup path.

=='''Examples'''==
===Calling Defined and Undefined Methods===

class A // creating a class 'A'
def say // defining a method 'say'
puts " say Hi " // body of method say
end
end

Creating the object of the class

a=A.new // object of the class
=> #<A:0x2a082e0> //object id

Calling the defined method

a.say // defined method
=> say Hi // returned result

Calling the undefined method

a.sayhi // undefined method sayhi
NoMethodError: undefined method `sayhi' for #<A:0x2a082e0> // the NoMethodError is raised

===method_missing Implementation<ref>http://www.thirdbit.net/articles/2007/08/01/10-things-you-should-know-about-method_missing/</ref>===

class A
def say
puts " say hi "
end
def method_missing(m,*args,&block) // defining method_missing
puts " This method does not exist" // body of method_missing
end
end

Calling a method that is not defined

a=A.new
a.sayhi // calling the undefined method sayhi with no arguments
=> This method does not exist // this result returned when method_missing is executed

When the object 'a' traces its method lookup path for a matching method 'sayhi', upon failure it resorts to method_missing and the body of method_missing is executed.

Sometimes when a class has many methods that do generally the same kinds of functionality, and the programmer is not sure in advance which methods the user will call since there are so many of them, and all of them are similar, writing code for all of the methods seems futile. In these situations method_missing can be defined to take care of these cases. The below 'Generic Handler' example implements this.

===Passing Parameters to an Undefined Method Call===

class A
def add(a,b)
a+b
end
def method_missing(name,*args,&block) // the method_missing is defined and the *args parameter accepts all the parameters passed during
the method call
puts “You have typed the method name wrong and these were the parameters passed ; #{args[0]}, #{args[1]}”
end
end

The passed parameters are stored in the array 'args' and can be accessed like a normal array

Calling the defined method

a.add(1,2) // calling the defined method add and passing the parameters (1,2)
=> 3 // result

Calling the undefined method

a.adds(4,2) // calling the undefined method adds and passing the parameter (4,2)
=> You have typed the method name wrong and these were the parameters passed; 4, 2

The user made a genuine mistake by typing 'adds', but this method is not defined. When the 'adds' method with parameters is called, the object 'a' tries to match the method in the method lookup path. Upon failure it invokes method_missing, the args are passed, stored in the array 'args' and the body of method_missing is executed.

===Converting Numbers from Roman Representation to Integer Representation<ref>http://courses.ncsu.edu/csc517/common/lectures/notes/wk2.pdf</ref>===
class Roman
DIGITS = {'I'=>1,'V'=>5,'X'=>10,'L'=>50,'C'=>100,'D'=>500,'M'=>1000,}
def roman_to_integer(roman_string)
last = nil
roman_string.to_s.upcase.split(//).reverse.inject(0) do
|memo, digit|
if digit_value = DIGITS[digit]
if last && last > digit_value
memo -= digit_value
else
memo += digit_value
end
last = digit_value
end
memo
end
end

def method_missing(method)
str=method.id2name
roman_to_integer(str)
end
end

Calling the undefined methods

r= Roman.new
r.vii
r.xxix
r.xxiv
r.xxvi

The Output

=> 7
=> 29
=> 24

===method_missing to Log Method Calls<ref>http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2007/wiki1b_2_22</ref>===
Another application that makes use of method_missing could be a simple logger used for debugging purposes. Many times, it may be required to log the trace of called methods and provide information such as: called method-name, arguments, return type. It can be tedious to repeat this part of code in every method. A simple solution to this problem can be obtained using method_missing as:

class SimpleCallLogger
def initialize(o)
@obj = o
end
def method_missing(methodname, *args)
puts "called: #{methodname}(#{args})"
a = @obj.send(methodname, *args)
puts "\t-> returned: #{a}"
return a
end
end

This program makes use of method_missing in a way that it wraps around called method to output the logging information on entry and on exit, it logs the return type. Further, method_missing intercepts the method call and forward it to internal object with ‘send’ method of ruby. Hence, this use of method_missing acts as wrapper.

===Generic Handler===
class NoBar
def method_missing(methodname, *args)
define_method(:bar) if "bar" == methodname.to_s
define_method(:nobar) if "nobar" == methodname.to_s
end
end

This is an example of using method_missing as a generic handler to handle when a calling method is not exist. You can use missing_method to dynamically create a method at a runtime.

=='''Advantages of method_missing'''==

*In addition to specifying the error messages for the undefined methods, method_missing provides a more dynamic behavior in the programming environment.
*If we are unfamiliar with the usage of the objects we created, then using method_missing is a good technique.
*Handles problems at runtime.
*Define's a generic method_missing and handle's any undefined method, a big advantage over Java. In Java, when you call an undefined method, the program will not compile.
*method_missing falls under the general technique of [http://en.wikipedia.org/wiki/Metaprogramming meta-programming]. Employ meta-programming in missing_function to write an another function to handle the call.

=='''Disadvantages of method_missing'''==
*Slower than conventional method lookup. Simple tests indicate that method dispatch with method_missing is at least two to three times as expensive in time as conventional dispatch.

*Since the methods being called never actually exist—they are just intercepted at the last step of the method lookup process—they cannot be documented or introspected as conventional methods can.

*method_missing restricts compatibility with future versions of an [http://en.wikipedia.org/wiki/Application_programming_interface API]. Introducing new methods in a future API version can break users' expectations.

=='''Key Points'''==

*In the following example, if within method_missing() we define an undefined method, we get a stack level too deep error message.

class A
@@i = 0
def method_missing(method_id)
puts "In Method Missing #{@@i}"
@@i += 1
self.fun
end
end

a = A.new
a.foo

Output

The result is a 'stack level too deep' error.

When the 'foo' method is called, after no method match the method_missing is run and this block has a method 'self.fun' that is undefined. Here when the program execution encounters 'self.fun' it once again calls method_missing. This goes on in an endless loop till the stack memory becomes full.

*Ruby knows method_missing( ) exists, because it's a private instance method of 'BasicObject' that every object inherits. The BasicObject#method_missing( ) responds by raising the NoMethodError. Overriding this method_missing( ) allows you to call methods that don't really exist.

*If method_missing is only looking for certain method names, don't forget to call the [http://en.wikibooks.org/wiki/Java_Programming/Keywords/super super] keyword if you haven't found what you're looking for, so that the other superclass' method_missing can handle it.

*[http://www.prateekdayal.net/2007/10/16/rubys-responds_to-for-checking-if-a-method-exists/ obj.respond_to?] function returns 'true' if the obj responds to the given method. So if you want to know whether your class will respond to a function you can use respond_to? to know the answer. But if method_missing() is used, the output may not be what you expect.

class A
def method_missing(method_id)
puts "In method_missing"
end
end

a = A.new
puts a.respond_to?(:foo)
a.foo

Output
false
In method_missing

=='''Similar functionality in other languages'''==
Method missing, one of the dynamic features of Ruby, is not a feature that is unique to Ruby. It exists in Smalltalk, Python, Groovy, some Javascripts and most CLOS (Common Lisp Object System)extensions. In this section we look at the few such similar implementations in other languages. The table below gives different ways the functionality related to method_missing is handled in other languages.<ref>http://olabini.com/blog/2010/04/patterns-of-method-missing/</ref>

'''Construct''' '''Language '''
AUTOLOAD Perl
AUTOSCALAR, AUTOMETH, AUTOLOAD... Perl6
__getattr__ Python
method_missing Ruby
doesNotUnderstand Smalltalk
__noSuchMethod__(1) CoffeeScript, JavaScript
unknown Tcl
no-applicable-method Common Lisp
doesNotRecognizeSelector Objective-C
TryInvokeMember(2) C#
match [name, args] { ... } E
the predicate fail Prolog
forward Io

(1) supported by Firefox

(2) only for dynamic objects

Table Reference<ref>http://stackoverflow.com/questions/2865865/are-there-equivalents-to-rubys-method-missing-in-other-languages</ref>

*'''_getattr_ implementation in Python'''<ref>http://docs.python.org/reference/datamodel.html?highlight=__getattr__#object.__getattr__</ref>

object.__getattr__(self,name)

This method is called when an attribute lookup has not found the attribute in the usual places i.e. it is not an instance attribute nor is it found in the class tree for self. name is the attribute name. This method should return the (computed) attribute value or raise an AttributeError exception.

class Roman(object):
def roman_to_int(self, roman):
# implementation here
end

def __getattr__(self, name):
return self.roman_to_int(name)
end

>>> r = Roman()

>>> r.iv

4

*'''doesNotUnderstand in Smalltalk language'''<ref>http://c2.com/cgi/wiki?DoesNotUnderstand</ref>

In SmalltalkLanguage When a receiver is asked to perform a method that is unknown to it, then a run-time complaint is issued which is #doesNotUnderstand.
When a Smalltalk object is sent a message for a method it has not defined, the runtime system turns the message-send into an object and sends #doesNotUnderstand: to the original receiver with this message-send object as argument. By default the #doesNotUnderstand: method raises an exception, but the receiver can override it and implement it in a way that he sees fit.

*'''Other languages'''
JavaScript also has a method which has an implementation similar to that of method_missing and that is "noSuchMethod". The limitation of this method is that it is only supported by Firefox/Spidermonkey.

Similarly, Perl has an AUTOLOAD method which works on subroutines & class/object methods.

=='''Patterns of method missing<ref>http://olabini.com/blog/2010/04/patterns-of-method-missing/</ref>'''==
Now that we have covered all the important areas about method missing including the advantages, the disadvantages and key points related to its functionality, it would be appropriate to know about the different ways method_missing is used and what are the consequences of its use.

* Providing Debug information on Failure
Well as method missing is called when there is no object to handle the method being called, we can use method_missing to include more information about the reasons for it being called, i.e. to say that we can provide users with more information about the error messages and hence make the life of the programmers easy and provide a faster way to solve the bugs.

* Encode parameters in method name
Instead of sending method as explicit parameters, another method is to use the name to encode parameters. Find below a Rails-style find expression:
Person.find_by_name_and_age("ABC",30)
Another way of writing the same:
Person.find_by(:name => "ABC", :age => 30)

The disadvantage of this is that creating such kind of API's make it difficult to debug and maintain the application.

* Builders
The idea of a builder is that you use Ruby’s blocks and method_missing to make it easy to create any kind of output structure. You create a builder object and then send it messages and it responds to the messages by building up a data structure based on those messages. For example, the following code

builder = Builder::XmlMarkup.new("", 2)
puts builder.person {
name("ABC")
phone("12345", "local"=>"yes")
address("Raleigh")
}

will print

<person>
<name>ABC</name>
<phone local="yes">12345</phone>
<address>Raleigh</address>
</person>

Here we have defined a method_missing method and it handles any undefined method and adds the name of the method to the XML markup that is being built. Code blocks are used to capture the nested nature of the XML. The result is a very natural way to programmatically generate XML markup. Also the cumbersome task of closing the tags and escaping rules are taken care of for us.

* Accessors
The inversion of the builder pattern is to use a parser that goes through the XML document and then allow access to the elements by using method_missing.

* Test Helpers
Different kind of test helpers can be created using method_missing. Many of the open source Ruby projects implementations of method missing are found in the tests.

=='''Conclusion'''==
method_missing is a very powerful feature of Ruby and as is the way with powerful things it can help you a great deal if used properly but it can make things a lot harder for you if implemented incorrectly. It is a kind of a feature which should be used sparingly, if not at all. And there are things that needs to be taken into consideration, as mentioned in the Key Points section above, if method_missing is to be implemented.

=='''References'''==
<references/>

=='''Further Suggested Reading'''==
*http://www.rubyinside.com/
*https://www.youtube.com/watch?v=SAEiCkixrdE&feature=relmfu
*http://blog.jayfields.com/2008/02/ruby-replace-methodmissing-with-dynamic.html
*http://liquiddevelopment.blogspot.com/2006/04/twisting-and-shaping-dsls-using-ruby.html
*http://blog.rubybestpractices.com/posts/gregory/031-issue-2-method-lookup.html
*http://phrogz.net/RubyLibs/RubyMethodLookupFlow.pdf(Diagram)

CSC/ECE 517 Fall 2012/ch1 1w22 an

2012-09-20T03:58:40Z

Nloya: /* Similar functionality in other languages */

=='''Introduction<ref>http://rubylearning.com/satishtalim/ruby_method_missing.html</ref>'''==
A method that belongs to a class is called by creating an object of the class and passing the method name to the object as a message. The object then looks up the [http://www.madebydna.com/all/code/2011/06/24/eigenclasses-demystified.html method lookup path] and tries to match the called method with the defined methods in the class. On success, the method is executed and the result is returned.

If the object does not find a match in its method lookup, in normal circumstances the [http://www.ruby-doc.org/core-1.9.3/NoMethodError.html NoMethodError Exception] is raised .

In cases where the user wants to handle the methods which are not defined but are still called, “method_missing” can be defined and the user can handle the methods as he/she sees fit.

=='''Format for Defining method_missing'''==

=> def method_missing(m,*args,&block)

(i) '''m->''' accepts the symbol/name of the undefined method (ii) '''*args->''' accepts the array of arguments passed in the method call (iii) '''&block->'''accepts a block passed to the method

=='''Ruby Method Lookup Flow'''==
When the object of a class receives a method name to be executed, the following steps are carried out for matching and executing the method:

*First, the object looks in its own [http://docs.oracle.com/javase/tutorial/java/javaOO/classvars.html instance methods].
*Second, it looks in the list of instance methods that all objects of that class share.
*Third, in each of the included [http://www.tutorialspoint.com/ruby/ruby_modules.html modules] of that class, in reverse order of inclusion.
*Fourth, it looks in that class’s superclass.
*Fifth, in the superclass’s included modules, all the way up until it reaches the class Object.
*Sixth, if it still can’t find a method, the very last place it looks is in the [http://linux.die.net/lkmpg/x40.html Kernel module], included in the class Object.
*Finally, it calls method_missing (if defined in the class), else throws up the NOMethodError exception.

This entire tracing that the object does is called the method lookup path.

=='''Examples'''==
===Calling Defined and Undefined Methods===

class A // creating a class 'A'
def say // defining a method 'say'
puts " say Hi " // body of method say
end
end

Creating the object of the class

a=A.new // object of the class
=> #<A:0x2a082e0> //object id

Calling the defined method

a.say // defined method
=> say Hi // returned result

Calling the undefined method

a.sayhi // undefined method sayhi
NoMethodError: undefined method `sayhi' for #<A:0x2a082e0> // the NoMethodError is raised

===method_missing Implementation<ref>http://www.thirdbit.net/articles/2007/08/01/10-things-you-should-know-about-method_missing/</ref>===

class A
def say
puts " say hi "
end
def method_missing(m,*args,&block) // defining method_missing
puts " This method does not exist" // body of method_missing
end
end

Calling a method that is not defined

a=A.new
a.sayhi // calling the undefined method sayhi with no arguments
=> This method does not exist // this result returned when method_missing is executed

When the object 'a' traces its method lookup path for a matching method 'sayhi', upon failure it resorts to method_missing and the body of method_missing is executed.

Sometimes when a class has many methods that do generally the same kinds of functionality, and the programmer is not sure in advance which methods the user will call since there are so many of them, and all of them are similar, writing code for all of the methods seems futile. In these situations method_missing can be defined to take care of these cases. The below 'Generic Handler' example implements this.

===Passing Parameters to an Undefined Method Call===

class A
def add(a,b)
a+b
end
def method_missing(name,*args,&block) // the method_missing is defined and the *args parameter accepts all the parameters passed during
the method call
puts “You have typed the method name wrong and these were the parameters passed ; #{args[0]}, #{args[1]}”
end
end

The passed parameters are stored in the array 'args' and can be accessed like a normal array

Calling the defined method

a.add(1,2) // calling the defined method add and passing the parameters (1,2)
=> 3 // result

Calling the undefined method

a.adds(4,2) // calling the undefined method adds and passing the parameter (4,2)
=> You have typed the method name wrong and these were the parameters passed; 4, 2

The user made a genuine mistake by typing 'adds', but this method is not defined. When the 'adds' method with parameters is called, the object 'a' tries to match the method in the method lookup path. Upon failure it invokes method_missing, the args are passed, stored in the array 'args' and the body of method_missing is executed.

===Converting Numbers from Roman Representation to Integer Representation<ref>http://courses.ncsu.edu/csc517/common/lectures/notes/wk2.pdf</ref>===
class Roman
DIGITS = {'I'=>1,'V'=>5,'X'=>10,'L'=>50,'C'=>100,'D'=>500,'M'=>1000,}
def roman_to_integer(roman_string)
last = nil
roman_string.to_s.upcase.split(//).reverse.inject(0) do
|memo, digit|
if digit_value = DIGITS[digit]
if last && last > digit_value
memo -= digit_value
else
memo += digit_value
end
last = digit_value
end
memo
end
end

def method_missing(method)
str=method.id2name
roman_to_integer(str)
end
end

Calling the undefined methods

r= Roman.new
r.vii
r.xxix
r.xxiv
r.xxvi

The Output

=> 7
=> 29
=> 24

===method_missing to Log Method Calls<ref>http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2007/wiki1b_2_22</ref>===
Another application that makes use of method_missing could be a simple logger used for debugging purposes. Many times, it may be required to log the trace of called methods and provide information such as: called method-name, arguments, return type. It can be tedious to repeat this part of code in every method. A simple solution to this problem can be obtained using method_missing as:

class SimpleCallLogger
def initialize(o)
@obj = o
end
def method_missing(methodname, *args)
puts "called: #{methodname}(#{args})"
a = @obj.send(methodname, *args)
puts "\t-> returned: #{a}"
return a
end
end

This program makes use of method_missing in a way that it wraps around called method to output the logging information on entry and on exit, it logs the return type. Further, method_missing intercepts the method call and forward it to internal object with ‘send’ method of ruby. Hence, this use of method_missing acts as wrapper.

===Generic Handler===
class NoBar
def method_missing(methodname, *args)
define_method(:bar) if "bar" == methodname.to_s
define_method(:nobar) if "nobar" == methodname.to_s
end
end

This is an example of using method_missing as a generic handler to handle when a calling method is not exist. You can use missing_method to dynamically create a method at a runtime.

=='''Advantages of method_missing'''==

*In addition to specifying the error messages for the undefined methods, method_missing provides a more dynamic behavior in the programming environment.
*If we are unfamiliar with the usage of the objects we created, then using method_missing is a good technique.
*Handles problems at runtime.
*Define's a generic method_missing and handle's any undefined method, a big advantage over Java. In Java, when you call an undefined method, the program will not compile.
*method_missing falls under the general technique of [http://en.wikipedia.org/wiki/Metaprogramming meta-programming]. Employ meta-programming in missing_function to write an another function to handle the call.

=='''Disadvantages of method_missing'''==
*Slower than conventional method lookup. Simple tests indicate that method dispatch with method_missing is at least two to three times as expensive in time as conventional dispatch.

*Since the methods being called never actually exist—they are just intercepted at the last step of the method lookup process—they cannot be documented or introspected as conventional methods can.

*method_missing restricts compatibility with future versions of an [http://en.wikipedia.org/wiki/Application_programming_interface API]. Introducing new methods in a future API version can break users' expectations.

=='''Key Points'''==

*In the following example, if within method_missing() we define an undefined method, we get a stack level too deep error message.

class A
@@i = 0
def method_missing(method_id)
puts "In Method Missing #{@@i}"
@@i += 1
self.fun
end
end

a = A.new
a.foo

Output

The result is a 'stack level too deep' error.

When the 'foo' method is called, after no method match the method_missing is run and this block has a method 'self.fun' that is undefined. Here when the program execution encounters 'self.fun' it once again calls method_missing. This goes on in an endless loop till the stack memory becomes full.

*Ruby knows method_missing( ) exists, because it's a private instance method of 'BasicObject' that every object inherits. The BasicObject#method_missing( ) responds by raising the NoMethodError. Overriding this method_missing( ) allows you to call methods that don't really exist.

*If method_missing is only looking for certain method names, don't forget to call the [http://en.wikibooks.org/wiki/Java_Programming/Keywords/super super] keyword if you haven't found what you're looking for, so that the other superclass' method_missing can handle it.

*[http://www.prateekdayal.net/2007/10/16/rubys-responds_to-for-checking-if-a-method-exists/ obj.respond_to?] function returns 'true' if the obj responds to the given method. So if you want to know whether your class will respond to a function you can use respond_to? to know the answer. But if method_missing() is used, the output may not be what you expect.

class A
def method_missing(method_id)
puts "In method_missing"
end
end

a = A.new
puts a.respond_to?(:foo)
a.foo

Output
false
In method_missing

=='''Similar functionality in other languages'''==
Method missing, one of the dynamic features of Ruby, is not a feature that is unique to Ruby. It exists in Smalltalk, Python, Groovy, some Javascripts and most CLOS (Common Lisp Object System)extensions. In this section we look at the few such similar implementations in other languages. The table below gives different ways the functionality related to method_missing is handled in other languages.<ref>http://olabini.com/blog/2010/04/patterns-of-method-missing/</ref>

'''Construct''' '''Language '''
AUTOLOAD Perl
AUTOSCALAR, AUTOMETH, AUTOLOAD... Perl6
__getattr__ Python
method_missing Ruby
doesNotUnderstand Smalltalk
__noSuchMethod__(1) CoffeeScript, JavaScript
unknown Tcl
no-applicable-method Common Lisp
doesNotRecognizeSelector Objective-C
TryInvokeMember(2) C#
match [name, args] { ... } E
the predicate fail Prolog
forward Io

(1) supported by Firefox

(2) only for dynamic objects

Table Reference<ref>http://stackoverflow.com/questions/2865865/are-there-equivalents-to-rubys-method-missing-in-other-languages</ref>

*'''_getattr_ implementation in Python'''<ref>http://docs.python.org/reference/datamodel.html?highlight=__getattr__#object.__getattr__</ref>

object.__getattr__(self,name)

This method is called when an attribute lookup has not found the attribute in the usual places i.e. it is not an instance attribute nor is it found in the class tree for self. name is the attribute name. This method should return the (computed) attribute value or raise an AttributeError exception.

class Roman(object):
def roman_to_int(self, roman):
# implementation here
end

def __getattr__(self, name):
return self.roman_to_int(name)
end

>>> r = Roman()
>>> r.iv
4

*'''doesNotUnderstand in Smalltalk language'''<ref>http://c2.com/cgi/wiki?DoesNotUnderstand</ref>

In SmalltalkLanguage When a receiver is asked to perform a method that is unknown to it, then a run-time complaint is issued which is #doesNotUnderstand.
When a Smalltalk object is sent a message for a method it has not defined, the runtime system turns the message-send into an object and sends #doesNotUnderstand: to the original receiver with this message-send object as argument. By default the #doesNotUnderstand: method raises an exception, but the receiver can override it and implement it in a way that he sees fit.

*'''Other languages'''
JavaScript also has a method which has an implementation similar to that of method_missing and that is "noSuchMethod". The limitation of this method is that it is only supported by Firefox/Spidermonkey.

Similarly, Perl has an AUTOLOAD method which works on subroutines & class/object methods.

=='''Patterns of method missing<ref>http://olabini.com/blog/2010/04/patterns-of-method-missing/</ref>'''==
Now that we have covered all the important areas about method missing including the advantages, the disadvantages and key points related to its functionality, it would be appropriate to know about the different ways method_missing is used and what are the consequences of its use.

* Providing Debug information on Failure
Well as method missing is called when there is no object to handle the method being called, we can use method_missing to include more information about the reasons for it being called, i.e. to say that we can provide users with more information about the error messages and hence make the life of the programmers easy and provide a faster way to solve the bugs.

* Encode parameters in method name
Instead of sending method as explicit parameters, another method is to use the name to encode parameters. Find below a Rails-style find expression:
Person.find_by_name_and_age("ABC",30)
Another way of writing the same:
Person.find_by(:name => "ABC", :age => 30)

The disadvantage of this is that creating such kind of API's make it difficult to debug and maintain the application.

* Builders
The idea of a builder is that you use Ruby’s blocks and method_missing to make it easy to create any kind of output structure. You create a builder object and then send it messages and it responds to the messages by building up a data structure based on those messages. For example, the following code

builder = Builder::XmlMarkup.new("", 2)
puts builder.person {
name("ABC")
phone("12345", "local"=>"yes")
address("Raleigh")
}

will print

<person>
<name>ABC</name>
<phone local="yes">12345</phone>
<address>Raleigh</address>
</person>

Here we have defined a method_missing method and it handles any undefined method and adds the name of the method to the XML markup that is being built. Code blocks are used to capture the nested nature of the XML. The result is a very natural way to programmatically generate XML markup. Also the cumbersome task of closing the tags and escaping rules are taken care of for us.

* Accessors
The inversion of the builder pattern is to use a parser that goes through the XML document and then allow access to the elements by using method_missing.

* Test Helpers
Different kind of test helpers can be created using method_missing. Many of the open source Ruby projects implementations of method missing are found in the tests.

=='''Conclusion'''==
method_missing is a very powerful feature of Ruby and as is the way with powerful things it can help you a great deal if used properly but it can make things a lot harder for you if implemented incorrectly. It is a kind of a feature which should be used sparingly, if not at all. And there are things that needs to be taken into consideration, as mentioned in the Key Points section above, if method_missing is to be implemented.

=='''References'''==
<references/>

=='''Further Suggested Reading'''==
*http://www.rubyinside.com/
*https://www.youtube.com/watch?v=SAEiCkixrdE&feature=relmfu
*http://blog.jayfields.com/2008/02/ruby-replace-methodmissing-with-dynamic.html
*http://liquiddevelopment.blogspot.com/2006/04/twisting-and-shaping-dsls-using-ruby.html
*http://blog.rubybestpractices.com/posts/gregory/031-issue-2-method-lookup.html
*http://phrogz.net/RubyLibs/RubyMethodLookupFlow.pdf(Diagram)

CSC/ECE 517 Fall 2012/ch1 1w22 an

2012-09-20T03:58:20Z

Nloya: /* Similar functionality in other languages */

=='''Introduction<ref>http://rubylearning.com/satishtalim/ruby_method_missing.html</ref>'''==
A method that belongs to a class is called by creating an object of the class and passing the method name to the object as a message. The object then looks up the [http://www.madebydna.com/all/code/2011/06/24/eigenclasses-demystified.html method lookup path] and tries to match the called method with the defined methods in the class. On success, the method is executed and the result is returned.

If the object does not find a match in its method lookup, in normal circumstances the [http://www.ruby-doc.org/core-1.9.3/NoMethodError.html NoMethodError Exception] is raised .

In cases where the user wants to handle the methods which are not defined but are still called, “method_missing” can be defined and the user can handle the methods as he/she sees fit.

=='''Format for Defining method_missing'''==

=> def method_missing(m,*args,&block)

(i) '''m->''' accepts the symbol/name of the undefined method (ii) '''*args->''' accepts the array of arguments passed in the method call (iii) '''&block->'''accepts a block passed to the method

=='''Ruby Method Lookup Flow'''==
When the object of a class receives a method name to be executed, the following steps are carried out for matching and executing the method:

*First, the object looks in its own [http://docs.oracle.com/javase/tutorial/java/javaOO/classvars.html instance methods].
*Second, it looks in the list of instance methods that all objects of that class share.
*Third, in each of the included [http://www.tutorialspoint.com/ruby/ruby_modules.html modules] of that class, in reverse order of inclusion.
*Fourth, it looks in that class’s superclass.
*Fifth, in the superclass’s included modules, all the way up until it reaches the class Object.
*Sixth, if it still can’t find a method, the very last place it looks is in the [http://linux.die.net/lkmpg/x40.html Kernel module], included in the class Object.
*Finally, it calls method_missing (if defined in the class), else throws up the NOMethodError exception.

This entire tracing that the object does is called the method lookup path.

=='''Examples'''==
===Calling Defined and Undefined Methods===

class A // creating a class 'A'
def say // defining a method 'say'
puts " say Hi " // body of method say
end
end

Creating the object of the class

a=A.new // object of the class
=> #<A:0x2a082e0> //object id

Calling the defined method

a.say // defined method
=> say Hi // returned result

Calling the undefined method

a.sayhi // undefined method sayhi
NoMethodError: undefined method `sayhi' for #<A:0x2a082e0> // the NoMethodError is raised

===method_missing Implementation<ref>http://www.thirdbit.net/articles/2007/08/01/10-things-you-should-know-about-method_missing/</ref>===

class A
def say
puts " say hi "
end
def method_missing(m,*args,&block) // defining method_missing
puts " This method does not exist" // body of method_missing
end
end

Calling a method that is not defined

a=A.new
a.sayhi // calling the undefined method sayhi with no arguments
=> This method does not exist // this result returned when method_missing is executed

When the object 'a' traces its method lookup path for a matching method 'sayhi', upon failure it resorts to method_missing and the body of method_missing is executed.

Sometimes when a class has many methods that do generally the same kinds of functionality, and the programmer is not sure in advance which methods the user will call since there are so many of them, and all of them are similar, writing code for all of the methods seems futile. In these situations method_missing can be defined to take care of these cases. The below 'Generic Handler' example implements this.

===Passing Parameters to an Undefined Method Call===

class A
def add(a,b)
a+b
end
def method_missing(name,*args,&block) // the method_missing is defined and the *args parameter accepts all the parameters passed during
the method call
puts “You have typed the method name wrong and these were the parameters passed ; #{args[0]}, #{args[1]}”
end
end

The passed parameters are stored in the array 'args' and can be accessed like a normal array

Calling the defined method

a.add(1,2) // calling the defined method add and passing the parameters (1,2)
=> 3 // result

Calling the undefined method

a.adds(4,2) // calling the undefined method adds and passing the parameter (4,2)
=> You have typed the method name wrong and these were the parameters passed; 4, 2

The user made a genuine mistake by typing 'adds', but this method is not defined. When the 'adds' method with parameters is called, the object 'a' tries to match the method in the method lookup path. Upon failure it invokes method_missing, the args are passed, stored in the array 'args' and the body of method_missing is executed.

===Converting Numbers from Roman Representation to Integer Representation<ref>http://courses.ncsu.edu/csc517/common/lectures/notes/wk2.pdf</ref>===
class Roman
DIGITS = {'I'=>1,'V'=>5,'X'=>10,'L'=>50,'C'=>100,'D'=>500,'M'=>1000,}
def roman_to_integer(roman_string)
last = nil
roman_string.to_s.upcase.split(//).reverse.inject(0) do
|memo, digit|
if digit_value = DIGITS[digit]
if last && last > digit_value
memo -= digit_value
else
memo += digit_value
end
last = digit_value
end
memo
end
end

def method_missing(method)
str=method.id2name
roman_to_integer(str)
end
end

Calling the undefined methods

r= Roman.new
r.vii
r.xxix
r.xxiv
r.xxvi

The Output

=> 7
=> 29
=> 24

===method_missing to Log Method Calls<ref>http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2007/wiki1b_2_22</ref>===
Another application that makes use of method_missing could be a simple logger used for debugging purposes. Many times, it may be required to log the trace of called methods and provide information such as: called method-name, arguments, return type. It can be tedious to repeat this part of code in every method. A simple solution to this problem can be obtained using method_missing as:

class SimpleCallLogger
def initialize(o)
@obj = o
end
def method_missing(methodname, *args)
puts "called: #{methodname}(#{args})"
a = @obj.send(methodname, *args)
puts "\t-> returned: #{a}"
return a
end
end

This program makes use of method_missing in a way that it wraps around called method to output the logging information on entry and on exit, it logs the return type. Further, method_missing intercepts the method call and forward it to internal object with ‘send’ method of ruby. Hence, this use of method_missing acts as wrapper.

===Generic Handler===
class NoBar
def method_missing(methodname, *args)
define_method(:bar) if "bar" == methodname.to_s
define_method(:nobar) if "nobar" == methodname.to_s
end
end

This is an example of using method_missing as a generic handler to handle when a calling method is not exist. You can use missing_method to dynamically create a method at a runtime.

=='''Advantages of method_missing'''==

*In addition to specifying the error messages for the undefined methods, method_missing provides a more dynamic behavior in the programming environment.
*If we are unfamiliar with the usage of the objects we created, then using method_missing is a good technique.
*Handles problems at runtime.
*Define's a generic method_missing and handle's any undefined method, a big advantage over Java. In Java, when you call an undefined method, the program will not compile.
*method_missing falls under the general technique of [http://en.wikipedia.org/wiki/Metaprogramming meta-programming]. Employ meta-programming in missing_function to write an another function to handle the call.

=='''Disadvantages of method_missing'''==
*Slower than conventional method lookup. Simple tests indicate that method dispatch with method_missing is at least two to three times as expensive in time as conventional dispatch.

*Since the methods being called never actually exist—they are just intercepted at the last step of the method lookup process—they cannot be documented or introspected as conventional methods can.

*method_missing restricts compatibility with future versions of an [http://en.wikipedia.org/wiki/Application_programming_interface API]. Introducing new methods in a future API version can break users' expectations.

=='''Key Points'''==

*In the following example, if within method_missing() we define an undefined method, we get a stack level too deep error message.

class A
@@i = 0
def method_missing(method_id)
puts "In Method Missing #{@@i}"
@@i += 1
self.fun
end
end

a = A.new
a.foo

Output

The result is a 'stack level too deep' error.

When the 'foo' method is called, after no method match the method_missing is run and this block has a method 'self.fun' that is undefined. Here when the program execution encounters 'self.fun' it once again calls method_missing. This goes on in an endless loop till the stack memory becomes full.

*Ruby knows method_missing( ) exists, because it's a private instance method of 'BasicObject' that every object inherits. The BasicObject#method_missing( ) responds by raising the NoMethodError. Overriding this method_missing( ) allows you to call methods that don't really exist.

*If method_missing is only looking for certain method names, don't forget to call the [http://en.wikibooks.org/wiki/Java_Programming/Keywords/super super] keyword if you haven't found what you're looking for, so that the other superclass' method_missing can handle it.

*[http://www.prateekdayal.net/2007/10/16/rubys-responds_to-for-checking-if-a-method-exists/ obj.respond_to?] function returns 'true' if the obj responds to the given method. So if you want to know whether your class will respond to a function you can use respond_to? to know the answer. But if method_missing() is used, the output may not be what you expect.

class A
def method_missing(method_id)
puts "In method_missing"
end
end

a = A.new
puts a.respond_to?(:foo)
a.foo

Output
false
In method_missing

=='''Similar functionality in other languages'''==
Method missing, one of the dynamic features of Ruby, is not a feature that is unique to Ruby. It exists in Smalltalk, Python, Groovy, some Javascripts and most CLOS (Common Lisp Object System)extensions. In this section we look at the few such similar implementations in other languages. The table below gives different ways the functionality related to method_missing is handled in other languages.<ref>http://olabini.com/blog/2010/04/patterns-of-method-missing/</ref>

'''Construct''' '''Language '''
AUTOLOAD Perl
AUTOSCALAR, AUTOMETH, AUTOLOAD... Perl6
__getattr__ Python
method_missing Ruby
doesNotUnderstand Smalltalk
__noSuchMethod__(1) CoffeeScript, JavaScript
unknown Tcl
no-applicable-method Common Lisp
doesNotRecognizeSelector Objective-C
TryInvokeMember(2) C#
match [name, args] { ... } E
the predicate fail Prolog
forward Io

(1) supported by Firefox
(2) only for dynamic objects
Table Reference<ref>http://stackoverflow.com/questions/2865865/are-there-equivalents-to-rubys-method-missing-in-other-languages</ref>

*'''_getattr_ implementation in Python'''<ref>http://docs.python.org/reference/datamodel.html?highlight=__getattr__#object.__getattr__</ref>

object.__getattr__(self,name)

This method is called when an attribute lookup has not found the attribute in the usual places i.e. it is not an instance attribute nor is it found in the class tree for self. name is the attribute name. This method should return the (computed) attribute value or raise an AttributeError exception.

class Roman(object):
def roman_to_int(self, roman):
# implementation here
end

def __getattr__(self, name):
return self.roman_to_int(name)
end

>>> r = Roman()
>>> r.iv
4

*'''doesNotUnderstand in Smalltalk language'''<ref>http://c2.com/cgi/wiki?DoesNotUnderstand</ref>

In SmalltalkLanguage When a receiver is asked to perform a method that is unknown to it, then a run-time complaint is issued which is #doesNotUnderstand.
When a Smalltalk object is sent a message for a method it has not defined, the runtime system turns the message-send into an object and sends #doesNotUnderstand: to the original receiver with this message-send object as argument. By default the #doesNotUnderstand: method raises an exception, but the receiver can override it and implement it in a way that he sees fit.

*'''Other languages'''
JavaScript also has a method which has an implementation similar to that of method_missing and that is "noSuchMethod". The limitation of this method is that it is only supported by Firefox/Spidermonkey.

Similarly, Perl has an AUTOLOAD method which works on subroutines & class/object methods.

=='''Patterns of method missing<ref>http://olabini.com/blog/2010/04/patterns-of-method-missing/</ref>'''==
Now that we have covered all the important areas about method missing including the advantages, the disadvantages and key points related to its functionality, it would be appropriate to know about the different ways method_missing is used and what are the consequences of its use.

* Providing Debug information on Failure
Well as method missing is called when there is no object to handle the method being called, we can use method_missing to include more information about the reasons for it being called, i.e. to say that we can provide users with more information about the error messages and hence make the life of the programmers easy and provide a faster way to solve the bugs.

* Encode parameters in method name
Instead of sending method as explicit parameters, another method is to use the name to encode parameters. Find below a Rails-style find expression:
Person.find_by_name_and_age("ABC",30)
Another way of writing the same:
Person.find_by(:name => "ABC", :age => 30)

The disadvantage of this is that creating such kind of API's make it difficult to debug and maintain the application.

* Builders
The idea of a builder is that you use Ruby’s blocks and method_missing to make it easy to create any kind of output structure. You create a builder object and then send it messages and it responds to the messages by building up a data structure based on those messages. For example, the following code

builder = Builder::XmlMarkup.new("", 2)
puts builder.person {
name("ABC")
phone("12345", "local"=>"yes")
address("Raleigh")
}

will print

<person>
<name>ABC</name>
<phone local="yes">12345</phone>
<address>Raleigh</address>
</person>

Here we have defined a method_missing method and it handles any undefined method and adds the name of the method to the XML markup that is being built. Code blocks are used to capture the nested nature of the XML. The result is a very natural way to programmatically generate XML markup. Also the cumbersome task of closing the tags and escaping rules are taken care of for us.

* Accessors
The inversion of the builder pattern is to use a parser that goes through the XML document and then allow access to the elements by using method_missing.

* Test Helpers
Different kind of test helpers can be created using method_missing. Many of the open source Ruby projects implementations of method missing are found in the tests.

=='''Conclusion'''==
method_missing is a very powerful feature of Ruby and as is the way with powerful things it can help you a great deal if used properly but it can make things a lot harder for you if implemented incorrectly. It is a kind of a feature which should be used sparingly, if not at all. And there are things that needs to be taken into consideration, as mentioned in the Key Points section above, if method_missing is to be implemented.

=='''References'''==
<references/>

=='''Further Suggested Reading'''==
*http://www.rubyinside.com/
*https://www.youtube.com/watch?v=SAEiCkixrdE&feature=relmfu
*http://blog.jayfields.com/2008/02/ruby-replace-methodmissing-with-dynamic.html
*http://liquiddevelopment.blogspot.com/2006/04/twisting-and-shaping-dsls-using-ruby.html
*http://blog.rubybestpractices.com/posts/gregory/031-issue-2-method-lookup.html
*http://phrogz.net/RubyLibs/RubyMethodLookupFlow.pdf(Diagram)

CSC/ECE 517 Fall 2012/ch1 1w22 an

2012-09-20T03:57:44Z

Nloya: /* Similar functionality in other languages */

=='''Introduction<ref>http://rubylearning.com/satishtalim/ruby_method_missing.html</ref>'''==
A method that belongs to a class is called by creating an object of the class and passing the method name to the object as a message. The object then looks up the [http://www.madebydna.com/all/code/2011/06/24/eigenclasses-demystified.html method lookup path] and tries to match the called method with the defined methods in the class. On success, the method is executed and the result is returned.

If the object does not find a match in its method lookup, in normal circumstances the [http://www.ruby-doc.org/core-1.9.3/NoMethodError.html NoMethodError Exception] is raised .

In cases where the user wants to handle the methods which are not defined but are still called, “method_missing” can be defined and the user can handle the methods as he/she sees fit.

=='''Format for Defining method_missing'''==

=> def method_missing(m,*args,&block)

(i) '''m->''' accepts the symbol/name of the undefined method (ii) '''*args->''' accepts the array of arguments passed in the method call (iii) '''&block->'''accepts a block passed to the method

=='''Ruby Method Lookup Flow'''==
When the object of a class receives a method name to be executed, the following steps are carried out for matching and executing the method:

*First, the object looks in its own [http://docs.oracle.com/javase/tutorial/java/javaOO/classvars.html instance methods].
*Second, it looks in the list of instance methods that all objects of that class share.
*Third, in each of the included [http://www.tutorialspoint.com/ruby/ruby_modules.html modules] of that class, in reverse order of inclusion.
*Fourth, it looks in that class’s superclass.
*Fifth, in the superclass’s included modules, all the way up until it reaches the class Object.
*Sixth, if it still can’t find a method, the very last place it looks is in the [http://linux.die.net/lkmpg/x40.html Kernel module], included in the class Object.
*Finally, it calls method_missing (if defined in the class), else throws up the NOMethodError exception.

This entire tracing that the object does is called the method lookup path.

=='''Examples'''==
===Calling Defined and Undefined Methods===

class A // creating a class 'A'
def say // defining a method 'say'
puts " say Hi " // body of method say
end
end

Creating the object of the class

a=A.new // object of the class
=> #<A:0x2a082e0> //object id

Calling the defined method

a.say // defined method
=> say Hi // returned result

Calling the undefined method

a.sayhi // undefined method sayhi
NoMethodError: undefined method `sayhi' for #<A:0x2a082e0> // the NoMethodError is raised

===method_missing Implementation<ref>http://www.thirdbit.net/articles/2007/08/01/10-things-you-should-know-about-method_missing/</ref>===

class A
def say
puts " say hi "
end
def method_missing(m,*args,&block) // defining method_missing
puts " This method does not exist" // body of method_missing
end
end

Calling a method that is not defined

a=A.new
a.sayhi // calling the undefined method sayhi with no arguments
=> This method does not exist // this result returned when method_missing is executed

When the object 'a' traces its method lookup path for a matching method 'sayhi', upon failure it resorts to method_missing and the body of method_missing is executed.

Sometimes when a class has many methods that do generally the same kinds of functionality, and the programmer is not sure in advance which methods the user will call since there are so many of them, and all of them are similar, writing code for all of the methods seems futile. In these situations method_missing can be defined to take care of these cases. The below 'Generic Handler' example implements this.

===Passing Parameters to an Undefined Method Call===

class A
def add(a,b)
a+b
end
def method_missing(name,*args,&block) // the method_missing is defined and the *args parameter accepts all the parameters passed during
the method call
puts “You have typed the method name wrong and these were the parameters passed ; #{args[0]}, #{args[1]}”
end
end

The passed parameters are stored in the array 'args' and can be accessed like a normal array

Calling the defined method

a.add(1,2) // calling the defined method add and passing the parameters (1,2)
=> 3 // result

Calling the undefined method

a.adds(4,2) // calling the undefined method adds and passing the parameter (4,2)
=> You have typed the method name wrong and these were the parameters passed; 4, 2

The user made a genuine mistake by typing 'adds', but this method is not defined. When the 'adds' method with parameters is called, the object 'a' tries to match the method in the method lookup path. Upon failure it invokes method_missing, the args are passed, stored in the array 'args' and the body of method_missing is executed.

===Converting Numbers from Roman Representation to Integer Representation<ref>http://courses.ncsu.edu/csc517/common/lectures/notes/wk2.pdf</ref>===
class Roman
DIGITS = {'I'=>1,'V'=>5,'X'=>10,'L'=>50,'C'=>100,'D'=>500,'M'=>1000,}
def roman_to_integer(roman_string)
last = nil
roman_string.to_s.upcase.split(//).reverse.inject(0) do
|memo, digit|
if digit_value = DIGITS[digit]
if last && last > digit_value
memo -= digit_value
else
memo += digit_value
end
last = digit_value
end
memo
end
end

def method_missing(method)
str=method.id2name
roman_to_integer(str)
end
end

Calling the undefined methods

r= Roman.new
r.vii
r.xxix
r.xxiv
r.xxvi

The Output

=> 7
=> 29
=> 24

===method_missing to Log Method Calls<ref>http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2007/wiki1b_2_22</ref>===
Another application that makes use of method_missing could be a simple logger used for debugging purposes. Many times, it may be required to log the trace of called methods and provide information such as: called method-name, arguments, return type. It can be tedious to repeat this part of code in every method. A simple solution to this problem can be obtained using method_missing as:

class SimpleCallLogger
def initialize(o)
@obj = o
end
def method_missing(methodname, *args)
puts "called: #{methodname}(#{args})"
a = @obj.send(methodname, *args)
puts "\t-> returned: #{a}"
return a
end
end

This program makes use of method_missing in a way that it wraps around called method to output the logging information on entry and on exit, it logs the return type. Further, method_missing intercepts the method call and forward it to internal object with ‘send’ method of ruby. Hence, this use of method_missing acts as wrapper.

===Generic Handler===
class NoBar
def method_missing(methodname, *args)
define_method(:bar) if "bar" == methodname.to_s
define_method(:nobar) if "nobar" == methodname.to_s
end
end

This is an example of using method_missing as a generic handler to handle when a calling method is not exist. You can use missing_method to dynamically create a method at a runtime.

=='''Advantages of method_missing'''==

*In addition to specifying the error messages for the undefined methods, method_missing provides a more dynamic behavior in the programming environment.
*If we are unfamiliar with the usage of the objects we created, then using method_missing is a good technique.
*Handles problems at runtime.
*Define's a generic method_missing and handle's any undefined method, a big advantage over Java. In Java, when you call an undefined method, the program will not compile.
*method_missing falls under the general technique of [http://en.wikipedia.org/wiki/Metaprogramming meta-programming]. Employ meta-programming in missing_function to write an another function to handle the call.

=='''Disadvantages of method_missing'''==
*Slower than conventional method lookup. Simple tests indicate that method dispatch with method_missing is at least two to three times as expensive in time as conventional dispatch.

*Since the methods being called never actually exist—they are just intercepted at the last step of the method lookup process—they cannot be documented or introspected as conventional methods can.

*method_missing restricts compatibility with future versions of an [http://en.wikipedia.org/wiki/Application_programming_interface API]. Introducing new methods in a future API version can break users' expectations.

=='''Key Points'''==

*In the following example, if within method_missing() we define an undefined method, we get a stack level too deep error message.

class A
@@i = 0
def method_missing(method_id)
puts "In Method Missing #{@@i}"
@@i += 1
self.fun
end
end

a = A.new
a.foo

Output

The result is a 'stack level too deep' error.

When the 'foo' method is called, after no method match the method_missing is run and this block has a method 'self.fun' that is undefined. Here when the program execution encounters 'self.fun' it once again calls method_missing. This goes on in an endless loop till the stack memory becomes full.

*Ruby knows method_missing( ) exists, because it's a private instance method of 'BasicObject' that every object inherits. The BasicObject#method_missing( ) responds by raising the NoMethodError. Overriding this method_missing( ) allows you to call methods that don't really exist.

*If method_missing is only looking for certain method names, don't forget to call the [http://en.wikibooks.org/wiki/Java_Programming/Keywords/super super] keyword if you haven't found what you're looking for, so that the other superclass' method_missing can handle it.

*[http://www.prateekdayal.net/2007/10/16/rubys-responds_to-for-checking-if-a-method-exists/ obj.respond_to?] function returns 'true' if the obj responds to the given method. So if you want to know whether your class will respond to a function you can use respond_to? to know the answer. But if method_missing() is used, the output may not be what you expect.

class A
def method_missing(method_id)
puts "In method_missing"
end
end

a = A.new
puts a.respond_to?(:foo)
a.foo

Output
false
In method_missing

=='''Similar functionality in other languages'''==
Method missing, one of the dynamic features of Ruby, is not a feature that is unique to Ruby. It exists in Smalltalk, Python, Groovy, some Javascripts and most CLOS (Common Lisp Object System)extensions. In this section we look at the few such similar implementations in other languages. The table below gives different ways the functionality related to method_missing is handled in other languages.<ref>http://olabini.com/blog/2010/04/patterns-of-method-missing/</ref>

'''Construct''' '''Language '''
AUTOLOAD Perl
AUTOSCALAR, AUTOMETH, AUTOLOAD... Perl6
__getattr__ Python
method_missing Ruby
doesNotUnderstand Smalltalk
__noSuchMethod__# CoffeeScript, JavaScript
unknown Tcl
no-applicable-method Common Lisp
doesNotRecognizeSelector Objective-C
TryInvokeMember## C#
match [name, args] { ... } E
the predicate fail Prolog
forward Io

# supported by Firefox
## only for dynamic objects
Table Reference<ref>http://stackoverflow.com/questions/2865865/are-there-equivalents-to-rubys-method-missing-in-other-languages</ref>

*'''_getattr_ implementation in Python'''<ref>http://docs.python.org/reference/datamodel.html?highlight=__getattr__#object.__getattr__</ref>

object.__getattr__(self,name)

This method is called when an attribute lookup has not found the attribute in the usual places i.e. it is not an instance attribute nor is it found in the class tree for self. name is the attribute name. This method should return the (computed) attribute value or raise an AttributeError exception.

class Roman(object):
def roman_to_int(self, roman):
# implementation here
end

def __getattr__(self, name):
return self.roman_to_int(name)
end

>>> r = Roman()
>>> r.iv
4

*'''doesNotUnderstand in Smalltalk language'''<ref>http://c2.com/cgi/wiki?DoesNotUnderstand</ref>

In SmalltalkLanguage When a receiver is asked to perform a method that is unknown to it, then a run-time complaint is issued which is #doesNotUnderstand.
When a Smalltalk object is sent a message for a method it has not defined, the runtime system turns the message-send into an object and sends #doesNotUnderstand: to the original receiver with this message-send object as argument. By default the #doesNotUnderstand: method raises an exception, but the receiver can override it and implement it in a way that he sees fit.

*'''Other languages'''
JavaScript also has a method which has an implementation similar to that of method_missing and that is "noSuchMethod". The limitation of this method is that it is only supported by Firefox/Spidermonkey.

Similarly, Perl has an AUTOLOAD method which works on subroutines & class/object methods.

=='''Patterns of method missing<ref>http://olabini.com/blog/2010/04/patterns-of-method-missing/</ref>'''==
Now that we have covered all the important areas about method missing including the advantages, the disadvantages and key points related to its functionality, it would be appropriate to know about the different ways method_missing is used and what are the consequences of its use.

* Providing Debug information on Failure
Well as method missing is called when there is no object to handle the method being called, we can use method_missing to include more information about the reasons for it being called, i.e. to say that we can provide users with more information about the error messages and hence make the life of the programmers easy and provide a faster way to solve the bugs.

* Encode parameters in method name
Instead of sending method as explicit parameters, another method is to use the name to encode parameters. Find below a Rails-style find expression:
Person.find_by_name_and_age("ABC",30)
Another way of writing the same:
Person.find_by(:name => "ABC", :age => 30)

The disadvantage of this is that creating such kind of API's make it difficult to debug and maintain the application.

* Builders
The idea of a builder is that you use Ruby’s blocks and method_missing to make it easy to create any kind of output structure. You create a builder object and then send it messages and it responds to the messages by building up a data structure based on those messages. For example, the following code

builder = Builder::XmlMarkup.new("", 2)
puts builder.person {
name("ABC")
phone("12345", "local"=>"yes")
address("Raleigh")
}

will print

<person>
<name>ABC</name>
<phone local="yes">12345</phone>
<address>Raleigh</address>
</person>

Here we have defined a method_missing method and it handles any undefined method and adds the name of the method to the XML markup that is being built. Code blocks are used to capture the nested nature of the XML. The result is a very natural way to programmatically generate XML markup. Also the cumbersome task of closing the tags and escaping rules are taken care of for us.

* Accessors
The inversion of the builder pattern is to use a parser that goes through the XML document and then allow access to the elements by using method_missing.

* Test Helpers
Different kind of test helpers can be created using method_missing. Many of the open source Ruby projects implementations of method missing are found in the tests.

=='''Conclusion'''==
method_missing is a very powerful feature of Ruby and as is the way with powerful things it can help you a great deal if used properly but it can make things a lot harder for you if implemented incorrectly. It is a kind of a feature which should be used sparingly, if not at all. And there are things that needs to be taken into consideration, as mentioned in the Key Points section above, if method_missing is to be implemented.

=='''References'''==
<references/>

=='''Further Suggested Reading'''==
*http://www.rubyinside.com/
*https://www.youtube.com/watch?v=SAEiCkixrdE&feature=relmfu
*http://blog.jayfields.com/2008/02/ruby-replace-methodmissing-with-dynamic.html
*http://liquiddevelopment.blogspot.com/2006/04/twisting-and-shaping-dsls-using-ruby.html
*http://blog.rubybestpractices.com/posts/gregory/031-issue-2-method-lookup.html
*http://phrogz.net/RubyLibs/RubyMethodLookupFlow.pdf(Diagram)

CSC/ECE 517 Fall 2012/ch1 1w22 an

2012-09-20T03:57:13Z

Nloya: /* Similar functionality in other languages */

=='''Introduction<ref>http://rubylearning.com/satishtalim/ruby_method_missing.html</ref>'''==
A method that belongs to a class is called by creating an object of the class and passing the method name to the object as a message. The object then looks up the [http://www.madebydna.com/all/code/2011/06/24/eigenclasses-demystified.html method lookup path] and tries to match the called method with the defined methods in the class. On success, the method is executed and the result is returned.

If the object does not find a match in its method lookup, in normal circumstances the [http://www.ruby-doc.org/core-1.9.3/NoMethodError.html NoMethodError Exception] is raised .

In cases where the user wants to handle the methods which are not defined but are still called, “method_missing” can be defined and the user can handle the methods as he/she sees fit.

=='''Format for Defining method_missing'''==

=> def method_missing(m,*args,&block)

(i) '''m->''' accepts the symbol/name of the undefined method (ii) '''*args->''' accepts the array of arguments passed in the method call (iii) '''&block->'''accepts a block passed to the method

=='''Ruby Method Lookup Flow'''==
When the object of a class receives a method name to be executed, the following steps are carried out for matching and executing the method:

*First, the object looks in its own [http://docs.oracle.com/javase/tutorial/java/javaOO/classvars.html instance methods].
*Second, it looks in the list of instance methods that all objects of that class share.
*Third, in each of the included [http://www.tutorialspoint.com/ruby/ruby_modules.html modules] of that class, in reverse order of inclusion.
*Fourth, it looks in that class’s superclass.
*Fifth, in the superclass’s included modules, all the way up until it reaches the class Object.
*Sixth, if it still can’t find a method, the very last place it looks is in the [http://linux.die.net/lkmpg/x40.html Kernel module], included in the class Object.
*Finally, it calls method_missing (if defined in the class), else throws up the NOMethodError exception.

This entire tracing that the object does is called the method lookup path.

=='''Examples'''==
===Calling Defined and Undefined Methods===

class A // creating a class 'A'
def say // defining a method 'say'
puts " say Hi " // body of method say
end
end

Creating the object of the class

a=A.new // object of the class
=> #<A:0x2a082e0> //object id

Calling the defined method

a.say // defined method
=> say Hi // returned result

Calling the undefined method

a.sayhi // undefined method sayhi
NoMethodError: undefined method `sayhi' for #<A:0x2a082e0> // the NoMethodError is raised

===method_missing Implementation<ref>http://www.thirdbit.net/articles/2007/08/01/10-things-you-should-know-about-method_missing/</ref>===

class A
def say
puts " say hi "
end
def method_missing(m,*args,&block) // defining method_missing
puts " This method does not exist" // body of method_missing
end
end

Calling a method that is not defined

a=A.new
a.sayhi // calling the undefined method sayhi with no arguments
=> This method does not exist // this result returned when method_missing is executed

When the object 'a' traces its method lookup path for a matching method 'sayhi', upon failure it resorts to method_missing and the body of method_missing is executed.

Sometimes when a class has many methods that do generally the same kinds of functionality, and the programmer is not sure in advance which methods the user will call since there are so many of them, and all of them are similar, writing code for all of the methods seems futile. In these situations method_missing can be defined to take care of these cases. The below 'Generic Handler' example implements this.

===Passing Parameters to an Undefined Method Call===

class A
def add(a,b)
a+b
end
def method_missing(name,*args,&block) // the method_missing is defined and the *args parameter accepts all the parameters passed during
the method call
puts “You have typed the method name wrong and these were the parameters passed ; #{args[0]}, #{args[1]}”
end
end

The passed parameters are stored in the array 'args' and can be accessed like a normal array

Calling the defined method

a.add(1,2) // calling the defined method add and passing the parameters (1,2)
=> 3 // result

Calling the undefined method

a.adds(4,2) // calling the undefined method adds and passing the parameter (4,2)
=> You have typed the method name wrong and these were the parameters passed; 4, 2

The user made a genuine mistake by typing 'adds', but this method is not defined. When the 'adds' method with parameters is called, the object 'a' tries to match the method in the method lookup path. Upon failure it invokes method_missing, the args are passed, stored in the array 'args' and the body of method_missing is executed.

===Converting Numbers from Roman Representation to Integer Representation<ref>http://courses.ncsu.edu/csc517/common/lectures/notes/wk2.pdf</ref>===
class Roman
DIGITS = {'I'=>1,'V'=>5,'X'=>10,'L'=>50,'C'=>100,'D'=>500,'M'=>1000,}
def roman_to_integer(roman_string)
last = nil
roman_string.to_s.upcase.split(//).reverse.inject(0) do
|memo, digit|
if digit_value = DIGITS[digit]
if last && last > digit_value
memo -= digit_value
else
memo += digit_value
end
last = digit_value
end
memo
end
end

def method_missing(method)
str=method.id2name
roman_to_integer(str)
end
end

Calling the undefined methods

r= Roman.new
r.vii
r.xxix
r.xxiv
r.xxvi

The Output

=> 7
=> 29
=> 24

===method_missing to Log Method Calls<ref>http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2007/wiki1b_2_22</ref>===
Another application that makes use of method_missing could be a simple logger used for debugging purposes. Many times, it may be required to log the trace of called methods and provide information such as: called method-name, arguments, return type. It can be tedious to repeat this part of code in every method. A simple solution to this problem can be obtained using method_missing as:

class SimpleCallLogger
def initialize(o)
@obj = o
end
def method_missing(methodname, *args)
puts "called: #{methodname}(#{args})"
a = @obj.send(methodname, *args)
puts "\t-> returned: #{a}"
return a
end
end

This program makes use of method_missing in a way that it wraps around called method to output the logging information on entry and on exit, it logs the return type. Further, method_missing intercepts the method call and forward it to internal object with ‘send’ method of ruby. Hence, this use of method_missing acts as wrapper.

===Generic Handler===
class NoBar
def method_missing(methodname, *args)
define_method(:bar) if "bar" == methodname.to_s
define_method(:nobar) if "nobar" == methodname.to_s
end
end

This is an example of using method_missing as a generic handler to handle when a calling method is not exist. You can use missing_method to dynamically create a method at a runtime.

=='''Advantages of method_missing'''==

*In addition to specifying the error messages for the undefined methods, method_missing provides a more dynamic behavior in the programming environment.
*If we are unfamiliar with the usage of the objects we created, then using method_missing is a good technique.
*Handles problems at runtime.
*Define's a generic method_missing and handle's any undefined method, a big advantage over Java. In Java, when you call an undefined method, the program will not compile.
*method_missing falls under the general technique of [http://en.wikipedia.org/wiki/Metaprogramming meta-programming]. Employ meta-programming in missing_function to write an another function to handle the call.

=='''Disadvantages of method_missing'''==
*Slower than conventional method lookup. Simple tests indicate that method dispatch with method_missing is at least two to three times as expensive in time as conventional dispatch.

*Since the methods being called never actually exist—they are just intercepted at the last step of the method lookup process—they cannot be documented or introspected as conventional methods can.

*method_missing restricts compatibility with future versions of an [http://en.wikipedia.org/wiki/Application_programming_interface API]. Introducing new methods in a future API version can break users' expectations.

=='''Key Points'''==

*In the following example, if within method_missing() we define an undefined method, we get a stack level too deep error message.

class A
@@i = 0
def method_missing(method_id)
puts "In Method Missing #{@@i}"
@@i += 1
self.fun
end
end

a = A.new
a.foo

Output

The result is a 'stack level too deep' error.

When the 'foo' method is called, after no method match the method_missing is run and this block has a method 'self.fun' that is undefined. Here when the program execution encounters 'self.fun' it once again calls method_missing. This goes on in an endless loop till the stack memory becomes full.

*Ruby knows method_missing( ) exists, because it's a private instance method of 'BasicObject' that every object inherits. The BasicObject#method_missing( ) responds by raising the NoMethodError. Overriding this method_missing( ) allows you to call methods that don't really exist.

*If method_missing is only looking for certain method names, don't forget to call the [http://en.wikibooks.org/wiki/Java_Programming/Keywords/super super] keyword if you haven't found what you're looking for, so that the other superclass' method_missing can handle it.

*[http://www.prateekdayal.net/2007/10/16/rubys-responds_to-for-checking-if-a-method-exists/ obj.respond_to?] function returns 'true' if the obj responds to the given method. So if you want to know whether your class will respond to a function you can use respond_to? to know the answer. But if method_missing() is used, the output may not be what you expect.

class A
def method_missing(method_id)
puts "In method_missing"
end
end

a = A.new
puts a.respond_to?(:foo)
a.foo

Output
false
In method_missing

=='''Similar functionality in other languages'''==
Method missing, one of the dynamic features of Ruby, is not a feature that is unique to Ruby. It exists in Smalltalk, Python, Groovy, some Javascripts and most CLOS (Common Lisp Object System)extensions. In this section we look at the few such similar implementations in other languages. The table below gives different ways the functionality related to method_missing is handled in other languages.<ref>http://olabini.com/blog/2010/04/patterns-of-method-missing/</ref>

'''Construct''' '''Language '''
AUTOLOAD Perl
AUTOSCALAR, AUTOMETH, AUTOLOAD... Perl6
__getattr__ Python
method_missing Ruby
doesNotUnderstand Smalltalk
__noSuchMethod__* CoffeeScript, JavaScript
unknown Tcl
no-applicable-method Common Lisp
doesNotRecognizeSelector Objective-C
TryInvokeMember** C#
match [name, args] { ... } E
the predicate fail Prolog
forward Io

* supported by Firefox
** only for dynamic objects
Table Reference<ref>http://stackoverflow.com/questions/2865865/are-there-equivalents-to-rubys-method-missing-in-other-languages</ref>

*'''_getattr_ implementation in Python'''<ref>http://docs.python.org/reference/datamodel.html?highlight=__getattr__#object.__getattr__</ref>

object.__getattr__(self,name)

This method is called when an attribute lookup has not found the attribute in the usual places i.e. it is not an instance attribute nor is it found in the class tree for self. name is the attribute name. This method should return the (computed) attribute value or raise an AttributeError exception.

class Roman(object):
def roman_to_int(self, roman):
# implementation here
end

def __getattr__(self, name):
return self.roman_to_int(name)
end

>>> r = Roman()
>>> r.iv
4

*'''doesNotUnderstand in Smalltalk language'''<ref>http://c2.com/cgi/wiki?DoesNotUnderstand</ref>

In SmalltalkLanguage When a receiver is asked to perform a method that is unknown to it, then a run-time complaint is issued which is #doesNotUnderstand.
When a Smalltalk object is sent a message for a method it has not defined, the runtime system turns the message-send into an object and sends #doesNotUnderstand: to the original receiver with this message-send object as argument. By default the #doesNotUnderstand: method raises an exception, but the receiver can override it and implement it in a way that he sees fit.

*'''Other languages'''
JavaScript also has a method which has an implementation similar to that of method_missing and that is "noSuchMethod". The limitation of this method is that it is only supported by Firefox/Spidermonkey.

Similarly, Perl has an AUTOLOAD method which works on subroutines & class/object methods.

=='''Patterns of method missing<ref>http://olabini.com/blog/2010/04/patterns-of-method-missing/</ref>'''==
Now that we have covered all the important areas about method missing including the advantages, the disadvantages and key points related to its functionality, it would be appropriate to know about the different ways method_missing is used and what are the consequences of its use.

* Providing Debug information on Failure
Well as method missing is called when there is no object to handle the method being called, we can use method_missing to include more information about the reasons for it being called, i.e. to say that we can provide users with more information about the error messages and hence make the life of the programmers easy and provide a faster way to solve the bugs.

* Encode parameters in method name
Instead of sending method as explicit parameters, another method is to use the name to encode parameters. Find below a Rails-style find expression:
Person.find_by_name_and_age("ABC",30)
Another way of writing the same:
Person.find_by(:name => "ABC", :age => 30)

The disadvantage of this is that creating such kind of API's make it difficult to debug and maintain the application.

* Builders
The idea of a builder is that you use Ruby’s blocks and method_missing to make it easy to create any kind of output structure. You create a builder object and then send it messages and it responds to the messages by building up a data structure based on those messages. For example, the following code

builder = Builder::XmlMarkup.new("", 2)
puts builder.person {
name("ABC")
phone("12345", "local"=>"yes")
address("Raleigh")
}

will print

<person>
<name>ABC</name>
<phone local="yes">12345</phone>
<address>Raleigh</address>
</person>

Here we have defined a method_missing method and it handles any undefined method and adds the name of the method to the XML markup that is being built. Code blocks are used to capture the nested nature of the XML. The result is a very natural way to programmatically generate XML markup. Also the cumbersome task of closing the tags and escaping rules are taken care of for us.

* Accessors
The inversion of the builder pattern is to use a parser that goes through the XML document and then allow access to the elements by using method_missing.

* Test Helpers
Different kind of test helpers can be created using method_missing. Many of the open source Ruby projects implementations of method missing are found in the tests.

=='''Conclusion'''==
method_missing is a very powerful feature of Ruby and as is the way with powerful things it can help you a great deal if used properly but it can make things a lot harder for you if implemented incorrectly. It is a kind of a feature which should be used sparingly, if not at all. And there are things that needs to be taken into consideration, as mentioned in the Key Points section above, if method_missing is to be implemented.

=='''References'''==
<references/>

=='''Further Suggested Reading'''==
*http://www.rubyinside.com/
*https://www.youtube.com/watch?v=SAEiCkixrdE&feature=relmfu
*http://blog.jayfields.com/2008/02/ruby-replace-methodmissing-with-dynamic.html
*http://liquiddevelopment.blogspot.com/2006/04/twisting-and-shaping-dsls-using-ruby.html
*http://blog.rubybestpractices.com/posts/gregory/031-issue-2-method-lookup.html
*http://phrogz.net/RubyLibs/RubyMethodLookupFlow.pdf(Diagram)

CSC/ECE 517 Fall 2012/ch1 1w22 an

2012-09-20T03:55:30Z

Nloya: /* Key Points */

=='''Introduction<ref>http://rubylearning.com/satishtalim/ruby_method_missing.html</ref>'''==
A method that belongs to a class is called by creating an object of the class and passing the method name to the object as a message. The object then looks up the [http://www.madebydna.com/all/code/2011/06/24/eigenclasses-demystified.html method lookup path] and tries to match the called method with the defined methods in the class. On success, the method is executed and the result is returned.

If the object does not find a match in its method lookup, in normal circumstances the [http://www.ruby-doc.org/core-1.9.3/NoMethodError.html NoMethodError Exception] is raised .

In cases where the user wants to handle the methods which are not defined but are still called, “method_missing” can be defined and the user can handle the methods as he/she sees fit.

=='''Format for Defining method_missing'''==

=> def method_missing(m,*args,&block)

(i) '''m->''' accepts the symbol/name of the undefined method (ii) '''*args->''' accepts the array of arguments passed in the method call (iii) '''&block->'''accepts a block passed to the method

=='''Ruby Method Lookup Flow'''==
When the object of a class receives a method name to be executed, the following steps are carried out for matching and executing the method:

*First, the object looks in its own [http://docs.oracle.com/javase/tutorial/java/javaOO/classvars.html instance methods].
*Second, it looks in the list of instance methods that all objects of that class share.
*Third, in each of the included [http://www.tutorialspoint.com/ruby/ruby_modules.html modules] of that class, in reverse order of inclusion.
*Fourth, it looks in that class’s superclass.
*Fifth, in the superclass’s included modules, all the way up until it reaches the class Object.
*Sixth, if it still can’t find a method, the very last place it looks is in the [http://linux.die.net/lkmpg/x40.html Kernel module], included in the class Object.
*Finally, it calls method_missing (if defined in the class), else throws up the NOMethodError exception.

This entire tracing that the object does is called the method lookup path.

=='''Examples'''==
===Calling Defined and Undefined Methods===

class A // creating a class 'A'
def say // defining a method 'say'
puts " say Hi " // body of method say
end
end

Creating the object of the class

a=A.new // object of the class
=> #<A:0x2a082e0> //object id

Calling the defined method

a.say // defined method
=> say Hi // returned result

Calling the undefined method

a.sayhi // undefined method sayhi
NoMethodError: undefined method `sayhi' for #<A:0x2a082e0> // the NoMethodError is raised

===method_missing Implementation<ref>http://www.thirdbit.net/articles/2007/08/01/10-things-you-should-know-about-method_missing/</ref>===

class A
def say
puts " say hi "
end
def method_missing(m,*args,&block) // defining method_missing
puts " This method does not exist" // body of method_missing
end
end

Calling a method that is not defined

a=A.new
a.sayhi // calling the undefined method sayhi with no arguments
=> This method does not exist // this result returned when method_missing is executed

When the object 'a' traces its method lookup path for a matching method 'sayhi', upon failure it resorts to method_missing and the body of method_missing is executed.

Sometimes when a class has many methods that do generally the same kinds of functionality, and the programmer is not sure in advance which methods the user will call since there are so many of them, and all of them are similar, writing code for all of the methods seems futile. In these situations method_missing can be defined to take care of these cases. The below 'Generic Handler' example implements this.

===Passing Parameters to an Undefined Method Call===

class A
def add(a,b)
a+b
end
def method_missing(name,*args,&block) // the method_missing is defined and the *args parameter accepts all the parameters passed during
the method call
puts “You have typed the method name wrong and these were the parameters passed ; #{args[0]}, #{args[1]}”
end
end

The passed parameters are stored in the array 'args' and can be accessed like a normal array

Calling the defined method

a.add(1,2) // calling the defined method add and passing the parameters (1,2)
=> 3 // result

Calling the undefined method

a.adds(4,2) // calling the undefined method adds and passing the parameter (4,2)
=> You have typed the method name wrong and these were the parameters passed; 4, 2

The user made a genuine mistake by typing 'adds', but this method is not defined. When the 'adds' method with parameters is called, the object 'a' tries to match the method in the method lookup path. Upon failure it invokes method_missing, the args are passed, stored in the array 'args' and the body of method_missing is executed.

===Converting Numbers from Roman Representation to Integer Representation<ref>http://courses.ncsu.edu/csc517/common/lectures/notes/wk2.pdf</ref>===
class Roman
DIGITS = {'I'=>1,'V'=>5,'X'=>10,'L'=>50,'C'=>100,'D'=>500,'M'=>1000,}
def roman_to_integer(roman_string)
last = nil
roman_string.to_s.upcase.split(//).reverse.inject(0) do
|memo, digit|
if digit_value = DIGITS[digit]
if last && last > digit_value
memo -= digit_value
else
memo += digit_value
end
last = digit_value
end
memo
end
end

def method_missing(method)
str=method.id2name
roman_to_integer(str)
end
end

Calling the undefined methods

r= Roman.new
r.vii
r.xxix
r.xxiv
r.xxvi

The Output

=> 7
=> 29
=> 24

===method_missing to Log Method Calls<ref>http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2007/wiki1b_2_22</ref>===
Another application that makes use of method_missing could be a simple logger used for debugging purposes. Many times, it may be required to log the trace of called methods and provide information such as: called method-name, arguments, return type. It can be tedious to repeat this part of code in every method. A simple solution to this problem can be obtained using method_missing as:

class SimpleCallLogger
def initialize(o)
@obj = o
end
def method_missing(methodname, *args)
puts "called: #{methodname}(#{args})"
a = @obj.send(methodname, *args)
puts "\t-> returned: #{a}"
return a
end
end

This program makes use of method_missing in a way that it wraps around called method to output the logging information on entry and on exit, it logs the return type. Further, method_missing intercepts the method call and forward it to internal object with ‘send’ method of ruby. Hence, this use of method_missing acts as wrapper.

===Generic Handler===
class NoBar
def method_missing(methodname, *args)
define_method(:bar) if "bar" == methodname.to_s
define_method(:nobar) if "nobar" == methodname.to_s
end
end

This is an example of using method_missing as a generic handler to handle when a calling method is not exist. You can use missing_method to dynamically create a method at a runtime.

=='''Advantages of method_missing'''==

*In addition to specifying the error messages for the undefined methods, method_missing provides a more dynamic behavior in the programming environment.
*If we are unfamiliar with the usage of the objects we created, then using method_missing is a good technique.
*Handles problems at runtime.
*Define's a generic method_missing and handle's any undefined method, a big advantage over Java. In Java, when you call an undefined method, the program will not compile.
*method_missing falls under the general technique of [http://en.wikipedia.org/wiki/Metaprogramming meta-programming]. Employ meta-programming in missing_function to write an another function to handle the call.

=='''Disadvantages of method_missing'''==
*Slower than conventional method lookup. Simple tests indicate that method dispatch with method_missing is at least two to three times as expensive in time as conventional dispatch.

*Since the methods being called never actually exist—they are just intercepted at the last step of the method lookup process—they cannot be documented or introspected as conventional methods can.

*method_missing restricts compatibility with future versions of an [http://en.wikipedia.org/wiki/Application_programming_interface API]. Introducing new methods in a future API version can break users' expectations.

=='''Key Points'''==

*In the following example, if within method_missing() we define an undefined method, we get a stack level too deep error message.

class A
@@i = 0
def method_missing(method_id)
puts "In Method Missing #{@@i}"
@@i += 1
self.fun
end
end

a = A.new
a.foo

Output

The result is a 'stack level too deep' error.

When the 'foo' method is called, after no method match the method_missing is run and this block has a method 'self.fun' that is undefined. Here when the program execution encounters 'self.fun' it once again calls method_missing. This goes on in an endless loop till the stack memory becomes full.

*Ruby knows method_missing( ) exists, because it's a private instance method of 'BasicObject' that every object inherits. The BasicObject#method_missing( ) responds by raising the NoMethodError. Overriding this method_missing( ) allows you to call methods that don't really exist.

*If method_missing is only looking for certain method names, don't forget to call the [http://en.wikibooks.org/wiki/Java_Programming/Keywords/super super] keyword if you haven't found what you're looking for, so that the other superclass' method_missing can handle it.

*[http://www.prateekdayal.net/2007/10/16/rubys-responds_to-for-checking-if-a-method-exists/ obj.respond_to?] function returns 'true' if the obj responds to the given method. So if you want to know whether your class will respond to a function you can use respond_to? to know the answer. But if method_missing() is used, the output may not be what you expect.

class A
def method_missing(method_id)
puts "In method_missing"
end
end

a = A.new
puts a.respond_to?(:foo)
a.foo

Output
false
In method_missing

=='''Similar functionality in other languages'''==
Method missing, one of the dynamic features of Ruby, is not a feature that is unique to Ruby. It exists in Smalltalk, Python, Groovy, some Javascripts and most CLOS (Common Lisp Object System)extensions. In this section we look at the few such similar implementations in other languages. The table below gives different ways the functionality related to method_missing is handled in other languages.<ref>http://olabini.com/blog/2010/04/patterns-of-method-missing/</ref>

'''Construct''' '''Language '''
AUTOLOAD Perl
AUTOSCALAR, AUTOMETH, AUTOLOAD... Perl6
__getattr__ Python
method_missing Ruby
doesNotUnderstand Smalltalk
__noSuchMethod__(17) CoffeeScript, JavaScript
unknown Tcl
no-applicable-method Common Lisp
doesNotRecognizeSelector Objective-C
TryInvokeMember(18) C#
match [name, args] { ... } E
the predicate fail Prolog
forward Io
Table Reference<ref>http://stackoverflow.com/questions/2865865/are-there-equivalents-to-rubys-method-missing-in-other-languages</ref>

*'''_getattr_ implementation in Python'''<ref>http://docs.python.org/reference/datamodel.html?highlight=__getattr__#object.__getattr__</ref>

object.__getattr__(self,name)

This method is called when an attribute lookup has not found the attribute in the usual places i.e. it is not an instance attribute nor is it found in the class tree for self. name is the attribute name. This method should return the (computed) attribute value or raise an AttributeError exception.

class Roman(object):
def roman_to_int(self, roman):
# implementation here
end

def __getattr__(self, name):
return self.roman_to_int(name)
end

>>> r = Roman()
>>> r.iv
4

*'''doesNotUnderstand in Smalltalk language'''<ref>http://c2.com/cgi/wiki?DoesNotUnderstand</ref>

In SmalltalkLanguage When a receiver is asked to perform a method that is unknown to it, then a run-time complaint is issued which is #doesNotUnderstand.
When a Smalltalk object is sent a message for a method it has not defined, the runtime system turns the message-send into an object and sends #doesNotUnderstand: to the original receiver with this message-send object as argument. By default the #doesNotUnderstand: method raises an exception, but the receiver can override it and implement it in a way that he sees fit.

*'''Other languages'''
JavaScript also has a method which has an implementation similar to that of method_missing and that is "noSuchMethod". The limitation of this method is that it is only supported by Firefox/Spidermonkey.

Similarly, Perl has an AUTOLOAD method which works on subroutines & class/object methods.

=='''Patterns of method missing<ref>http://olabini.com/blog/2010/04/patterns-of-method-missing/</ref>'''==
Now that we have covered all the important areas about method missing including the advantages, the disadvantages and key points related to its functionality, it would be appropriate to know about the different ways method_missing is used and what are the consequences of its use.

* Providing Debug information on Failure
Well as method missing is called when there is no object to handle the method being called, we can use method_missing to include more information about the reasons for it being called, i.e. to say that we can provide users with more information about the error messages and hence make the life of the programmers easy and provide a faster way to solve the bugs.

* Encode parameters in method name
Instead of sending method as explicit parameters, another method is to use the name to encode parameters. Find below a Rails-style find expression:
Person.find_by_name_and_age("ABC",30)
Another way of writing the same:
Person.find_by(:name => "ABC", :age => 30)

The disadvantage of this is that creating such kind of API's make it difficult to debug and maintain the application.

* Builders
The idea of a builder is that you use Ruby’s blocks and method_missing to make it easy to create any kind of output structure. You create a builder object and then send it messages and it responds to the messages by building up a data structure based on those messages. For example, the following code

builder = Builder::XmlMarkup.new("", 2)
puts builder.person {
name("ABC")
phone("12345", "local"=>"yes")
address("Raleigh")
}

will print

<person>
<name>ABC</name>
<phone local="yes">12345</phone>
<address>Raleigh</address>
</person>

Here we have defined a method_missing method and it handles any undefined method and adds the name of the method to the XML markup that is being built. Code blocks are used to capture the nested nature of the XML. The result is a very natural way to programmatically generate XML markup. Also the cumbersome task of closing the tags and escaping rules are taken care of for us.

* Accessors
The inversion of the builder pattern is to use a parser that goes through the XML document and then allow access to the elements by using method_missing.

* Test Helpers
Different kind of test helpers can be created using method_missing. Many of the open source Ruby projects implementations of method missing are found in the tests.

=='''Conclusion'''==
method_missing is a very powerful feature of Ruby and as is the way with powerful things it can help you a great deal if used properly but it can make things a lot harder for you if implemented incorrectly. It is a kind of a feature which should be used sparingly, if not at all. And there are things that needs to be taken into consideration, as mentioned in the Key Points section above, if method_missing is to be implemented.

=='''References'''==
<references/>

=='''Further Suggested Reading'''==
*http://www.rubyinside.com/
*https://www.youtube.com/watch?v=SAEiCkixrdE&feature=relmfu
*http://blog.jayfields.com/2008/02/ruby-replace-methodmissing-with-dynamic.html
*http://liquiddevelopment.blogspot.com/2006/04/twisting-and-shaping-dsls-using-ruby.html
*http://blog.rubybestpractices.com/posts/gregory/031-issue-2-method-lookup.html
*http://phrogz.net/RubyLibs/RubyMethodLookupFlow.pdf(Diagram)

CSC/ECE 517 Fall 2012/ch1 1w22 an

2012-09-20T03:53:09Z

Nloya: /* Key Points */

=='''Introduction<ref>http://rubylearning.com/satishtalim/ruby_method_missing.html</ref>'''==
A method that belongs to a class is called by creating an object of the class and passing the method name to the object as a message. The object then looks up the [http://www.madebydna.com/all/code/2011/06/24/eigenclasses-demystified.html method lookup path] and tries to match the called method with the defined methods in the class. On success, the method is executed and the result is returned.

If the object does not find a match in its method lookup, in normal circumstances the [http://www.ruby-doc.org/core-1.9.3/NoMethodError.html NoMethodError Exception] is raised .

In cases where the user wants to handle the methods which are not defined but are still called, “method_missing” can be defined and the user can handle the methods as he/she sees fit.

=='''Format for Defining method_missing'''==

=> def method_missing(m,*args,&block)

(i) '''m->''' accepts the symbol/name of the undefined method (ii) '''*args->''' accepts the array of arguments passed in the method call (iii) '''&block->'''accepts a block passed to the method

=='''Ruby Method Lookup Flow'''==
When the object of a class receives a method name to be executed, the following steps are carried out for matching and executing the method:

*First, the object looks in its own [http://docs.oracle.com/javase/tutorial/java/javaOO/classvars.html instance methods].
*Second, it looks in the list of instance methods that all objects of that class share.
*Third, in each of the included [http://www.tutorialspoint.com/ruby/ruby_modules.html modules] of that class, in reverse order of inclusion.
*Fourth, it looks in that class’s superclass.
*Fifth, in the superclass’s included modules, all the way up until it reaches the class Object.
*Sixth, if it still can’t find a method, the very last place it looks is in the [http://linux.die.net/lkmpg/x40.html Kernel module], included in the class Object.
*Finally, it calls method_missing (if defined in the class), else throws up the NOMethodError exception.

This entire tracing that the object does is called the method lookup path.

=='''Examples'''==
===Calling Defined and Undefined Methods===

class A // creating a class 'A'
def say // defining a method 'say'
puts " say Hi " // body of method say
end
end

Creating the object of the class

a=A.new // object of the class
=> #<A:0x2a082e0> //object id

Calling the defined method

a.say // defined method
=> say Hi // returned result

Calling the undefined method

a.sayhi // undefined method sayhi
NoMethodError: undefined method `sayhi' for #<A:0x2a082e0> // the NoMethodError is raised

===method_missing Implementation<ref>http://www.thirdbit.net/articles/2007/08/01/10-things-you-should-know-about-method_missing/</ref>===

class A
def say
puts " say hi "
end
def method_missing(m,*args,&block) // defining method_missing
puts " This method does not exist" // body of method_missing
end
end

Calling a method that is not defined

a=A.new
a.sayhi // calling the undefined method sayhi with no arguments
=> This method does not exist // this result returned when method_missing is executed

When the object 'a' traces its method lookup path for a matching method 'sayhi', upon failure it resorts to method_missing and the body of method_missing is executed.

Sometimes when a class has many methods that do generally the same kinds of functionality, and the programmer is not sure in advance which methods the user will call since there are so many of them, and all of them are similar, writing code for all of the methods seems futile. In these situations method_missing can be defined to take care of these cases. The below 'Generic Handler' example implements this.

===Passing Parameters to an Undefined Method Call===

class A
def add(a,b)
a+b
end
def method_missing(name,*args,&block) // the method_missing is defined and the *args parameter accepts all the parameters passed during
the method call
puts “You have typed the method name wrong and these were the parameters passed ; #{args[0]}, #{args[1]}”
end
end

The passed parameters are stored in the array 'args' and can be accessed like a normal array

Calling the defined method

a.add(1,2) // calling the defined method add and passing the parameters (1,2)
=> 3 // result

Calling the undefined method

a.adds(4,2) // calling the undefined method adds and passing the parameter (4,2)
=> You have typed the method name wrong and these were the parameters passed; 4, 2

The user made a genuine mistake by typing 'adds', but this method is not defined. When the 'adds' method with parameters is called, the object 'a' tries to match the method in the method lookup path. Upon failure it invokes method_missing, the args are passed, stored in the array 'args' and the body of method_missing is executed.

===Converting Numbers from Roman Representation to Integer Representation<ref>http://courses.ncsu.edu/csc517/common/lectures/notes/wk2.pdf</ref>===
class Roman
DIGITS = {'I'=>1,'V'=>5,'X'=>10,'L'=>50,'C'=>100,'D'=>500,'M'=>1000,}
def roman_to_integer(roman_string)
last = nil
roman_string.to_s.upcase.split(//).reverse.inject(0) do
|memo, digit|
if digit_value = DIGITS[digit]
if last && last > digit_value
memo -= digit_value
else
memo += digit_value
end
last = digit_value
end
memo
end
end

def method_missing(method)
str=method.id2name
roman_to_integer(str)
end
end

Calling the undefined methods

r= Roman.new
r.vii
r.xxix
r.xxiv
r.xxvi

The Output

=> 7
=> 29
=> 24

===method_missing to Log Method Calls<ref>http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2007/wiki1b_2_22</ref>===
Another application that makes use of method_missing could be a simple logger used for debugging purposes. Many times, it may be required to log the trace of called methods and provide information such as: called method-name, arguments, return type. It can be tedious to repeat this part of code in every method. A simple solution to this problem can be obtained using method_missing as:

class SimpleCallLogger
def initialize(o)
@obj = o
end
def method_missing(methodname, *args)
puts "called: #{methodname}(#{args})"
a = @obj.send(methodname, *args)
puts "\t-> returned: #{a}"
return a
end
end

This program makes use of method_missing in a way that it wraps around called method to output the logging information on entry and on exit, it logs the return type. Further, method_missing intercepts the method call and forward it to internal object with ‘send’ method of ruby. Hence, this use of method_missing acts as wrapper.

===Generic Handler===
class NoBar
def method_missing(methodname, *args)
define_method(:bar) if "bar" == methodname.to_s
define_method(:nobar) if "nobar" == methodname.to_s
end
end

This is an example of using method_missing as a generic handler to handle when a calling method is not exist. You can use missing_method to dynamically create a method at a runtime.

=='''Advantages of method_missing'''==

*In addition to specifying the error messages for the undefined methods, method_missing provides a more dynamic behavior in the programming environment.
*If we are unfamiliar with the usage of the objects we created, then using method_missing is a good technique.
*Handles problems at runtime.
*Define's a generic method_missing and handle's any undefined method, a big advantage over Java. In Java, when you call an undefined method, the program will not compile.
*method_missing falls under the general technique of [http://en.wikipedia.org/wiki/Metaprogramming meta-programming]. Employ meta-programming in missing_function to write an another function to handle the call.

=='''Disadvantages of method_missing'''==
*Slower than conventional method lookup. Simple tests indicate that method dispatch with method_missing is at least two to three times as expensive in time as conventional dispatch.

*Since the methods being called never actually exist—they are just intercepted at the last step of the method lookup process—they cannot be documented or introspected as conventional methods can.

*method_missing restricts compatibility with future versions of an [http://en.wikipedia.org/wiki/Application_programming_interface API]. Introducing new methods in a future API version can break users' expectations.

=='''Key Points'''==

*In the following example, if within method_missing() we define an undefined method, we get a stack level too deep error message.

class A
@@i = 0
def method_missing(method_id)
puts "In Method Missing #{@@i}"
@@i += 1
self.fun
end
end

a = A.new
a.foo

Output

The result is a 'stack level too deep' error.

When the 'foo' method is called, after no method match the method_missing is run and this block has a method “self.fun” that is undefined. Here when the program execution encounters 'self.fun' it once again calls method_missing. This goes on in an endless loop till the stack memory is full.

*Ruby knows method_missing( ) exists, because it's a private instance method of 'BasicObject' that every object inherits. The BasicObject#method_missing( ) responds by raising the NoMethodError. Overriding this method_missing( ) allows you to call methods that don't really exist.

*If method_missing is only looking for certain method names, don't forget to call the [http://en.wikibooks.org/wiki/Java_Programming/Keywords/super super] keyword if you haven't found what you're looking for, so that the other superclass' method_missing can handle it.

*[http://www.prateekdayal.net/2007/10/16/rubys-responds_to-for-checking-if-a-method-exists/ obj.respond_to?] function returns 'true' if the obj responds to the given method. So if you want to know whether your class will respond to a function you can use respond_to? to know the answer. But if method_missing() is used, the output may not be what you expect.

class A
def method_missing(method_id)
puts "In method_missing"
end
end

a = A.new
puts a.respond_to?(:foo)
a.foo

Output
false
In method_missing

=='''Similar functionality in other languages'''==
Method missing, one of the dynamic features of Ruby, is not a feature that is unique to Ruby. It exists in Smalltalk, Python, Groovy, some Javascripts and most CLOS (Common Lisp Object System)extensions. In this section we look at the few such similar implementations in other languages. The table below gives different ways the functionality related to method_missing is handled in other languages.<ref>http://olabini.com/blog/2010/04/patterns-of-method-missing/</ref>

'''Construct''' '''Language '''
AUTOLOAD Perl
AUTOSCALAR, AUTOMETH, AUTOLOAD... Perl6
__getattr__ Python
method_missing Ruby
doesNotUnderstand Smalltalk
__noSuchMethod__(17) CoffeeScript, JavaScript
unknown Tcl
no-applicable-method Common Lisp
doesNotRecognizeSelector Objective-C
TryInvokeMember(18) C#
match [name, args] { ... } E
the predicate fail Prolog
forward Io
Table Reference<ref>http://stackoverflow.com/questions/2865865/are-there-equivalents-to-rubys-method-missing-in-other-languages</ref>

*'''_getattr_ implementation in Python'''<ref>http://docs.python.org/reference/datamodel.html?highlight=__getattr__#object.__getattr__</ref>

object.__getattr__(self,name)

This method is called when an attribute lookup has not found the attribute in the usual places i.e. it is not an instance attribute nor is it found in the class tree for self. name is the attribute name. This method should return the (computed) attribute value or raise an AttributeError exception.

class Roman(object):
def roman_to_int(self, roman):
# implementation here
end

def __getattr__(self, name):
return self.roman_to_int(name)
end

>>> r = Roman()
>>> r.iv
4

*'''doesNotUnderstand in Smalltalk language'''<ref>http://c2.com/cgi/wiki?DoesNotUnderstand</ref>

In SmalltalkLanguage When a receiver is asked to perform a method that is unknown to it, then a run-time complaint is issued which is #doesNotUnderstand.
When a Smalltalk object is sent a message for a method it has not defined, the runtime system turns the message-send into an object and sends #doesNotUnderstand: to the original receiver with this message-send object as argument. By default the #doesNotUnderstand: method raises an exception, but the receiver can override it and implement it in a way that he sees fit.

*'''Other languages'''
JavaScript also has a method which has an implementation similar to that of method_missing and that is "noSuchMethod". The limitation of this method is that it is only supported by Firefox/Spidermonkey.

Similarly, Perl has an AUTOLOAD method which works on subroutines & class/object methods.

=='''Patterns of method missing<ref>http://olabini.com/blog/2010/04/patterns-of-method-missing/</ref>'''==
Now that we have covered all the important areas about method missing including the advantages, the disadvantages and key points related to its functionality, it would be appropriate to know about the different ways method_missing is used and what are the consequences of its use.

* Providing Debug information on Failure
Well as method missing is called when there is no object to handle the method being called, we can use method_missing to include more information about the reasons for it being called, i.e. to say that we can provide users with more information about the error messages and hence make the life of the programmers easy and provide a faster way to solve the bugs.

* Encode parameters in method name
Instead of sending method as explicit parameters, another method is to use the name to encode parameters. Find below a Rails-style find expression:
Person.find_by_name_and_age("ABC",30)
Another way of writing the same:
Person.find_by(:name => "ABC", :age => 30)

The disadvantage of this is that creating such kind of API's make it difficult to debug and maintain the application.

* Builders
The idea of a builder is that you use Ruby’s blocks and method_missing to make it easy to create any kind of output structure. You create a builder object and then send it messages and it responds to the messages by building up a data structure based on those messages. For example, the following code

builder = Builder::XmlMarkup.new("", 2)
puts builder.person {
name("ABC")
phone("12345", "local"=>"yes")
address("Raleigh")
}

will print

<person>
<name>ABC</name>
<phone local="yes">12345</phone>
<address>Raleigh</address>
</person>

Here we have defined a method_missing method and it handles any undefined method and adds the name of the method to the XML markup that is being built. Code blocks are used to capture the nested nature of the XML. The result is a very natural way to programmatically generate XML markup. Also the cumbersome task of closing the tags and escaping rules are taken care of for us.

* Accessors
The inversion of the builder pattern is to use a parser that goes through the XML document and then allow access to the elements by using method_missing.

* Test Helpers
Different kind of test helpers can be created using method_missing. Many of the open source Ruby projects implementations of method missing are found in the tests.

=='''Conclusion'''==
method_missing is a very powerful feature of Ruby and as is the way with powerful things it can help you a great deal if used properly but it can make things a lot harder for you if implemented incorrectly. It is a kind of a feature which should be used sparingly, if not at all. And there are things that needs to be taken into consideration, as mentioned in the Key Points section above, if method_missing is to be implemented.

=='''References'''==
<references/>

=='''Further Suggested Reading'''==
*http://www.rubyinside.com/
*https://www.youtube.com/watch?v=SAEiCkixrdE&feature=relmfu
*http://blog.jayfields.com/2008/02/ruby-replace-methodmissing-with-dynamic.html
*http://liquiddevelopment.blogspot.com/2006/04/twisting-and-shaping-dsls-using-ruby.html
*http://blog.rubybestpractices.com/posts/gregory/031-issue-2-method-lookup.html
*http://phrogz.net/RubyLibs/RubyMethodLookupFlow.pdf(Diagram)

CSC/ECE 517 Fall 2012/ch1 1w22 an

2012-09-20T03:51:01Z

Nloya: /* Ruby Method Lookup Flow */

=='''Introduction<ref>http://rubylearning.com/satishtalim/ruby_method_missing.html</ref>'''==
A method that belongs to a class is called by creating an object of the class and passing the method name to the object as a message. The object then looks up the [http://www.madebydna.com/all/code/2011/06/24/eigenclasses-demystified.html method lookup path] and tries to match the called method with the defined methods in the class. On success, the method is executed and the result is returned.

If the object does not find a match in its method lookup, in normal circumstances the [http://www.ruby-doc.org/core-1.9.3/NoMethodError.html NoMethodError Exception] is raised .

In cases where the user wants to handle the methods which are not defined but are still called, “method_missing” can be defined and the user can handle the methods as he/she sees fit.

=='''Format for Defining method_missing'''==

=> def method_missing(m,*args,&block)

(i) '''m->''' accepts the symbol/name of the undefined method (ii) '''*args->''' accepts the array of arguments passed in the method call (iii) '''&block->'''accepts a block passed to the method

=='''Ruby Method Lookup Flow'''==
When the object of a class receives a method name to be executed, the following steps are carried out for matching and executing the method:

*First, the object looks in its own [http://docs.oracle.com/javase/tutorial/java/javaOO/classvars.html instance methods].
*Second, it looks in the list of instance methods that all objects of that class share.
*Third, in each of the included [http://www.tutorialspoint.com/ruby/ruby_modules.html modules] of that class, in reverse order of inclusion.
*Fourth, it looks in that class’s superclass.
*Fifth, in the superclass’s included modules, all the way up until it reaches the class Object.
*Sixth, if it still can’t find a method, the very last place it looks is in the [http://linux.die.net/lkmpg/x40.html Kernel module], included in the class Object.
*Finally, it calls method_missing (if defined in the class), else throws up the NOMethodError exception.

This entire tracing that the object does is called the method lookup path.

=='''Examples'''==
===Calling Defined and Undefined Methods===

class A // creating a class 'A'
def say // defining a method 'say'
puts " say Hi " // body of method say
end
end

Creating the object of the class

a=A.new // object of the class
=> #<A:0x2a082e0> //object id

Calling the defined method

a.say // defined method
=> say Hi // returned result

Calling the undefined method

a.sayhi // undefined method sayhi
NoMethodError: undefined method `sayhi' for #<A:0x2a082e0> // the NoMethodError is raised

===method_missing Implementation<ref>http://www.thirdbit.net/articles/2007/08/01/10-things-you-should-know-about-method_missing/</ref>===

class A
def say
puts " say hi "
end
def method_missing(m,*args,&block) // defining method_missing
puts " This method does not exist" // body of method_missing
end
end

Calling a method that is not defined

a=A.new
a.sayhi // calling the undefined method sayhi with no arguments
=> This method does not exist // this result returned when method_missing is executed

When the object 'a' traces its method lookup path for a matching method 'sayhi', upon failure it resorts to method_missing and the body of method_missing is executed.

Sometimes when a class has many methods that do generally the same kinds of functionality, and the programmer is not sure in advance which methods the user will call since there are so many of them, and all of them are similar, writing code for all of the methods seems futile. In these situations method_missing can be defined to take care of these cases. The below 'Generic Handler' example implements this.

===Passing Parameters to an Undefined Method Call===

class A
def add(a,b)
a+b
end
def method_missing(name,*args,&block) // the method_missing is defined and the *args parameter accepts all the parameters passed during
the method call
puts “You have typed the method name wrong and these were the parameters passed ; #{args[0]}, #{args[1]}”
end
end

The passed parameters are stored in the array 'args' and can be accessed like a normal array

Calling the defined method

a.add(1,2) // calling the defined method add and passing the parameters (1,2)
=> 3 // result

Calling the undefined method

a.adds(4,2) // calling the undefined method adds and passing the parameter (4,2)
=> You have typed the method name wrong and these were the parameters passed; 4, 2

The user made a genuine mistake by typing 'adds', but this method is not defined. When the 'adds' method with parameters is called, the object 'a' tries to match the method in the method lookup path. Upon failure it invokes method_missing, the args are passed, stored in the array 'args' and the body of method_missing is executed.

===Converting Numbers from Roman Representation to Integer Representation<ref>http://courses.ncsu.edu/csc517/common/lectures/notes/wk2.pdf</ref>===
class Roman
DIGITS = {'I'=>1,'V'=>5,'X'=>10,'L'=>50,'C'=>100,'D'=>500,'M'=>1000,}
def roman_to_integer(roman_string)
last = nil
roman_string.to_s.upcase.split(//).reverse.inject(0) do
|memo, digit|
if digit_value = DIGITS[digit]
if last && last > digit_value
memo -= digit_value
else
memo += digit_value
end
last = digit_value
end
memo
end
end

def method_missing(method)
str=method.id2name
roman_to_integer(str)
end
end

Calling the undefined methods

r= Roman.new
r.vii
r.xxix
r.xxiv
r.xxvi

The Output

=> 7
=> 29
=> 24

===method_missing to Log Method Calls<ref>http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2007/wiki1b_2_22</ref>===
Another application that makes use of method_missing could be a simple logger used for debugging purposes. Many times, it may be required to log the trace of called methods and provide information such as: called method-name, arguments, return type. It can be tedious to repeat this part of code in every method. A simple solution to this problem can be obtained using method_missing as:

class SimpleCallLogger
def initialize(o)
@obj = o
end
def method_missing(methodname, *args)
puts "called: #{methodname}(#{args})"
a = @obj.send(methodname, *args)
puts "\t-> returned: #{a}"
return a
end
end

This program makes use of method_missing in a way that it wraps around called method to output the logging information on entry and on exit, it logs the return type. Further, method_missing intercepts the method call and forward it to internal object with ‘send’ method of ruby. Hence, this use of method_missing acts as wrapper.

===Generic Handler===
class NoBar
def method_missing(methodname, *args)
define_method(:bar) if "bar" == methodname.to_s
define_method(:nobar) if "nobar" == methodname.to_s
end
end

This is an example of using method_missing as a generic handler to handle when a calling method is not exist. You can use missing_method to dynamically create a method at a runtime.

=='''Advantages of method_missing'''==

*In addition to specifying the error messages for the undefined methods, method_missing provides a more dynamic behavior in the programming environment.
*If we are unfamiliar with the usage of the objects we created, then using method_missing is a good technique.
*Handles problems at runtime.
*Define's a generic method_missing and handle's any undefined method, a big advantage over Java. In Java, when you call an undefined method, the program will not compile.
*method_missing falls under the general technique of [http://en.wikipedia.org/wiki/Metaprogramming meta-programming]. Employ meta-programming in missing_function to write an another function to handle the call.

=='''Disadvantages of method_missing'''==
*Slower than conventional method lookup. Simple tests indicate that method dispatch with method_missing is at least two to three times as expensive in time as conventional dispatch.

*Since the methods being called never actually exist—they are just intercepted at the last step of the method lookup process—they cannot be documented or introspected as conventional methods can.

*method_missing restricts compatibility with future versions of an [http://en.wikipedia.org/wiki/Application_programming_interface API]. Introducing new methods in a future API version can break users' expectations.

=='''Key Points'''==

*In the following example, if within method_missing() we define an undefined method.

class A
@@i = 0
def method_missing(method_id)
puts "In Method Missing #{@@i}"
@@i += 1
self.fun
end
end

a = A.new
a.foo

Output

The result is a 'stack level too deep' error.

When the 'foo' method is called, after no method match the method_missing is run and this block has a method “self.fun” that is undefined. Here when the program execution encounters 'self.fun' it once again calls method_missing. This goes on in an endless loop till the stack memory is full.

*Ruby knows method_missing( ) exists, because it's a private instance method of 'BasicObject' that every object inherits. The BasicObject#method_missing( ) responds by raising the NoMethodError. Overriding this method_missing( ) allows you to call methods that don't really exist.

*If method_missing is only looking for certain method names, don't forget to call the [http://en.wikibooks.org/wiki/Java_Programming/Keywords/super super] keyword if you haven't found what you're looking for, so that the other superclass' method_missing can handle it.

*[http://www.prateekdayal.net/2007/10/16/rubys-responds_to-for-checking-if-a-method-exists/ obj.respond_to?] function returns 'true' if the obj responds to the given method. So if you want to know whether your class will respond to a function you can use respond_to? to know the answer. But if method_missing() is used, the output may not be what you expect.

class A
def method_missing(method_id)
puts "In method_missing"
end
end

a = A.new
puts a.respond_to?(:foo)
a.foo

Output
false
In method_missing

=='''Similar functionality in other languages'''==
Method missing, one of the dynamic features of Ruby, is not a feature that is unique to Ruby. It exists in Smalltalk, Python, Groovy, some Javascripts and most CLOS (Common Lisp Object System)extensions. In this section we look at the few such similar implementations in other languages. The table below gives different ways the functionality related to method_missing is handled in other languages.<ref>http://olabini.com/blog/2010/04/patterns-of-method-missing/</ref>

'''Construct''' '''Language '''
AUTOLOAD Perl
AUTOSCALAR, AUTOMETH, AUTOLOAD... Perl6
__getattr__ Python
method_missing Ruby
doesNotUnderstand Smalltalk
__noSuchMethod__(17) CoffeeScript, JavaScript
unknown Tcl
no-applicable-method Common Lisp
doesNotRecognizeSelector Objective-C
TryInvokeMember(18) C#
match [name, args] { ... } E
the predicate fail Prolog
forward Io
Table Reference<ref>http://stackoverflow.com/questions/2865865/are-there-equivalents-to-rubys-method-missing-in-other-languages</ref>

*'''_getattr_ implementation in Python'''<ref>http://docs.python.org/reference/datamodel.html?highlight=__getattr__#object.__getattr__</ref>

object.__getattr__(self,name)

This method is called when an attribute lookup has not found the attribute in the usual places i.e. it is not an instance attribute nor is it found in the class tree for self. name is the attribute name. This method should return the (computed) attribute value or raise an AttributeError exception.

class Roman(object):
def roman_to_int(self, roman):
# implementation here
end

def __getattr__(self, name):
return self.roman_to_int(name)
end

>>> r = Roman()
>>> r.iv
4

*'''doesNotUnderstand in Smalltalk language'''<ref>http://c2.com/cgi/wiki?DoesNotUnderstand</ref>

In SmalltalkLanguage When a receiver is asked to perform a method that is unknown to it, then a run-time complaint is issued which is #doesNotUnderstand.
When a Smalltalk object is sent a message for a method it has not defined, the runtime system turns the message-send into an object and sends #doesNotUnderstand: to the original receiver with this message-send object as argument. By default the #doesNotUnderstand: method raises an exception, but the receiver can override it and implement it in a way that he sees fit.

*'''Other languages'''
JavaScript also has a method which has an implementation similar to that of method_missing and that is "noSuchMethod". The limitation of this method is that it is only supported by Firefox/Spidermonkey.

Similarly, Perl has an AUTOLOAD method which works on subroutines & class/object methods.

=='''Patterns of method missing<ref>http://olabini.com/blog/2010/04/patterns-of-method-missing/</ref>'''==
Now that we have covered all the important areas about method missing including the advantages, the disadvantages and key points related to its functionality, it would be appropriate to know about the different ways method_missing is used and what are the consequences of its use.

* Providing Debug information on Failure
Well as method missing is called when there is no object to handle the method being called, we can use method_missing to include more information about the reasons for it being called, i.e. to say that we can provide users with more information about the error messages and hence make the life of the programmers easy and provide a faster way to solve the bugs.

* Encode parameters in method name
Instead of sending method as explicit parameters, another method is to use the name to encode parameters. Find below a Rails-style find expression:
Person.find_by_name_and_age("ABC",30)
Another way of writing the same:
Person.find_by(:name => "ABC", :age => 30)

The disadvantage of this is that creating such kind of API's make it difficult to debug and maintain the application.

* Builders
The idea of a builder is that you use Ruby’s blocks and method_missing to make it easy to create any kind of output structure. You create a builder object and then send it messages and it responds to the messages by building up a data structure based on those messages. For example, the following code

builder = Builder::XmlMarkup.new("", 2)
puts builder.person {
name("ABC")
phone("12345", "local"=>"yes")
address("Raleigh")
}

will print

<person>
<name>ABC</name>
<phone local="yes">12345</phone>
<address>Raleigh</address>
</person>

Here we have defined a method_missing method and it handles any undefined method and adds the name of the method to the XML markup that is being built. Code blocks are used to capture the nested nature of the XML. The result is a very natural way to programmatically generate XML markup. Also the cumbersome task of closing the tags and escaping rules are taken care of for us.

* Accessors
The inversion of the builder pattern is to use a parser that goes through the XML document and then allow access to the elements by using method_missing.

* Test Helpers
Different kind of test helpers can be created using method_missing. Many of the open source Ruby projects implementations of method missing are found in the tests.

=='''Conclusion'''==
method_missing is a very powerful feature of Ruby and as is the way with powerful things it can help you a great deal if used properly but it can make things a lot harder for you if implemented incorrectly. It is a kind of a feature which should be used sparingly, if not at all. And there are things that needs to be taken into consideration, as mentioned in the Key Points section above, if method_missing is to be implemented.

=='''References'''==
<references/>

=='''Further Suggested Reading'''==
*http://www.rubyinside.com/
*https://www.youtube.com/watch?v=SAEiCkixrdE&feature=relmfu
*http://blog.jayfields.com/2008/02/ruby-replace-methodmissing-with-dynamic.html
*http://liquiddevelopment.blogspot.com/2006/04/twisting-and-shaping-dsls-using-ruby.html
*http://blog.rubybestpractices.com/posts/gregory/031-issue-2-method-lookup.html
*http://phrogz.net/RubyLibs/RubyMethodLookupFlow.pdf(Diagram)

CSC/ECE 517 Fall 2012/ch1 1w22 an

2012-09-20T03:49:50Z

Nloya:

=='''Introduction<ref>http://rubylearning.com/satishtalim/ruby_method_missing.html</ref>'''==
A method that belongs to a class is called by creating an object of the class and passing the method name to the object as a message. The object then looks up the [http://www.madebydna.com/all/code/2011/06/24/eigenclasses-demystified.html method lookup path] and tries to match the called method with the defined methods in the class. On success, the method is executed and the result is returned.

If the object does not find a match in its method lookup, in normal circumstances the [http://www.ruby-doc.org/core-1.9.3/NoMethodError.html NoMethodError Exception] is raised .

In cases where the user wants to handle the methods which are not defined but are still called, “method_missing” can be defined and the user can handle the methods as he/she sees fit.

=='''Format for Defining method_missing'''==

=> def method_missing(m,*args,&block)

(i) '''m->''' accepts the symbol/name of the undefined method (ii) '''*args->''' accepts the array of arguments passed in the method call (iii) '''&block->'''accepts a block passed to the method

=='''Ruby Method Lookup Flow'''==
When the object of a class receives a method name to be executed, the following steps are carried out for matching and executing the method:

*First, the object looks in its own [http://docs.oracle.com/javase/tutorial/java/javaOO/classvars.html instance methods].
*Second, it looks in the list of instance methods that all objects of that class share.
*Third, in each of the included [http://www.tutorialspoint.com/ruby/ruby_modules.html modules] of that class, in reverse order of inclusion.
*Fourth, it looks in that class’s superclass.
*Fifth, in the superclass’s included modules, all the way up until it reaches the class Object.
*Sixth, if it still can’t find a method, the very last place it looks is in the [http://linux.die.net/lkmpg/x40.html Kernel module], included in the class Object.
*Finally, it calls method_missing (if defined in the class), else throws up the NOMethodError exception.

This entire tracing that the object does is the method lookup path.

=='''Examples'''==
===Calling Defined and Undefined Methods===

class A // creating a class 'A'
def say // defining a method 'say'
puts " say Hi " // body of method say
end
end

Creating the object of the class

a=A.new // object of the class
=> #<A:0x2a082e0> //object id

Calling the defined method

a.say // defined method
=> say Hi // returned result

Calling the undefined method

a.sayhi // undefined method sayhi
NoMethodError: undefined method `sayhi' for #<A:0x2a082e0> // the NoMethodError is raised

===method_missing Implementation<ref>http://www.thirdbit.net/articles/2007/08/01/10-things-you-should-know-about-method_missing/</ref>===

class A
def say
puts " say hi "
end
def method_missing(m,*args,&block) // defining method_missing
puts " This method does not exist" // body of method_missing
end
end

Calling a method that is not defined

a=A.new
a.sayhi // calling the undefined method sayhi with no arguments
=> This method does not exist // this result returned when method_missing is executed

When the object 'a' traces its method lookup path for a matching method 'sayhi', upon failure it resorts to method_missing and the body of method_missing is executed.

Sometimes when a class has many methods that do generally the same kinds of functionality, and the programmer is not sure in advance which methods the user will call since there are so many of them, and all of them are similar, writing code for all of the methods seems futile. In these situations method_missing can be defined to take care of these cases. The below 'Generic Handler' example implements this.

===Passing Parameters to an Undefined Method Call===

class A
def add(a,b)
a+b
end
def method_missing(name,*args,&block) // the method_missing is defined and the *args parameter accepts all the parameters passed during
the method call
puts “You have typed the method name wrong and these were the parameters passed ; #{args[0]}, #{args[1]}”
end
end

The passed parameters are stored in the array 'args' and can be accessed like a normal array

Calling the defined method

a.add(1,2) // calling the defined method add and passing the parameters (1,2)
=> 3 // result

Calling the undefined method

a.adds(4,2) // calling the undefined method adds and passing the parameter (4,2)
=> You have typed the method name wrong and these were the parameters passed; 4, 2

The user made a genuine mistake by typing 'adds', but this method is not defined. When the 'adds' method with parameters is called, the object 'a' tries to match the method in the method lookup path. Upon failure it invokes method_missing, the args are passed, stored in the array 'args' and the body of method_missing is executed.

===Converting Numbers from Roman Representation to Integer Representation<ref>http://courses.ncsu.edu/csc517/common/lectures/notes/wk2.pdf</ref>===
class Roman
DIGITS = {'I'=>1,'V'=>5,'X'=>10,'L'=>50,'C'=>100,'D'=>500,'M'=>1000,}
def roman_to_integer(roman_string)
last = nil
roman_string.to_s.upcase.split(//).reverse.inject(0) do
|memo, digit|
if digit_value = DIGITS[digit]
if last && last > digit_value
memo -= digit_value
else
memo += digit_value
end
last = digit_value
end
memo
end
end

def method_missing(method)
str=method.id2name
roman_to_integer(str)
end
end

Calling the undefined methods

r= Roman.new
r.vii
r.xxix
r.xxiv
r.xxvi

The Output

=> 7
=> 29
=> 24

===method_missing to Log Method Calls<ref>http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2007/wiki1b_2_22</ref>===
Another application that makes use of method_missing could be a simple logger used for debugging purposes. Many times, it may be required to log the trace of called methods and provide information such as: called method-name, arguments, return type. It can be tedious to repeat this part of code in every method. A simple solution to this problem can be obtained using method_missing as:

class SimpleCallLogger
def initialize(o)
@obj = o
end
def method_missing(methodname, *args)
puts "called: #{methodname}(#{args})"
a = @obj.send(methodname, *args)
puts "\t-> returned: #{a}"
return a
end
end

This program makes use of method_missing in a way that it wraps around called method to output the logging information on entry and on exit, it logs the return type. Further, method_missing intercepts the method call and forward it to internal object with ‘send’ method of ruby. Hence, this use of method_missing acts as wrapper.

===Generic Handler===
class NoBar
def method_missing(methodname, *args)
define_method(:bar) if "bar" == methodname.to_s
define_method(:nobar) if "nobar" == methodname.to_s
end
end

This is an example of using method_missing as a generic handler to handle when a calling method is not exist. You can use missing_method to dynamically create a method at a runtime.

=='''Advantages of method_missing'''==

*In addition to specifying the error messages for the undefined methods, method_missing provides a more dynamic behavior in the programming environment.
*If we are unfamiliar with the usage of the objects we created, then using method_missing is a good technique.
*Handles problems at runtime.
*Define's a generic method_missing and handle's any undefined method, a big advantage over Java. In Java, when you call an undefined method, the program will not compile.
*method_missing falls under the general technique of [http://en.wikipedia.org/wiki/Metaprogramming meta-programming]. Employ meta-programming in missing_function to write an another function to handle the call.

=='''Disadvantages of method_missing'''==
*Slower than conventional method lookup. Simple tests indicate that method dispatch with method_missing is at least two to three times as expensive in time as conventional dispatch.

*Since the methods being called never actually exist—they are just intercepted at the last step of the method lookup process—they cannot be documented or introspected as conventional methods can.

*method_missing restricts compatibility with future versions of an [http://en.wikipedia.org/wiki/Application_programming_interface API]. Introducing new methods in a future API version can break users' expectations.

=='''Key Points'''==

*In the following example, if within method_missing() we define an undefined method.

class A
@@i = 0
def method_missing(method_id)
puts "In Method Missing #{@@i}"
@@i += 1
self.fun
end
end

a = A.new
a.foo

Output

The result is a 'stack level too deep' error.

When the 'foo' method is called, after no method match the method_missing is run and this block has a method “self.fun” that is undefined. Here when the program execution encounters 'self.fun' it once again calls method_missing. This goes on in an endless loop till the stack memory is full.

*Ruby knows method_missing( ) exists, because it's a private instance method of 'BasicObject' that every object inherits. The BasicObject#method_missing( ) responds by raising the NoMethodError. Overriding this method_missing( ) allows you to call methods that don't really exist.

*If method_missing is only looking for certain method names, don't forget to call the [http://en.wikibooks.org/wiki/Java_Programming/Keywords/super super] keyword if you haven't found what you're looking for, so that the other superclass' method_missing can handle it.

*[http://www.prateekdayal.net/2007/10/16/rubys-responds_to-for-checking-if-a-method-exists/ obj.respond_to?] function returns 'true' if the obj responds to the given method. So if you want to know whether your class will respond to a function you can use respond_to? to know the answer. But if method_missing() is used, the output may not be what you expect.

class A
def method_missing(method_id)
puts "In method_missing"
end
end

a = A.new
puts a.respond_to?(:foo)
a.foo

Output
false
In method_missing

=='''Similar functionality in other languages'''==
Method missing, one of the dynamic features of Ruby, is not a feature that is unique to Ruby. It exists in Smalltalk, Python, Groovy, some Javascripts and most CLOS (Common Lisp Object System)extensions. In this section we look at the few such similar implementations in other languages. The table below gives different ways the functionality related to method_missing is handled in other languages.<ref>http://olabini.com/blog/2010/04/patterns-of-method-missing/</ref>

'''Construct''' '''Language '''
AUTOLOAD Perl
AUTOSCALAR, AUTOMETH, AUTOLOAD... Perl6
__getattr__ Python
method_missing Ruby
doesNotUnderstand Smalltalk
__noSuchMethod__(17) CoffeeScript, JavaScript
unknown Tcl
no-applicable-method Common Lisp
doesNotRecognizeSelector Objective-C
TryInvokeMember(18) C#
match [name, args] { ... } E
the predicate fail Prolog
forward Io
Table Reference<ref>http://stackoverflow.com/questions/2865865/are-there-equivalents-to-rubys-method-missing-in-other-languages</ref>

*'''_getattr_ implementation in Python'''<ref>http://docs.python.org/reference/datamodel.html?highlight=__getattr__#object.__getattr__</ref>

object.__getattr__(self,name)

This method is called when an attribute lookup has not found the attribute in the usual places i.e. it is not an instance attribute nor is it found in the class tree for self. name is the attribute name. This method should return the (computed) attribute value or raise an AttributeError exception.

class Roman(object):
def roman_to_int(self, roman):
# implementation here
end

def __getattr__(self, name):
return self.roman_to_int(name)
end

>>> r = Roman()
>>> r.iv
4

*'''doesNotUnderstand in Smalltalk language'''<ref>http://c2.com/cgi/wiki?DoesNotUnderstand</ref>

In SmalltalkLanguage When a receiver is asked to perform a method that is unknown to it, then a run-time complaint is issued which is #doesNotUnderstand.
When a Smalltalk object is sent a message for a method it has not defined, the runtime system turns the message-send into an object and sends #doesNotUnderstand: to the original receiver with this message-send object as argument. By default the #doesNotUnderstand: method raises an exception, but the receiver can override it and implement it in a way that he sees fit.

*'''Other languages'''
JavaScript also has a method which has an implementation similar to that of method_missing and that is "noSuchMethod". The limitation of this method is that it is only supported by Firefox/Spidermonkey.

Similarly, Perl has an AUTOLOAD method which works on subroutines & class/object methods.

=='''Patterns of method missing<ref>http://olabini.com/blog/2010/04/patterns-of-method-missing/</ref>'''==
Now that we have covered all the important areas about method missing including the advantages, the disadvantages and key points related to its functionality, it would be appropriate to know about the different ways method_missing is used and what are the consequences of its use.

* Providing Debug information on Failure
Well as method missing is called when there is no object to handle the method being called, we can use method_missing to include more information about the reasons for it being called, i.e. to say that we can provide users with more information about the error messages and hence make the life of the programmers easy and provide a faster way to solve the bugs.

* Encode parameters in method name
Instead of sending method as explicit parameters, another method is to use the name to encode parameters. Find below a Rails-style find expression:
Person.find_by_name_and_age("ABC",30)
Another way of writing the same:
Person.find_by(:name => "ABC", :age => 30)

The disadvantage of this is that creating such kind of API's make it difficult to debug and maintain the application.

* Builders
The idea of a builder is that you use Ruby’s blocks and method_missing to make it easy to create any kind of output structure. You create a builder object and then send it messages and it responds to the messages by building up a data structure based on those messages. For example, the following code

builder = Builder::XmlMarkup.new("", 2)
puts builder.person {
name("ABC")
phone("12345", "local"=>"yes")
address("Raleigh")
}

will print

<person>
<name>ABC</name>
<phone local="yes">12345</phone>
<address>Raleigh</address>
</person>

Here we have defined a method_missing method and it handles any undefined method and adds the name of the method to the XML markup that is being built. Code blocks are used to capture the nested nature of the XML. The result is a very natural way to programmatically generate XML markup. Also the cumbersome task of closing the tags and escaping rules are taken care of for us.

* Accessors
The inversion of the builder pattern is to use a parser that goes through the XML document and then allow access to the elements by using method_missing.

* Test Helpers
Different kind of test helpers can be created using method_missing. Many of the open source Ruby projects implementations of method missing are found in the tests.

=='''Conclusion'''==
method_missing is a very powerful feature of Ruby and as is the way with powerful things it can help you a great deal if used properly but it can make things a lot harder for you if implemented incorrectly. It is a kind of a feature which should be used sparingly, if not at all. And there are things that needs to be taken into consideration, as mentioned in the Key Points section above, if method_missing is to be implemented.

=='''References'''==
<references/>

=='''Further Suggested Reading'''==
*http://www.rubyinside.com/
*https://www.youtube.com/watch?v=SAEiCkixrdE&feature=relmfu
*http://blog.jayfields.com/2008/02/ruby-replace-methodmissing-with-dynamic.html
*http://liquiddevelopment.blogspot.com/2006/04/twisting-and-shaping-dsls-using-ruby.html
*http://blog.rubybestpractices.com/posts/gregory/031-issue-2-method-lookup.html
*http://phrogz.net/RubyLibs/RubyMethodLookupFlow.pdf(Diagram)

CSC/ECE 517 Fall 2012/ch1 1w22 an

2012-09-20T03:09:05Z

Nloya:

=='''Introduction<ref>http://rubylearning.com/satishtalim/ruby_method_missing.html</ref>'''==
A method that belongs to a class is called by creating an object of the class and passing the method name to the object as a message. The object then looks up the [http://www.madebydna.com/all/code/2011/06/24/eigenclasses-demystified.html method lookup path] and tries to match the called method with the defined methods in the class. On success, the method is executed and the result is returned.

If the object does not find a match in its method lookup, in normal circumstances the [http://www.ruby-doc.org/core-1.9.3/NoMethodError.html NoMethodError Exception] is raised .

In cases where the user wants to handle the methods which are not defined but are still called, “method_missing” can be defined and the user can handle the methods as he/she sees fit.

=='''Format for Defining method_missing'''==

=> def method_missing(m,*args,&block)

(i) '''m->''' accepts the symbol/name of the undefined method (ii) '''*args->''' accepts the array of arguments passed in the method call (iii) '''&block->'''accepts a block passed to the method

=='''Ruby Method Lookup Flow'''==
When the object of a class receives a method name to be executed, the following steps are carried out for matching and executing the method:

*First, the object looks in its own [http://docs.oracle.com/javase/tutorial/java/javaOO/classvars.html instance methods].
*Second, it looks in the list of instance methods that all objects of that class share.
*Third, in each of the included [http://www.tutorialspoint.com/ruby/ruby_modules.html modules] of that class, in reverse order of inclusion.
*Fourth, it looks in that class’s superclass.
*Fifth, in the superclass’s included modules, all the way up until it reaches the class Object.
*Sixth, if it still can’t find a method, the very last place it looks is in the [http://linux.die.net/lkmpg/x40.html Kernel module], included in the class Object.
*Finally, it calls method_missing (if defined in the class), else throws up the NOMethodError exception.

This entire tracing that the object does is the method lookup path.

=='''Examples'''==
===Calling Defined and Undefined Methods===

class A // creating a class 'A'
def say // defining a method 'say'
puts " say Hi " // body of method say
end
end

Creating the object of the class

a=A.new // object of the class
=> #<A:0x2a082e0> //object id

Calling the defined method

a.say // defined method
=> say Hi // returned result

Calling the undefined method

a.sayhi // undefined method sayhi
NoMethodError: undefined method `sayhi' for #<A:0x2a082e0> // the NoMethodError is raised

===method_missing Implementation<ref>http://www.thirdbit.net/articles/2007/08/01/10-things-you-should-know-about-method_missing/</ref>===

class A
def say
puts " say hi "
end
def method_missing(m,*args,&block) // defining method_missing
puts " This method does not exist" // body of method_missing
end
end

Calling a method that is not defined

a=A.new
a.sayhi // calling the undefined method sayhi with no arguments
=> This method does not exist // this result returned when method_missing is executed

When the object 'a' traces its method lookup path for a matching method 'sayhi', upon failure it resorts to method_missing and the body of method_missing is executed.

Sometimes when a class has many methods that do generally the same kinds of functionality, and the programmer is not sure in advance which methods the user will call since there are so many of them, and all of them are similar, writing code for all of the methods seems futile. In these situations method_missing can be defined to take care of these cases. The below 'Generic Handler' example implements this.

===Passing Parameters to an Undefined Method Call===

class A
def add(a,b)
a+b
end
def method_missing(name,*args,&block) // the method_missing is defined and the *args parameter accepts all the parameters passed during
the method call
puts “You have typed the method name wrong and these were the parameters passed ; #{args[0]}, #{args[1]}”
end
end

The passed parameters are stored in the array 'args' and can be accessed like a normal array

Calling the defined method

a.add(1,2) // calling the defined method add and passing the parameters (1,2)
=> 3 // result

Calling the undefined method

a.adds(4,2) // calling the undefined method adds and passing the parameter (4,2)
=> You have typed the method name wrong and these were the parameters passed; 4, 2

The user made a genuine mistake by typing 'adds', but this method is not defined. When the 'adds' method with parameters is called, the object 'a' tries to match the method in the method lookup path. Upon failure it invokes method_missing, the args are passed, stored in the array 'args' and the body of method_missing is executed.

===Converting Numbers from Roman Representation to Integer Representation<ref>http://courses.ncsu.edu/csc517/common/lectures/notes/wk2.pdf</ref>===
class Roman
DIGITS = {'I'=>1,'V'=>5,'X'=>10,'L'=>50,'C'=>100,'D'=>500,'M'=>1000,}
def roman_to_integer(roman_string)
last = nil
roman_string.to_s.upcase.split(//).reverse.inject(0) do
|memo, digit|
if digit_value = DIGITS[digit]
if last && last > digit_value
memo -= digit_value
else
memo += digit_value
end
last = digit_value
end
memo
end
end

def method_missing(method)
str=method.id2name
roman_to_integer(str)
end
end

Calling the undefined methods

r= Roman.new
r.vii
r.xxix
r.xxiv
r.xxvi

The Output

=> 7
=> 29
=> 24

===method_missing to Log Method Calls<ref>http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2007/wiki1b_2_22</ref>===
Another application that makes use of method_missing could be a simple logger used for debugging purposes. Many times, it may be required to log the trace of called methods and provide information such as: called method-name, arguments, return type. It can be tedious to repeat this part of code in every method. A simple solution to this problem can be obtained using method_missing as:

class SimpleCallLogger
def initialize(o)
@obj = o
end
def method_missing(methodname, *args)
puts "called: #{methodname}(#{args})"
a = @obj.send(methodname, *args)
puts "\t-> returned: #{a}"
return a
end
end

This program makes use of method_missing in a way that it wraps around called method to output the logging information on entry and on exit, it logs the return type. Further, method_missing intercepts the method call and forward it to internal object with ‘send’ method of ruby. Hence, this use of method_missing acts as wrapper.

===Generic Handler===
class NoBar
def method_missing(methodname, *args)
define_method(:bar) if "bar" == methodname.to_s
define_method(:nobar) if "nobar" == methodname.to_s
end
end

This is an example of using method_missing as a generic handler to handle when a calling method is not exist. You can use missing_method to dynamically create a method at a runtime.

=='''Advantages of method_missing'''==

*In addition to specifying the error messages for the undefined methods, method_missing provides a more dynamic behavior in the programming environment.
*If we are unfamiliar with the usage of the objects we created, then using method_missing is a good technique.
*Handles problems at runtime.
*Define's a generic method_missing and handle's any undefined method, a big advantage over Java. In Java, when you call an undefined method, the program will not compile.
*method_missing falls under the general technique of [http://en.wikipedia.org/wiki/Metaprogramming meta-programming]. Employ meta-programming in missing_function to write an another function to handle the call.

=='''Disadvantages of method_missing'''==
*Slower than conventional method lookup. Simple tests indicate that method dispatch with method_missing is at least two to three times as expensive in time as conventional dispatch.

*Since the methods being called never actually exist—they are just intercepted at the last step of the method lookup process—they cannot be documented or introspected as conventional methods can.

*method_missing restricts compatibility with future versions of an [http://en.wikipedia.org/wiki/Application_programming_interface API]. Introducing new methods in a future API version can break users' expectations.

=='''Key Points'''==

*In the following example, if within method_missing() we define an undefined method.

class A
@@i = 0
def method_missing(method_id)
puts "In Method Missing #{@@i}"
@@i += 1
self.fun
end
end

a = A.new
a.foo

Output

The result is a 'stack level too deep' error.

When the 'foo' method is called, after no method match the method_missing is run and this block has a method “self.fun” that is undefined. Here when the program execution encounters 'self.fun' it once again calls method_missing. This goes on in an endless loop till the stack memory is full.

*Ruby knows method_missing( ) exists, because it's a private instance method of 'BasicObject' that every object inherits. The BasicObject#method_missing( ) responds by raising the NoMethodError. Overriding this method_missing( ) allows you to call methods that don't really exist.

*If method_missing is only looking for certain method names, don't forget to call the [http://en.wikibooks.org/wiki/Java_Programming/Keywords/super super] keyword if you haven't found what you're looking for, so that the other superclass' method_missing can handle it.

*[http://www.prateekdayal.net/2007/10/16/rubys-responds_to-for-checking-if-a-method-exists/ obj.respond_to?] function returns 'true' if the obj responds to the given method. So if you want to know whether your class will respond to a function you can use respond_to? to know the answer. But if method_missing() is used, the output may not be what you expect.

class A
def method_missing(method_id)
puts "In method_missing"
end
end

a = A.new
puts a.respond_to?(:foo)
a.foo

Output
false
In method_missing

=='''Similar functionality in other languages'''==
Method missing, one of the dynamic features of Ruby, is not a feature that is unique to Ruby. It exists in Smalltalk, Python, Groovy, some Javascripts and most CLOS (Common Lisp Object System)extensions. In this section we look at the few such similar implementations in other languages. The table below gives different ways the functionality related to method_missing is handled in other languages.<ref>http://olabini.com/blog/2010/04/patterns-of-method-missing/</ref>

'''Construct''' '''Language '''
AUTOLOAD Perl
AUTOSCALAR, AUTOMETH, AUTOLOAD... Perl6
__getattr__ Python
method_missing Ruby
doesNotUnderstand Smalltalk
__noSuchMethod__(17) CoffeeScript, JavaScript
unknown Tcl
no-applicable-method Common Lisp
doesNotRecognizeSelector Objective-C
TryInvokeMember(18) C#
match [name, args] { ... } E
the predicate fail Prolog
forward Io
Table Reference<ref>http://stackoverflow.com/questions/2865865/are-there-equivalents-to-rubys-method-missing-in-other-languages</ref>

*'''_getattr_ implementation in Python'''<ref>http://docs.python.org/reference/datamodel.html?highlight=__getattr__#object.__getattr__</ref>

object.__getattr__(self,name)

This method is called when an attribute lookup has not found the attribute in the usual places i.e. it is not an instance attribute nor is it found in the class tree for self. name is the attribute name. This method should return the (computed) attribute value or raise an AttributeError exception.

class Roman(object):
def roman_to_int(self, roman):
# implementation here
end

def __getattr__(self, name):
return self.roman_to_int(name)
end

>>> r = Roman()
>>> r.iv
4

*'''doesNotUnderstand in Smalltalk language'''<ref>http://c2.com/cgi/wiki?DoesNotUnderstand</ref>

In SmalltalkLanguage When a receiver is asked to perform a method that is unknown to it, then a run-time complaint is issued which is #doesNotUnderstand.
When a Smalltalk object is sent a message for a method it has not defined, the runtime system turns the message-send into an object and sends #doesNotUnderstand: to the original receiver with this message-send object as argument. By default the #doesNotUnderstand: method raises an exception, but the receiver can override it and implement it in a way that he sees fit.

*'''Other languages'''
JavaScript also has a method which has an implementation similar to that of method_missing and that is "noSuchMethod". The limitation of this method is that it is only supported by Firefox/Spidermonkey.

Similarly, Perl has an AUTOLOAD method which works on subroutines & class/object methods.

=='''Conclusion'''==
method_missing is a very powerful feature of Ruby and as is the way with powerful things it can help you a great deal if used properly but it can make things a lot harder for you if implemented incorrectly. It is a kind of a feature which should be used sparingly, if not at all. And there are things that needs to be taken into consideration, as mentioned in the Key Points section above, if method_missing is to be implemented.

=='''References'''==
<references/>

=='''Further Suggested Reading'''==
*http://www.rubyinside.com/
*https://www.youtube.com/watch?v=SAEiCkixrdE&feature=relmfu
*http://blog.jayfields.com/2008/02/ruby-replace-methodmissing-with-dynamic.html
*http://liquiddevelopment.blogspot.com/2006/04/twisting-and-shaping-dsls-using-ruby.html
*http://blog.rubybestpractices.com/posts/gregory/031-issue-2-method-lookup.html
*http://phrogz.net/RubyLibs/RubyMethodLookupFlow.pdf(Diagram)

CSC/ECE 517 Fall 2012/ch1 1w22 an

2012-09-20T02:44:42Z

Nloya:

CSC/ECE 517 Fall 2012/ch1 1w22 an

2012-09-20T02:43:38Z

Nloya:

CSC/ECE 517 Fall 2012/ch1 1w22 an

2012-09-15T02:23:55Z

Nloya:

'''method_missing in Ruby:'''

=='''Introduction<ref>http://rubylearning.com/satishtalim/ruby_method_missing.html</ref>'''==
A method of a class is called by creating an object of the class and passing the method name to the object as a message. The object then looks up into its [http://www.madebydna.com/all/code/2011/06/24/eigenclasses-demystified.html method lookup path] and tries to match the called method with the defined methods in the class. On success, the method is executed along with the parameters passed and the result is returned.

If the object does not find a match in its method lookup, in normal circumstances the [http://www.ruby-doc.org/core-1.9.3/NoMethodError.html NoMethodError Exception] is raised .

In cases where the user wants to handle the methods which are not defined but still called, “method_missing” can be defined and the user can handle the methods as he/she sees fit.

=='''Format for defining method_missing'''==

=> def method_missing(m,*args,&block)

(i) '''m->''' accepts the symbol/name of the undefined method (ii) '''*args->''' accepts the array of arguments passed in the method call (iii) '''&block->'''accepts a block passed to the method

=='''Different types of methods'''==
When the object of a class receives a method name to be executed, the following steps are carried out for matching and executing the method:

*First, the object looks in its own [http://docs.oracle.com/javase/tutorial/java/javaOO/classvars.html instance methods].
*Second, it looks in the list of instance methods that all objects of that class share.
*Third, in each of the included [http://www.tutorialspoint.com/ruby/ruby_modules.html modules] of that class, in reverse order of inclusion.
*Fourth, it looks in that class’s superclass.
*Fifth, in the superclass’s included modules, all the way up until it reaches the class Object.
*Sixth, if it still can’t find a method, the very last place it looks is in the [http://linux.die.net/lkmpg/x40.html Kernel module], included in the class Object.
*Finally, it calls method_missing (if defined in the class), else throws up the NOMethodError exception.

This entire tracing that the object does is the method lookup path.

=='''Examples'''==
===Calling defined and undefined methods===

class A // creating a class 'A'
def say // defining a method 'say'
puts " say Hi " // body of method say
end
end

Creating the object of the class

a=A.new // object of the class
=> #<A:0x2a082e0> //object id

Calling the defined method

a.say // defined method
=> say Hi // returned result

Calling the undefined method

a.sayhi // undefined method sayhi
NoMethodError: undefined method `sayhi' for #<A:0x2a082e0> // the NoMethodError is raised

===method_missing implementation<ref>http://www.thirdbit.net/articles/2007/08/01/10-things-you-should-know-about-method_missing/</ref>===

class A
def say
puts " say hi "
end
def method_missing(m,*args,&block) // defining method_missing
puts " This method does not exist" // body of method_missing
end
end

Calling a method that is not defined

a=A.new
a.sayhi // calling the undefined method sayhi with no arguments
=> This method does not exist // this result returned when method_missing is executed

When the object 'a' traces its method lookup path for a matching method as 'sayhi', upon failure it resorts to method_missing and the body of method_missing is executed. 'method_missing' is the last resort.

Sometimes when a class has many methods that do generally the same kinds of things, and the programmer is not sure in advance which methods the user will call since there are so many of them, and they are all so similar, writing code for all of them seems futile. In these situations method_missing can be defined to take care of different cases. The below 'Generic Handler' example implements this.

===passing parameters to an undefined method call===

class A
def add(a,b)
a+b
end
def method_missing(name,*args,&block) // the method_missing is defined and the *args parameter accepts all the parameters passed during
the method call
puts “You have typed the method name wrong and these were the parameters passed ; #{args[0]}, #{args[1]}”
end
end

The passed parameters are stored in the array 'args' and can be accessed like a normal array

Calling the defined method

a.add(1,2) // calling the defined method add and passing the parameters (1,2)
=> 3 // result

Calling the undefined method

a.adds(4,2) // calling the undefined method adds and passing the parameter (4,2)
=> You have typed the method name wrong and these were the parameters passed; 4, 2

The user made a genuine mistake by typing 'adds', but this method is not defined. When the 'adds' method with parameters is called, the object 'a' tries to match the method in the method lookup path. Upon failure it invokes method_missing, the args are passed, stored in the array 'args' and the body of method_missing is executed.

===converting numbers from roman representation to integer representation<ref>http://courses.ncsu.edu/csc517/common/lectures/notes/wk2.pdf</ref>===
class Roman
DIGITS = {'I'=>1,'V'=>5,'X'=>10,'L'=>50,'C'=>100,'D'=>500,'M'=>1000,}
def roman_to_integer(roman_string)
last = nil
roman_string.to_s.upcase.split(//).reverse.inject(0) do
|memo, digit|
if digit_value = DIGITS[digit]
if last && last > digit_value
memo -= digit_value
else
memo += digit_value
end
last = digit_value
end
memo
end
end

def method_missing(method)
str=method.id2name
roman_to_integer(str)
end
end

Calling the undefined methods

r= Roman.new
r.vii
r.xxix
r.xxiv
r.xxvi

The Output

=> 7
=> 29
=> 24

===method_missing to log method calls<ref>http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2007/wiki1b_2_22</ref>===
Another application that makes use of method_missing could be a simple logger used for debugging purposes. Many times, it may be required to log the trace of called methods and provide information such as: called method-name, arguments, return type. It can be tedious to repeat this part of code in every method. A simple solution to this problem can be obtained using method_missing as:

class SimpleCallLogger
def initialize(o)
@obj = o
end
def method_missing(methodname, *args)
puts "called: #{methodname}(#{args})"
a = @obj.send(methodname, *args)
puts "\t-> returned: #{a}"
return a
end
end

This program makes use of method_missing in a way that it wraps around called method to output the logging information on entry and on exit, it logs the return type. Further, method_missing intercepts the method call and forward it to internal object with ‘send’ method of ruby. Hence, this use of method_missing acts as wrapper.

===Generic Handler===
class NoBar
def method_missing(methodname, *args)
define_method(:bar) if "bar" == methodname.to_s
define_method(:nobar) if "nobar" == methodname.to_s
end
end

This is an example of using method_missing as a generic handler to handle when a calling method is not exist. You can use missing_method to dynamically create a method at a runtime.

=='''Advantages of method_missing'''==

*In addition to specifying the error messages for the undefined methods, method_missing provides a more dynamic behavior in the programming environment.
*If we are unfamiliar with the usage of the objects we created, then using method_missing is a good technique.
*Handles problems at runtime.
*Define's a generic method_missing and handle's any undefined method, a big advantage over Java. In Java, when you call an undefined method, the program will not compile.
*method_missing falls under the general technique of [http://en.wikipedia.org/wiki/Metaprogramming meta-programming]. Employ meta-programming in missing_function to write an another function to handle the call.

=='''Disadvantages of method_missing'''==
*Slower than conventional method lookup. Simple tests indicate that method dispatch with method_missing is at least two to three times as expensive in time as conventional dispatch.

*Since the methods being called never actually exist—they are just intercepted at the last step of the method lookup process—they cannot be documented or introspected as conventional methods can.

*[http://blog.jayfields.com/2008/02/ruby-dynamically-define-method.html Dynamic methods] must go through the method_missing method, the body of that method can become quite large if there are many different aspects of the code that needs to add methods dynamically.

*method_missing restricts compatibility with future versions of an [http://en.wikipedia.org/wiki/Application_programming_interface API]. Introducing new methods in a future API version can break users' expectations.

=='''Key Points'''==
*Ruby knows method_missing( ) exisits, because it's a private instance method of 'BasicObject' that every object inherits. The BasicObject#method_missing( ) responds by raising the NoMethodError. Overriding this method_missing( ) allows you to call methods that don't really exist.

*If method_missing is only looking for certain method names, don't forget to call the [http://en.wikibooks.org/wiki/Java_Programming/Keywords/super super] keyword if you haven't found what you're looking for, so that the other superclass' method_missing can handle it.

*[http://www.prateekdayal.net/2007/10/16/rubys-responds_to-for-checking-if-a-method-exists/ obj.respond_to?] function returns 'true' if the obj responds to the given method. So if you want to know whether your class will respond to a function you can use respond_to? to know the answer. But if method_missing() is used, the output may not be what you expect.

*Below class A defines only method method_missing() and no other method. When a new object of class A tries to access a method say 'foo', the respond_to? will return the value 'false'. When you actually try to implement it using “a.foo”, the code will get executed, courtesy of method_missing(). Even though the respond_to? says that you cannot access 'foo' method using object of class A, if you have method_missing() defined, you can access the method.

class A
def method_missing(method_id)
puts "In method_missing"
end
end

a = A.new
puts a.respond_to?(:foo)
a.foo

Output
false
In method_missing

*If within method_missing() we define an undefined method.

class A
@@i = 0
def method_missing(method_id)
puts "In Method Missing #{@@i}"
@@i += 1
self.fun
end
end

a = A.new
puts a.respond_to?(:foo) // just checking whether the receiver 'a' responds to the method 'foo'

a.foo

Output

The result is a 'stack level too deep' error.

When the 'foo' method is called, after no method match the method_missing is run and this block has a method “self.fun” that is undefined. Here when the program execution encounters 'self.fun' it once again calls method_missing. This goes on in an endless loop till the stack memory is full.

=='''References'''==
<references/>

=='''Further Suggested Reading'''==
*http://www.rubyinside.com/
*https://www.youtube.com/watch?v=SAEiCkixrdE&feature=relmfu
*http://blog.jayfields.com/2008/02/ruby-replace-methodmissing-with-dynamic.html
*http://liquiddevelopment.blogspot.com/2006/04/twisting-and-shaping-dsls-using-ruby.html
*http://blog.rubybestpractices.com/posts/gregory/031-issue-2-method-lookup.html
*http://phrogz.net/RubyLibs/RubyMethodLookupFlow.pdf