Unidad 4. Diseno Orientado a Objetos Con UML

Análisis y diseño orientado a objetos Programa desarrollado

Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 1

Ingeniería en Desarrollo de software

CUATRIMESTRE: 04

Programa de la asignatura:

Análisis y diseño orientado a objetos

Unidad 4. Diseño Orientado a Objetos con UML

(Lenguaje Unificado de Modelado)

Clave: 160920413 / 150920413



Índice

Unidad 4. Diseño orientado a objetos con UML (Lenguaje Unificado de Modelado) ............ 3

Presentación de la unidad .............................................................................................. 3

Propósito ........................................................................................................................ 3

Competencia específica ................................................................................................. 3

4.1. Representación de objetos y clases con UML ......................................................... 4

4.1.1. Representación de clases con UML ..................................................................... 4

4.1.2. Representación de objetos con UML .................................................................... 5

Actividad 1. Representación de clases y objetos con UML ............................................. 6

4.2. Diagramas y documentación para el diseño del software con UML ......................... 6

4.2.1. Casos de uso ....................................................................................................... 8

4.2.2. Escenarios del caso de uso ................................................................................ 12

4.2.3. Diagramas de actividades .................................................................................. 14

4.2.4. Diagrama secuencial .......................................................................................... 16

4.2.5. Diagrama de clase.............................................................................................. 17

Actividad 2. Aplicación de diagramas ........................................................................... 19

4.2.6. Diagrama de gráfico de estado ........................................................................... 20

Actividad 3. Diseño de diagramas en UML ................................................................... 21

Autoevaluación ............................................................................................................. 22

Evidencia de aprendizaje. Diagramas UML .................................................................. 22

Cierre de la unidad ....................................................................................................... 23

Para saber más ............................................................................................................ 23

Fuentes de consulta ..................................................................................................... 23



Unidad 4. Diseño orientado a objetos con UML (Lenguaje Unificado de

Modelado)

Presentación de la unidad

El lenguaje unificado de modelado (UML) brinda un sistema de trabajo con objetos,

basado en el análisis y diseño, con una consistencia del lenguaje para especificar,

construir y documentar un sistema de software.

Esta especificación representa la convergencia de las mejores prácticas en la tecnología

de la industria de objetos. El UML es un sucesor de los lenguajes de modelado de objetos

derivado de las tres metodologías (Booch, OMT y OOSE).

El UML es un lenguaje de modelado que integra a la comunidad orientada a objetos los

conceptos de modelado básico y permite desviaciones, las cuales se expresan en

términos de mecanismos de extensión. Es un conjunto preciso que consiste en la

definición de la semántica y notación del UML, definiendo también cómo se maneja el

Lenguaje de Especificación de Objetos.

Propósito

Con el uso constante de UML se podrá lograr una mejor comprensión entre los negocios y

los requerimientos del sistema y los procesos que se deben hacer para que se cumplan

éstos. En cada paso el sistema se define de manera más clara y precisa.

Así, al terminar el análisis y diseño se tienen de forma precisa y detallada las

especificaciones de clases y objetos, evitando el costo de una mala planeación en el

comienzo.

Competencia específica

Aplicar los tipos de diagramas para estructurar un sistema orientado a objetos mediante el

método de modelado UML.



4.1. Representación de objetos y clases con UML

En el diseño orientado a objetos todo se presenta través de objetos y clases. Por lo

general cuando se diseña una clase no es necesario mostrar todos los atributos ni todas

sus operaciones, basta con mostrar los subconjuntos más relevantes para organizarlos.

Un objeto, como recordarás, es la unidad mínima en la representación de algo real, y una

clase es un objeto con atributos y métodos o comportamientos.

4.1.1. Representación de clases con UML

Clases. Una clase es representada por medio de un marco subdividido en tres niveles: En

el primer nivel se muestra el nombre de la clase, el siguiente presenta los atributos y en el

último nivel se incluyen las operaciones.

Una clase puede representarse de forma esquemática con los atributos y operaciones

suprimidos, siendo entonces tan solo un rectángulo con el nombre de la clase. En la

siguiente figura se ve cómo una misma clase puede representarse a distinto nivel de

detalle, según interese, y según la fase en la que se esté.



Figura 4.1. Representacion de clases con diferentes tipos de detalles

