Mi segunda reflexión parcial


¡Hola! Sé que es raro que esté escribiendo en español, pero tengo varios motivos muy buenos para esto. Primero, por ser mi lengua natal, podré expresarme con más facilidad y podré dar a entender cosas que tal vez en inglés no sabría cómo; lo que me lleva a mi siguiente punto: para la reflexión del primer parcial la mayor parte del contenido fue una breve recapitulación de los masteries que había hecho hasta ese entonces, pero en retrospectiva siento que no aportaba la gran cosa. En español podré volver a hablar sobre estos temas, pero con una perspectiva diferente, pues claro, en dos idiomas distintos explicaré las cosas de manera distinta. Por último, y definitivamente no la razón principal, porque me es muchísimo más fácil escribir y escribir cosas en español, lo que me viene muy bien para esta entrega antes de que llegue la deadline final.

“Doing the bird dance.” flickr photo by Bernard Spragg https://flickr.com/photos/volvob12b/9418456505 shared into the public domain using (CC0)

Ahora bien, dejando todos estos detalles de lado, me gustaría copiar un poco el formato que usé para mi primera entrega y explicar qué fue lo más relevante que me ocurrió en el parcial respecto a mis clases en general.
Primero, los proyectos y exámenes comenzaron a ser más pesados, me cansaba más y necesitaba esforzarme bastante para poder cumplir con todos mis deberes. El problema aquí fue que para mis masteries no tenía una deadline tan ajustada, por lo que comencé a descuidar esa parte un poco. Sí redactaba alguno de vez en cuando, pero no los llegué a publicar en su momento pues no lo vi necesario. Por cierto, a partir de mi última entrega del primer parcial creé un documento en Google Docs en donde he estado trabajando en todas estas entradas de blog. Me ha sido muy útil tenerlo todo junto de este modo.

Una cosa de la que apenas me di cuenta conforme escribía el párrafo anterior es que había una prueba que quería realizar para escribir mis masteries, pero creo que ya es un poco tarde para eso. Hace un par de semanas leí el encabezado de un artículo que decía que, cuando estás en blanco y no se te ocurre qué escribir o redactar mientras trabajas en cualquier tipo de texto, cambiar la fuente de tu escrito a Comic Sans resulta muy útil para que las ideas fluyan. Esto probablemente sea un simple efecto placebo, pero de todos modos moría de ganas por intentar algo así. Supongo que para la reflexión final tendré que ponerlo a prueba.

Una última cosa que quiero comentar antes de comenzar a hablar de los masteries de este parcial está relacionada con mis fuentes de información. Una cosa que he hecho desde siempre cuando necesito investigar algún tema para tareas o proyectos es buscar dicho tema en Wikipedia para darme una idea general de qué es lo que estoy buscando y ser más selectivo con mi información, pero como dicho sitio siempre ha sido fuertemente desprestigiado por muchos maestros procuro no incluir páginas de Wikipedia en mis referencias. Últimamente me he percatado de que Wikipedia realmente tiene información muy completa, está bien referenciada y siempre están las versiones en otros idiomas para ver todavía más información al respecto. Incluso para este blog he sacado mucha información de Wikipedia, pero no agrego los hipervínculos respectivos. Comenzaré a hacerlo porque empiezo a ver que Wikipedia es una herramienta que también vale la pena consultar.

“Magnify!” flickr photo by robad0b https://flickr.com/photos/robadob/523367560 shared under a Creative Commons (BY-SA) license

Por último, también relacionado a mis referencias, para un par de masteries obtuve datos e información de distintos foros y páginas de pregunta-respuesta. Sé que no siempre es lo ideal, pero para algunos de los temas que necesité ver en este parcial solo conseguía datos y hechos, pero en muchas ocasiones necesitaba de algún punto de vista ajeno para ampliar mi panorama y conocer un poco más, porque al fin y al cabo, la experiencia es una de las mejores fuentes de conocimiento que hay. Quise tomar varias perspectivas para generar la mía propia.

Bueno, dicho todo esto, repasemos los masteries:

Patrones de diseño

Este tema en particular es uno que conocía ya desde hace un año gracias a la clase de Ingeniería de Software. De hecho, me tocó hablar sobre él, pero si soy completamente sincero, en ese entonces no le entendía del todo. ¡Pero eso cambió! Ahora tengo una visión más clara de los patrones de diseño y de su utilidad.

“pattern” flickr photo by walmarc04 https://flickr.com/photos/ioachimphotos/29693349040 shared into the public domain using (PDM)

Estos patrones de diseño son herramientas que guían a los desarrolladores a darle una mejor implementación a las soluciones de sus problemas. Son respuestas ya estudiadas y que son consideradas como mejores prácticas por alguna razón. Los creadores de este concepto (y de 23 de los patrones) son conocidos como Gang of Four. Ellos también decidieron la clasificación de los patrones según su funcionamiento en creacionales (controlan creación e instanciación de objetos), estructurales (definen relaciones entre objetos) y de comportamiento (establece cómo se comunican e interactúan dos o más objetos).

La comparación que decidí hacer con este tema fue la de intentar bloquear la luz del Sol. Hay quienes lo hacen con la mano, hay quienes lo hacen con alguna gorra o sombrero, hay quienes usan lentes para ello, pero todos están colocando algo que se interponga entre los ojos de uno y la luz solar. Los patrones de diseño funcionan de manera similar en el sentido de que no te dicen cómo conseguir tu objetivo, sino que solo te indican qué es lo que debes hacer.

Este tema es básico dentro del diseño de software, así que tiene mucho sentido que lo veamos en esta materia.

UML I y II

UML también es de esas cosas que conocemos en los primeros semestres de la carrera. Es una herramienta que hemos utilizado una y otra vez y aún así parece que todos estamos muy lejos de aprender todo lo que hay por saber al respecto.

En los masteries de UML el enfoque principal era explicar algunos de los diagramas manejados. Una de las cosas que logré aprender mientras investigaba este tema fue que la clasificación de los diagramas UML depende en una buena parte del componente primario que predomine.

“All You Need is Tools, Tools, Tools” flickr photo by cogdogblog https://flickr.com/photos/cogdog/49021347718 shared into the public domain using (CC0)

Aquí resumo muy brevemente los diagramas de los que llegué a hablar en sus respectivos masteries:

