QUE ES POO EN SOFTWARE
Los objetos manipulan los datos de entrada para la obtención de datos de salida permiten al usuario la creación de sus propias bibliotecas.
Está basada en varias técnicas: herencia, cohesión, abstracción, polimorfismo, acoplamiento y encapsulamiento.
Su uso se popularizó a principios de la década de 1990. En la actualidad, existe una gran variedad de lenguajes de programación que soportan la orientacion
específicos, donde cada objeto ofrece una funcionalidad especial.
Muchos de los objetos prediseñados de los lenguajes de programación actuales permiten la agrupación en bibliotecas o librerías, sin embargo, muchos de estos lenguajes
Está basada en varias técnicas: herencia, cohesión, abstracción, polimorfismo, acoplamiento y encapsulamiento.
Su uso se popularizó a principios de la década de 1990. En la actualidad, existe una gran variedad de lenguajes de programación que soportan la orientacion
específicos, donde cada objeto ofrece una funcionalidad especial.
Muchos de los objetos prediseñados de los lenguajes de programación actuales permiten la agrupación en bibliotecas o librerías, sin embargo, muchos de estos lenguajes
QUE ES UN OBJETO EN POO
https://www.draw.io/ untitled driagram – draw.io diseño
https://www.draw.io/ untitled driagram – draw.io diseño
Estados en objetos,Mensajes en objetos
QUE ES UNA CLASE EN POO
Clases en POO
Las clases son declaraciones de objetos, también se podrían definir como abstracciones de objetos. Esto quiere decir que la definición de un objeto es la clase. Cuando programamos un objeto y definimos sus características y funcionalidades en realidad lo que estamos haciendo es programar una clase. En los ejemplos anteriores en realidad hablábamos de las clases coche o fracción porque sólo estuvimos definiendo, aunque por encima, sus formas.
Propiedades en clases
Las propiedades o atributos son las características de los objetos. Cuando definimos una propiedad normalmente especificamos su nombre y su tipo. Nos podemos hacer a la idea de que las propiedades son algo así como variables donde almacenamos datos relacionados con los objetos.
Métodos en las clases
Son las funcionalidades asociadas a los objetos. Cuando estamos programando las clases las llamamos métodos. Los métodos son como funciones que están asociadas a un objeto.
CUALES SON LOS 4 PILARES FUNDAMENTALES DE POO
Pólimorfismo: cambiar atributos de un objeto
Encapsulamiento: Datos públicos,datos privados, datos protegidos
Abstraccion: Identificar las características y comportamientos de un objeto para construir la clase.
Abstracción
De acuerdo a la RAE, una de las acepciones de abstraer es:
“Hacer caso omiso de algo, o dejarlo a un lado.” Y ofrece como ejemplo: “Centremos la atención en lo esencial abstrayendo DE consideraciones marginales.”
El ejemplo dado captura la esencia del concepto de abstraer. Cuando hacemos una abstracción, queremos omitir detalles que no son necesarios para nosotros, y queremos solamente mostrar lo que sí es relevante.
Desde el punto de vista del desarrollo de software, podemos ver que con una clase podemos realizar una abstracción de una entidad del mundo real. Tomemos por ejemplo la clase carro que hicimos, esta tiene la posibilidad de guardar datos relacionados a la marca y al año de salida al mercado del carro, pero, ¿Por qué solamente estas dos informaciones? Un carro del mundo real tiene más propiedades, como el color y el modelo. Sin embargo, debemos preguntarnos, ¿Son estas informaciones relevantes para nuestro software?
Nuestra clase abstrae todo lo que representa un carro, tomando solamente lo que nos interesa, descartando todo lo demás.
Encapsulamiento
Ya sabes que puedes utilizar clases para modelar entidades las cuales son relevantes para tu aplicación, sabes además que puedes guardar datos dentro de objetos, y también ejecutar funcionalidad. La pregunta que debemos hacernos es, ¿Debe cualquiera poder modificar de manera directa estos datos? ¿Debe cualquiera ejecutar cualquier funcionalidad de nuestros objetos en cualquier momento? Normalmente esto no es algo que queremos, nosotros queremos poder controlar la manera en que se asignen los datos, queremos poder controlar quién ve la data interna de nuestros objetos, e incluso quizás queramos controlar la ejecución de funcionalidad de nuestros objetos. Para esto tenemos el concepto de encapsulamiento.
El encapsulamiento nos permite controlar quien puede ver y utilizar los distintos módulos internos de nuestro sistema. En términos de clases, con el encapsulamiento definimos el acceso a los miembros de la clase.
En C# podemos utilizar modificadores de acceso para definir el control de agentes externos a distintas partes de nuestro sistema, como clases, miembros de las clases, interfaces, entre otros. Supongamos que tenemos una variable, llamada velocidad, la cual queremos colocar en nuestra clase Carro, para indicar la velocidad en la cual se desplaza un vehículo en particular. Sin embargo, queremos que solamente dentro de la clase podamos ver y modificar el valor de dicha variable. Esto lo podemos hacer o con un campo o con una propiedad. Hagámoslo con una propiedad:
public class Carro
{
public string Marca;
public int AñoSalidaAlMercado { get; set; }
private int Velocidad { get; set; }
public void Acelerar()
{
Velocidad += 10;
}
}
Cuando hagamos una instancia de la clase Carro, no podremos acceder al valor de la propiedad Velocidad, ni tampoco podemos alterarlo desde afuera. Lo que sí podemos hacer es utilizar la función acelerar para aumentar el valor de la velocidad en 10 unidades. Esta es una de las ventajas del encapsulamiento: Nos permite controlar la manera en que se va a alterar la data interna de nuestro objeto.
Si quisiéramos que agentes externos puedan ver el valor la propiedad Velocidad, pero que no puedan alterar libremente dicho valor, podemos utilizar la siguiente sintaxis:
public int Velocidad { get; private set; }
Herencia
Compartir código es una importante y crucial característica de cualquier proyecto de software. Compartir código permite ahorrar trabajo cuando queremos hacer un cambio en nuestro sistema; permite que un solo algoritmo pueda procesar distintas clases de entidades; entre otras cosas.
Hay varias maneras de compartir código, una de ellas es utilizando herencia. La herencia es una relación especial entre dos clases, la clase base y la clase derivada, en donde la clase derivada obtiene la habilidad de utilizar ciertas propiedades y funcionalidades de la clase base, incluso pudiendo sustituir funcionalidad de la clase base. La idea es que la clase derivada “hereda” algunas de las características de la clase base.
Podemos ver un ejemplo de la clase Carro. Un carro es un tipo de vehículo, además, queremos procesar otro tipo de vehículos, cada uno con su entidad, como camión. Un carro y un camión comparten el concepto de velocidad, además, ambos tienen la capacidad de acelerar, y ambos tienen la capacidad de ir de reversa, sin embargo, cuando un camión va de reversa, este debe emitir un sonido. Finalmente, un carro debe poder encender la radio. Vamos entonces a modelar esto:
public class Vehículo
{
public string Marca;
public int AñoSalidaAlMercado { get; set; }
public int Velocidad { get; private set; }
public void Acelerar()
{
Velocidad += 10;
}
public virtual void Reversa()
{
Console.WriteLine("Voy de reversa!");
}
}
public class Carro: Vehículo
{
public void EncenderRadio()
{
Console.WriteLine("Encendiendo la radio");
}
}
public class Camión: Vehículo
{
public override void Reversa()
{
base.Reversa();
Console.WriteLine("BEEP BEEP BEEP!");
}
}
Vemos que tenemos 3 clases: Vehículo, Carro y Camión. Carro y Camión heredan de la clase Vehículo. La relación de herencia se representa de esta manera:
class Carro: Vehículo
Con esta sintaxis decimos que Carro es una clase derivada de Vehículo.
Vemos además que la función Acelerar está definida en la clase Vehículo, esto hace que todas las clases derivadas pueden hacer uso de dicha función. Lo mismo sucede con los campos y propiedades.
Ciertamente las clases Carro y Camión pueden definir sus propios miembros que no se relacionan con la clase Vehículo. Por ejemplo, la clase Carro tiene el método EncenderRadio el cual solo esta lo tiene.
Podemos también modificar funcionalidad de la clase base. Para esto, en la clase base, el método debe estar marcado como virtual. Y cuando se quiera sobrescribir, es decir, cambiar o agregar funcionalidad, esto lo podemos hacer haciendo un override, tal cual vemos en la clase Camión. Dentro del método Reversa de la clase Camión, tenemos el código base.Reversa(); el cual sirve para invocar el método reversa de la clase base.
Podemos utilizar el código anterior de la siguiente manera:
Carro miCarro = new Carro();
miCarro.AñoSalidaAlMercado = 2018;
miCarro.Acelerar();
Console.WriteLine(miCarro.Velocidad);
miCarro.Reversa();
Console.WriteLine("-------");
Camión miCamion = new Camión();
miCamion.Acelerar();
miCamion.AñoSalidaAlMercado = 2012;
miCamion.Reversa();
Clases Abstractas
¿Qué tal si quisiéramos que la clase Vehículo no pudiera ser instanciada? Podemos marcarla como una clase abstracta. Una clase abstracta es aquella que no puede ser instanciada. Es útil en situaciones de herencia donde no queremos que los usuarios instancien la clase base, sino que queremos que instancien solamente las clases derivadas. Para marcar la clase Vehículo como abstracta utilizamos abstract:
public abstract class Vehículo
¿Qué tal si quisiéramos obligar a las clases derivadas a implementar una función específica, sin que la clase base dé una implementación por defecto? Para esto podemos marcar el método como abstract. Ejemplo:
public abstract void MetodoObligatorio();
Interfaces
Las interfaces nos ayudan a realizar otro tipo de herencia. Mientras que una clase base nos ofrece implementación por defecto de algunos métodos, como el método reversa de la clase Vehículo, las interfaces nos ofrecen un conjunto de miembros que las clases que implementan la interfaz deben implementar. Las interfaces no pueden ser instanciadas, igual que las clases abstractas.
Históricamente, una diferencia fundamental entre interfaces y clases abstractas es que las clases abstractas nos permiten crear implementaciones por defecto de métodos y las interfaces no. Sin embargo, es posible que en C# 8 eso cambie con la introducción de implementaciones por defecto en interfaces.
Nota: Aunque las interfaces son un tipo de herencia, es normal referirse a herencia solamente al caso en el que tenemos una clase base.
Polimorfismo
Cuando empezamos a hablar de herencia, dijimos que la herencia “permite que un solo algoritmo pueda procesar distintas clases de entidades”. La idea es que podemos tener una función la cual reciba un parámetro, como una clase base, y podemos pasarle a ese método objetos que sean instancias de las clases derivadas de dicha clase base. Lo mismo ocurre si el método recibe como parámetro una interfaz. Podemos pasarle a dicho método cualquier clase que implemente dicha interfaz.
Polimorfismo significa de muchas formas. En nuestro caso llamamos polimorfismo cuando un método recibe un parámetro que abarca varios tipos.
Veamos un ejemplo de polimorfismo donde pasamos a un método la clase base Vehículo:
static void Reparar(Vehículo vehículo)
{
Console.WriteLine("Iniciando reparación");
Console.WriteLine("Probando acelerador");
Console.WriteLine($"Velocidad inicial {vehículo.Velocidad}");
vehículo.Acelerar();
Console.WriteLine($"Velocidad final {vehículo.Velocidad}");
Console.WriteLine("Probando reversa");
vehículo.Reversa();
Console.WriteLine("Listo!");
}
Este método invoca los métodos Acelerar y Reversa del vehículo que se le envíe como parámetro. La ventaja que esto ofrece es que podemos generalizar algoritmos para que funcionen con distintos tipos. En este caso, este método va a funciona con cualquier clase que herede de Vehículo, en tal sentido, incluso si en el futuro agregamos la clase Motocicleta, la cual hereda de Vehículo, podemos utilizar esta nueva clase con el método Reparar, y va a funcionar perfectamente. De esta manera se da el polimorfismo, pues el método reparar puede trabajar con varios tipos distintos.
En el método reparar no podemos hacer uso del método EncenderRadio de la clase Carro, pues la clase Vehículo no implementa dicho método. Lo que podríamos hacer es utilizar el operador is para castear a Carro en caso de que el Vehículo sea un carro:
if (vehículo is Carro miCarro)
{
miCarro.EncenderRadio();
}
Esta sintaxis es una manera resumida de decir:
if (vehículo is Carro)
{
Carro miCarro = vehículo as Carro;
miCarro.EncenderRadio();
QUE ES UML
Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y compuestos reciclados.
Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.
Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional, Rational Unified Process o RUP), pero no especifica en sí mismo qué metodología o proceso usar.
QUE SON DIAGRAMAS UML
Los diagramas de UML está compuesto por diversos elementos gráficos que se combinan para conformar diagramas. Debido a que el UML es un lenguaje, cuenta con reglas para combinar tales elementos. La finalidad de los diagramas es presentar diversas perspectivas de un sistema, a las cuales se les conoce como modelo. Recordemos que un modelo es una representación simplificada de la realidad; el modelo UML describe lo que supuestamente hará un sistema, pero no dice cómo implementar dicho sistema.
ENUNCIAR 8 TIPOS DE MDIAGRAMAS UL
Diagramas estructurales
Los diagramas estructurales muestran la estructura estática del sistema y sus partes en diferentes niveles de abstracción. Existen un total de siete tipos de diagramas de estructura:
Diagrama de clases
Muestra la estructura del sistema, subsistema o componente utilizando clases con sus características, restricciones y relaciones: asociaciones, generalizaciones, dependencias, etc.
Diagrama de componentes
Muestra componentes y dependencias entre ellos. Este tipo de diagramas se utiliza para el desarrollo basado en componentes (CDB), para describir sistemas con arquitectura orientada a servicios (SOA).
Diagrama de despliegue
Muestra la arquitectura del sistema como despliegue (distribución) de artefactos de software.
Diagrama de objetos
Un gráfico de instancias, incluyendo objetos y valores de datos. Un diagrama de objeto estático es una instancia de un diagrama de clase; muestra una instantánea del estado detallado de un sistema en un punto en el tiempo.
Diagrama de paquetes
Muestra los paquetes y las relaciones entre los paquetes.
Diagrama de perfiles
Diagrama UML auxiliar que permite definir estereotipos personalizados, valores etiquetados y restricciones como un mecanismo de extensión ligero al estándar UML. Los perfiles permiten adaptar el metamodelo UML para diferentes plataformas o dominios.
Diagrama de estructura compuesta
Muestra la estructura interna (incluidas las partes y los conectores) de un clasificador estructurado.
Diagramas de comportamiento
A diferencia de los diagramas estructurales, muestran como se comporta un sistema de información de forma dinámica. Es decir, describe los cambios que sufre un sistema a través del tiempo cuando está en ejecución. Hay un total de siete diagramas de comportamiento, clasificados de la siguiente forma:
Diagrama de actividades
Muestra la secuencia y las condiciones para coordinar los comportamientos de nivel inferior, en lugar de los clasificadores que poseen esos comportamientos. Estos son comúnmente llamados modelos de flujo de control y flujo de objetos.
Diagrama de casos de uso
Describe un conjunto de acciones (casos de uso) que algunos sistemas o sistemas (sujetos) deben o pueden realizar en colaboración con uno o más usuarios externos del sistema (actores) para proporcionar algunos resultados observables y valiosos a los actores u otros interesados del sistema(s).
Diagrama de máquina de estados
Se utiliza para modelar el comportamiento discreto a través de transiciones de estados finitos. Además de expresar el comportamiento de una parte del sistema, las máquinas de estado también se pueden usar para expresar el protocolo de uso de parte de un sistema.
Diagramas de interacción
Es un subconjunto de los diagramas de comportamiento. Comprende los siguientes diagramas:
Diagrama de secuencia
Es el tipo más común de diagramas de interacción y se centra en el intercambio de mensajes entre líneas de vida (objetos).
Diagrama de comunicación
Se enfoca en la interacción entre líneas de vida donde la arquitectura de la estructura interna y cómo esto se corresponde con el paso del mensaje es fundamental. La secuencia de mensajes se da a través de una numeración.
Diagrama de tiempos
Se centran en las condiciones que cambian dentro y entre las líneas de vida a lo largo de un eje de tiempo lineal.
Diagrama global de interacciones
Los diagramas global de interacciones brindan una descripción general del flujo de control donde los nodos del flujo son interacciones o usos de interacción.
Es un subconjunto de los diagramas de comportamiento. Comprende los siguientes diagramas:
Diagrama de secuencia
Es el tipo más común de diagramas de interacción y se centra en el intercambio de mensajes entre líneas de vida (objetos).
Diagrama de comunicación
Se enfoca en la interacción entre líneas de vida donde la arquitectura de la estructura interna y cómo esto se corresponde con el paso del mensaje es fundamental. La secuencia de mensajes se da a través de una numeración.
Diagrama de tiempos
Se centran en las condiciones que cambian dentro y entre las líneas de vida a lo largo de un eje de tiempo lineal.
Diagrama global de interacciones
Los diagramas global de interacciones brindan una descripción general del flujo de control donde los nodos del flujo son interacciones o usos de interacción.
¿Qué versiones existen de UML?
La versión actual de UML es la 2.5.1 y fue publicada en Junio de 2015. UML es gestionada y actualizada por la OMG (Object Manabement Group).
Los creadores originales de UML son 3: Jim Rumbaugh, Grady Booch e Ivar Jacobson.
Esta es la lista de versiones que han sido publicadas:
1.1 – Noviembre de 1997
1.3 – Marzo de 2000
1.4 – Septiembre de 2001
1.5 – Marzo de 2003
1.4.2 – Enero de 2005
2.0 – Octubre de 2005
2.1 – Abril de 2006
2.1.1 – Febrero de 2007
2.1.2 – Noviembre de 2007
2.2 – Febrero de 2009
2.3 – Mayo de 2010
2.4.1 – Agosto de 2011
2.5 – Junio de 2015
2.5.1 – Diciembre de 2017 (Última versión)
https://caprendizaje.sena.edu.co/sgva/SGVA_Diseno/pag/login.aspx
La versión actual de UML es la 2.5.1 y fue publicada en Junio de 2015. UML es gestionada y actualizada por la OMG (Object Manabement Group).
Los creadores originales de UML son 3: Jim Rumbaugh, Grady Booch e Ivar Jacobson.
Esta es la lista de versiones que han sido publicadas:
1.1 – Noviembre de 1997
1.3 – Marzo de 2000
1.4 – Septiembre de 2001
1.5 – Marzo de 2003
1.4.2 – Enero de 2005
2.0 – Octubre de 2005
2.1 – Abril de 2006
2.1.1 – Febrero de 2007
2.1.2 – Noviembre de 2007
2.2 – Febrero de 2009
2.3 – Mayo de 2010
2.4.1 – Agosto de 2011
2.5 – Junio de 2015
2.5.1 – Diciembre de 2017 (Última versión)
https://caprendizaje.sena.edu.co/sgva/SGVA_Diseno/pag/login.aspx
DIAGRAMA DE CASOS DE USO
Un caso de uso es la descripción de una acción o actividad. Un diagrama de caso de uso es una descripción de las actividades que deberá realizar alguien o algo para llevar a cabo algún proceso. Los personajes o entidades que participarán en un diagrama de caso de uso se denominan actores. En el contexto de ingeniería del software, un diagrama de caso de uso representa a un sistema o subsistema como un conjunto de interacciones que se desarrollarán entre casos de uso y entre estos y sus actores en respuesta a un evento que inicia un actor principal. Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la especialización y la generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requisitos del sistema al mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo.
Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. A menudo es útil para complementar a un diagrama de clases, pues el diagrama de secuencia se podría describir de manera informal como "el diagrama de clases en movimiento", por lo que ambos deben estar relacionados entre sí (mismas clases, métodos, atributos...). Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos;
Típicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si se dispone de la descripción de cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.
EJEMPLO DE CLASE
EJERCICIO PROPUESTO
DIAGRAMA DE ESTADOS
Diagrama de Estado: Este muestra la secuencia de estados por los que pasa bien un caso de uso, un objeto a lo largo de su vida, o bien todo el sistema. Es una forma de representación gráfica más intuitiva de los autómatas finitos basadas en dígrafos con arcos acotados llamados transiciones en los cuales se ponen los símbolos de tránsito entre un vértice (estado) y otro y se identifican los estados de partida y los de aceptación del resto. Los diagramas de estados finitos son también representaciones más cómodas para su elaboración, legibilidad y comprensión de distintos tipos de abstracciones computacionales de reconocimiento como los autómatas de pila y las máquinas de Turing.
EJERCICIO DE CLASE PROPUESTO
DIAGRAMAS DE ACTIVIDADES
El Diagrama de Actividad es un diagrama de flujo del proceso multi-propósito que se usa para modelar el comportamiento del sistema. Los diagramas de actividad se pueden usar para modelar un Caso de Uso, o una clase, o un método complicado.
Un diagrama de actividad es parecido a un diagrama de flujo; la diferencia clave es que los diagramas de actividad pueden mostrar procesado paralelo (parallel processing). Esto es importante cuando se usan diagramas de actividad para modelar procesos 'bussiness' algunos de los cuales pueden actuar en paralelo, y para modelar varios hilos en los programas concurrentes.
ACTIVIDAD
Explorar paso a paso como instalar a un pc de escritorio
En ingeniería de software, un diagrama de clases en Lenguaje Unificado de Modelado (UML) es un tipo de diagrama de estructura estática que describe la estructura de un sistema mostrando las clases del sistema, sus atributos, operaciones (o métodos), y las relaciones entre los objetos.
EJERCICIO DE CLASE
Crear un diagrama de clases que tenga el nombre del cliente,nacionalidad,Boleto,numero de boleto,vuelo,elid del vuelo,fecha de salida,destino,motor del avión,marca del avión,año de fabricación del avión,avión,numero de placa y modelo del avión, decir si es avión de carga ponerle la capacidad de carga, si es avión de pasajeros poner la cantidad de asientos
DIAGRAMAS DE COMPONENTES
Un diagrama de componentes representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema.
Debido a que los diagramas de componentes son más parecidos a los diagramas de casos de usos, éstos son utilizados para modelar la vista estática y dinámica de un sistema. Muestra la organización y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema. En él se situarán librerías, tablas, archivos, ejecutables y documentos que formen parte del sistema. Uno de los usos principales es que puede servir para ver qué componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema.
EJERCICIOS
EJERCICIO DE CLASE DIAGRAMA DE CASOS DE USO SOFTWARE
EJERCICIO DE SOFWARE DE ESTADO CIVIL DIAGRAMA DE ESTADOS
0 comentarios:
Publicar un comentario