Fecha y hora actual: Jueves 27 Jun 2019 08:43
Índice del Foro

Foros de programación informática, diseño gráfico y Web

En esta comunidad intentaremos dar soporte de programación a todos los niveles, desde principiantes a profesionales de la informática, desarrollo de programas, programación web y mucho más.

Lección 80: Introducción a UML

Responder al Tema

Índice del Foro > Programación en general > Lección 80: Introducción a UML

Autor Mensaje
Kyshuo Ayame
Moderador Global


Registrado: 07 Ene 2011
Mensajes: 1042

Mensaje Publicado: Lunes 21 Ene 2013 17:37

Título del mensaje: Lección 80: Introducción a UML

Responder citando

Introducción a UML

Unified Modeling Languaje o bien, Lenguaje de Modelado Unificado, es justamente un lenguaje para crear modelos de sistemas. Hasta ahora hemos visto algunos dibujos de dependencias que yo he hecho y los dibujos de herencia. Sin embargo no respetaban un estándar UML.

A diferencia de lo que conocemos hasta ahora como lenguaje, como mínimo Pascal, Modula 2 y Java, UML no es un lenguaje textual con el cual se escriban instrucciones, sino que es un lenguaje gráfico. Entonces, en vez de escribir lo que hacemos es dibujar. Sin embargo UML sigue siendo un lenguaje, y como tal tiene reglas bien estructuradas de lo que significa tal o cual cosa.

Mediante este lenguaje nosotros haremos Diagramas de Clases y tal vez algún Diagrama de Comportamiento. Sin embargo no ahondaremos en demasiados detalles al respecto dado que UML escapa a los fines de este curso. Decidí que veamos algo porque me parece que es una herramienta muy utilizada en el mercado y que, dado un pantallazo al respecto, ustedes podrán luego estudiarlo por su cuenta. Si uno quiere saber todo sobre UML terminará estudiando todo un libro acera de él.

A la hora de pensar en un problema de la realidad e intentar llevarlo a un problema de software, UML suele ayudar mucho a modelar ese problema en el proceso de desarrollo de software. Es importante diferenciar bien el hecho de que UML no es el proceso de desarrollo, sino que es una herramienta que nos ayuda en uno de los aspectos de dicho proceso.



Modelo de dominio:

Cuando tenemos un problema del mundo real que queremos llevar al mundo de la programación tenemos que comenzar a analizarlo (esto ya lo he hablado). Al momento de analizar es importante sentarse a hacer dibujitos en un pizarrón o una hoja de papel. Estos dibujitos pueden ser rectángulos con nombres de “cosas” que hay en nuestro problema. En la etapa de análisis uno puede usar el UML de una forma un poco informal, es decir, sin ceñirse demasiado a las reglas que el lenguaje impone, sino más bien intentando esclarecer ideas que flotan en la mente y que no han llegado a hacerse claras del todo.
Es muy usual que el dibujo formal se parezca mucho al dibujo informal, pero no tiene por qué ser así. En el dibujo informal o Modelo de Dominio (también llamado Modelo Conceptual) uno dibuja justamente los conceptos, por ejemplo: “En mi problema hay personas y autos”.


Diagrama de clases:

Una vez analizado el problema, podemos comenzar a dibujar el diagrama de clases, es decir, el diseño del software en sí. Mientras que el modelo de dominio abstraía el problema para volverlo algo concreto y entendible, el diagrama de clases modela la solución a él. En esta instancia uno ya está pensando “En mi sistema habrá una clase llamada Persona y otra llamada Autos las cuales serán implementadas.”

============================================

Notaciones:

Veamos entonces como se representa cada elemento en un diagrama UML.


Notación para clases:

En UML una clase es, como mínimo un rectángulo con su nombre, por ejemplo:



Sin embargo sabemos que una clase normalmente contiene más cosas que solo su nombre, es decir, tiene atributos y operaciones. UML entonces define una representación para esto, donde se agregan al dibujo anterior dos compartimientos más: uno para los atributos y otro para las operaciones.



Aquí podemos ver como he agregado los dos nuevos compartimientos al dibujo anterior. En el primero irán los atributos y en el segundo las operaciones.