Diagrama secuencial: Su componente principal es la secuencia y se encarga de manejar interacciones entre entidades para llegar a una meta.

Diagrama de clase: Siento que ni siquiera necesito explicar este de nuevo.

Diagrama de objeto: Algo obsoleto, pero se encarga de manejar las instancias que surgen a partir de distintas clases.

Diagrama de paquetes: Agrupan varios elementos en uno. Un paquete, vaya.

Diagrama de estado: Parecido a un autómata, pues define estados y sus transiciones.

Diagrama de componente: Parecido en cierto sentido a los bloques de programación o a módulos de acción. Pueden intercambiarse y modificarse independientemente.

También hablé de GRASP y sus principios, pero la verdad es que el modelo que quiero comentar es el MVC. Verán, al principio no comprendía muy bien cómo funcionaba este modelo, pero justo hace un par de días estaba trabajando en un proyecto de Java donde precisamente este modelo fue el que me hizo la vida imposible. Estaba trabajando con Threads y buscaba dibujar sus actualizaciones con JTable, pero debido a la velocidad de los hilos y al funcionamiento del MVC, una excepción se arrojaba constantemente. La razón era que se modificaba el modelo, pero la vista no era notificada a tiempo antes de repintar, así que buscaba elementos inexistentes en el modelo.

En fin, UML es algo muy útil para el diseño y todo lo que implica ya lo digo en mi entrada original, así que les recomiendo mejor ir a ver esa.

Clases a tablas

Este tema fue uno de los que más se me facilitó entender y redactar. Las bases de datos pueden implementarse de muchas maneras, y con temas tan estudiados como lo son el paradigma orientado a objetos y las bases de datos relacionales, era claro que habría maneras muy sistematizadas de hacer la conversión de uno a otro. 

“Old ship planks” flickr photo by zsolt.palatinus https://flickr.com/photos/137424368@N06/26782878937 shared into the public domain using (PDM)

Esa parte fue muy sencilla de explicar y en la página original incluí un tutorial muy completo sobre cómo llevar a cabo ese proceso.

Afortunadamente, este semestre he estado llevando la materia de bases de datos avanzadas, en la que trabajamos con múltiples bases de datos no relacionales. C* y MongoDB son los mejores ejemplos que tengo para demostrar lo diferentes que son a los que siguen SQL. Gracias a esto, me fue un poco más sencillo entender la complicación de pasar clases a tablas no relacionales, la manera en que estas últimas se manejan y el hecho de que no siempre existen uniones hacen la translación una tarea difícil.

Mi comparación de este mastery me pareció muy apropiada. Pasar de texto a texto siempre es muy sencillo, pero cuando el formato destino va a cambiar radicalmente, muy probablemente se vaya a requerir de un esfuerzo mucho mayor para lograr un resultado de calidad comparable. Es justo lo que pasa con las conversiones contempladas en este tema.

Clases a código

Para el último tema comprendido dentro del segundo parcial utilicé una analogía con pintura y las distintas técnicas y estilos que existen. Me enfoqué en explicar algunas de las diferencias fundamentales entre algunos lenguajes de programación. 

“Classroom” flickr photo by cogdogblog https://flickr.com/photos/cogdog/46702870 shared into the public domain using (CC0)

(Qué curioso el nombre del autor de esta foto)

También hablé sobre los distintos paradigmas que son compatibles o no con ciertos lenguajes y qué implicaciones trae esto consigo al momento de querer hacer ciertas implementaciones.

Hablé sobre cómo es muy fácil implementar un diseño orientado a objetos en un lenguaje que soporte este paradigma, así que de esa parte no incluí mucho. La parte más extensa y que requirió de un poco más de investigación fue la de diseño orientado a objetos en un lenguaje no orientado a objetos. Claro que la conversión no sería tan sencilla, pero de acuerdo a lo que leí (porque nunca he necesitado hacer algo por el estilo por mi cuenta), es posible simular de cierta manera el comportamiento de las clases e instancias, pero que siempre habrá algunos detalles que simplemente no se podrán comparar con un lenguaje diseñado para OO.

Sigo sin entender por qué alguien haría algo así, la verdad.

Pero bueno, fuera de todos los temas vistos en el parcial y de todo el estrés que ha causado la escuela puedo comenzar a relajarme un poco más. La conclusión final del curso, mis opiniones y demás cosas por el estilo quiero incluirlas en mi reflexión final, es lo único que me falta para el blog y ya tengo pensadas algunas ideas.

Así que, por ahora, lo único que me queda por decir es que estoy muy feliz porque ya van a empezar las vacaciones. Daré un gran esfuerzo por escribir otra reflexión que se merezca aparecer en el Twitter de Ken Bauer.

“twitter” flickr photo by o.tacke https://flickr.com/photos/otacke/13970870674 shared into the public domain using (CC0)

Hasta la próxima.

ML ; NL: Lo chido viene en la reflexión final

It’s OOkay to fail these


If you are involved in the computing/software areas, you’ve definitely heard about the binary system. You probably also know that there are infinite ways of representing every number by changing the base of the representation. Binary, Octal, Decimal and Hexadecimal are some of the most common representations for numbers nowadays, each has their own advantages depending on what they are going to be used for. Either way, they are all different ways of doing the same kind of representation and can be used to perform the same operations.

“Numbers” flickr photo by cogdogblog https://flickr.com/photos/cogdog/2932900735 shared into the public domain using (CC0)

As I’ve been doing since I started this blog, I’ll be comparing the first paragraph to an OO topic. This time, I’ll explain the testing performed in OO languages and, as always, my focus will be Java. For the rest of this entry I’m assuming you already know basic concepts like classes or objects.

As I was doing my research for this entry I stumbled upon many different approaches to object oriented testing, and since I really don’t know which one’s best, I wanted to include all three of them. That’s why I mentioned the different numerical representations in the beginning: there are multiple ways of testing and all of them are valid. Of course, some are more detailed or strict than others, but they all serve the same purpose.

First, according to Minigranth, object oriented testing can be classified into three different categories depending on how extensive the actual tests are.

The first category is called Class testing, but is also known as Unit testing (which is actually the name I see the most). It consists in testing individual classes to look out for errors or bugs that help us decide whether our classes were implemented as they were designed or not.