4.1.2. Representación de objetos con UML

Objetos. El objeto es representado de forma similar que una clase. En la parte superior

del marco aparece el nombre del objeto junto con el nombre de la clase, subrayados.

El siguiente ejemplo muestra la sintaxis: nombre_del_objeto: nombre_de_la_clase. Puede

representarse un objeto sin un nombre específico, entonces sólo aparece el nombre de la

clase.



Figura 4.2. Representación de objeto sin nombre

Actividad 1. Representación de clases y objetos con UML

Con el fin de reflexionar sobre la asignatura, en el foro: Cómo representar clases y

objetos con UML construirás un concepto propio sobre la mejor manera de representar

clases y objetos con UML, tomando en cuenta los temas abordados con anterioridad y los

comentarios de tus compañeros.

Instrucciones:

1. Recupera lo sustancial de las lecturas del tema 4.1. Representación de objetos y

clases con UML.

2. Identifica la forma más óptima para representar diferentes objetos dados por tu

Facilitador(a).

3. Ingresa al foro y genera una nueva entrada.

4.2. Diagramas y documentación para el diseño del software con UML



Los diagramas se utilizan para representar diferentes perspectivas de un sistema, de

forma que un diagrama es una proyección del propio sistema

El diseño de modelado UML proporciona un amplio conjunto de diagramas que

normalmente se usan en pequeños subconjuntos para poder representar las vistas

principales de la arquitectura de un sistema.

Los seis diagramas de UML que más se utilizan son:

1. Diagrama de caso de uso: describe cómo se usa el sistema; es ideal para comenzar.

2. Escenario de caso de uso (aunque técnicamente no es un diagrama), es una

descripción verbal de las excepciones.

3. Diagrama de actividades, muestra el recorrido de las actividades.

4. Diagramas de secuencias, muestran el orden de actividades y las relaciones de las

clases.

5. Diagramas de clases, muestran las clases y las relaciones.

6. Diagramas de gráfico de estado, muestra las transiciones de estado. Cada clase podría

crear un diagrama de gráfico de estado.

La siguiente figura muestra cómo se relacionan:



Figura 4.3. Conjunto de diagramas UML (Kendall & Kendall, 2005: 665)

4.2.1. Casos de uso

Un Diagrama de casos de uso muestra la relación entre los actores y los casos de uso del

sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su

interacción externa.

El caso de uso es la descripción de las secuencias de acciones recíprocas entre dos o

más objetos que se producen entre un actor y el sistema, cuando el actor usa el sistema

para llevar a cabo una tarea específica. Expresa una unidad coherente de funcionalidad, y

se representa en el Diagrama de casos de uso mediante una elipse con el nombre del

caso de uso en su interior. El nombre del caso de uso debe reflejar la tarea específica que

el actor desea llevar a cabo usando el sistema.

Los casos de uso son la parte realmente útil del documento que describe el caso de uso,

ya que en este documento se explica la forma de interactuar entre el sistema y el usuario.



En los casos de uso, la palabra uso se utiliza como sustantivo en lugar de verbo. Un

modelo de caso de uso muestra lo que hace un sistema sin describir cómo lo hace,

muestra como si tuviera un usuario fuera del sistema, mostrando los requerimientos y se

puede hacer usando los objetos y sus interacciones para derivar comportamiento del

objeto, atributos y relaciones.

Los actores dentro del modelado UML son aquellos que interactúan con el sistema a

desarrollar. Las precondiciones son los hechos que se han de cumplir para que el flujo de

evento se pueda llevar a cabo. El flujo de eventos corresponde a la ejecución normal y

exitosa del caso de uso. Los flujos alternativos son los que permiten indicar qué es lo que

hace el sistema en los casos menos frecuentes e inesperados. Por último, las

poscondiciones son los hechos que se ha de cumplir si el flujo de eventos normal se ha

ejecutado correctamente.

El diagrama de caso de uso contiene el actor y símbolos de caso de uso, y además las

líneas de conexión. Los actores se refieren a una situación de un usuario del sistema, por

ejemplo un actor podría ser cliente.

Los actores dan o reciben los datos del sistema. Los actores secundarios ayudan a

mantener el sistema en ejecución o proporcionan ayuda, como las personas que operan