Al nombre de la clase se le podría anteponer el estereotipo <<class>> como para aclarar que es una clase. Sin embargo, si no se pone se sobreentiende que el rectángulo dibujado representa a una clase. Luego veremos que hace falta aclarar algunas cosas, como por ejemplo, podría anteponer al nombre de una clase el estereotipo <<ventana>> para indicar que dicha clase es además una ventana de la interfaz gráfica. Por ahora dejaremos eso de lado.

__________________________________________________

Notación para atributos:

Supongamos que esa clase Persona que dibujé allí es la clase Persona con la que trabajamos en nuestro sistema Herencia01. Esta clase tenía tres atributos: nombre, edad e id. En UML los atributos se colocan listados en el primer compartimiento del rectángulo, colocando primero el nombre del atributo, dos puntos y luego el tipo de datos:



Allí pueden observar que he incluido los tres atributos de la clase Persona. Noten que la declaración utilizada es idéntica a la de Pascal o Modula, es decir, va el nombre del atributo, dos puntos y el tipo de datos.

Otro punto a observar es que todos los atributos que coloqué allí están precedidos por un signo de menos (-), eso es porque son atributos privados de la clase Persona. Si un atributo es público se antepone un signo de más (+), si es protegido va un numeral o almohadilla (#) y si su modificador de acceso es por defecto va el símbolo (~). Para nuestro ejemplo son todos privados, por tanto van todos con signo de menos.

Si un atributo es estático (static) entonces, además del símbolo que indica su acceso (privado(-) o público(+)) debe ir subrayado:



En ese ejemplo, el atributo id sería estático.


Otro tipo de atributos que podríamos querer incluir en un diagrama de clases son los atributos derivados. Si bien no los mencionamos directamente, los atributos derivados son aquellos que se calculan a partir del valor de otros atributos. Por ejemplo, para un Trabajador yo podría tener un atributo sueldoTotal que se calcule a partir de su sueldoBase multiplicado por sus diasTrabajados; o para un Triángulo yo podría tener un atributo llamado área que se calcule a partir del atributo base multiplicado por el atributo altura:



Allí tenemos una clase Triangulo que contiene un atributo area que está precedido por la barra inclinada (/). Eso indica que dicho atributo es derivado o calculado a partir de otros. En esa notación no queda explicitado cómo se realiza el cálculo del valor de dicho atributo, para esto se utilizan notas las cuales veremos luego.

_________________________________________________

Notación para operaciones:

Las operaciones van listadas en el último compartimiento del rectángulo que representa a la clase. Al igual que para los atributos usamos +, –, # y ~ para indicar si son públicas, privadas, protegidas o con el acceso por defecto (de paquete) respectivamente y las subrayamos si son estáticas. La notación es:

Código:
  1. nombreOpreacion(parámetros): tipoDeDatos




En este ejemplo he escrito las cuatro operaciones de nuestra clase Persona. Como ven todas tienen el signo de + antes que su nombre porque son públicas.

Observen que los argumentos se escriben como lo hacíamos en Pascal. Si hubiera más de uno en una misma operación se separan por coma. Las funciones indican su tipo de retorno luego de los dos puntos, tal como lo hacíamos antes. Los procedimientos no indican nada, ni siquiera ponemos void, aunque si queremos podemos incluirlo.

______________________________________________________

Asociaciones entre clases:

Decimos que dos clases están asociadas cuando al menos una de ellas contiene objetos de la otra. Por ejemplo, hay una asociación entre la clase ListaPersonas y la clase Personas justamente porque la primera contiene objetos de la segunda. Del mismo modo hay asociación entre la clase Herencia01 y la clase ListaPersonas porque la primera tiene objetos de la segunda, además también Herencia01 se asocia con Persona, Proveedor y Trabajador. En UML esto se nota simplemente uniendo las clases asociadas con una línea continua:



En una relación se suelen colocar multiplicidades, es decir, se suele especificar cuantos objetos de una clase habrá en la otra. Por ejemplo yo puedo querer decir que en ListaPersonas habrá muchas Personas ya que no será un número fijo.



El asterisco indica que la clase ListaPersonas tiene muchas Personas. La multiplicidad va al lado de la clase en cuestión, no al lado de la clase que contendrá objetos de la otra. En este caso coloqué el asterisco al lado de Persona porque es de esa clase de la que existirán muchos objetos siendo ListaPersonas la que los contendrá ¿se entiende? Dicho más claramente, la cantidad de objetos que existirán de una clase dada se coloca al lado de ella. Esto en función de la clase con la que la estamos asociando. Por ejemplo, si tuviéramos como tope que ListaPersonas puede contener un máximo de 1000 (mil) Personas, entonces allí iría un 1000 ya que estamos asociando a Persona con ListaPersona. No me interesa luego si en mi sistema tengo 50 ListaPersona (lo cual sumaría un máximo de 50000 objetos Persona). Ahora estamos asociando a la clase Persona con la clase ListaPersona y por tanto nos resumimos únicamente a establecer los vínculos entre ellas dos, todo lo demás no existe.

Ahora hay que establecer la multiplicidad de ListaPersonas según la clase Persona:



Coloqué un 1 (uno) al lado de ListaPersonas. Esto indica que una Persona es a una ListaPersonas. Si leemos toda esa línea de relación diríamos “Una Persona es a una ListaPersonas y una ListaPersonas es a muchas Personas”. ¿Cómo nos damos cuenta de todo eso? Bueno, con práctica. Lo que tienen que asimilar ahora es que la multiplicidad indica para una unidad de una clase cuántas unidades de la otra habrá. En este caso, para una unidad de Persona se indica una unidad de ListaPersonas, y para una unidad de ListaPersonas se indican muchas unidades de Persona.
Para aclarar estas relaciones suelen agregarse anotaciones así:



Las anotaciones pueden ser cualquier texto que aclare las ideas. Se indica en qué sentido van con un signo de > o de < como si fueran puntas de flecha. Entonces allí la anotación está dentro de indica que va desde Persona a ListaPersonas y dice que una Persona está dentro de una ListaPersonas. La anotación de abajo indica que va desde ListaPersonas hacia Persona y dice una ListaPersonas contiene muchas Personas. Según mi juicio estas anotaciones son de lo mejor y habría que incluirlas siempre, sin embargo no es obligación hacerlo, sí la multiplicidad.

Tabla de multiplicidades: Podemos indicar la cantidad de elementos de una clase en función de otra de muchas formas. En nuestro ejemplo vimos el asterisco (*) y un número; veámoslas todas:



Recordar que la multiplicidad se lee siempre a partir de una unidad de una clase hacia la otra. Una Persona se relaciona con tantas ListasPersonas. Una ListaPersonas se relaciona con tantas Personas. Siempre se lee igual.

Cuando una asociación tiene un único sentido este se indica en la línea que une a ambas clases con una flecha abierta:



Allí no he indicado multiplicidad ni nada, solo el sentido de la relación y una pequeña anotación. Entonces ¿cómo me doy cuenta cuando una relación es doble o cuando va en un sentido? Y si va en un sentido ¿en cuál? Bien, simplemente hay que pensar qué clase tendrá objetos de cual y listo, eso nos establece el sentido. Si lo analizamos un segundo, resulta entonces que la relación Persona ListaPersona entonces no es doble ya que la clase ListaPersonas contendrá objetos Persona pero a la inversa no. El diagrama correcto entonces es:



Rara vez sucede que la relación es doble, o sea, que una clase tiene objetos de la otra y viceversa.

________________________________________________

Herencia:

La Herencia en UML se denota fácil, incluso ya lo dije en su momento al hablar de la jerarquía de clases, solo que añadiré una corrección. La herencia se indica con una flecha de punta cerrada:



Si la flecha fuera de punta abierta entonces estaría indicando una asociación. Para la herencia siempre apuntamos a la clase base o superclase. Allí indicamos que Trabajador hereda de Persona. Podría incluir los atributos de Trabajador si quisiera. En este momento no hace falta.

NOTA: En UML esto que yo he llamado herencia se llama Generalización.

_____________________________________________________

Dependencias:

Hasta ahora las dependencias las habíamos dibujado simplemente con flechas, sobretodo en Modula. Ahora bien, dado esto del UML todo ha cambiado. Una flecha de punta abierta indica asociación, una de punta cerrada indica herencia o generalización, una línea sin puntas indica asociación doble. ¿Cómo indico dependencia?
Suele ser un problema el hecho de si en un diagrama de clases se colocarán dependencias o no. El hecho es que normalmente las dependencias son tantas que tienden a oscurecer el diagrama y dejarlo más confuso. A veces con ir indicando todo lo anterior (asociación, herencia, etc) ya alcanza, sin embargo puede que no. Para decir que una clase depende de otra simplemente usamos una flecha punteada de punta abierta:



Allí se dice que A depende de B. Como ven, es igual que con la herencia solo que cambiamos el tipo de flecha. Esto cambia un poco la idea que traíamos, donde si una clase ListaPersona depende de una clase Persona teníamos algo así:



Ahora el sentido de la flecha cambia y ListaPersonas apuntaría a Persona.


Notas o comentarios:

A veces no alcanza con las anotaciones para dejar una idea clara en el diagrama, o puede que lo que se quiere representar sea muy complejo y uno quiera explicar un poquito más. Para eso existen las notas o comentarios. Simplemente consta de una línea punteada que une el lugar al que se quiere comentar con una recuadro con el texto que detalla lo que se quiere explicar:



Es importante dibujar la punta superior derecha como si estuviera doblada, representando una hoja de papel. Si no fuera así, un rectángulo común representa una clase y pues, una nota no es una clase.

Esto es lo que podríamos usar para describir a un atributo derivado como el área del triángulo.

=============================================

EJERCICIO 1: HERENCIA SIN POLIMORFISMO

El ejercicio que dejaré a continuación no ha sido pensado por mí sino que lo he tomado del instituto donde estudié programación en Java, por tanto el crédito de su elaboración es para los docentes del curso de Programador Java dictado allí.

Idea:

La idea de este ejemplo es resolver un problema sin utilizar polimorfismo. El problema a resolver es recorrer un arreglo de Empleados, que pueden ser tanto Asalariados como Jornaleros, para luego permitir obtener un listado de todos ellos o calcular el sueldo de cada uno.

Se pide:

Hacer un programa Java, basado en consola, que pida al usuario la cantidad de empleados que desea ingresar, para luego permitir ingresar esa cantidad de empleados, sabiendo que estos sólo pueden ser Asalariados o Jornaleros. De todos los empleados se conoce su nombre; de los jornaleros se conoce además los días trabajados al mes y el jornal diario y de los asalariados se conoce además su sueldo fijo mensual.

La forma de cálculo del sueldo de un jornalero es mediante la fórmula:

sueldo = diasTrabajados * jornal;

mientras que la forma de cálculo del sueldo de un asalariado es mediante la fórmula:

sueldo = sueldoFijo * 0.85

Luego de pedir la cantidad de empleados a ingresar, se deberá mostrar un menú que permita al usuario elegir entre ingresar un jornalero (tecleando “J” o “j”) e ingresar un asalariado (tecleando “A” o “a”). En caso de que el usuario teclee cualquier otra cosa, se deberá mostrar un mensaje de error preguntándole de nuevo.
Luego de haber ingresado la cantidad deseada de empleados, se deberá mostrar un menú con dos opciones:

Código:
1) mostrar todos los datos de todos los empleados (un listado)
2) calcular (y mostrar) el sueldo de cada uno de los empleados.