The second type of test is Inter-class testing or Subsystem testing. This one is pretty easy to understand, since it only tests compatibility between modules or classes and makes sure everything works as it should.

Finally, there’s System testing. Which tests all of the classes as a whole unit and makes sure both functional and non-functional requirements are met.

This seems like an interesting way of testing, since it’s incremental and hence, more intuitive.

Second, Ambysoft has included a diagram that corresponds to each one of the steps of the Full Life Cycle Object-Oriented Testing Method (FLOOT). Unlike the previous classification, this approach is more like a series of steps that must be followed and repeated constantly. There are six different stages included in this cycle:

Requirements testing, analysis testing, architecture/design testing, code testing, system testing and user testing.

Each one of these steps involves making use of certain techniques to complete them. I’ll briefly explain the most common ones.

Model review. An inspection, which can be as informal or strict as one wishes.

Prototype review. Testers pretend to be in real situations and use the user cases to get through them.

Black-box testing. Verifies that certain inputs actually give us the expected outputs.

This one provides us with many tools for each of the steps, which it also gives. There are many options, so this can be useful when not sure of what to do. Since I didn’t list nearly as many techniques as in the original website, I’d suggest checking them out, because the information is pretty vast.

Finally, there’s another way of classifying testing methods for the OOP. This one was provided by EComputerNotes and revolves around a similar idea to the first one and is also classified into three different categories.

State-based testing. Verifies whether the methods of a class are interacting properly with each other. Finite-state machines are often used for this, since they allow to represent different states and their transitions. Also that’s where the name comes from.

Fault-based testing. Determines a set of plausible faults and detects the possibility of bugs in the code. The testing is mainly done to find these errors in the chosen implementation of the program. The effectiveness of this test depends heavily on the ability of the tester to detect possible bugs.

Scenario-based testing. Detects errors that are caused due to incorrect specifications and improper interactions among various segments of software. This is a common approach, since it’s really easy to think of how the system/program is supposed to be working, so coming up with the cases that lead to those situations is very easy too.

This last classification of testing focuses on more technical aspects, so these techniques may be more useful for formal reports, although the practicality of these methods could make it so they’re used for informal testing too.

Whatever classification you choose to follow, the important thing is to test your software. I’ve never seen a single person writing code and not testing it immediately afterwards. This is a crucial step in every sense, and I believe that’s also the reason for the high number of different methods, techniques and types of testing that exist. And that’s only considering the OOP! That’s really fascinating to me.

TL; DR: Just test your code, please.

Veridation & Valification


There are some words that many people get confused. Something effective successfully achieves its intention and something efficient does it with maximum productivity. If you affect something, then you’ve had an effect on it. Some people don’t know the differences between these pairs of words and don’t want to, their brains must have a problem if they’re thinking like that. 

“dsc04080.jpg” flickr photo by mlinksva https://flickr.com/photos/mlinksva/2754456925 shared into the public domain using (CC0)

I didn’t know this, but “verification and validation” (also known as “independent verification and validation”) is a common process in which a service, product or system is accepted after it has met all of its requirements and specifications. The same applies for software, but obviously, the implications are different, and for this entry I will try and explain what are the particularities of this process when applied to software, which is sometimes called software quality control.

I mentioned the similar words in the first paragraph because, even if verification and validation may sound similar, they’re not the same. I decided to include the other name for verification and validation that adds independent at the beginning because it’s there for a reason. It’s important to tell the difference between them before we even begin with the process itself, since they try to achieve different things. This website already provides us with definitions for both of this words AND with important points that each of them need for the V&V process.

Verification. Its objective is to ensure that the product is being built according to the requirements and design specifications. In other words, to ensure that work products meet their specified requirements. To know if we’ve fulfilled the objective we ask the question “Are we building the product right?”.

Validation. Its objective is to ensure that the product actually meets the user’s needs and that the specifications were correct in the first place. In other words, to demonstrate that the product fulfills its intended use when placed in its intended environment. To know if we’ve fulfilled the objective we ask the question “Are we building the right product?”.

Knowing these definitions may help you realize that there can be one without the other, but you must have in mind that both validation and verification are needed to ensure that a product passes quality control.

There are some activities that are usually related to the V&V process. I actually only found a few, but they seem to represent the majority of the whole thing. The one that seems more representative of the whole objective and, therefore, helps the most as an activity is testing.

Testing is often performed with test cases. In case you aren’t familiar with the, test cases are basically the expected outcomes for specific situations when using some application; they may include a detailed description of what steps to follow in order to get to certain point where the actual testing takes place. This tool is very useful, if done correctly it could actually help with both parts of the V&V process.

Other tools for the verification part may include reviews, walkthroughs and inspections, and they all can have different levels of rigor depending on how serious or formal the V&V process is.

The main obstacle for many organizations is how overwhelming it can be for them to correctly perform a strict verification and validation process. In reality, V&V can be somewhat simplified to be better understood, and this site has come up with five general steps that may be follow to meet basic requirements and still achieve great quality. Obviously the process isn’t THAT simple, but these steps are only intended to serve as a basic guide to at least know what’s supposed to be done through the process:

1. Create the validation plan. Helps identify the responsibilities for each of the participants and defines what has to be achieved, what criteria has to be met, what tools are to be used, and other similar things.

2. Define system requirements. Define what the system is supposed to do and classify all of it depending on what is specified in each requirement: resources, users, security, etc.

3. Create a validation protocol and test specifications. Create all of the tests to be performed in the next step as complete and detailed as possible.

4. Testing. Testing (do I even have to explain?)

5. Develop/revise procedures and final report. A final validation report is produced, reviewed, and approved. Its approval means the system is ready to be released.

In case the previous steps weren’t exactly what you expected, there are more possible interpretations! For instance, this webpage also lists some steps that may help with the V&V process, but this one has ten and rather than stating the activities that should be performed, it describes what kind of document or protocol should be completed by the end of each one. I won’t list any of that in this entry, but I definitely recommend checking it out.

This is yet another way of improving your software products by following certain steps and protocols and all of that stuff. For me, this process in particular can be very helpful for some people since it aims to answer to very clear and simple questions. That may be more than enough to make developers understand what the actual goal is.

TL; DR: Verification and validation are different things.

*Code* 👏 *review* 👏


