De Computacion

La tarea de programación de aplicaciones hoy en día ha pasado de ser una actividad centrada en la mente del programador frente a la máquina, a una actividad de ingeniería en la cual se debe diseñar muchos componentes que permitan una representación adecuada de aquello que se desea construir, lo cual no es posible hacerlo si no se dispone de dos armas fundamentales que son: capacidad para resolver problemas y soluciones y el uso de una notación suficientemente clara que permita a todos los involucrados comprender de manera inequívoca las decisiones de diseño que se han tomado. En este contexto cobra sentido el modelado de sistemas, que al igual que en todas las ingenierías permite una representación clara de los componentes que formarán parte de la solución propuesta. La ingeniería del software posee una serie de notaciones estándares que permiten expresar tales decisiones, una de estas notaciones o podríamos llamarlo lenguaje de modelado es UML, el cual ha sido adoptado como estándar para los diseños orientados a objetos. La presente asignatura por tanto tiene como objetivos ayudar al estudiante a desarrollar la capacidad de resolver e idear soluciones a problemas de programación complejos aplicando el enfoque orientado a objetos y enseñar el lenguaje unificado de modelado UML. No se enseñará en ningún momento una metodología o proceso de desarrollo, simplemente se enfoca en aprender las competencias requeridas para modelar software de manera adecuada. Este conocimiento será necesario para avanzar en asignaturas futuras donde se estudian procesos de desarrollo, técnicas de Ingeniería de software, etc. que requieren el conocimiento de este lenguaje. Cabe acotar que la presente guía didáctica ha sido concebida como una guía de aprendizaje fuertemente apoyada en tres elementos básicos:

1. El texto guía, en cada capítulo contine una descripción de los aspectos relevantes del contenido, no pretende reemplazar el estudio del texto guía o texto básico, por tanto ambos elementos son importantes, y tenga cuidado porque no todos los temas del libro se han considerado importantes para la asignatura, por lo que deberá seguir las instrucciones de la presente guía. 2. Interacción a través del entorno virtual de aprendizaje o campus virtual, puesto que muchas temas se desarrollarán más a fondo a través de esta interacción por tanto es imprescindible que el estudiante busque la manera de acceder a este entorno. 3. El estudio de documentos publicados por autores representativos de esta área del conocimiento, que se colocaron en el entorno virtual de aprendizaje, denominados también papers que reforzarán los temas planteados en la asignatura y serán motivo de discusión a través del EVA.

El primer bimestre está compuesto de tres capítulos encaminados a mostrar algunos principios de la ingeniería del software que la ciencia en la que se enmarca la asignatura, resaltando su importancia y permitirá al estudiante dilucidar el objetivo de formación de la carrera que ha elegido. En el primer capítulo hace un breve paseo por la ingeniería de software y un repaso de algunos de los conceptos clave de la programación orientada a objetos que es el matiz que tendrá nuestro estudio. En el segundo capítulo se estudia el modelado de clases en profundidad, lo cual permitirá conocer a fondo desde la identificación de los objetos en un problema determinado hasta la definición de detalles de los modelos de clases utilizando UML. El capítulo tercero estudia la técnica de los casos de uso para capturar los requerimientos de sistema representado lo que en UML se denomina el modelado funcional. En el capítulo cuarto se aborda el estudio de los diagramas de interacción para mostrar una de las partes dinámicas del sistema. En el capítulo cinco tratamos el tema de los diagramas de estado, que permiten modelar los cambios que se dan en los objetos durante todo su ciclos de vida, permitiendo una mejor comprensión del sistema, se aborda a demás los diagramas de actividades como técnica para representar la lógica de las operaciones. Y finalmente se trata el tema de los diagramas de componentes y diagramas de implementación para representar la arquitectura de componentes así como lo diagramas de paquetes que finalmente muestra tanto la organización lógica como física de la aplicación. En cada capítulo encontrará ejercicios, cuyos respuestas le ayudaran a comprender mejor los temas en caso de duda remitirse a la tutoría telefónica o virtual.

Le deseo muchos éxitos en su estudio.

Tabla de contenidos 1 Objetivo General 2 Objetivo Especificos 3 Bibliografia 4 Desarrollo del Aprendizaje 4.1 Capitulo 1 Introduccion a la Ingenieria del Software y Modelado 4.1.1 Datos Generales: 4.1.2 Propositos: 4.1.3 Conceptos Clave 4.1.4 Esquema de Estudio: 4.2 Capitulo 2 Modelado de Clases 4.2.1 Datos Generales: 4.2.2 Propositos: 4.2.3 Conceptos Clave: 4.2.4 Esquema de Estudio: 4.3 Capitulo 3 Modelado de Casos de Uso 4.3.1 Datos Generales: 4.3.2 Propositos: 4.3.3 Conceptos Clave: 4.3.4 Esquema de Estudio: 4.4 Capitulo 4 Diagrama de Interaccion 4.4.1 Datos Generales: 4.4.2 Propositos: 4.4.3 Conceptos Clave: 4.4.4 Esquema de Estudio: 4.5 Capitulo 5 Diagrama de Estado y Actividad 4.5.1 Datos Generales: 4.5.2 Propositos: 4.5.3 Conceptos Clave: 4.5.4 Esquema de Estudio: 4.6 Capitulo 6 Diagrama de Implementacion y Diagramas de Componentes 4.6.1 Datos Generales: 4.6.2 Propositos: 4.6.3 Conceptos Clave: 4.6.4 Esquema de Estudio:

[editar] Objetivo General

Que el estudiante desarrolle habilidades para proponer soluciones a problemas de software utilizando el enfoque de la Programación Orientada a Objetos y el lenguaje UML como herramienta de modelado.

[editar] Objetivo Especificos

Los objetivos específicos de la materia, en función de los capítulos que se van a desarrollar son:

1. Estudiar los conceptos y herramientas de la Ingeniería de Software como una ciencia para el desarrollo de software de alta calidad. 2. Introducir al estudiante en la terminología de la programación orientada a objetos basada en componentes como herramienta de modelado y diseño de soluciones de software. 3. Aprender la estructura y sintaxis del lenguaje de modelado unificado UML, como herramienta para la representación de los modelos funcional, estático y dinámico del software. 4. Identificar y modelar el comportamiento dinámico de los objetos representando sus interacciones mediante diagramas de colaboración y diagramas de secuencia. 5. Aprender a capturar el comportamiento interno de los objetos identificando aspectos esenciales para el modelado e implementación del sistema. 6. Establecer elementos de arquitectura de sistemas que permitan tanto a desarrolladores como arquitectos de software establecer componentes y modelos de implementación.

[editar] Bibliografia

Texto Base

STEVENS, P., POOLEY, R. (2002). Utilización de UML en Ingeniería de Software con Objetos y Componentes. Ed. Addison Wesley. Madrid, España. ISBN: 84-7829-054-0

Bibliografía complementaria

RUMBAUGH, J., BLAHA, M., PREMERLANI, W., EDDY, F. Y LORENESEN, W. (1996): Modelado y Diseño Orientados a Objetos. Madrid. Ed. Prentice Hall.

BOOCH, G., RUMBAUGH, J., JACOBSON, I. (1999): El Lenguaje de Unificado de Modelado. Addison Wesley. 1999. 464p.

SCHMULLER J. (2000): Aprendiendo UML en 24 horas. México. Ed. Prentice Hall. Direcciones importantes en la web

http://www.digilife.be/quickreferences/indexe.html

En esta página puede descargar libros en formato digital sobre programación en java y temas afines a la programación orientada a objetos. Además encontrará muchos papers e información relaciona a programación en objetos.

http://www.stepanovpapers.com/

Encontrará una serie de papers, apuntes y otro tipo de información relacionada con programación y modelado de software.

http://www-306.ibm.com/software/rational/uml/

Centro oficial de recursos UML de IBM Rational. Aquí encontrará tanto papers como especificaciones del lenguaje e incluso herramientas para descargar de IBM.

http://www-128.ibm.com/developerworks/rational

Herramientas y recursos para desarrolladores IBM.

http://www.rspa.com/spi/

Página web de Roger Pressman, autor de libro de Ingeniería del Software, con recursos en el tema de Ingeniería del Software.

http://www-128.ibm.com/developerworks/rational/library/content/RationalEdge/archives/uml.html

Centro de recursos UML de IBM. Colección de muchos papers y documentos relativos a procesos de desarrollo, modelado y estrategias de desarrollo.

http://www.objectsbydesign.com/tools/umltools_byCompany.html

En esta dirección se puede encontrar links para comprar o descargar herramientas CASE para el modelado con UML.

http://www.dsic.upv.es/~uml/

Curso de desarrollo de software orientado de objetos de la Universidad de Valencia, España, en Español.

http://www.omg.org/uml/

Página web de Object Management Group, organización encargada de establecer los estándares en la programación orientada a objetos.

http://www.dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/

En este link encontrará un ejemplo de desarrollo completo utilizando RUP.

[editar] Desarrollo del Aprendizaje

[editar] Capitulo 1 Introduccion a la Ingenieria del Software y Modelado

---

[editar] Datos Generales:

Texto Base	STEVENS, P., POOLEY, R. (2002). Utilización de UML en Ingeniería de Software con Objetos y Componentes. Ed. Addison Wesley. Madrid, España.
Capítulo	1. Principios de Ingeniería de Software y Modelado
Páginas	3 – 31
Horas de estudio empleadas para el desarrollo del contenido	7 horas

[editar] Propositos:

