Selecting new UseCases


As you can see in my friend David’s blog, we had a small change in our final project (and for small I mean a whole new project). The idea of the RaspLapse was kind of obsolete. That’s why we decided to select a new project; this new project we had had developed this semester as a project for a government contest, but we chose to begin again giving it a more objected-oriented path, so that it adjust to the requests of the final project.

Due to it is well… a new project, it needs to have it respective Use Cases defined. In this blog post I’m going to expose the Use Cases of our new project called “Bot.e”:

We defined nine Use Cases in total were there are explained all the tasks that the different actors or users of the app must do in order to have a good performance of the app.

  • Use Case #1

Title: Downloading the app

Actor: User

Description: Enter to the AppStore or Google Store, search for the app “Bot.e”, and install it.

  • Use Case #2

Title: Register

Actor: User

Description: Open the app, create a new username and select a new password. Fill the information that is request in order to register as a new user.

  • Use Case #3

Title: Access the camera

Actor: App, User.

Description: The app will request the phone to access the camera. The user may click ‘accept’ button in the pop-up window to accomplish this process.

  • Use Case #4

Title: Home page

Actor: App

Description: When the user opens the app, he/she has to see the home page in his/her phone screen. The app has to show the ‘scan’ button, the ‘store’ button, the ‘my coupons’ button, and the display of points. Also it has to show the official logo of the app, and the layout with the official colors.

  • Use Case #5

Title: Scanner

Actor: User, Phone, App.

Description: When a QR code is displayed, the user has to open the app, and click the ‘scan’ button. The app has to open the phone’s camera. When the camera is open, the user has to put the phone in front of the QR code, so that the app can scan it through the camera.

  • Use Case #6

Title: Store

Actor: App, User.

Description: If the user decides to click the ‘store’ button, the app has to display the store page. In this store page, the different options of offers will be shown.

  • Use Case #7

Title: Display Points

Actor: App

Description: As it is mentioned in Use Case # 4, when the user opens the app, in the home page there must be a display showing the points that the user has accumulated. The display of points has to update immediately every time the user scan a QR code.

  • Use Case #8

Title: Alert messages

Actor: App

Description: The app must pop-up alert messages in many occasions. The app displays an alert message when the user wants to buy something in the store, but he/she does not have enough points. The app displays an alert message when the user attempt to buy an item in the store just to make sure that is the correct item de user wants, and also there is an alert message when he/she successfully buys an item in the store. The app displays an alert message when the user scans a QR code successfully. Finally, the app displays an alert message when the user tries to scan an incorrect QR code.

  • Use Case #9

Title: Buy & exchange coupons

Actor: User, App.

Description: As described in Use Case #6, the user has to enter the ‘store’ in order to buy an item. The user has to select the item he/she wants by clicking the button of the selected item. The user has to confirm that he/she wants to buy that specific item. When exchanging the bought item, the user has to enter to ‘My coupons’, select the item he/she wants to exchange, and the app would display a code bar that would be processed by the establishment’s staff where the user is trying to exchange the item.



Last argue about University


plan de carrera

I have read Joel Spolsky’s blog post about the advice he gives for Computer Science students in order to have more chances to succeed in their careers.  Joel writes down seven pieces of advice, almost all related to academic stuff, in which he encouraged students to not only center on programming stuff, but also on other topics that may not seem as interesting as computer science itself.

Here are the seven pieces of advice Joel talks about:

  1. Learn how to write before graduating.
  2. Learn C before graduating.
  3. Learn microeconomics before graduating.
  4. Don’t blow off non-CS classes just because they’re boring.
  5. Take programming-intensive courses.
  6. Stop worrying about all the jobs going to India.
  7. No matter what you do, get a good summer internship.

Last semester I had a course called “Introducción a la Electrónica” taught by Electronic Engineering director Eduardo Espadas. Here I was asked to elaborate an academic plan for my years at Tec de Monterrey. In this ‘plan de carrera’ I enlisted my goals for every semester I’m going to attend here at Tec. One of my ideas was that for every semester I would try something new, I would register myself in a new course that has nothing to do with electronics. Some of my plans are: take the Legal English course (I swear I had this idea long before reading Joel’s advice of learning how to write); enter to cultural courses such as guitar, cuisine, etc; learn another language (currently I’m in German courses); and many other plans for the rest of my years in University.