Responsibilities and chores. Maybe just reading these words is enough to tire some people out, but we all understand that whether they’re exhausting or not, whether they’re many or just a few, whether you have to do them yourself or not, they’re required for us to have good/healthy lives. It’s the price to pay for a better outcome in the long-term.

“Bond cleaning” flickr photo by Elaine_Smith https://flickr.com/photos/155416046@N05/35473335420 shared into the public domain using (CC0)

As programmers and humans, we are bound to make some mistakes every now and then. We can prevent many of them thanks to the design phase of development, but writing the code itself is a different story. The way we implement certain functions, the way we manage our resources, the algorithms we come up with, among many other things, will not always be the most efficient. It’s important to periodically go through our code to look for any mistake or to find some details that would need to be changed, and that’s (kind of) what code review is all about. Just like chores, this process is fundamental to achieve better results in the long-term.

Code review is an activity in which one or more persons go through a programmer’s source code looking for said mistakes and details. Formally, the author of the code shouldn’t go through their own code by themselves, since they may overlook certain parts from the code or simply not be aware of an error in it. This “rule” has led to the creation of many techniques or methodologies for a better analysis of the code, which along with systematic processes and specialized software/tools has created many efficient ways for us to get our code revised.

Some of these tools help us checking our code automatically, but I won’t be focusing on those, since they are better suited for what’s called static program analysis. Instead, I want to quickly explain what kind of tools are used for this type of activity. Online software repositories, like Git, are useful since many developers can regularly check for changes, revert them or even write themselves, very useful for code revision. Ticket systems, like Redmine, allow people to collectively review code. There are even more specialized tools for this particular activity, you can take a look at some of them and their particularities in this link.

These tools can be used for multiple different methodologies. Each of them has a different approach as to how the code review is to be performed and, obviously, they require different things. I’ll provide a brief explanation for some of them.

Email Thread. This one is really simple. The main idea is to send a file via email with the code you want reviewed to a colleague or a supervisor. Their workflow will eventually let them download/open the sent file and resend it with the appropriate corrections. This method is simple and flexible, but having to constantly download files and putting all corrections together may be a little more exhausting than it should. This problem could be solved by using a repository like Git, but that wouldn’t be an email thread anymore.

Pair programming. Definitely one of the more popular approaches. This one consists of two people working on the same code at the same time while checking each other’s progress. This combines the programming and its revision, and can be really useful, but I feel like it presents the same risks as if the coding were being done individually, since both people could overlook some stuff.

Over the shoulder. This one is also very simple and very easy to perform. Similar to the email thread, once you finish coding you have to get someone to get your code revised, but with this method you have to walk them through the code and explain why you did it the way you did. Generally this one’s done with people in your same workspace (so no downloading is necessary) and makes it a more informal approach. This one doesn’t need documentation, but a way of keeping track of corrections and changes is very recommended.

Likewise, there are tons and tons of recommended practices for code revision. The ones I’ll mention come from this website in case you want to check it out!

Review between 200 and 400 lines of code at a time. The brain’s effectiveness to process information and detect errors in code can diminish after approximately reading 400 lines of code, at least according to a study by SmartBear.

Don’t review more than 500 lines of code per hour. In a similar way to last recommendation, this one comes from the way we process information. If we do it to quickly, then we are probably not doing it correctly.

Don’t review for more than 60 minutes at a time. Again, since our effectiveness diminishes as time passes, this recommendations intends to always keep us at our best when reviewing.

Now, the whole point of code revision is, of course, to improve the quality of our code. It creates defect-free, well-documented software; it makes our program compile with enterprise coding standards and serves to teach and share knowledge between developers. When done correctly, peer reviews save time, reduces the required amount of work and can even save money. I can’t stress enough how useful it’s to do code review in the long-term.

TL; DR: Try code revision!!!

Class ⇒ Code (Charlie Lima Alpha Sierra Sierra)


Are you fond of painting? There are multiple types of painting styles and techniques, each with their own characteristics. The same picture can be represented in multiple styles, and although the final product will be “the same”, the techniques inherent to each of those styles will make each of the versions distinct from each other. Some may evoke different feelings, some may highlight certain parts more than others, some may look different because of the physical properties of the paint. And, of course, some techniques may be better suited for certain goals than others.

“paint” flickr photo by Burntwood90 https://flickr.com/photos/66355109@N00/32410795875 shared into the public domain using (CC0)

Once again, the topic for this entry will be class design. It’s actually pretty fun to come up with new analogies for the same thing over and over. And one more time, I’ll be taking UML class diagrams as my main reference for this post, so have that in mind.

As I’ve already stated in my modelling languages post, class diagrams are a way of graphically representing an Object-Oriented structure; they display behaviors and relations among classes, which is particularly useful for the design stage of development. After having designed all of our classes the ideal thing is to plan on how the system is going to be implemented, and that’s when we face a new issue: what language are we supposed to use for said implementation?

Just like painting and the different techniques that exist for it, programming has a similar relation with different programming languages. If we want to develop an application, there are tons of languages which we could use and objectively archive the program’s purpose. However, different languages have different characteristics, some may be more efficient regarding resources like time or memory, others could have functions that are better implemented for what is needed, others can simply be preferred by certain developers. Regardless, it’s important to determine what language would be more appropriate for some situations.

Let’s get the obvious out of the way. Classes by themselves are fundamental parts of object-oriented programming, so it’s much easier to implement class diagrams with a language that supports the object-oriented programming. The thing is that, even among this type of languages, we still have multiple options. Different object-oriented languages have different degrees of object orientation and, therefore, can adapt to different necessities. A few distinctions derived from these differences are the following:

  • “Pure” OOL, where everything is treated as an object. (Python, SmallTalk,…)
  • Languages designed for OOP that still have some procedural elements (Java, C++,…)
  • Procedural languages with some OO elements (PHP, MATLAB,…)

Regardless of which subclassification of OOL is chosen, the process of implementation will most likely be very easy. Class diagrams already define classes, methods and attributes, so translating that into any of the languages above is a simple task.

One thing that I’d like to point out is that a lot of the Object-Oriented Languages aren’t actually Object-Oriented exclusively. Many of them (most notably, the more popular ones, like Java, Python and C++) are actually multi-paradigm languages. This means that they support multiple programming paradigms and, that if OO is one of them, then they can implement class diagrams easily but also, even if not completely related to the class ⇒ code topic, adapt many other functionalities available from other paradigms.