el centro de atención telefónica, los empleados(as) de ventanilla, etcétera.

Un caso de uso ilustra a los desarrolladores un panorama de lo que quieren los usuarios.

No tiene detalles técnicos o de implementación.

Un caso de uso se compone de tres elementos: un actor, para comenzar el evento; el

evento, que activa un caso de uso; y el caso de uso, que desempeña las acciones

activadas por el evento.



Los casos de uso documentan un solo evento. Un caso de uso se nombra con un verbo y

un sustantivo. Las relaciones son el comportamiento y se usan para conectar a un actor,

y hay cuatro tipos básicos:

En la imagen, por el tipo de flechas, se muestran los cuatro tipos: Comunica, Incluye,

Extiende y Generaliza.

Al hacer el diagrama del caso de uso hay que pedir todo lo que los usuarios quieren que

el sistema haga para ellos, es decir, mostrar los servicios que se deben proporcionar.

En las fases iniciales ésta podría ser una lista parcial que se extiende en las últimas fases

del análisis. Usa los siguientes lineamientos:

Revisar las especificaciones para establecer los actores.

Identificar los eventos y hacer los casos de uso.

Revisar el caso de uso para determinar el flujo de los datos.



Figura 4.4. Ejemplo de caso de uso de matriculación de estudiante (Kendall &

Kendall, 2005: 669)

La figura muestra un caso de uso de una matriculación de un estudiante. Agregar un

estudiante incluye verificar la identidad de éste.

El caso de uso Comprar libro de texto extiende el caso de uso Matricularse en la clase y

podría ser parte de un sistema para matricular a los estudiantes de un curso en línea.

Pareciera como si el caso de uso Cambiar información del estudiante fuera una

característica menor del sistema y no se debiera incluir en el diagrama de caso de uso,

pero debido a que esta información cambia con frecuencia, la administración tiene un

interés sutil en permitir a los estudiantes cambiar su propia información personal. El hecho

de que los administradores juzguen esto como importante no solo justifica, sino que exige

que el estudiante pueda cambiar su información.



A los estudiantes no se les permitiría cambiar su promedio de calificaciones, cuotas a

pagar y otra información. Este caso de uso también incluye el caso de uso Verificar

identidad, y en esta situación, significa que el estudiante tiene que introducir una clave de

usuario y contraseña antes de acceder al sistema. Ver información del estudiante permite

a los estudiantes visualizar su información personal, así como también los cursos y

calificaciones.

Los diagramas de caso de uso son un buen punto de partida, pero se necesita una

descripción más completa de ellos para su documentación.

Figura 4.5. Cuatro tipos de relaciones (Kendall & Kendall, 2005: 667)

4.2.2. Escenarios del caso de uso



Cada caso de uso tiene una descripción como escenario del caso de uso, el cual

representa un caso en el que hay flujo de eventos y rutas para el comportamiento.

No hay un formato establecido, pero se deben considerar tres puntos importantes:

1. Identificadores e iniciadores de caso de uso.

2. Pasos desempeñados.

3. Condiciones, suposiciones y preguntas.

Este podría ser el caso de uso (use case) de escribir un mensaje en un foro.

Nombre: Crear mensaje foro

Autor: Juan Pérez

Fecha: 28/03/2011

Descripción:

Permite crear un mensaje en el foro de discusión.

Actores:

Usuario de Internet firmado.

Precondiciones:

El usuario debe haberse firmado en el sistema.

Flujo Normal:

1. El actor pulsa sobre el botón para crear un nuevo mensaje.

2. El sistema muestra una caja de texto para introducir el título del mensaje y una

zona de mayor tamaño para introducir el cuerpo del mensaje.

3. El actor introduce el título del mensaje y el cuerpo del mismo.

4. El sistema comprueba la validez de los datos y los almacena.

Flujo Alternativo:

1. El sistema comprueba la validez de los datos, si los datos no son correctos, se

avisa al actor de ello permitiéndole que los corrija.

Poscondiciones:

El mensaje ha sido almacenado en el sistema.

Ejemplo de caso de uso (Gracia, J., 2003: 1)



Un escenario del caso de uso, es una instancia expresada en el caso de uso.

Figura 4.6. Escenario de caso de uso

4.2.3. Diagramas de actividades