El propósito del presente capítulo es mostrar una introducción a la Ingeniería de Software que es la ciencia en la que se enmarca la presente asignatura, y se encarga de estudiar y resolver los problemas relacionados con el Desarrollo de Software cubriendo etapas desde la concepción inicial del proyecto, pasando por la planificación, seguimiento, implantación y mantenimiento del sistema. Como todas las ingenierías las técnicas y métodos utilizados en la Ingeniería de Software han ido evolucionando en función de la complejidad inherente al mundo que envuelve a los proyectos de software, y esta se justifica en la complejidad de los negocios y las organizaciones que usan el software.

[editar] Conceptos Clave

• Software:

  Conjunto de instrucciones dadas en lenguaje de ordenador que permiten que la máquina desarrolle operaciones de procesamiento de información y manejo de dispositivos.

• Ingeniería del software:

  Rama de las ciencias de la computación de que encarga de estudiar y resolver los problemas de la planificación, concepción, diseño, construcción e implantación de software.

• Encapsulamiento:

  Propiedad de los objetos que les permite ocultar su estructura, mostrando únicamente aquellos elementos que le sirven para comunicarse con el exterior a los cuales se los conoce como la interfaz.

• Acoplamiento:

  En la ingeniería del software se usa este término para medir el grado en que una clase depende de otras para cumplir con sus responsabilidad, a mayor número de clases u operaciones de las que depende, se dice que es mayor el acoplamiento, y a mientras menor es la dependencia, menor es el acoplamiento. En general se considera que mientras menor es el acoplamiento, es más ventajoso el diseño.

• Interfaz:

  Se conoce como interfaz aquellos elementos de un componente que le permiten interactuar con otros componentes, es la parte no encapsulada a través de la cual se intercambia información entre ellos.

• Abstracción:

  Es una habilidad innata del ser humano que le permite reducir la complejidad mediante el aislamiento de los detalles innecesarios de un objeto para centrarse en aquellos que le son útiles para un propósito en particular, así por ejemplo se dice que de un mismo objeto del mundo real se puede obtener diferentes abstracciones para propósitos diferentes. También se puede entender como el aislamiento de detalles que no se requiere mostrar, como una aplicación de este concepto se ven la interfaz y el encapsulamiento.

[editar] Esquema de Estudio:

A continuación se detallan los temas que se deben desarrollar, una descripción general del mismo, y un conjunto de actividades que se recomienda sean desarrolladas para una mejor asimilación de los conceptos. Se han dispuesto las tres columnas de la derecha para llevar un control personal del tiempo de dedicación a cada tema, marcar las actividades que estima que necesita tutoría y realizar anotaciones.

Tema a revisar	Descripción del Contenido a revisar	Actividades Recomendadas	Planificación Personal del estudio (fecha)	¿Requiero Tutorial?	Anotaciones
1.1 Breve revisión de la Ingeniería de Software	En este apartado estudia una introducción a los conceptos y elementos importantes de la Ingeniería del Software	Estudie el capítulo 1 del texto básico
1.2. Conceptos de POO	Estudiamos algunos conceptos importantes de Programación Orientada a Objetos, se agregan algunos conceptos nuevos que tienen que ver con el comportamiento dinámico de los objetos.	Estudie el capítulo 2 del texto básico y desarrolle las preguntas de discusión #13 y #14. En el capítulo 3 se desarrolla un caso de estudio, en el cual se resumen todos los componentes de un modelo de software, este caso de estudio deberá estudiarlo y conforme avanza en el estudio de la asignatura le sugiero que vuelva a este capítulo para ubicar en que parte del proceso se encuentra.
1.3. Proceso de desarrollo de software.	En este apartado se muestra un resumen de las principales metodologías de desarrollo de software. Vale acotar que este contenido es únicamente para que el estudiante tenga una noción de cómo se desarrolla software, pero su objeto de estudio ha quedado para asignaturas posteriores como son Sistemas I y Sistemas II.	Para completar este apartado deberá estudiar el capítulo 4 donde se específica lo que es el proceso de desarrollo de software. Desarrolle la pregunta de discusión #29.
1.4. El modelado	Una de las etapas y habilidades fundamentales para cualquier ingeniería o ciencia es precisamente la capacidad de crear modelos que reflejen lo que será una entidad antes de ser construida. Vale la pena decir que estas habilidades no son para nada triviales. En este apartado se estudia algunas características del modelado en la disciplina de la Ingeniería del Software.	En el documento denominado The value of modeling usted encontrará el documento titulado “Value of modeling”, que está escrito en idioma inglés y refleja los diferentes aspectos a considerar al momento de crear modelos. Estúdielo cuidadosamente y una vez comprendido, elabore una carta abierta a los desarrolladores de software invitándolos a usar el modelado como técnica fundamental para la construcción de software indicando los matices que deberá aplicar de acuerdo a las características del proyecto.
1.5. El lenguaje de modelado unificado.	El lenguaje unificado de modelado UML, es precisamente el objetivo central de estudio de esta asignatura, en este apartado se hace una introducción a este lenguaje, basado en un documento proporcionado por IBM Rational.	Estudie el artículo titulado Introduction to the Unified Modeling Language para obtener un visión completa de lo que es UML. En el EVA se creará un espacio para que coloque sus preguntas e inquietudes con relación a la comprensión del texto.