Now, if we wanted to implement class diagrams (or any kind of OOP design for that matter) in a non-OOL it would not be an easy task. Practically every feature shown in OOP diagrams is proper to the object-oriented paradigm, so there wouldn’t be any support for the implementation of such diagrams as they’d be. There are ways in C, for instance, to manipulate and kind of achieve similar behaviors to those of OOP, but I’d rather recommend modifying diagrams to better fit the paradigm that’s available in certain languages, it’s probably easier and would take less time to complete.

Whether we decide to implement a diagram in an OOL or a non-OOL, design is key for a better outcome. There’s a reason for artists to do sketches, right? Deciding on what language to write code in is also a very important step for the development process, I’d say that sometimes the differences between one language or another are not that significant, but when specific necessities must be fulfilled, it’s the developer’s duty to correctly determine the best option for the code.

TL; DR: Don’t implement Object-Oriented Designs in a non-Object-Oriented Language.

Also, most of the information I got for this entry actually came from forums or opinions on different websites like this or this. I justify that decision in the second partial reflection!

Class > Tlass > Taass > Tabss > Tabls > Table


Have you ever written a summary? Whether it was of a chapter from a literature book or of one of your class’s lessons, all you had to do was to read whatever you needed to, identify the main ideas and their most important complements and turn all of that into a new transcript. It’s simple, really. All you are doing is turning plain text into less plain text, but, what if that wasn’t the case? What if you wanted to change the source’s format and following a couple steps wasn’t enough?

Let’s say you just read a chapter from one of your school’s books and want to make a mind map with its information. Only identifying main ideas wouldn’t cut it, you would also need to classify them, connect them and be able to express ideas in fewer words. This isn’t as simple as a summary, and the same happens with timelines, diagrams, other kinds of maps and many other similar representations. The methods have essentially the same purpose, but extra or different steps may be needed to achieve it.

I’ve talked about class diagrams before and how they’re used in OOP to denote object classes, their attributes and methods; what their components are and why they can be useful. This time I will talk about one of the processes in which class diagrams get to be implemented, more specifically: converting class diagrams (or similar) to database tables.

Lots of tables in a class (get it?):

“Orderly Structure” flickr photo by cogdogblog https://flickr.com/photos/cogdog/2555287254 shared into the public domain using (CC0)

If you’ve ever worked with databases then you must know that they can be classified into relational and non-relational. In case you haven’t, I’ll explain the key (hehe) difference regarding class conversions: relational databases, which mostly use SQL for queries, store data in tables with both rows and columns; while non-relational databases change their way of representation depending on what type of data is supported.

Since relational databases’ tables always have the same structure (rows and columns), the way of mapping class representations into these tabulations is easier. This is also the reason why there are many tutorials on how to do this kind of translation. The process can be compared to the summaries I mentioned in the first paragraph of this entry. There’s not much to think about, you only need to identify certain patterns or elements in one representation and apply the appropriate method to make it work for the other. 

I found a very complete tutorial that even includes an example for how to follow the conversion process. I will now list the steps it includes and let you visit the website in case you are interested:

  1. Replace the standard identifier stereotype stid by pkey.
  2. Replace the platform-independent data type names by their SQL equivalents.
  3. Eliminate multi-valued attributes.
  4. Turn any enumeration data type into a corresponding table.
  5. Eliminate generalization relationships.
  6. Eliminate associations.
  7. Define an index for attributes that serve as a search field.

Yes, only seven steps are enough for this implementation of a class. But remember, they are designed to work for UML class diagrams, so other class representations may need some adjustments. Regardless, this is still simple.

On the other hand, classes can also be implemented in non-relational databases. The problem is that, since the structures used to store data may vary greatly there’s no standard method. Also, since non-relational databases are not as common nor studied, this kind of process may be even less common. This is similar to the example I gave with mind maps.

As I was doing research for this I found two websites, each explaining a different process to map class diagrams to non-relational databases. Now you may be thinking: Oh, well, if people already figured out how to map that, then the problem must’ve been solved, right?. But the thing is, they explain different processes because they focus on different non-relational structures. One does it for graphs, while the other, for documents. The fact that they only work for certain formats, along with the information included in these websites leads me to think that this kind of mapping can be more complicated than it seems. Also, both processes start from UML diagrams, so they’re not even complete in that regard. Regardless, they seem to work fine for what they claim, so that’s something, at least.

A funny thing happened as I finished writing this entry. I realized that the comparisons I made between mapping and summaries were actually present when redacting some of the paragraph in this post. Let me explain: since there’s so much information about relational databases and the conversion from classes to tables it was easy figuring out what to write. I just had to take the main ideas from any page I found: a summary. But it was different for the non-relational part, there was definitely enough information for me to use, sure, but I had to take different pieces from several websites so I could understand, reinterpret and write about it: somewhat similar to the example with mind maps.

Mapping to non-relational databases may be complicated, but not impossible. Using relational databases is the easier solution, though. Besides, SQL has by far more documentation, which is also a great advantage and why I’d definitely recommend using.

TL; DR: Stick to SQL.

Unexpected Metonymy Linkages II


Before I even begin with one of my weird analogies have in mind that I’m assuming that you’ve already read my previous entry, so if I don’t have much of an introduction or there’s seems to be missing information, that’s the reason.

“Crayons” flickr photo by idreamlikecrazy https://flickr.com/photos/purple-lover/5979587149 shared under a Creative Commons (BY) license

One of the things I mentioned in the first part of UML is that diagrams are classified into categories depending on its primary symbols. This time I’ll cover three other types of diagrams:

First, if the diagram contains packages it’s classified as a package diagram. Package diagrams are a subcategory of structure diagrams, and sure they are. Packages are a way of grouping different elements into one, it works (and also looks) like a folder and their use in a package diagram is to simplify and provide a better structure of the system. Packages can interact with each other in order to form a logical structure that tells how different components work together. It’s almost like package diagrams are maps of the world, and each of the packages is the (more detailed) map of a country.

When the primary symbols of a diagram are behavioral states and transitions it belongs to the state machine diagram category. This kind of diagram is pretty intuitive and rather simple, it contains all possible states our system can be in, such as active, out of order and waiting. These diagrams include what actions have to be taken in certain states in order for the system to transition into another one. They’re very very similar to automats, but are not as complex.