Son un tipo especial de diagramas de estado que se centra en mostrar el flujo de

actividades dentro de un sistema. Los diagramas de actividades cubren la parte dinámica

de un sistema y se utilizan para modelar el funcionamiento de un sistema resaltando el

flujo de control entre objetos.

Un diagrama de actividades muestra el flujo de actividades. Las actividades producen

finalmente alguna acción, que está compuesta de ejecutables que producen un cambio en

el estado del sistema o la devolución de un valor. Las acciones incluyen llamadas a otras

operaciones, envío de señales, creación o destrucción de objetos, o simples cálculos

(como la evaluación de una expresión).

Gráficamente, un diagrama de actividades es una colección de nodos y arcos.

Básicamente un diagrama de actividades contiene:

Estados de actividad. La representación de este estado está basada en un

rectángulo con las puntas redondeadas, donde el interior se representa una

actividad. El estado de actividad puede descomponerse en más sub-actividades

representadas a través de otros diagramas de actividades, estos estados pueden

ser interrumpidos y pueden tardar cierto tiempo en concluir. Adicional se pueden



encontrar elementos como: acciones de entrada y acciones de salida, tal como se

muestra en el ejemplo siguiente.

Figura 4.7 Diagrama de actividades para modelar una actividad (Alarcón, 2005: 73)



Estados de acción. Al igual que el estado de actividad, el estado de acción, está

basado en un rectángulo con las puntas redondeadas, donde en el interior se

representa una acción.

Transiciones. Las transiciones muestran el paso de un estado a otro, bien sea

estado de actividad o de acción. Esta transición se produce como resultado de la

finalización del estado del que parte el arco dirigido que marca la transición. Como

todo flujo de control debe empezar y terminar en algún momento, se puede indicar

esto utilizando dos disparadores de inicio y final.

Figura 4.8.Transición

4.2.4. Diagrama secuencial

Los diagramas de secuencia son un tipo de diagramas nombrados de interacción, y

constan de un conjunto de objetos y sus relaciones, incluyendo los mensajes que se

pueden enviar unos objetos a otros. Cubren la vista dinámica del sistema. Los diagramas

de secuencia enfatizan el ordenamiento temporal de los mensajes, mientras que los

diagramas de colaboración muestran la organización estructural de los objetos que envían

y reciben mensajes. Los diagramas de secuencia se pueden convertir en diagramas de

colaboración sin pérdida de información, lo mismo ocurre en sentido opuesto.



Figura 4.9. Representación de clases en diagramas de secuencia

Un diagrama de secuencia en el modelado UML muestra una interacción ordenada según

la secuencia de cada evento. Muestra los objetos participantes en la interacción y los

mensajes que intercambian, ordenados según su secuencia en el tiempo. El eje vertical

representa el tiempo, y en el eje horizontal se colocan los objetos y actores participantes

en la interacción, sin un orden prefijado. Cada objeto o actor tiene una línea vertical, y los

mensajes se representan mediante flechas entre los distintos objetos. El tiempo fluye de

arriba abajo. Se pueden colocar etiquetas (como restricciones de tiempo, descripciones

de acciones, etc.) bien en el margen izquierdo o bien junto a las transiciones o

activaciones a las que se refieren.

4.2.5. Diagrama de clase

Los diagramas de clase son utilizados para mostrar las relaciones entre las clases que

involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de

contenido.

Un diagrama de clases está compuesto por los siguientes elementos: clase, atributos,

métodos y visibilidad, y relaciones: herencia, composición, agregación, asociación y uso.

Elementos

Clase

Es la unidad básica que incluye toda la información de un Objeto, y un objeto es una

instancia de una clase. A través de ella podemos modelar el entorno en estudio: una

Casa, un Auto, una Cuenta Corriente, etc.

En UML una clase es representada por un rectángulo que posee tres divisiones:



Figura 4.10.Representación de una clase

Nivel Superior: Contiene el nombre de la Clase a utilizar.

Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase

(pueden ser private, protected o public).

Nivel Inferior: Contiene los métodos u operaciones, los cuales son la forma como

interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o

public).

Un ejemplo sobre el diagrama de clase:

Un Crédito que posee como característica:

Solicitud

Puede realizar las operaciones de:

Investigación de Crédito (investigación)