[editar] Capitulo 2 Modelado de Clases

---

[editar] Datos Generales:

Texto Base	STEVENS, P., POOLEY, R. (2002). Utilización de UML en Ingeniería de Software con Objetos y Componentes. Ed. Addison Wesley. Madrid, España.
Capítulo	5. Fundamentos de los modelos de clases. 6 Más sobre los modelos de clases.
Páginas	67 – 128
Horas de estudio empleadas para el desarrollo del contenido	18 horas

[editar] Propositos:

El propósito del presente capítulo es estudiar la estructura estática de los sistemas reflejada en los denominados modelos de clases, las cuales resultan esenciales al momento de construir software orientado a objetos, este modelado se realizará utilizando la notación y la semántica de UML.

[editar] Conceptos Clave:

• Objeto:

  Desde el punto de vista más simple, un objeto es cualquier cosa que se puede ver, tocar o sentir. Pero para efectos de nuestro estudio en el ámbito de la Ingeniería de Software, un objeto es cualquier entidad que hace sentido en el contexto de una aplicación sobre la cual podemos guardar información y podemos asignarle responsabilidades.

• Clase:

  Es una abstracción que agrupa las características comunes a varios objetos concretamente sus atributos y sus operaciones, de manera que se definan una sola vez y se usen en cada instancia de la clase (objeto). Sirven como moldes para crear los objetos.

• Atributos:

  Podemos decir que los atributos de una clase son los campos en los cuales se puede almacenar información, estos campos se definen en las clases y se llenan en sus instancias (objetos). Los valores permitidos para esos atributos deben corresponder al tipo de datos definido en la clase.

• Operaciones:

  Son acciones que los objetos pertenecientes a la clase están en condiciones de ejecutar. Estas se definen e implementan en las clases y son usadas y ejecutadas por cada uno de los objetos pertenecientes a estas clases.

• Asociación:

  Una aplicación orientada a objetos se concibe como un grupo de objetos interactuando entre sí, esto significa que al igual que en el mundo real cada objeto cumple con su función y comunica a otros el resultado de su trabajo para que a su vez estos hagan lo suyo, por ello entre estos objetos hay una correspondencia o relación definida a nivel de las clases que se denomina asociación. Por ejemplo: A un objeto estudiante le corresponde una matrícula, a un objeto matricula le corresponden varias asignaturas, a un profesor le corresponden una o más asignaturas a cargo, etc. Cada una de estas asociaciones tiene un nombre que establece la manera como se relacionan las clases. En los ejemplos anteriores los nombres de estas asociaciones pueden ser: estudiante se inscribe en una matrícula, la matrícula contiene varias asignaturas, un profesor dicta varias asignaturas, etc.

• Multiplicidad:

  En una asociación pueden participar dos o más clases, especificado el número de instancias de las clases mínimo y máximo que pueden participar en dicha relación, a este número se lo conoce como multiplicidad. Por ejemplo en el caso de la Universidad, un estudiante debe tomar entre 1 a 6 asignaturas, y una asignatura puede ser tomada por muchos estudiantes; otro ejemplo más gráfico un automóvil tiene 4 ruedas y una rueda corresponde a 1 automóvil. La multiplicidad siempre se describe de ida y vuelta y para especificarla correctamente se debe indicar Una instancia de la clase A, se asocia con N instancias de la clase B y Una instancia de la clase B se asocia con N instancias de la clase A. UML tiene una notación específica para representar esta multiplicidad.

• Grado de una relación:

  El grado de una relación está dado el número de clases que participan en una relación. Así podemos encontrar relaciones unarias, en las cuales las instancias de una clase se asocian con otras instancias de sí misma, por ejemplo: Una persona es jefe de otras personas; las más comunes son las binarias, es decir entre dos clases, por ejemplo una persona trabaja en un departamento; también de otros grados aunque nos son tan comunes, como por ejemplo: Un equipo juega un partido en un estadio, en este caso la particularidad es de que si alguna de las clases falta, la información es incompleta.

• Herencia:

  La herencia es una relación entre clases que replica el concepto de herencia que se da en el mundo real, esto significa que a partir de una clase se puede crear otras clases con las mismas características de la primera y se le puede agregar otras más. A la primera clase se la denomina superclase y a las clases obtenidas a partir de esta se las conoce como subclases. El propósito de este tipo de relación es reutilizar las características de las superclases para no estar implementando todo en nuevas clases. Esta es una de las relaciones más importantes y poderosas de la programación orientada a objetos. A este tipo de relación se la puede identificar en las descripciones con la frase “es un”, Ej. Un estudiante es una persona, lo cual denota que la clase estudiante tiene todas las características de la clase persona.