Ambas opciones involucrarán una recorrida sobre el arreglo de empleados.

Comentarios:

  • Tener en cuenta que los objetivos del presente ejemplo pasan por escribir un programa que maneje conceptos de orientación a objetos en Java, manejo de entrada y salida estándar (en consola) y particularmente utilizar la herencia entre clases pero sin utilizar polimorfismo. El no uso del polimorfismo sobre las operaciones para mostrar y para calcular sueldos se evidencia ya que, para el caso de mostrar, disponemos de tres operaciones distintas (por tratarse de diferentes operaciones no estamos ante la presencia de polimorfismo) y para el caso de calcular los sueldos, no disponemos de ninguna operación en la clase base (la clase Empleado no tiene ninguna operación de cálculo de sueldo, lo cual impide la redefinición de la misma).
  • Todo esto traerá aparejado que cuando se desee recorrer el arreglo, ya sea para mostrar o calcular el sueldo de todos los empleados, se deberá primero verificar de qué tipo realmente es el objeto que cuelga de la posición actual del arreglo. Para esto se deberá utilizar el operador instanceof, quien devolverá la información dinámica de la referencia contenida en el arreglo. Luego, esta referencia deberá ser casteada al tipo real que corresponda, porque de lo contrario no se le podrán pedir las operaciones correspondientes (por ejemplo, a un Asalariado se le debe pedir mostrarAsalariado() y calcularSueldoAsalariado()). Esta verificación implica un IF por cada tipo de empleado (por cada sub-clase). Por lo tanto, no sólo se debe escribir más código que si se utilizara polimorfismo, sino que además si se agregan (o quitan) tipos de empleados, habrá que identificar todos los códigos que recorran el arreglo para agregar (o quitar) un IF. La conclusión es que se requiere un mayor esfuerzo de programación, no sólo para codificar por primera vez la solución, sino también para mantener el programa.
  • Vale la pena notar que el arreglo (que será de elementos de tipo Empleado declarado como Empleado[] emps = new Empleado[cant]; por ejemplo) cuando se le pide un elemento, devolverá en realidad un objeto de tipo Asalariado o Jornalero, pero éste se verá como de tipo Empleado, ya que para el arreglo son todos Empleados.