Análisis de crédito (análisis)

Y Entrega de crédito (entrega)

El diseño asociado es:

Figura 4.11. Representación de la clase cuenta



Atributos y Métodos:

Atributos:

Los atributos o características de una Clase pueden ser de tres tipos, los que definen el

grado de comunicación y visibilidad de ellos con el entorno, éstos son:

public (+, ): Indica que el atributo será visible tanto dentro como fuera de la clase, es

decir, es accesible desde todos lados.

private (-, ): Indica que el atributo sólo será accesible desde dentro de la clase (sólo

sus métodos lo pueden accesar).

protected (#, ): Indica que el atributo no será accesible desde fuera de la clase, pero

si podrá ser accesado por métodos de la clase además de las subclases que se deriven

(ver herencia).

Métodos:

Los métodos u operaciones de una clase son la forma en cómo ésta interactúa con su

entorno, éstos pueden tener las características:

public (+, ): Indica que el método será visible tanto dentro como fuera de la

clase, es decir, es accesible desde todos lados.

private (-, ): Indica que el método sólo será accesible desde dentro de la clase (sólo

otros métodos de la clase lo pueden accesar).

protected (#, ): Indica que el método no será accesible desde fuera de la clase, pero

sí podrá ser accesado por métodos de la clase además de métodos de las subclases que

se deriven (ver herencia).

Actividad 2. Aplicación de diagramas

Esta actividad tiene como finalidad aplicar cada uno de los conceptos básicos de los

diagramas: casos de uso, actividades secuenciales y clase.

1. En un archivo de texto, realiza un listado en el que se mencionen cada uno de los tipos

de diagramas de casos de uso de actividades secuenciales y clase, incluye su definición

y en qué utilizarías cada uno de ellos de acuerdo al concepto entendido.



2. Guarda la Actividad con el nombre DOO_U4_A2_XXYZ. Sustituye las XX por las dos

primeras letras de tu primer nombre, la Y por la inicial de tu apellido paterno y la Z por la

inicial de tu apellido materno.

3. Envía el archivo a tu Facilitador(a) a través de Tareas.

4.2.6. Diagrama de gráfico de estado

El Diagrama de Estados especifica la secuencia de estados que pasa el caso de uso, o

puede ser un objeto a lo largo de su vida. Se indican qué eventos hacen que se pase de

un estado a otro y cuáles son las respuestas y acciones que da por resultado.

Un diagrama de estados es un gráfico donde los nodos son estados y los arcos son

transiciones etiquetadas con los nombres de los eventos.

Un estado se representa como una caja redondeada con el nombre del estado en su

interior, una transición se representa como una flecha desde el estado origen al estado

destino.

La caja de un estado puede tener uno o dos niveles: en el primer nivel aparece el nombre

del estado, el segundo nivel es opcional, y en él pueden aparecer acciones de entrada, de

salida y acciones internas.

Una acción de entrada aparece en la forma entrada/acción_asociada donde

acción_asociada es el nombre de la acción que se realiza al entrar en ese estado, cada

vez que se entra al estado por medio de una transición, la acción de entrada se ejecuta.

Una acción de salida aparece en la forma salida/acción_asociada, cada vez que se sale

del estado por una transición de salida la acción de salida se ejecuta. Una acción interna

es una acción que se ejecuta cuando se recibe un determinado evento en ese estado,

pero que no causa una transición a otro estado. Se indica en la forma

nombre_de_evento/acción_asociada.



Figura 4.12. Gráfico de estado de conexión a Internet

Un diagrama de estados puede representar ciclos continuos o bien una vida finita, en la

que hay un estado inicial de creación y un estado final de destrucción (finalización del

caso de uso o destrucción del objeto). El estado inicial se muestra como un círculo sólido

y el estado final como un círculo sólido rodeado de otro círculo. En realidad, los estados

inicial y final no son estados, pues un objeto no puede “estar” en esos estados, pero nos

sirven para saber cuáles son las transiciones inicial(es) y final(es).

Actividad 3. Diseño de diagramas en UML

Esta actividad tiene como finalidad aplicar cada uno de los conceptos básicos delos

diagramas casos de uso, actividades secuenciales, clase y gráfico de estado.

1. En Word o Microsoft Visio diseña un ejercicio para cada uno de los diagramas,

suponiendo que se quiere diseñar un sistema para el control de ventas de una farmacia

en donde el usuario sería el despachador de la misma.

2. Describe cada uno de los diagramas y su contenido o justificación.

3. Guarda la Actividad con el nombre DOO_U4_A3_XXYZ. Sustituye las XX por las

dos primeras letras de tu primer nombre, la Y por la inicial de tu apellido paterno y la Z por

la inicial de tu apellido materno.

4. Envía el archivo a tu Facilitador(a) para recibir retroalimentación.



Autoevaluación

Para reforzar los conocimientos relacionados con los temas que se abordaron en esta

unidad del curso, es necesario que resuelvas la actividad integradora. Recuerda que es

muy importante leer cuidadosamente los planteamientos indicados y elegir la opción

adecuada para cada uno.

Evidencia de aprendizaje. Diagramas UML

Como parte de la evaluación de esta unidad, realiza la siguiente actividad cuyo propósito

es conceptualizar el proceso de diagramación.

Instrucciones:

1. En un archivo de texto o Microsoft Visio diseña un ejercicio para cada uno de los

diagramas que revisaste en esta unidad, señalando el o los usuarios.

2. Describe cada uno de los diagramas y su contenido o justificación.

3. Consulta la Escala de evaluación.

4. Guarda la evidencia con el nombre ADOO_U4_EA_XXYZ. Sustituye las XX por las

dos primeras letras de tu primer nombre, la Y por la inicial de tu apellido paterno y la Z por

la inicial de tu apellido materno.

5. Envía el archivo a tu Facilitador(a) a través de Evidencia de aprendizaje, para recibir

retroalimentación.

Autorreflexiones

Además de enviar tu trabajo de la Evidencia de aprendizaje, es importante que ingreses

al foro Preguntas de Autorreflexión y consultes las preguntas que tu Facilitador(a)

presente; a partir de ellas debes elaborar tu Autorreflexión en un archivo de texto llamado

DOO_U4_ATR_XXYZ. Posteriormente envía tu archivo mediante la herramienta

Autorreflexiones.



Cierre de la unidad

Has concluido la unidad 4 del curso. A lo largo de ésta se vieron conceptos de diseño

orientado a objetos con UML, cómo se representan los objetos y las clases, además de

cómo se hacen los diagramas para los casos de uso, escenarios del caso de uso,

diagramas de actividades, diagramas secuenciales, de clase y el gráfico de estado.

Es aconsejable que revises nuevamente la unidad en caso de que los temas que se

acaban de mencionar no te sean familiares, o no los recuerdes; de no ser éste tu caso, ya

habrás terminado tu curso de Análisis y diseño Orientado a Objetos, ¡FELICIDADES!

Para saber más

Insertar o crear un dibujo de Visio en otro programa:

Cómo insertar en Word un diagrama en Visio: http://office.microsoft.com/es-

mx/visio-help/utilizar-visio-con-otros-programas-de-2007-microsoft-office-

system-HA010198865.aspx

Fuentes de consulta

Alarcón, Raúl. (2005). Diseño orientado a objetos con UML. Grupo Eidos. Página

73.

Fowler, M. & Scott, K. (1999) UML GOTA A GOTA México: Addison Wesley.

Gracia, J. (2003) UML: Casos de Uso. Use case, Desarrollo de Software Orientado

a Objetos. Recuperado de:

http://www.ingenierosoftware.com/analisisydiseno/casosdeuso.php

Kendall, J. & Kendall, J. (1990) Análisis y Diseño de sistemas. México: Prentice

Hall Iberoamericana.

Larman, C. (2004) Applying UML and Patterns an Introduction to object-Oriented

Analysis and Design. México: Prentice Hall.

http://office.microsoft.com/es-mx/visio-help/utilizar-visio-con-otros-programas-de-2007-microsoft-office-system-HA010198865.aspx



http://www.ingenierosoftware.com/analisisydiseno/casosdeuso.php



Quatrani, T. & James, R. (1997) Visual Modeling with Rational Rose and UML

México: Addison Wesley.

Unidad 4. Diseno Orientado a Objetos Con UML

Documents

Transcript of Unidad 4. Diseno Orientado a Objetos Con UML