• Agregación:

  Es otro tipo de relación entre clases que denota que una clase está formada o es un contenedor de instancias de otras clases. Ej. Un pensum contiene asignaturas. Cuando las relaciones son estructurales, es decir hay una fuerte correspondencia entre el todo y las partes, se habla de composición, Ej. Un automóvil está formado por chasis, carrocería, ruedas, motor, llantas. Si alguna de estas partes falta, dejaría de ser automóvil.

[editar] Esquema de Estudio:

A continuación se detallan los temas que se deben desarrollar, una descripción general del mismo, y un conjunto de actividades que se recomienda sean desarrolladas para una mejor asimilación de los conceptos. Se han dispuesto las tres columnas de la derecha para llevar un control personal del tiempo de dedicación a cada tema, marcar las actividades que estima que necesita tutoría y realizar anotaciones.

Tema a revisar	Descripción del Contenido a revisar	Actividades Recomendadas	Planificación Personal del estudio (fecha)	¿Requiero Tutorial?	Anotaciones
2.1 Identificación de objetos y clases	Este apartado estudia cómo identificar los objetos y clases que formarán parte del sistema, además orienta sobre cuándo y por qué motivos descartar del modelo algunas clases.	Estudie el apartado 5.1 del texto básico y desarrolle las preguntas de discusión 31 y 32.
2.2 Atributos, operaciones y relaciones.	Este apartado comprende la especificación de los atributos y las asociaciones entre clases, la manera de establecerlas y prácticas para afinar los modelos.	Estudie los apartados 5.2 y 5.3 del texto y desarrolle las preguntas de discusión #33 y #36.
2.3. Generalización.	En este apartado se estudia uno de los principios básicos de la Programación Orientada a Objetos, que permite la reutilización de componentes y la estructuración de aplicaciones robustas.	Para estudiare este contenido, concéntrese en el apartado 5.4 del texto básico. Desarrolle la pregunta de discusión #40.
2.4 Documentación de clases.	Los diagramas no son suficientes para especificar un modelo de software. Es necesario especificar los detalles de estos elementos del modelo mediante descripciones textuales, en el caso de las clases se usan las denominadas tarjetas CRC. Cuyo uso ayuda incluso a establecer la pertinencia de una clase.	Este apartado es corto, pero muy importante, revise por favor el apartado 5.6
2.5. Elementos avanzados del modelado de clases.	En este apartado se estudian algunos elementos estructurales más completos del modelado de clases.	Estudie los apartados del 6.1 al 6.3, Considere la importancia de comprender los paneles. Desarrolle la pregunta de discusión #41.

[editar] Capitulo 3 Modelado de Casos de Uso

---

[editar] Datos Generales:

Texto Base	STEVENS, P., POOLEY, R. (2002). Utilización de UML en Ingeniería de Software con Objetos y Componentes. Ed. Addison Wesley. Madrid, España.
Capítulo	7. Fundamentos de los modelos de casos de uso, Capítulo 8 Mas sobre los modelos de casos de uso.
Páginas	107 – 128
Horas de estudio empleadas para el desarrollo del contenido	15 horas

[editar] Propositos:

El propósito del presente capítulo es estudiar la denominada estructura funcional del software en la cual básicamente se definen desde el punto de vista del usuario, aquellas cosas que se desea que haga el sistema. Vale acotar que la técnica de casos de uso es una herramienta muy importante para especificación de requisitos, que es uno de los factores que determinan el éxito de un proyecto de software.

[editar] Conceptos Clave:

• Actor:

  Un actor es cualquier ente externo al sistema que puede interactuar con él, entendiéndose por interacción la capacidad de comunicarse mediante el envío o recepción de información. En este contexto los actores más comunes son las personas que se constituyen en usuarios del sistema, pero también podemos encontrar en la categoría de actores a dispositivos como por ejemplo un reloj de registro de asistencias que envía información sobre las horas de entrada y salida a un servidor de recursos humanos, o un sistema financiero que recibe información sobre las facturas emitidas por un sistema académico.

• Caso de uso:

  Un caso de uso es una unidad funcional del sistema, en la cual se define la manera como interactuará un usuario con el sistema para cumplir con una tarea completa, una de las maneras más fáciles de entender lo que es un caso de uso es fijarse en el manual de instrucciones de un electrodoméstico, por ejemplo en un microondas, en el manual se puede encontrar los usos que puede tener, entre ellos: Calentar un plato, descongelar alimentos, cocinar carne, preparar palomitas de maíz, cocer frijoles, etc. Note que cada uno de estos usos implica una operación completa y ninguna depende de la otra, si leemos el manual, nos indica paso a paso lo que debe hacer el usuario para cumplir con dicho uso, coloque los alimentos, presione botones, la pantalla preguntará, espera su respuesta, etc. Esta es precisamente la idea de un caso de uso: describir de manera sencilla y en términos del usuario como debería relacionarse el actor con el sistema para cumplir cada uno de los usos del software.

