Notas de la clase 7 y guía de trabajos prácticos

El foco de esta clase fue introducción a análisis y diseño. Vimos un conjunto de estrategias que nos permite avanzar desde una especificación de un sistema (medianamente completa) a un diseño e implementación del mismo. Las estrategias que aplicamos con una combinación de lo propuesto por varios autores (Larman en lo referente a casos de uso y identificar comportamiento para cada uno, Wirfs-Brock en lo referente a la estrategia de sustantivos para identificar clases). Aquí les resumo cuales son los pasos a seguir cuando uno todavía no sabe por donde arrancar con el diseño.

1. Listar los casos de uso. Que cosas puede hacer el usuario con el sistema? Por ahora nos alcanza con una frase que resuma cada caso de uso, por ejemplo, "calcular el peso de un contenedor".
2. Subrayar todos los sustantivos en la especificación (enunciado). También hacer esto en mi lista de casos de uso dado que puedo haber introducido nueva información y vocabulario.
3. Construir una lista con todos esos sustantivos. No descartar ninguno. En la lista incluyo los calificativos que acompañan, por ejemplo "Pieza de metal", "Ciudad destino", "Usuario vip". 
4. Vamos a utilizar esa lista para construir un modelo del dominio (Larman le llama diagrama de conceptos). Es muy parecido a un diagrama de clases, pero todavia no puedo asegurar navegabilidad de las relaciones y todavia no hablo de comportamiento. Procedemos así: hasta que la lista este vacía (o ya no me sirva porque los sustantivos que quedan no me ayudan mucho) repito lo siguiente:
1. De la lista tomo un sustantivo que creamos que, casi sin discusión, es una clase. Uso un poco de intuición, me pregunto cuales serían sus atributos si fuera una clase, me pregunto cuan central es ese concepto al problema, etc. Incluyo en el diagrama y lo tacho de la lista. Si en la lista hay un sinónimo para esa palabra, veo cual de las dos palabras representa mejor el concepto, uso esa y tacho las dos.
2. Busco en la lista atributos obvios para esa nueva clase. Los incluyo en el diagrama y los tacho.
3. Si en mi diagrama hay otras clases, pienso como se relacionan con la que acabo de agregar. Si hay relación de conocimiento la indico sin hablar todavía de navegabilidad (dirección de la flecha). También indico cardinalidad. Si creo que hay relación de especialización o generalización (herencia) también la indico. Recuerden preguntar "es_un"?".
4. Busco en la lista para ver si alguna de las palabras en la lista describe los roles de las relaciones que agregué (etiquetas en los extremos de las relaciones).
5. Contínuo, siempre eligiendo lo mas obvio, menos discutible, hasta que tengo un diagrama que a mi entender representa bien el dominio e incluye la mayoría de los sustantivos de la lista. Puede que me queden algunos sustantivos en la lista que no se donde ubicar.
5.  Ahora, pienso en comportamiento. Tomo alguno de los casos de uso y pienso:
1. Como estaría instanciado mi diagrama de clases para que ejecutar ese caso de uso tenga sentido (por ejemplo, debe existir una instancia de Container, con su colección de cajas inicializada y vacía). Que objetos deberían existir, como serían sus atributos, como estarían relacionados? Si puedo lo dibujo para no olvidarme (diagrama de instancias)
2. Luego de que el caso de uso termine, como quedaría mi diagrama de instancias? Que nuevas instancias aparecen? Que atributos cambian? Que relaciones cambian? 
3. Ahora pienso que tendrían que hacer mis objetos para llegar del estado inicial (1) al estado final (2). A quien le envío que mensaje con que argumentos? A quienes le envía mensajes ese? Agrego esos mensajes en la lista de los mensajes que debe entender cada una de las clases involucradas. En este punto pueden utilzar un diagrama de comunicación para documentar como es la cadena de envío de mensajes (ojo que hay cosas que no voy a intentar documentar el en diagrama para no complicarlo como iteraciones, ifs, etc). Si su diseño los va convenciendo, pueden ir implementando y probando en el workspace.

Práctica

Les dejo la práctica 7 en las que repito el enunciado visto en clase para que lo diseñen e implementen completamente (además de unos ejercicios de diseño e implementación simples) para

Notas de la clase 6 y guía de trabajos prácticos

Les debía las notas de la clase 6.