Component diagrams are UML diagrams used for Component-Based Development, where components interact with each other. These components act as pieces that can be replaced, swapped or rearranged when necessary. The goal of using components is to be able to develop each one of them independently from each other. These components can be either logical or physical and often have associated interfaces or ports in order to interact with other components.

There are obviously a lot more categories for UML diagrams, but there are too many for me to cover them all. Instead, I recommend checking out this site to read about UML 2.5’s considered classifications and this one to see some examples of different UML diagrams. Those helped me understand many of the diagrams in this and in the previous post. UML-diagrams.org was my main source when doing research for this entries, they have detailed explanations of every single possible component in a UML diagram, so that can also be useful at some point.

Now, I’ve already talked about design patterns and many Object Oriented Programming related subjects in other blog posts, so the next concept should be easier to grasp (hehe). GRASP stands for General Responsibility Assignment Software Patterns, and is actually the name of a set of design patterns that aid Object Oriented Design. I think the name fits perfectly, since it already perfectly describes what these patterns’ objective is. But just in case it’s not completely clear: GRASP are patterns that receive certain responsibilities regarding objects and classes in the OOP paradigm.

GRASP makes use of the following patterns and principles:

Creator – Class responsible for creating objects. Similar to the Factory design pattern.

Indirection – Assigns responsibility of mediation to an intermediate object.

Information expert – Determines where to delegate responsibilities.

High cohesion – Keeps objects appropriately focused, manageable and understandable.

Low coupling – Dictates how to assign responsibilities to support multiple aspects.

Polymorphism – Defines variation of behaviors based on types.

Protected variations – Protects elements from the variations on other elements.

Pure fabrication – A class made for the sole purpose of achieving low coupling and high cohesion.

Controller – An object responsible for receiving and handling a system event.

I mentioned controller at the end of the list because it’s actually an important component in the next pattern I want to briefly explain: MVC. Model-View-Controller is yet another design pattern. This one divides the associated program into three interdependent systems. Each of them has a specific role in the whole thing, and the reason for doing this is so the representation of information is separated from the actual manipulation of it. I will be talking a little more about this particular pattern in my second partial reflection, since something funny regarding this happened last week.

All of these patterns and models may seem like advanced stuff that we may not get to use or even see at any point, but the more time I’ve spent studying and working on different projects I’ve realized that many of these are waaay more common that I’d first thought.

Note: I was told that I could have only written about even more UML diagram classifications. I could’ve done that, but I wouldn’t have had a chance to think of any new comparisons and that’d have been boring and not challenging at all. 

TL; DR: You’ll eventually find every pattern implemented in some way.

Unexpected Metonymy Linkages


Have you ever heard of metonymies? Well, maybe the term is not that well-known, but that’s how you call it when people refer to certain objects by the name of a brand instead of the product’s. At least in Mexico it’s very common to hear somebody refer to crayons as Crayolas, glue sticks as Pritt, tissues as Kleenex, or many other similar cases. I believe this is caused because some brands are greatly preferred over others (mainly because of quality) or because there are only a few offering such products.

“Tissues” flickr photo by kaktuslampan https://flickr.com/photos/kaktuslampa/1810941940 shared under a Creative Commons (BY-SA) license

Although not exactly a metonymy, the situation of UML diagrams is very similar in a sense. But before I explain myself, I want to briefly remind you what UML is. I have already mentioned this in other blog entries, but UML is the most prominent modeling language out there. It was developed by three people working for Rational Software between 1994 and 1995, then adopted by, you won’t believe it… the Object Management Group (OMG, I know) in 1997 and finally published by the International Organization for Standardization (ISO) as an official standard in 2005. Since then, many versions of UML have been released, with several additions and changes to existing diagrams, and with the creation of new kinds of diagrams as well.

I wanted to compare UML diagrams to metonymies because they have similar effects. If somebody needs a graphical representation of a system and their classes they’ll probably think that they need a class diagram (which is the UML equivalent to such kind of representation) because of one of the following reasons: they do want a class diagram, knowing that it’s the implementation in UML and that there are other alternatives; they want something similar to a class diagram, but since that’s the only name they know, they believe that’s what they are all called; or they believe class diagrams are the only alternative to what they need. Even if none of these is the case, the reference everybody will most likely use is a UML class diagram because of how common they are.

Do you get where my comparison is coming from? Even if a class diagram is not a brand, that’s probably what most people will call that kind of representation. So even if it’s not entirely accurate, it allows us to understand what is needed.

But now, think about this: if there’s already a diagram that depicts exactly what I need and it’s so popular that everyone around me knows it well enough to work as a point of reference, why would I want an alternative to that? To me, it makes no sense to look for an alternative to UML, it works well and practically everybody already uses it so, why waste time and effort looking for something else that does the same? I believe that’s the main reasoning for everyone to keep using UML diagrams. So, in the example I gave two paragraphs above, I believe the reason will almost always be that they do want a class diagram, you know?

So yeah, UML diagrams are super common, hence how useful it is to know how its classification works and some of the basic behavior/structure of some of its diagrams. Oh, would you look at that, that’s exactly what we were told to cover in this entry, so I guess I’ll have to talk about that now.

According to uml-diagrams.org, the classification of a UML diagram is defined by the primary graphical symbols shown on it. Here’s a representation of the current classification of UML diagrams, for this entry I’ll just mention three:

If there’s a sequence of message exchanges between lifelines the diagram would classify as a sequence diagram. Now, if you know as much as me before doing some research you may be thinking: what in the heavens is a lifeline? so I will answer that question for you: they are each of the individual entities that take part in any process of the respective system. Sequence diagrams are the most common kind of interaction diagram, with the focus being the already mentioned messages. According to the examples I saw, the interaction between entities and their respective restrictions are important to successfully achieve a goal or end a process. I understood it as a more complex and complete flowchart, even if there’s not exactly a flow to follow.

If the primary symbols are classes, then the diagram is, surprisingly, a class diagram. These may be easier to understand, since a lot of people are already familiarized with OOP and that kind of classes. I’ve used this type of diagrams since my second semester, they’re useful to get a general idea of the methods and attributes of certain classes (not so much of what they do, but of their definitions), along with the interactions/relationships between them.