• Relación actor-caso de uso:

  Un actor se vincula con un caso de uso a través de una línea continua que va desde el actor al caso de uso, denominada relación y su significado es que el actor interactúa con el caso de uso, o dicho en otras palabras provoca su ejecución. Las relaciones entre actores y casos de uso siempre son bidireccionales, se acostumbra colocar una punta de flecha misma que se usa para indicar quien inicia la interacción, pero esto en ningún momento indica la dirección de las interacciones.

• Inclusión:

  Entre si los casos de uso también tienen relaciones, una de ellas es la denominada relación de inclusión, la cual consiste básicamente en que un caso un caso de uso incluye dentro de su proceso al otro caso de uso, esta relación es obligatoria, es decir que siempre se ejecuta el caso de uso incluido cada vez que se ejecuta el primero. Ej.: El caso de uso Retirar fondos, requiere obligatoriamente la autenticación del usuario, por lo tanto haría uso del caso de uso Autenticar Usuario.

• Extensión:

  La relación de extensión se da cuando un caso de uso invoca de manera opcional a otro caso de uso, es decir dicha llamada se produce bajo ciertas condiciones por lo que no forma parte el flujo normal de eventos. Ej.: Un caso de uso denominado Registrar Matrícula, para un estudiante antiguo, se ejecutaría normalmente, pero si se tratase de un Estudiante Nuevo, debería invocar a un caso de uso denominado Crear Ficha Personal.

[editar] Esquema de Estudio:

A continuación se detallan los temas que se deben desarrollar, una descripción general del mismo, y un conjunto de actividades que se recomienda sean desarrolladas para una mejor asimilación de los conceptos. Se han dispuesto las tres columnas de la derecha para llevar un control personal del tiempo de dedicación a cada tema, marcar las actividades que estima que necesita tutoría y realizar anotaciones.

Tema a revisar	Descripción del Contenido a revisar	Actividades Recomendadas	Planificación Personal del estudio (fecha)	¿Requiero Tutorial?	Anotaciones
3.1 Fundamentos del modelo de casos de uso.	Este apartado estudia la manera de especificar el comportamiento requerido para el sistema desde el punto de vista del usuario. Aquí se revisan los principales componentes de los casos de uso tales como actores, características de los casos de uso, límites del sistema.	Estudie todo el capítulo 7 del texto base. Y desarrolle la pregunta de discusión # 54.
3.2 Relaciones y otros componentes del modelo de casos de uso.	Este apartado estudia las relaciones entre casos de uso y las relaciones entre actores.	Estudie el capítulo 8 del texto básico, y resuelva las preguntas de discusión #59.

[editar] Capitulo 4 Diagrama de Interaccion

---

[editar] Datos Generales:

Texto Base	STEVENS, P., POOLEY, R. (2002). Utilización de UML en Ingeniería de Software con Objetos y Componentes. Ed. Addison Wesley. Madrid, España.
Capítulo	9 Fundamentos de los diagramas de interacción y 10 Más sobre los diagramas de interacción.
Páginas	129 – 154
Horas de estudio empleadas para el desarrollo del contenido	12 horas

[editar] Propositos:

En este capítulo aprenderá sobre la vista dinámica de los sistemas expresada a través de dos modelos de trascendental importancia, se trata de lo diagramas de Secuencia y los Diagramas de actividad, conocidos también como Diagramas de Interacción.

[editar] Conceptos Clave:

• Activación:

  Es el proceso que sucede cuando un objeto inactivo ha recibido un mensaje y como consecuencia se activa para realizar su trabajo, este proceso se representa en los diagramas de secuencia mediante un rectángulo en la línea de vida del objeto.

• Colaboración:

  Se conoce como colaboración al conjunto de objetos que interactúan entre sí para ejecutar una tarea junto con los enlaces entre ellos. Dicho en otras palabras una colaboración es grupo de elementos necesarios para que el sistema haga su trabajo, en el modelado dinámico se busca identificar las interacciones necesarias entre los diferentes objetos.

• Diagrama de colaboración:

  Es un tipo de diagrama de interacción que cuyo objetivo principal es mostrar la manera como los objetos está asociados y reflejar las interacciones entre ellos. Sus componentes son los objetos, los enlaces y los mensajes. Son de mucha utilidad para determinar si hay consistencia con el modelo de clases.

• Diagrama de secuencia:

  Es un tipo de diagrama de interacción en el que se muestran principalmente el orden cronológico en que suceden las interacciones entre objetos, sus componentes principales son los objetos, cada uno de los cuales tiene su línea de vida, los mensajes y sus activaciones.

• Enlaces:

  Los enlaces en son las instancias de las asociaciones, tal como se estudió en el capítulo 2, estos enlaces son indispensables para la representación de los mensajes, puesto que los objetos no relacionados no pueden interactuar. Esto se profundiza en la denominada Ley de Demeter, página 135.

• Interacción:

  Paso de mensajes entre objetos que se da con el propósito de ejecutar una tarea. Las interacciones tienen una secuencia que se numera sobre todo en los diagramas de colaboración.