En esta clase hablamos principalmente sobre colecciones. De la jerarquia de colecciones de Squeak nos concentramos en OrderedCollection (tamaño dinámico, muy flexible), Set (elimina duplicados), Array (tamaño fijo, rápida) y SortedColection (ordenada), y Dictionary (cualquier objeto puede ser una clave).
Collections esta muy bien cubierto en el capítulo 9 de Squeak by Example.

Al hablar de Set, aprovechamos y vimos la diferencia entre igualdad (el mensaje #=) e identidad (el mensaje #==). Nunca redefinimos el #==. Es comun que redefinamos el #= en nuestras clases (por ejemplo para definir que dos personas son iguales si tienen el mismo DNI aunque haya alguna diferencia entre sus nombres, por ejemplo, por un error ortográfico). El set envia el mensaje #= para ver si un nuevo objeto ya esta incluido. Si quiero que compare por identidad utilizo un IdentitySet. Para leer mas sobre identidad e igualdad, vean la página 178 (Identity and equality) del libro Squeak By Example.

Finalmente, para hacer cosas con colecciones, vimos lo importante que son los  iteradores: #do:, #collect:, #select:, #detect:ifNone:, #reject: e #inject:into:

Les dejo la práctica 6, muy enfocada en Colecciones. Es una práctica muy importante porque les va a servir de apunte para estudiar.

Notas de la clase 5 y guía de trabajos prácticos

Hablamos de UML y vimos en detalle lo que vamos a usar de diagramas de clase. Recomiendo que consigan UML gota a gota. Si no lo consiguen, este articulo parece estar bastante actualizado.

Anteriormente habíamos hablado de diagramas de colaboración (o de comunicación como se los llama en UML 2.0). Aqui les dejo un link que les puede servir (ademas del libro)

Confirmamos que en Smalltalk las clases son objetos y por tanto entienden mensajes. Uno de los mensajes que entienden las clases es #new. Puedo definir otros mensajes de clase, y en particular nos interesan aquellos que reciben varios parámetros y nos devuelven una instancia completamente inicializada. Los llamamos complete creation methods.

En esta clase retomamos el tema de las cuentas y vimos que para aprovechar herencia debía ser posible extender métodos heredados (no solo redefinirlos). Para eso nos viene bien super. Al final de este post les dejo un mini-apunte sobre super y self.

Ya esta disponible la práctica 5. Tiene ejercicios de UML, super y self, métodos de clase y uso del debugger de Squeak.

self y super

self y super son pseudovariables. No se puede asignar objetos a estas variables. Es responsabilidad de la maquina virtual asegurarse de que cada vez que se ejecuta un método, self y super apuntan (referencian) al objeto correcto, es decir, al objeto que se encuentra ejecutando el método.

Primer lección importante: tanto super como self apuntan (referencian) al mismo objeto: el objeto que esta ejecutando el método.

self puede pasarse como parámetro en un mensaje, puede asignarse a una variable, y puede ser receptor de mensajes.

Cuando en un método veo "self hacerAlgo"  lo leo como "el objeto se envía #hacerAlgo a si mismo". Permite entre, otras cosas, refactorizar un metodo complejo, haciendo que el objeto se delegue tareas a si mismo que se resuelven en otro método (en este caso #hacerAlgo).

Cuando en un método veo "super hacerAlgo" lo leo "TAMBIEN" como el que el objeto se envía hacerAlgo() a "si mismo". Ya veremos la diferencia.

Cuando un objeto recibe un mensaje, no importa si se lo envió otro objeto o si se lo envió él a si mismo tratándose de "self". En ambos casos pasa lo mismo. Se inicia la búsqueda de un método en la clase del objeto y si no se encuentra en esa clase se sigue buscando siguiendo las relaciones de "hereda de".

Cuando un objeto recibe un mensaje que se envió él a si mismo, pero en lugar de referirse a si mismo como self, utilizósuper (p.e., self hacerAlgo) se cambia la forma en la que se comienza a buscar el método.

• Cuando super recibe un mensaje, la búsqueda de método comienza en la clase superior a aquella donde está el método que envió el mensaje a super. Esto no es lo mismo que decir "en la superclase", o "en la superclase del objeto".
• Esto es independiente de la clase de super/self.

Ese cambio el mecanismo de method lookup (busqueda de método) permite enviar nuevamente el mensaje cuyo metodo se esta definiendo al objeto receptor y evitar entrar en un ciclo infinito. Esto es útil para "EXTENDER" comportamiento heredado.

Ojo que en algunas definiciones de super equivocadamente dicen que la búsqueda de método comienza en la superclase del objeto receptor! Eso no es correcto.

Notas de la clase 4 y guía de trabajos prácticos

Como siempre, comenzamos con ping-ping de preguntas y respuestas para recordar lo visto hasta ahora.

En la práctica (TP3) anterior utilizamos el "if" de Smalltalk como receta. Ahora vimos que se trata de un mensaje (#ifTrue:) que entienden tanto true (la única instancia de la clase True) como false (la única instancia de la clase False). Es un muy buen ejemplo de polimorfismo.

#ifTrue: es un mensaje que espera un bloque (instancia de la clase BlockContext) como parámetro. Los bloques se crean literalmente encerrando una expresión Smalltalk entre corchetes. Como son objetos podemos asignarlos a variables, pasarlos como parámetros, y enviarles mensajes. En particular los bloques entienden el mensaje #value que hace que ejecuten su expresión Smalltalk.

Avanzando sobre el ejercicio de las cuentas bancarias vimos herencia. Vimos como funciona la herencia de conocimiento (variables de instancia) y como funciona la herencia de comportamiento (vía la búsqueda de métodos siguiendo la cadena de herencia). Vimos que una subclase puede agregar nuevos métodos y variables a las que hereda. También vimos que si define nuevamente un método que hereda, este "ocultará" al heredado en la búsqueda de método. A eso le llamamos sobre-escribir métodos (override en inglés).

También hablamos sobre self, la pseudovariable que apunta al objeto que se encuentra ejecutando el método. Todavía nos queda por conocer super, una pseudovariable que también apunta al mismo objeto que self, pero que cambia la forma en la que se buscan los métodos.

Finalmente hicimos un diagrama que mostraba envió de mensajes entre instancias de distintas clases en el ejemplo de un cajero automático. El objetivo de ese diagrama es doble; por un lado introduce la notación de diagramas de comunicación de UML; por otro lado da un panorama de como se combina todo lo visto hasta ahora para construir algo mas interesante.

Práctica

Les dejé prática nueva en el grupo de google . Esta práctica tienen que entregarla resuelta antes del lunes 12 de octubre. Cuenta como nota de concepto para definir el parcial en caso de que este dudoso.

Lectura

Les recomiendo que lean el capitulo 2 (y los anteriores si todavía no los leyeron) del libro Programando con Smalltalk de Diego Gomez Deck. Repasa todo lo que vimos hasta ahora (tipos de mensajes, variables, precedencia, etc.) y en la sección 2.7 habla de bloques y del mensaje #ifTrue: y  sus variantes.

En ese mismo libro (al final del capitulo 1) pueden leer sobre herencia. 

El capitulo 3 (Syntax in a nutshell) de Squeak by Example da un panorama completo de toda la sintaxis del languaje vista hasta ahora. Como lo dice el título, tiene muchos ejemplos.

La sección Developing in Squeak de Squeak by Example presenta los principios de Smalltalk. Es recomiendo leerlo. En particular habla de herencia. 

• Rule 1. Everything is an object.
• Rule 2. Every object is an instance of a class.
• Rule 3. Every class has a superclass.
• Rule 4. Everything happens by message sends.
• Rule 5. Method lookup follows the inheritance chain.

La notación gráfica que usaremos se llama UML. Pueden leer sobre diagramas de comunicación en el capítulo 12 del libro UML Gota a Gota de Martin Fowler 

Notas de la clase 3 y guía de trabajos prácticos

El foco de esta clase fue entender relaciones entre objetos. Hicimos rol playing (algunos de ustedes eran objetos) para hacer bien gráficos temas como envío de mensaje, encapsulamiento, relaciones entre objetos y pasaje de parámetros.

Hablamos sobre literales y sobre magnitudes. Vimos que los operadores aritméticos son envíos de mensajes y que los números (y otras magnitudes) son objetos.

Hicimos MUCHO hincapié en el proceso de búsqueda de método (¿qué hace un objeto cuando recibe un mensaje?) y hablamos de binding dinámico. También hablamos un poco de polimorfismo con el ejemplo de las magnitudes y los mensajes de comparar. Vimos que el binding dinámico es importante para el polimorfismo.

Hablamos sobre tipos de mensajes en Smalltalk y orden de precedencia (unarios, binarios, palabra clave).

¿Que capítulos de la bibliografía recomiendan que leamos para repasar estos temas? ¿Están leyendo esto al menos? :)

Les dejo una práctica nueva para fijar algunos de los temas que vimos en clase. Esta práctica además los guía paso a paso para cargar una aplicación web que interactue con uno de sus objetos.

La práctica es un archivo zip con el enunciado y un par de archivos con objetos ya preparados para que carguen en la imagen.

Notas de la clase 2 y guía de trabajos prácticos

Iniciamos la clase con algunas preguntas sobre los temas vistos anteriormente. La pregunta clase es ¿qué es un objeto?

Basándonos en el (clásico) ejemplo de la cuenta bancaria reforzamos la idea de conocimiento y comportamiento de un objeto. El conocimiento de la cuenta son su saldo, titular y numero. Su comportamiento es devolverme su saldo, extraer y depositar.

Implementamos los métodos para una cuenta y simulamos el comportamiento de la misma haciendo que uno de los alumnos tomara el rol de la cuenta (sus variables estaban escritas en una hoja que el sostenía).  Luego vimos que podíamos tener otras cuentas como esta y llegamos al concepto de "la clase" como "molde" para la creación de instancias. Pueden leer mas sobre clases e instancias en el capítulo 1 del libro de Budd.

Recordamos que un objeto oculta su información y por tanto solo podemos acceder a su conocimiento enviándole mensajes.

Luego vimos como implementar clases y métodos en Squeak usando el browser. Interactuamos con instancias de Cuenta en el workspace. Para verificar que estuvieran funcionando bien, monitoreabamos su estado interno con inspectores. El libro Squeak by example seguro les sirve de ayuda para recordar todo sobre el browser y los menues de Squeak. También pueden dar una mirada al link que dejé en bibliografia "Squeak Smalltalk: language reference".

Nos dimos cuenta de que un objeto debe estar inicializado y hablamos del método #initialize. En squeak, el mensaje #initialize se envía automaticamente a las instancias tan pronto son creadas (ya veremos porque).

Resumimos todo lo que sabíamos sobre variables hasta ahora (de instancia, de workspace, parametros y temporales).

Finalmente terminanos de cerrar la idea de las variables como apuntadores a objeto. Esto implica que las variables de instancia de un objeto pueden apuntar a otros objetos. Esto nos permite hacer que un objeto  "conozca" a otro. El ejemplo que vimos en clase fue la Cuenta, que en su variable "titular" ya no tiene un String sino una Persona.

La guía de trabajos prácticos 2 que ya esta subida al grupo de google tiene preguntas y ejercicios para reforzar todo lo visto en clase. Haré algunas preguntas al principio de la clase que próxima.

Notas de la clase 1 y guía de trabajos prácticos

El foco de la primer clase es introducir el paradigma de programación orientada a objetos y algunos de sus conceptos principales: abstracción, objeto, mensaje,  métodos, atributos, encapsulamiento. Estos temas los cubre muy bien el capítulo 1 (Thinking Object Oriented) del libro de Timothy Budd. Ojo que todavía no hablamos clases, de herencia ni de polimorfismo.

Para entender la OOP y aprender a pensar en objetos se requiere una herramienta adecuada (y mucha práctica). Squeak (Smalltalk) es esa herramienta. En la primer clase conoceremos un poco de la historia de Smalltalk, instalaremos y exploraremos Squeak y veremos como crear objetos, enviarles mensajes, y ver el resultado. En Squeak todo es un objeto. Pueden leer estos temas en español del libro de Gomez-Deck, sin embargo sigue un orden diferente al que seguimos en la materia y seguro menciona temas que todavía no vimos. El capitulo 1 (hasta la sección 1.5 inclusive) del libro Squeak By Example es otro buen punto de partida para arrancar con Squeak.

Descarguen y resuelvan la guia de trabajos prácticos correspondiente a esta clase. Es importante que se tomen un buen tiempo para entender y responder las preguntas (leyendo la bibliografía y buscando en la web). Los ejercicios en Smalltalk apuntan a que todos tengan esta semana un Squeak funcionando, sepan como instalarlo y copiarlo, y puedan utilizar un workspace para prácticar lo visto en clase. Además ya vamos fijando el vocabulario.