Diagrama de Clases:

A continuación se presenta el Diagrama de Clases UML de la solución que se debe implementar. No se incluye en el diagrama la clase que contiene al método main() con el menú principal y la entrada y salida. Tampoco se incluyen los métodos getXXX y setXXX que debe existir para poder acceder a los atributos de las clases, ya que éstos han sido declarados privados, como lo indica el signo de menos en el diagrama.



____________________________________


Ejercicio 2:

Crear una clase llamada ListaO que permita crear una lista simple encadenada de objetos Object con las siguientes operaciones:
  • Crear la lista vacía.
    Crear una lista a partir de un elemento.
  • Agregar al principio: addFirst(o: Object) --> El objeto no debe existir en la lista.
  • Agregar al final: addLast(o: Object) --> El objeto no debe existir en la
  • Quitar un elemento pasado como argumento: remove(o: Object)  El objeto debe existir en la lista.
  • Saber si la lista es vacía o no: isEmpty(): boolean.
  • Saber si un elemento existe en ella: exists(o: Object)boolean.
  • Obtener el primer elemento: getFirst(): Object -->Si la lista es vacía retorna null.
  • Obtener el último elemento: getLast(): Object -->Si la lista es vacía retorna null.
  • Obtener la cantidad de elementos: getSize(): int -->Si es vacía retorna cero (0).
  • Obtener el elemento en la posición X de la lista: getElem(posición: int):Object -->La posición debe ser 0 (para el primer elemento) o más. Si la posición pasada no existe en la lista entonces se retorna null. Si la lista es vacía no existe ninguna posición.
  • Quitar un elemento en una posición dada: remove(posición: int) -->La posición debe ser 0 (para el primer elemento) o más. Si la posición pasada no existe en la lista entonces retorna null. Si la lista es vacía no existe ninguna posición.
  • Saber si una posición es válida: isValidPos(posición: int): boolean.
  • Obtener la posición de un objeto de la lista dado: getPos(o: Object): int -->El objeto debe existir en la lista.
  • Eliminar todos los objetos de la lista dejándola vacía: removeAll()  Si la lista ya es vacía no se hace nada.