Object diagrams are an interesting case. Since UML 2.4 (current version is 2.5) there’s no definition for object diagrams, but previous versions defined them as a way of depicting instances of classes with values for each of their attributes and relationships between them. UML 2.5 states that class and object diagrams are completely unrelated, but other UML sources say that object diagrams are kind of an instance of class diagrams (which is funny if you consider that objects are instances of classes themselves). Anyways, these diagrams can be useful to keep track of certain values at set points or situations inside a program or process. I’ve never used an object diagram, but it seems to be an interesting concept.

Because UML is such a big topic, this is the first part of two about UML, so I’ll wrap everything up in the next post. For now, I’d recommend checking out the link in the paragraph just above the one where I explained sequence diagrams, that website explains every classification considered in UML 2.5.

TL; DR: I said diagram a lot

Fine design


Has the sunlight ever bothered you while driving, walking, watching a game, or simply when going outside? I think we all know what that’s like, but, how do we usually tackle that problem? Hats, sunglasses and even our own hands are common alternatives that, if you think about it, are based around the same simple solution: use the shadow of an object to stop the light from hitting your eyes.

“LEGO” flickr photo by Pietro Zuco https://flickr.com/photos/drzuco/28678155725 shared under a Creative Commons (BY-SA) license

Design patterns are Object-Oriented tools that can be used in a similar way. When a developer faces a problem it’s a common solution to seek some help on the Internet, why? Because there’s a high chance that someone else has had the exact same problem before, and probably a solution has already been provided. 

Design patterns are references, templates that show a standard solution for a problem. They, unlike stackoverflow’s answers, only tell you what the solution to a specific problem is, and don’t include any kind of implementation or information on how to do it. More specifically, design patterns usually have some kind of structure: they have identifiers (names), the problem they’re solving, the detailed solution and, sometimes, tips for implementation and possible consequences of their use.

They are usually considered good practices, since they’re not arbitrary solutions, but well-thought and well-defined alternatives. That’s why it’s recommended to completely understand how they solve the problem and why it works instead of just learning methods and classes.

The concept of design patterns (at least when talking about software) became popular when the Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides) published a book in 1994 called ‘Design Patterns: Elements of Reusable Object-Oriented Software’, where they classified and described 23 different design patterns that could solve recurrent problems in programming.

Their classification consisted of three groups, with each one covering a different aspect of OOP. I will list the three categories and give an example of one of the corresponding design patterns.

First, we have creational patterns, which are related to instantiation and creation of objects and classes and how to manage these processes. These patterns control how new objects should be created and managed, some even define how many instances of certain class should exist at the same time. Speaking of which, the singleton pattern describes a way of having only one instance of certain object at all times, ensuring that once an instance exists, no others can be created.

“one” flickr photo by andrechinn https://flickr.com/photos/andrec/2893549851 shared under a Creative Commons (BY) license

Structural patterns help define relationships between objects. They usually dictate how two classes work together in the sense of what one represents to the other. These patterns are useful to later simplify interactions between objects, like the adapter pattern; its implementation is what we normally know as a wrapper and it basically “translates” an object into another format so otherwise incompatible methods can work on its instances.

“Gift” flickr photo by h0lydevil https://flickr.com/photos/praveenpn4u/4344132308 shared under a Creative Commons (BY) license

Finally, behavioral patterns work as guides to establish how two or more objects interact and communicate. Usually, their goal is to delegate responsibilities so no unintentional modifications happen. The observer pattern is a way of keeping track of certain changes that happen in an associated class, when certain action occurs, the observer notifies other objects and they act accordingly. It works as a messenger.

“eye” flickr photo by randychiu https://flickr.com/photos/randychiu/4302633525 shared under a Creative Commons (BY) license

For way more detailed information on the 23 original design patterns and concrete examples for each of them I recommend checking out this page.

To this day, the classification provided by the Gang of Four is still used. And 23 out of their 23 original suggestions are still used as standard solutions, although many others have originated since. As it happens in many other fields, there are new suggested categories and patterns, and, of course, criticism towards the original patterns have come up ever since they were first published.

A couple of things I noticed while trying to understand each pattern is that, just like in the example of wrappers I gave earlier, many concepts used in OOP probably originated from design patterns, and some of them even are taken as the best practices for some situations. Also, after reading the benefits section of this website, a particular statement stuck in my mind: understanding how each design pattern works instead of memorizing their implementation not only reinforces OOP concepts, as I said in the fourth paragraph, but it improves communication too, and as I said in my previous mastery entry, communication is key to an efficient teamwork. Knowing what others are talking about when just mentioning the name of a pattern saves time from explanations.

Tools like design patterns have lasted for as long as they have because they work, and they work pretty well. It amazes me how good and simple some solutions can be and, since their focus is OOP, I think they’re the thing I can get the most of among the topics of the course so far.

TL;DR: Efficient solutions are efficient.

laitraP tsriF ehT


In case you didn’t get the title of the post: this is a reflection of The First Partial.

It’s been a whole month since the semester started and, so far, four topics have been considered for the course. I’d like to summarize the important stuff that I’ve learned along the course about each of them, as well as the things I’ve grasped as the course went on.

But first:

“moc surprise” flickr photo by Capricorn Cringe https://flickr.com/photos/capricorncringe/3425386526 shared under a Creative Commons (BY-SA) license

I finally learned how to correctly include images in my blog posts. I know! What a shocker. But jokes aside, originally I hadn’t included any kind of picture in any of my previous posts mainly because I was too worried about not correctly crediting the original author. Fortunately, mister Alan Levine (not to be confused with Maroon 5’s singer, Adam Levine, as Google suggested) has written this script that can be used in some web browsers to help with Creative Commons License; it provides a way to automatically credit Flickr pictures, so thanks to him and also thanks to my teacher, Ken Bauer, for providing me with this tool. You can click on their names to check out their respective blogs.

Now, back to the topics themselves, I would like to synthesize the most important aspects for each of them. As I’ve said in practically every single one of my entries, I feel like analogies are the best way of understanding new concepts, or at least their importance in certain fields. That’s why I want to start by listing all comparisons I’ve already used, followed by their proper explanation regarding the topic of the corresponding week.


Software Development Life Cycles

The scientific method is a strict procedure followed by many. It functions as a guide that tells you what to do before, during and after an experiment; it encourages you to have some background on the problem you are tackling; it helps you figure out what to expect during your testing and it provides options on what to do whether the experiment is successful or not. 