• Mensaje:

  Es la llamada a una operación del objeto que recibe dicho mensaje, estos mensajes pueden llevar argumentos o pueden devolver valores que son almacenados en variables. Los mensajes solo se pueden dar a través de los enlaces entre objetos.

• Objeto:

  Desde el punto de vista del modelado dinámico, un objetos es una instancia de una clase, y en general son los elementos que interactúan, las clases por ser elementos abstractos, es decir simplemente definiciones de cómo deberían ser los objetos no pueden participar en las interacciones. La notación de los objetos es con un recuadro en el que se anota el nombre del objeto, seguido de dos puntos el nombre de la clase y todo esto subrayado.

[editar] Esquema de Estudio:

A continuación se detallan los temas que se deben desarrollar, una descripción general del mismo, y un conjunto de actividades que se recomienda sean desarrolladas para una mejor asimilación de los conceptos. Se han dispuesto las tres columnas de la derecha para llevar un control personal del tiempo de dedicación a cada tema, marcar las actividades que estima que necesita tutoría y realizar anotaciones.

Tema a revisar	Descripción del Contenido a revisar	Actividades Recomendadas	Planificación Personal del estudio (fecha)	¿Requiero Tutorial?	Anotaciones
4.1 Fundamentos de los diagramas de interacción.	En este apartado se revisa el vínculo que tiene el modelado dinámico con el modelado estático y se explica la manera de construir tanto los diagramas de colaboración como los diagramas de secuencia.	Estudiar el capítulo 9, y desarrollar las preguntas de discusión #62, #70, #71.
4.2 Diagramas de interacción a fondo	En esta sección se ahonda en el tema de los diagramas de interacción abordando temas avanzados como son los diagramas de interacción genéricos y la concurrencia.	Estudiar el capítulo 10, y desarrollar las preguntas de discusión #75 y #77

[editar] Capitulo 5 Diagrama de Estado y Actividad

---

[editar] Datos Generales:

Texto Base	STEVENS, P., POOLEY, R. (2002). Utilización de UML en Ingeniería de Software con Objetos y Componentes. Ed. Addison Wesley. Madrid, España.
Capítulo	11 Fundamentos de los diagramas de estado y actividad 12 Más sobre los diagramas de estado y actividad.
Páginas	155 – 172
Horas de estudio empleadas para el desarrollo del contenido	16 horas

[editar] Propositos:

Avanzando con el modelado dinámico de sistemas, en el presente capítulo se estudia el comportamiento interno de los objetos. Los diagramas de estados se enfocan en mostrar lo que sucede dentro de un objeto desde que recibe una activación hasta que termina su ciclo de ejecución, por otro lado los diagramas de actividad reflejan la lógica de procesamiento usada en una operación bien sea esta interna o global.

[editar] Conceptos Clave:

• Acciones:

Son las actividades que realiza un objeto como respuesta a un mensaje, estas acciones son las respuestas a los eventos.

• Barras de sincronización:

Son barras gruesas en sentido horizontal, que se usan en los diagramas de actividades para representar grupos de acciones que suceden de manera coordinada, es decir actividades que se producen como unión y en paralelo.

• Guardas:

Son elementos que se colocan en los estados que se usan para evitar que el objeto reaccione o cambie de estado en condiciones no favorables, podemos decir que es una manera de protegerse de errores o estados inconsistentes.

• Estado:

Es la condición en que se encuentra un objeto en un determinado momento durante la ejecución de las diferentes interacciones o como consecuencia de ellas. Por ejemplo piense en un foco, que está apagado, este es un estado, luego se activa el interruptor y pasa de estado apagado a estado encendido. Se representan con rectángulos de esquina redondeadas.

• Estado inicial:

Es el primer estado en el que normalmente se encuentra un objeto, para indicarlo se usa la notación de inicio que consiste en un gran punto negro del cual sale una flecha dirigida hacia el estado que se considera como estado inicial. También se conoce como marca de creación de un objeto.

• Estado final:

Es el último estado en el que queda un objeto antes de terminar su activación, para indicarlo se usa la notación de inicio que consiste en un gran punto negro encerrado en un círculo al cual llega una flecha desde el estado que se considera como final.

• Transición:

Es el proceso de cambio entre un estado a otro que sufre un objeto como producto de un mensaje que lo obliga a cambiar de estado, las transiciones se representan mediante líneas donde se especifica el nombre o evento que produce el cambio de estado. En los diagramas de actividad estas transiciones no se etiquetan.

• Evento:

Son aquellos elementos que provocan las transiciones, se representa con un mensaje. Es algo que se le hace a un objeto, como puede ser el envío de un mensaje.

[editar] Esquema de Estudio:

A continuación se detallan los temas que se deben desarrollar, una descripción general del mismo, y un conjunto de actividades que se recomienda sean desarrolladas para una mejor asimilación de los conceptos. Se han dispuesto las tres columnas de la derecha para llevar un control personal del tiempo de dedicación a cada tema, marcar las actividades que estima que necesita tutoría y realizar anotaciones.