El diseño de esta clase queda totalmente por parte de ustedes.

_____________________________________________

Ejercicio 3:

Dada la clase ListaO diseñada e implementada en el ejercicio anterior, crear una clase ListaOInd que extienda a ListaO para poder manipular el manejo implícito de posiciones tal como lo vimos en Modula 2. La clase ListaOInd entonces debe agregar estas operaciones:

  • start(): Que retorne la posición corriente hacia el primer elemento de la lista.
  • add(o: Object): Que inserte un elemento en la posición corriente de la lista  El objeto no debe existir en la lista.
  • getActual():Object: Retorna el objeto corriente de la lista. Si la lista es vacía retorna null.
  • remove(): Elimina el objeto corriente de la lista. Si esta es vacía no se hace nada.
  • isEnd(): boolean: Indica si la posición actual es la posición final de la lista.
  • isStart(): boolean: Indica si la posición actual es la posición inicial de la lista.
  • next(): Mueve la posición corriente hacia el siguiente nodo. Si el nodo es el último entonces se pasa a la posición inicial de la lista  La lista no debe ser vacía.


Como consecuencia de esto tenemos que ListaOInd es una clase que puede manipular listas enlazadas de forma normal pero también puede manipular la indización implícita.

============================================

Hasta la próxima

Volver arriba
Ver perfil del usuario Enviar mensaje privado
pirdy
Usuario Inquieto