“SCIENCE” flickr photo by chase_elliott https://flickr.com/photos/chasblackman/7006530174 shared under a Creative Commons (BY) license

SDLC are also procedures, but they support the software development process (duh). They’re practically alternative versions of the scientific method when we take a look at the features listed in the last paragraph. SDLC do consider stages before (definition of requirements), during (coding) and after (testing, deploying, updating) the development of software. More specifically, they encourage research as to what will be needed for a project and define its requirements with the help of the clients prior to the implementation; they help figure out what the expected outcome for certain test/case/version is to then compare it with actual results and, at last, have plans for maintaining, updating, fixing and/or reviewing the application depending on how successful certain test was.

As the name suggests, SDLC involve cycles and, therefore, a sequence of steps. The number of steps and each of their names change from one variant to the other, but the global idea is pretty much the same. Many types of SDLC exist, some are simple, some are repetitive, some are intuitive. Their main differences rely on how often you test or deploy your application, how much time you spend on each phase and whether you can go back to previous steps or not. Each variant may serve for different kind of projects, so it’s useful to know a thing or two about them.


Unified Software Process

Burgers! Who doesn’t like burgers? Even vegans have found ways to have burgers themselves. This popular dish has, of course, many different versions. Multiple recipes for burgers exist, and alongside different cooks, different tastes and different ingredients, it’s very unlikely for two burgers to taste the same, even for the same recipe. But in the end, whoever eats it will have enjoyed a nice burger, that’s for sure.

“Certified Angus Beef Burger w/ Avocado” flickr photo by ppacificvancouver https://flickr.com/photos/panpacificvancouver/5962021070 shared under a Creative Commons (BY) license

I think the Unified Software Process (USP) is similar, not only to burgers, but to most dishes. The basic structure or idea is the same for all variants, USP divides itself into four blocks: Inception, Elaboration, Construction and Transition; and the last three are also subdivided into iterations. This could be seen as the idea of the dish. You probably will include some kind of pasta and meat if you plan on cooking spaghetti and meatballs, for instance.

A USP has to consider disciplines to cover all aspects of the development process. They are then distributed across the four mentioned blocks to indicate how much relevance each of them will have in every stage of the procedure. Disciplines have to be well defined. I like to think of disciplines like if they were the ingredients for a recipe: you choose what to use, how much of it and in what stage of the preparation.

The key difference between SDLC and USP is that, just like recipes, USP serve as reference and not necessarily as a strict guide. Many refinements of the process exist, each with different disciplines, distributions and goals. Some tweaks may be made in order to better fit a project, just like you can add/remove an ingredient from a recipe to meet your preferences. Adaptation also allows USP to work on smaller projects, its versatility is what makes me prefer it over SDLC.


Use Cases

Burgers! But just the patties, yay! Wouldn’t you agree that a single patty could change a burger’s flavor completely? It doesn’t matter how good the rest of the burger is, if the “base” is bad the whole thing would turn out worse than it could’ve.

“Burger patties” flickr photo by star5112 https://flickr.com/photos/johnjoh/520999007 shared under a Creative Commons (BY-SA) license

Just like patties and burgers, requirements are the base of any software development process/life cycle. Your requirements define what’s important, what has priority over what, what’s completely necessary and what could be postponed.

Use cases are a term used to describe how every kind of user accomplishes different goals by using the application. These goals should cover all possible scenarios so, when listed, the developers can figure out how those goals could be achieved through their software, and could go from as simple as logging in to find a very specific section to do a very specific action.

Just to clarify, by users I don’t mean each individual using the application, but rather the roles they can take. Roles define what you are able to do and what you are allowed to see/change. For example, a student and a teacher don’t have the same kind of privileges; teachers should be allowed to change students’ grades, but the students themselves should only be able to consult them.

Thinking of situations like this help you come up with new use cases, the example above could be reinterpreted to define a new user requirement for both student and teacher roles. The best way of thinking of new situations, in my opinion, would be to find an actual representative of the role and ask about what they usually want to do, what they usually have to do and how their role functions, basically.

Use cases are an easy way of visualizing user requirements.


Modeling Languages

Communication is vital for people. Whether you’re reading something like this entry or seeing a picture like the one below, you’re probably getting a message. People can accurately get these messages only if they know the language they originate from. The more people understand a language, the better it is to use it since it requires less effort. 

“Smiley” flickr photo by katerha https://flickr.com/photos/katerha/4238730308 shared under a Creative Commons (BY) license

Modeling languages intend to formalize the way of representing multiple types of information so more people can let others know what is needed in, for instance, each software development process stage. The goal is to set a standard that everyone understands so representations are interpreted as quick as possible.

Diagrams and other graphical representations are popular ways of defining modeling languages, since shapes and colors are more easily recognizable and do not depend on languages to be understood. In fact, the most popular modeling language, UML, is mostly graphical.

UML diagrams are standard ways of depicting different tools and procedures in a more universal manner, and they cover practically every process related to software. From OOP class diagrams to representation of use cases, UML has defined structures, relations, symbols and many more things to express everything needed in each of them.

Modeling languages are a powerful tool that break language barriers and allow for better teamwork and more efficient communication.


What else?

Outside of the topics of the masteries, I’ve learned a few things related to OOP during the last couple classes and I now realize that most languages I had been told are object-oriented aren’t completely. We’ve been working with SmallTalk, a programming language where absolutely everything is treated as an object, because everything is, indeed, an object of some sort.

The way SmallTalk works is pretty distinct to what I’m used to, so I’ve been a little confused as to how efficiently/correctly make use of SmallTalk, but I think that’s something I’ll eventually figure out.

Also, I like that I’ve finally had the opportunity to practice my English once again after like a whole year of not really needing it. I think it’s cool.

For now, I hope that the next topics make me think of analogies as hard as these last four have. I think that’s a fun challenge and help both me and whoever might end up reading these entries to better understand all of these different concepts. And not only that, but the ones we’ve already gone through are quite useful, even if we don’t get to make use of them yet the fact that we are now conscious about their existence and how they roughly work is useful enough.

“Thumb up…” flickr photo by Guido van Nispen https://flickr.com/photos/vannispen/33686742682 shared under a Creative Commons (BY) license

TL; DR: I hope to keep doing as well as I think I have.

Create your website at WordPress.com
Get started