Tema a revisar	Descripción del Contenido a revisar	Actividades Recomendadas	Planificación Personal del estudio (fecha)	¿Requiero Tutorial?	Anotaciones
5.1 Fundamentos de los diagramas de estado y actividad.	En este apartado revisamos lo que son los diagramas de estado que se usan para representar el comportamiento de cada uno de los objetos al recibir mensajes y los diagramas de actividades que se usan para representar la lógica de las operaciones, se estudia la notación y la manera de desarrollar dichos diagramas..	Estudiar el capítulo 11, y desarrollar las preguntas de discusión #79, #83.
5.2 Más sobre los diagramas de estado y actividad.	En esta sección se estudian otros eventos y otros tipos de acciones que los objetos pueden ejecutar.	Estudiar el capítulo 12.

[editar] Capitulo 6 Diagrama de Implementacion y Diagramas de Componentes

---

[editar] Datos Generales:

Texto Base	STEVENS, P., POOLEY, R. (2002). Utilización de UML en Ingeniería de Software con Objetos y Componentes. Ed. Addison Wesley. Madrid, España.
Capítulo	13 Diagramas de implementación 14 Paquetes, subsistemas y modelos.
Páginas	173 – 188
Horas de estudio empleadas para el desarrollo del contenido	12 horas

[editar] Propositos:

Estudiar los diagramas de implementación, mismos que sirven para representar unidades de código resultantes de la implementación o librerías que se usan en el paquete de software que se ha desarrollado y agregan las relaciones entre estos componentes. Un diagrama de componentes muestra las dependencias lógicas entre componentes software, sean estos archivos de código fuente, archivos binarios o ejecutables. Los componentes de software tienen un tipo que indica si son útiles en tiempo de compilación, enlace o ejecución. Se consideran en este tipo de diagramas sólo tipos de componentes. Las instancias específicas se encuentran en el diagrama de ejecución.

[editar] Conceptos Clave:

• Componente:

  Es una parte física y reemplazable de un sistema que conforma con un conjunto de interfaces y proporciona la realización de dicho conjunto. Estos componentes pueden ser programas ejecutables, librerías, tablas, archivos y documentos. Gráficamente un componente se representa como un rectángulo con pestañas. Cada componente debe tener un nombre que lo distinga del resto de componentes.

• Interfaz:

  Es una colección de operaciones que se utilizan para especificar un servicio de una clase o un componente. La relación entre componente e interfaz es importante, puesto que las interfaces se usan como mecanismo de enlace entre componentes.

• Tipos de componentes:

  Se pueden distinguir tres tipos de componentes. Componentes de despliegue que sirven para formar un sistema ejecutable, tales como las bibliotecas dinámicas (DLL), los ejecutables (EXE), etc. Componentes producto de trabajo, que son los que quedan al final de un proceso de desarrollo, como por ejemplo código fuente, archivos de datos, estos no participan directamente en el sistema ejecutable. Y finalmente tenemos los Componentes de ejecución, que sol el resultado de la ejecución del sistema.

• Estereotipos de componentes:UML define cinco estereotipos estándar que se aplican a los componentes:

1. executable Especifica si un componente se puede ejecutar en un nodo.

2. library Especifica una biblioteca de objetos estática o dinámica.

3. table Especifica una tabla de base de datos.

4. file Especifica un archivo que contiene código fuente o datos.

5. document Especifica un componente que representa un documento.

• Nodo:

  Es un componente de hardware en donde se ejecutan los componentes de software. En los diagramas de despliegue los nodos representan el despliegue físico de los componentes.

• Paquete:

  Unidad de organización lógica que se usa en UML para agrupar elementos relacionados de acuerdo a la función o propósito para el que ha sido creados con el ánimo de simplificar su vista, facilitar las comprensión, ocultar detalles innecesarios en los niveles más altos de los modelos.

[editar] Esquema de Estudio:

A continuación se detallan los temas que se deben desarrollar, una descripción general del mismo, y un conjunto de actividades que se recomienda sean desarrolladas para una mejor asimilación de los conceptos. Se han dispuesto las tres columnas de la derecha para llevar un control personal del tiempo de dedicación a cada tema, marcar las actividades que estima que necesita tutoría y realizar anotaciones.

Tema a revisar	Descripción del Contenido a revisar	Actividades Recomendadas	Planificación Personal del estudio (fecha)	¿Requiero Tutorial?	Anotaciones
6.1 Diagramas de implementación	Se estudia la manera como se organizan los componentes de software y sus dependencias para formar un sistema ejecutable.	Estudiar el capítulo 13, y desarrollar las preguntas de discusión #90, #92.
6.2 Paquetes, subsistemas y modelos.	Estudia la manera cómo organizar de manera lógica los diferentes componentes de software en contenedores denominados paquetes de manera que se incremente su reutilización y se facilite su distribución.	Estudie el capítulo 14 y desarrolle la pregunta de discusión #96.