Registrado: 11 Feb 2010
Mensajes: 137

Mensaje Publicado: Miércoles 23 Ene 2013 00:17

Título del mensaje: Re: Lección 80: Introducción a UML

Responder citando

Muchas gracias por la leccion profe aunque para mi es avanzado ya que todavia no he acabado ni con Pascal pero por lo menos se toman conceptos nuevos.

¿Con que va a continuar profe?

Un fuerte saludo y le deseo lo mejor ya que creo que este año empezaba a estudiar para la enseñanza si no me equivoco.

Volver arriba
Ver perfil del usuario Enviar mensaje privado
Kyshuo Ayame
Moderador Global


Registrado: 07 Ene 2011
Mensajes: 1042

Mensaje Publicado: Miércoles 23 Ene 2013 01:34

Título del mensaje: Re: Lección 80: Introducción a UML

Responder citando

Pues la próxima lección será sobre Pilas y Colas mostrando un ejemplo para que un programa pueda evaluar correctamente las expresiones matemáticas. Luego seguirán otros conceptos propios de Java como Clases Abstractas, Interfaces y Paquetes para poder atacar por fin la creación de Interfaces Gráficas de Usuario.

Allí habrá todo un mundo de cosas por ver. Una vez eso esté "cocinado" comenzaremos a trabajar con sistemas divididos en capas. Pasaremos luego a las bases de datos y la persistencia. Veremos también, no se aún en qué orden, la creación de videojuegos en 2D y lo que valla surgiendo.

Hay mucho por hacer aún jeje... Saludos.

Volver arriba
Ver perfil del usuario Enviar mensaje privado
luis862



Registrado: 15 Jul 2013
Mensajes: 1

Mensaje Publicado: Lunes 15 Jul 2013 05:15

Título del mensaje: Re: Lección 80: Introducción a UML

Responder citando

hola profe buen curso, manejo el lenguaje "C", lo basico diria no tengo mucha experiencia pero lo manejo, pascal seria necesario para mi(no esta muy viejo ese lenguaje?) y en cuanto a modula nunca lo habia escuchado,
estoy viendo actualmente visual basic.net pero se me complica con el uso de oop ya que vengo de un lenguaje estructurado.

mi duda es la siguiente: quiero empezar java(su curso obviamente) lei al principio que decia que se tenia que seguir la secuencia de sus cursos. y como java es totalmente orientado a objetos, no se si ir de una a java o pasar primero por modula(aunque no se si sea bueno estudiar modula)

que me recomienda.

y gracias por el compartir esa informacion valiosa.

Volver arriba
Ver perfil del usuario Enviar mensaje privado
Kyshuo Ayame
Moderador Global


Registrado: 07 Ene 2011
Mensajes: 1042

Mensaje Publicado: Lunes 15 Jul 2013 16:07

Título del mensaje: Re: Lección 80: Introducción a UML

Responder citando

El curso, como bien lo indica su título, está orientado a comenzar desde cero. Pascal es viejo pero hoy día se utiliza en ámbitos académicos por lo fácil que es aprender a programar con él, en este sentido es excelente para quién no sabe nada y pretende adentrarse a este mundo. Luego se utiliza Modula como una extensión de Pascal para acercarse a la programación orientada a objetos sin darla de lleno para así, llegar a Java y darle duro.