Clearly I agree with most of the ideas of Joel, but of course there must be at least one thing that I don’t share with him, and this thing is the importance he gives to the GPA. This disagreement has nothing to do with my grades, I have a very good GPA; the real reason is that I think that there are things way more important than the GPA. I know that the GPA is very important, and in some way it tells many things about level of responsibility and dedication of a student. The thing is that if in this time of my life I became an employer of a company, I would definitely give more importance to extra academic important achievements than to the GPA of a potential great engineer.

Of course we all have different points of view, and not always we are going to agree absolutely everything about something, but what its a fact is that if you want to be a great engineer whom the company’s fight between them for you, conforming with taking only classes of your academic area is just not enough.

Overloading vs Overriding


Continuing with the blog posts about the mastery topics, we get to Overloading and Overriding. These two concepts are related to the use of methods in classes, but they differ in many things.

Overloading is the action of using two methods with THE SAME NAME & AND IN THE SAME CLASS, but the ARGUMENTS & THE RETURN TYPE are different. For example we have this piece of code:

public class Overload {

public int sum(int x, int y) {
return x + y;


public double sum(double x, double y, double z) {
return x + y + z;


We have a couple of methods in the Overload class, both called ‘sum’, but the first has a return type ‘int’, and receive two variables ‘int’; while the second one has a return type ‘double’, and receives three variables ‘double’. In Overloading, Inheritance and Polymorphism are not involve.

The we have Overriding, that is some kind the opposite of Overloading. Overriding occurs when you have a SupperClass  with a method: int multiply(). Then you have a SubClass with another method called ‘multiply’. For it to be an Overriding, the method of the subclass MUST have the same ARGUMENT & same RETURN TYPE. In this case inheritance and polymorphism are clearly involved in this action.

All this info was provided by a Youtube video posted by EJ MEDIA. Here it is:


CRC Cards

CRC Cards… CRC Cards is a method used for modelling the app, and establish the responsibilities of every object of the app, and their main collaborators. CRC cards are made in index cards (yes, by hand) where at the very top is written the name of the class. Then there are written the responsibilities or actions that the mentioned class has to perform. A line is drawn at 2/3’s of the index card, and in the right side of that line, the main collaborators of this class are shown. The collaborators are every other object that has to interact with this class, the relationship between the class, and other classes.

CRC cards are used to distribute responsibilities between the objects of the app, and to have a first idea of the interactions that have to exist between object in order to achieve a good performance of the app.

Here I leave the structure of a CRC card:


Delegation: as interesting as merchants selling apparel in ‘tianguis’


In preparation for the exam, here is my blog post about mastery topic: delegation. This term may seem as a tough to understand one, but actually is a concept that we as humans practice everyday in almost every situation we have.

I searched in a bunch of web pages trying to understand the concept of delegation; I searched in Wikipedia, in some Community web pages, and plenty of other web pages, and I finally, I got to a final definition that I like a lot: delegation is to ask someone else to help you. In this case (in an POO environment) the definition its transformed to ‘an object that when receives a request, it passes this request to a second object that is more specialized in this task’. As I said it before, humans tend to do this a lot in their daily lives. When someone receives a bunch of tasks, the first thing he/she does is ask for help; he/she delegates part of their tasks to someone else so that the amount of work can be less stressful or less complicated.

I found a number of good examples in code that explain how delegation is performed in code. Something important to mention is that when an object delegates its request to another object, the first object passes its request as well as itself as a parameter to the other object, so the later can complete the task.

The clearer example was published by Mladen Prajdic (cool name!) in a community web page called ‘Stackoverflow’. It’s important to notice the way that a delegation process is declared, and how it is transferred to the object #2 so that this obj#2 inherit the necessary methods to complete the requested task.

delegate void delMyDelegate(object o);
private void MethodToExecute1(object o)
    // do something with object
private void MethodToExecute2(object o)
    // do something else with object
private void DoSomethingToList(delMyDelegate methodToRun)
    foreach(object o in myList)
public void ApplyMethodsToList()

Its important to see how the declaration of a delegation is made,