Unidad 4. Diseno Orientado a Objetos Con UML

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

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

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

1

Análisis y diseño orientado a objetos Programa desarrollado Í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

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

2

Análisis y diseño orientado a objetos Programa desarrollado 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.

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

3

Análisis y diseño orientado a objetos Programa desarrollado 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é.

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

4

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

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.

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

5

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

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

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

6

Análisis y diseño orientado a objetos Programa desarrollado 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:

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

7

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

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.

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

8

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

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.

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

9

Análisis y diseño orientado a objetos Programa desarrollado 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.

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

10

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

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.

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

11

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

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

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

12

Análisis y diseño orientado a objetos Programa desarrollado 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)

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

13

Análisis y diseño orientado a objetos Programa desarrollado 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

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

14

Análisis y diseño orientado a objetos Programa desarrollado 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)

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

15

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

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.

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

16

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

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:

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

17

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

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

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

18

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

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.

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

19

Análisis y diseño orientado a objetos Programa desarrollado 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.

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

20

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

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.

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

21

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

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.

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

22

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

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/esmx/visio-help/utilizar-visio-con-otros-programas-de-2007-microsoft-officesystem-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.

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

23

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

Quatrani, T. & James, R. (1997) Visual Modeling with Rational Rose and UML México: Addison Wesley.

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

24