Tu dices quen o sabes si sea bueno estudiar Modula, pues no es que sea bueno o malo, lo único que implica es tiempo. Quiero dejarte claro que las primeras partes (Pascal y Modula) no son cursos de esos lenguajes, son cursos de programación usando como herramienta a los lenguajes. Así, con Pascal no doy un CURSO DE PASCAL, enseño a programar usando a ese lenguaje como herramienta, es decir, enseño que son variables, constantes, bucles, condiciones, etc. Luego en Modula no doy un curso de Modula, es más bien un curso donde se ven ESTRUCTURAS DE DATOS y ALGORITMOS para resovler problemas complejos, así se habla de LISTAS ENLAZADAS, ÁRBOLES BINARIOS y algún otro tema más.

En lo que a mí respecta, te diría que leas desde el principio, seguramente avanzarás muy rápido si ya sabes programar pudiendo además intentar aplicar lo que enseño en Pascal a C.

Si ese camino no te atrae, pues podrías (y digo "podrías") intentar iniciar desde Java a ver cómo le sigues el hilo, quizá te sea sencillo. Si no es así pues a leer un poco desde atrás.

Gastar tiempo en aprender es en realidad invertirlo, y las inversiones si son bien pensadas siempre dan frutos. Seguro que leyendo Pascal aprenderás cosas que no conocías.

Un saludo y cualquier cosa a tus ordenes.

Volver arriba
Ver perfil del usuario Enviar mensaje privado
Alfonso Lara
Usuario Iniciado


Registrado: 07 May 2019
Mensajes: 13

Mensaje Publicado: Domingo 02 Jun 2019 22:23

Título del mensaje: Lección 80: Introducción a UML

Responder citando

Cita:
Esta verificación implica un IF por cada tipo de empleado (por cada sub-clase). Por lo tanto, no sólo se debe escribir más código que si se utilizara polimorfismo, sino que además si se agregan (o quitan) tipos de empleados, habrá que identificar todos los códigos que recorran el arreglo para agregar (o quitar) un IF. La conclusión es que se requiere un mayor esfuerzo de programación, no sólo para codificar por primera vez la solución, sino también para mantener el programa.


A pesar de haber realizado el ejercicio número 1, llamado HERENCIA SIN POLIMORFISMO no me percaté de lo que cito. Una anotación muy importante.
Ya en el desarrollo del ejercicio mismo me ayudó mucho esta sintaxis para el casteo:
Código:
 ((b)a).operacionx();

Donde b pertenece a clase B, a pertenece a clase A, y B hereda de A.

Volver arriba
Ver perfil del usuario Enviar mensaje privado
Responder al Tema
Mostrar mensajes anteriores:   
Ir a:  
Todas las horas están en GMT + 2 Horas

Temas relacionados

Tema Autor Foros Respuestas Publicado
El foro no contiene ningún mensaje nuevo

Curso de Introducción al desarrollo de videojue...

Tesis Programación de juegos o videojuegos 2 Jueves 06 Mar 2014 21:40 Ver último mensaje
El foro no contiene ningún mensaje nuevo

CA0 001: Introducción y preparación.

Kyshuo Ayame Programación en general 2 Jueves 20 Feb 2014 21:36 Ver último mensaje
El foro no contiene ningún mensaje nuevo

Lección 101: Lectura/Escritura de archivos de t...

Kyshuo Ayame Programación en general 3 Sábado 26 Oct 2013 03:04 Ver último mensaje
El foro no contiene ningún mensaje nuevo

Lección 100: JMasterMind

Kyshuo Ayame Programación en general 7 Lunes 02 Sep 2013 20:29 Ver último mensaje
El foro no contiene ningún mensaje nuevo

Lección 99: JBuscaminas - GUI - Mouse Event

Kyshuo Ayame Programación en general 2 Lunes 19 Ago 2013 16:55 Ver último mensaje
Panel de Control
No puede crear mensajes, No puede responder temas, No puede editar sus mensajes, No puede borrar sus mensajes, No puede votar en encuestas,