Tabla de Contenido - ozarate.net · Universidad Tecnológica de Jalisco Manual de Análisis y diseño I 2 Vistas y diagramas en UML

Academia de Ingeniería de Software Ana E. Romo González

1

Tabla de Contenido

1 Introducción ........................................................................................................................ 1

2 Introducción a los sistemas de información............................................................................. 2 e ingeniería de SW...................................................................................................................... 2

Sistema.................................................................................................................................... 2 Tipos comunes de sistemas..................................................................................................... 2 Tipos comunes de sistemas, Continuación ............................................................................. 3 Conceptos de análisis y diseño de sistemas ............................................................................ 4 Ingeniería de SW..................................................................................................................... 6 Capas de la ingeniería de software.......................................................................................... 7 Fases genéricas de la Ingeniería de SW.................................................................................. 7 Fases complementarias........................................................................................................................ 9 Modelos de procesos de SW................................................................................................. 10 1. El modelo lineal secuencial .............................................................................................. 10 2. El modelo de construcción de prototipos.......................................................................... 12 3. El modelo DRA................................................................................................................. 13 4. El modelo incremental ...................................................................................................... 14 5. El modelo en espiral.......................................................................................................... 16 Gestión de proyectos............................................................................................................. 18 Requerimientos del software................................................................................................. 20 Requerimientos funcionales y no funcionales ...................................................................... 21 Procesos de Ingeniería de requerimientos........................................................................................ 22 Debe definirse un plan preliminar de actividades................................................................. 23

3. Programación Orientada a Objetos ....................................................................................... 25 Programación orientada a objetos......................................................................................... 25 Objeto.................................................................................................................................... 26 Clase...................................................................................................................................... 26 Abstracción ........................................................................................................................... 26 Herencia ................................................................................................................................ 26 Polimorfismo .......................................................................................................................... 26 Encapsulamiento.......................................................................................................................... 26 Envío de mensajes................................................................................................................. 26 Asociaciones ........................................................................................................................... 26 Ejercicios....................................................................................................................... 28

4. Introducción al Lenguaje Unificado de Modelado ............................................................... 31 Historia de UML................................................................................................................... 31 Resumen de UML................................................................................................................. 31 Objetivos en UML ................................................................................................................ 32 Participantes en UML ........................................................................................................... 32 Modelo .................................................................................................................................. 33 Diagrama............................................................................................................................... 33

Universidad Tecnológica de Jalisco Manual de Análisis y diseño I

2

Vistas y diagramas en UML ................................................................................................. 34 Diagramas de UML............................................................................................................... 34 Paquetes ................................................................................................................................ 35 Clases .................................................................................................................................... 36 Encapsulamiento.......................................................................................................................... 37 Reglas de visibilidad................................................................................................................... 37 Qué es lo que hacen las clases y cómo encontrarlas............................................................. 40 Diagrama de Clases............................................................................................................... 41 Uso de relaciones entre clases............................................................................................... 42 Asociaciones ........................................................................................................................... 42 Vínculos ................................................................................................................................ 43 Posibles multiplicidades y como representarlas en UML.................................................................... 44 Asociaciones calificadas .......................................................................................................... 46 Asociaciones reflexivas............................................................................................................ 46 Herencia y generalización............................................................................................................ 47 Ventajas de la generalización ....................................................................................................... 47 Clases abstractas...................................................................................................................... 51 Dependencias .......................................................................................................................... 52 Agregaciones .......................................................................................................................... 52 Restricciones en las agregaciones ............................................................................................. 52 Ejemplo de agregación con restricción O................................................................................... 53 Composición ........................................................................................................................... 53 Contextos................................................................................................................................ 54 Casos de uso ........................................................................................................................... 57 Secuencia de pasos en los escenarios ........................................................................................ 57 Diagramas de caso de uso en el proceso de análisis .................................................................... 58 Puntos clave de los casos de uso ............................................................................................... 58 Actores ................................................................................................................................... 59 Relaciones .............................................................................................................................. 59 Comunicación ........................................................................................................................... 59 Inclusión................................................................................................................................. 59 Extensión................................................................................................................................ 59 Herencia ................................................................................................................................. 59 Construcción del caso de uso.................................................................................................... 60 Qué comprende la descripción del Caso de Uso ......................................................................... 61 Diagramas de interacción ......................................................................................................... 69 Mensajes................................................................................................................................. 69 Diagrama de secuencia............................................................................................................. 69 Representación de un objeto en un diagrama de secuencia.................................................................. 69 Mensaje .................................................................................................................................. 70 Tiempo ................................................................................................................................... 70 Diagrama de colaboración........................................................................................................ 74


3

Mensajes................................................................................................................................. 74 sincronización ........................................................................................................................... 74 condiciones ............................................................................................................................. 74 Valores de retorno ................................................................................................................... 74 Diagrama de estados ................................................................................................................ 76 Símbolos UML en el diagrama de estados ................................................................................. 76 Acciones ................................................................................................................................. 76 Sub-estados secuenciales.......................................................................................................... 77 Diagrama de actividades .......................................................................................................... 79 Decisiones en un diagrama de actividades ................................................................................. 79 Marcos de trabajo .................................................................................................................... 80 Diagrama de componentes ....................................................................................................... 82 Diagramas de despliegue.......................................................................................................... 83 Diagrama de componentes y despliegue .................................................................................... 83

Anexo A: Project......................................................................................................................... 84 Capitulo 1.................................................................................................................................. 84 Capitulo 2.................................................................................................................................. 97 Capitulo 3................................................................................................................................ 106 Anexo B: Prácticas Rational Rose .......................................................................................... 113


4


1

1 Introducción

Esta primera versión del manual de análisis y diseño

surgió por la necesidad de estructurar un curso que se encuentra colmado de información, con la intención de presentar una metodología que sirva de guía a los alumnos que toman el curso inicial de la materia. Este curso permite generar las bases para la construcción de programas de complejidad media a mayor. Quiero mencionar que fue de gran ayuda la participación de los alumnos a quienes les impartí de forma inicial el curso, ya que sus comentarios y sugerencias fueron la principal motivación para realizar este material. Espero que los nuevos cursos y alumnos traigan como siempre nuevas ideas que permitan actualizar y renovar el manual. Ojalá este viaje al conocimiento nos lleve a concretar una fase de enseñanza aprendizaje que permita alcanzar las metas que de forma general y particular cada uno de nosotros nos hemos propuesto.


2

2 Introducción a los sistemas de información

e ingeniería de SW

Sistema Grupo de elementos interdependientes o que interactúan regularmente

formando un todo.

Tipos comunes de sistemas

Dado que nuestro objetivo son los sistemas computacionales, empezaremos por dividir los sistemas en dos categorías: sistemas naturales, y sistemas hechos por el hombre.

1. Sistemas naturales

La gran mayoría de los sistemas no están hechos por el hombre: existen en la naturaleza y sirven a sus propios fines: 2. Sistemas hechos por el hombre

Un buen numero de sistemas son construidos, organizados y mantenidos por humanos, e incluyen:

o Sistemas sociales o Sistemas de transporte o Sistemas de comunicación etc.

3. Sistemas automatizados

Son sistemas hechos por el hombre que interactúan con o son controlados por una o más computadoras Una gran división en categorías más útil de los sistemas automatizados es la siguiente:

• Sistemas en línea • Sistemas de tiempo real • Sistemas de apoyo a decisiones • Sistemas basados en el conocimiento

Continúa en la siguiente página


3

Tipos comunes de sistemas, Continuación

Sistemas en línea

Un sistema en línea es aquel que acepta material de entrada directamente del área donde se creó. También es el sistema en el que el material de salida, o el resultado de la computación, se devuelve directamente a donde es requerido. Sistemas de tiempo real

Un sistema computacional de tiempo real puede definirse como aquel que controla un ambiente recibiendo datos, procesándolos y devolviéndolos con la suficiente rapidez como para influir en dicho ambiente en ese momento Sistemas de apoyo a decisiones

La mayor parte de los sistemas automatizados de información que se crean son sistemas operacionales que ayudan a llevar a cabo los detalles del trabajo cotidiano de una organización. Estos sistemas incluyen ejemplos como el sistema de nomina, de contabilidad, etc.

Sistemas basados en el conocimiento

La meta de los científicos de la computación que trabajan en el campo de la inteligencia artificial es producir programas capaces de imitar el desempeño humano en una gran variedad de tareas inteligentes. Sistemas expertos

Son programas de computadora que contienen el conocimiento y la capacidad necesarios para desempeñarse en un nivel de experto. Manejo de la información como recurso Las organizaciones han reconocido, desde hace mucho, la importancia de administrar recursos principales tales como la mano de obra y las materias primas. La información se ha colocado en un lugar adecuado como recurso principal.



4

Conceptos de análisis y diseño de sistemas

Los sistemas de información son desarrollados con propósitos diferentes dependiendo de las necesidades del negocio.

• Sistemas de procesamiento de transacciones (TPS) Son sistemas de información computarizada desarrollados para procesar gran cantidad de datos para transacciones rutinarias de los negocios, tales como nómina e inventario. estos sistemas reducen el tiempo que alguna vez se requirió para ejecutarlas manualmente.

• Sistemas de automatización de oficina y sistemas de manejo de conocimiento.

Al nivel de conocimiento de la organización hay dos clases de sistemas. Los sistemas de automatización de oficina (OAS) que dan soporte a los trabajadores de datos, quienes, por lo general, no crean un nuevo conocimiento sino que usan la información para analizarla y transformar datos, o para manejarla en alguna forma y luego compartirla con toda la organización y algunas veces más allá de ella. Los aspectos familiares de los OAS incluyen procesamiento de palabras, hojas de calculo, editor de publicaciones, calendarización electrónica y comunicación mediante correo de voz, correo electrónico y videoconferencias Los sistemas de manejo de conocimiento (KWS) dan soporte a los trabajadores profesionales, tales como científicos que contribuyan a la organización o a toda la sociedad.

• Sistemas de información gerencial (MIS) Estos no reemplazan a los sistemas de procesamiento de transacciones, sino que todos los MIS incluyen procesamiento de transacciones. Los MIS son sistemas de información que trabajan debido a la interacción resuelta entre gentes y computadoras, requiere que las gentes, el software y el hardware trabajen al unísono. Los sistemas de información dan soporte a un espectro más amplio de tareas organizacionales que los sistemas de procesamiento de transacciones. Para poder ligar la información, los usuarios de un sistema de información gerencial comparten una base de datos común. La base de datos guarda modelos que ayudan a los usuarios a interpretar y aplicar esos mismos datos.



5

Conceptos de análisis y diseño de sistemas, Continuación

• Sistemas de apoyo a decisiones:(DSS) Una clase de más alto nivel en los sistemas de información computarizada son los sistemas de apoyo a decisiones, éste es similar al sistema de información gerencial tradicional en que ambos dependen de una base de datos como fuente. Un sistema de apoyo a decisiones se aparta del sistema de información gerencial tradicional en que enfatiza el apoyo a la toma de decisiones en todas sus fases, aunque la decisión actual todavía es del dominio del tomador de decisiones. Los sistemas de apoyo a decisiones están más hechos a la medida de la persona o grupo que los usa que los sistemas de información gerencial tradicionales.

• Sistemas expertos e inteligencia artificial (AI) La inteligencia artificial (AI) puede ser considerada la meta de los sistemas expertos. El objetivo general de la AI ha sido desarrollar máquinas que se comporten de forma inteligente. Dos caminos de investigación de la AI son la comprensión del lenguaje natural y el análisis de la habilidad para razonar un problema y llegar a conclusiones lógicas. Los componentes básicos de un sistema experto son la base de conocimiento, una máquina de inferencia que conecta al usuario y la interfaz de usuario.

• Sistemas de apoyo a decisiones de grupo (DGSS)

Cuando los grupos necesitan trabajar juntos para tomar decisiones semi-estructuradas o sin estructura, un sistema de apoyo a decisiones de grupo puede plantear una solución. Los sistemas de apoyo a decisiones de grupo permiten que los miembros de un grupo interactúen con apoyo electrónico, frecuentemente en forma de software especializado y con una persona que da facilidades al grupo.

• Sistemas de apoyo a ejecutivos (ESS)

Un sistema de apoyo a ejecutivos ayuda a éstos, para organizar sus interacciones con el ambiente externo, proporcionando apoyo de gráficos y comunicaciones en lugares accesibles tales como salas de juntas u oficinas personales corporativas.


6

Ingeniería de SW

Planeación completa de sistemas.

Fritz Bauer La ingeniería de SW es el establecimiento y uso de principios robustos de la ingeniería a fin de obtener económicamente software que sea fiable y que funcione eficientemente sobre máquinas reales.

IEEE La aplicación de un enfoque sistemático, disciplinado y cuantificable hacia el desarrollo, operación y mantenimiento del SW.

Utilidad de la Ingeniería de SW

Brinda herramientas para: la estimación y planificación de proyectos y técnicas para analizar, documentar y diseñar sistemas. el diseño de entradas, salidas, BD, programas, interfaz. prueba e implantación de los sistemas.

Da pautas para el control de calidad de todo el proceso de ingeniería. Provee técnicas para la codificación eficiente de programas. Incluye el mantenimiento de programas

Atributos esenciales de un buen SW

Reflejan su comportamiento durante su ejecución y en la escritura y organización del programa fuente y en la documentación apropiada. Sommerville. Cap. 1. Pág. 13


7

Capas de la ingeniería de software

La ingeniería de SW es una tecnología multicapa

Proceso Mantiene juntas las capas de tecnología. Define un marco de trabajo para un conjunto de áreas clave de proceso (ACPs: base del control de gestión de proyectos, establecen el contexto en el que se aplican los métodos técnicos, se producen los resultados de trabajo, se asegura la calidad, etc.)

Métodos Indican cómo construir técnicamente el SW . Incluye análisis, diseño, construcción de programas, pruebas y mantenimiento.

Herramientas Proporcionan un soporte automático o semiautomático para el proceso y para los métodos. CASE (ingeniería de software asistida por computadora: computer-aided software engineering).

Fases genéricas de la Ingeniería de SW

• Fase de definición (se centra sobre el qué) • Fase de desarrollo (se centra en el cómo) • Fase de mantenimiento (se centra en el cambio)

o Corrección o Adaptación o Mejora o Prevención (reingeniería del sw)


Un enfoque de calidad

proceso

métodos

herramientas


8

Fases genéricas de la ingeniería de SW, Continuación

La fase de definición La fase de desarrollo La fase de mantenimiento

se centra en el que. Es decir, durante la definición, el que desarrolla el software intenta identificar qué información ha de ser procesada, que función y rendimiento se desea, qué comportamiento del sistema, que interfaces van a ser establecidas, que restricciones de diseño existen y que criterios de validación se necesitan para definir un sistema correcto. se centra en el cómo. Es decir, durante el desarrollo un ingeniero de software intenta definir cómo han de diseñarse las estructuras de datos, cómo ha de implementarse la función como una arquitectura del software, cómo han de implementarse detalles procedimentales, cómo han de caracterizarse las interfaces, cómo ha de traducirse el diseño en un lenguaje de programación y cómo ha de desarrollarse la prueba. se centra en el cambio que va asociado a la corrección de errores, a las adaptaciones requeridas a medida que evoluciona el entorno del software, y a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente.

Durante el proceso de mantenimiento se encuentran cuatro tipos de cambios:

Corrección. Incluso llevando a cabo las mejores actividades de garantía de calidad, es muy probable que el cliente descubra defectos en el software. El mantenimiento modifica el software para corregir los defectos. Adaptación. Con el paso del tiempo, es probable que cambie el entorno original (p.e. CPU, el sistema operativo, las reglas de empresa, las características externas de productos) para el desarrolló del software. El mantenimiento adaptativo produce modificación en el software para acomodarlo a los cambios de su entorno externo. Mejora. Conforme se utilice el software, el cliente/usuario puede descubrir funciones adicionales que van a producir beneficios. El mantenimiento perfectivo lleva al software más allá de sus requisitos funcionales originales. Prevención. El software de computadora se deteriora debido al cambio, y por esto al mantenimiento preventivo también llamado reingeniería de software, se debe conducir para permitir que el software sirva para las necesidades de los usuarios finales.



9

Fases complementarias

Seguimiento y control del proyecto de SW

Preparación y producción de documentos

Revisiones técnicas formales Gestión de reutilización Garantía de calidad del SW Mediciones Gestión de configuración del SW Gestión de riesgos

El proceso del software

Se establece un marco común del proceso definiendo un pequeño número de actividades del marco de trabajo que son aplicables a todos los proyectos del software, con independencia de su tamaño o complejidad. Un número de conjunto de tareas – cada una es una colección de tareas de trabajo de ingeniería del software, hitos de proyectos, productos de trabajo, y puntos de garantía de calidad – permitiendo que las actividades se adapten a las características del proyecto y a los requisitos del proyecto.

Marco de trabajo común del proceso

Actividades de protección

Actividades del marco de trabajo

Conjuntos de tareas

Tareas

Hitos, entregas

Puntos SQA

El proceso del software


10

Modelos de procesos de SW

1. El modelo lineal secuencial 2. El modelo de construcción de prototipos 3. El modelo DRA 4. El modelo incremental 5. El modelo en espiral 6. El modelo de ensamblaje de componentes 7. El modelo de desarrollo concurrente 8. El modelo de métodos formales

1. El modelo lineal secuencial

Llamado algunas veces ciclo de vida básico o modelo en cascada este modelo sugiere el enfoque sistemático, secuencial del desarrollo del software que comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y mantenimiento. El modelo lineal secuencial acompaña a las siguientes actividades:

Ingeniería y modelado de sistemas/infor-mación

Como el software siempre forma parte de un sistema más grande (o empresa), el trabajo comienza estableciendo requisitos de todos los elementos del sistema y asignándole al software algún subgrupo de estos requisitos.


Ingeniería de sistemas/ información

Análisis Diseño Código Prueba Mantenimiento


11

Modelo lineal secuencial, Continuación

Análisis de los requisitos del software

El proceso de reunión de requisitos se intensifica y se centra especialmente en el software.

Diseño Se centra en cuatro atributos distintos de un programa: estructura de datos, arquitectura del software, representaciones de interfaz y detalle procedimental (algoritmo). Al igual que los requisitos, el diseño se documenta y se hace parte de la configuración del software.

Generación de código

El diseño se debe traducir a una forma legible por la máquina.

Pruebas Una vez que se ha generado un código, comienzan las pruebas del programa. El proceso se centra en los procesos lógicos internos del software, asegurando que todas las sentencias se han comprobado.

Mantenimiento El software indudablemente sufrirá cambios después de ser entregado al cliente.

Desventajas del modelo lineal secuencial

1. Los proyectos reales raras veces siguen el modelo secuencial que propone el modelo.

2. A menudo es difícil que el cliente exponga explícitamente todos los requisitos.

3. El cliente debe tener paciencia. Una versión de trabajo del programa no estará disponible hasta que el proyecto este muy avanzado.

4. Los responsables del desarrollo del software siempre se retrasan innecesariamente.


12

Modelos de procesos de SW, Continuación

2. El modelo de construcción de prototipos

Un cliente a menudo define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. El paradigma de construcción de prototipos comienza con la recolección de requisitos. El desarrollador y el cliente definen los objetivos globales para el software, identifican los requisitos conocidos, y las áreas del esquema en donde es obligatoria más definición. Entonces aparece un diseño rápido. El diseño rápido se centra en una representación de esos aspectos del software que serán visibles para el usuario/cliente. El prototipo lo evalúa el cliente y lo utiliza para refinar los requisitos del software a desarrollar. La interacción ocurre cuando el prototipo satisface las necesidades del cliente, a la vez que permite que el desarrollador comprenda mejor lo que se necesita saber. En la mayoría de los proyectos, el primer sistema construido apenas se puede utilizar. Puede ser demasiado lento, demasiado grande, o torpe en su uso, o las tres a la vez. No hay alternativa sino comenzar de nuevo y construir una versión rediseñada en la que se resuelvan estos problemas.


Escuchar al cliente Construir/revisar maqueta

El cliente aprueba la maqueta


13

El modelo de construcción de prototipos, Continuación

Desventajas del modelo de construcción de prototipos

1. El cliente ve lo que parece ser una versión de trabajo del software sin tener conocimiento que con la prisa de hacer que funcione no se ha tenido en cuenta la calidad del software global o la facilidad de mantenimiento a largo plazo.

2. El desarrollador a menudo hace compromisos de implementación para

hacer que el prototipo funcione rápidamente. Se puede utilizar un sistema operativo o lenguaje de programación inadecuado simplemente por que esta disponible y es conocido.

3. El modelo DRA

El desarrollo Rápido de Aplicaciones (DRA) (Rapid Aplication Development, RAD), es un modelo del proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. El modelo DRA es una adaptación a alta velocidad del modelo lineal secuencial en el que se logra el desarrollo rápido utilizando un enfoque de construcción basado en componentes.


Modelado y gestión

Modelado de datos

Modelado de procesos

Generación de aplicaciones

Pruebas y volumen

Modelado y gestión

Modelado de datos

Modelado de procesos


Pruebas y volumen

Modelado y gestión

Modelado de datos

Modelado de proces

Generación de aplicaci

Pruebas y volume

Equipo 1 Equipo 2 Equipo 3

De 30 a 60 días


14

Fases del modelo DRA , Continuación

Modelado de gestión

El flujo de información entre las funciones de gestión se modela de forma que responda a las preguntas: ¿qué información conduce al proceso de gestión? ¿qué información se genera? ¿quién la genera? ¿a dónde va la información? ¿quién la procesa?

Modelado de datos

El flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre ellos.

Modelado de proceso

Los objetos de datos definidos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones se crean para añadir, modificar, suprimir, o recuperar un objeto de datos.


El DRA asume la utilización de técnicas de cuarta generación, utilizando componentes de programas existentes o crear componentes reutilizables.

Pruebas y entrega

Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce el tiempo de pruebas. Sin embargo se deben probar todos los componentes.

Desventajas del modelo DRA

1. Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el número correcto de equipos.

2. DRA requiere clientes y desarrolladores comprometidos en las rápidas

actividades necesarias para completar un sistema en un marco de tiempo abreviado.

4. El modelo incremental

Este modelo combina elementos del modelo lineal secuencial con la filosofía interactiva de construcción de prototipos. Este modelo aplica secuencias lineales de forma sorprendente de la misma forma que progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software.



15

El modelo incremental, Continuación

Cuando se utiliza un modelo incremental, el primer incremento a menudo es

un producto esencial (núcleo). Es decir, se afrontan requisitos básicos pero muchas funciones suplementarias (algunas conocidas, otras no) quedan sin extraer. El cliente utilízale producto central. Como resultado de utilización y/o evaluación, se desarrolla un plan para el incremento siguiente. El plan afronta la modificación del producto central a fin de cumplir mejor las necesidades del cliente y la entrega de funciones, y características adicionales. Este proceso se repite siguiendo la entrega de cada incremento, hasta que se elabore el producto completo.


Ingeniería de sistemas/ información

Análisis Diseño Código Prueba




Incremento 2

Incremento 3

Incremento 4

Entrega de 1 incremento

Entrega de Incremento 2

Entrega de Incremento 3

Tiempo de calendario


16

El modelo incremental, continuación

El modelo de proceso incremental, como la construcción de prototipos y otros

enfoques evolutivos, es interactivo por naturaleza. Pero a diferencia de la construcción de prototipos, el modelo incremental se centra en la entrega de un producto operacional con cada incremento. El desarrollo incremental es particularmente útil cuando la dotación de personal no está disponible para una implementación completa en cuanto a de la fecha limite de gestión que se haya establecido para el proyecto. Los primeros incrementos se pueden implementar con menos personas. Si el producto central es bien recibido, se puede añadir más personal (si se requiere) para implementar el incremento siguiente.

5. El modelo en espiral

Este modelo propuesto originalmente por Boehm, es un modelo de proceso de software evolutivo que acompaña la naturaleza interactiva de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial. Se proporciona el potencial para el desarrollo rápido de versiones incrementales del software. En el modelo en espiral. El software se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones, la versión incremental podría ser un modelo en papel o un prototipo. Durante las últimas iteraciones se producen versiones cada vez más completas de ingeniería del sistema. El modelo en espiral se divide en un número de actividades estructurales, también llamadas regiones o áreas, generalmente existen entre tres y seis regiones de tareas:



17

El modelo en espiral, Continuación

Comunicación con el cliente

Las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.

Planificación Las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto.

Análisis de riesgo

Las tareas requeridas para evaluar riesgos técnicos y de gestión. Ingeniería. Las tareas requeridas para construir una o más representaciones de la aplicación.

Construcción y adaptación

Las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.

Evaluación del cliente

Las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementada durante la etapa de instalación.

Cuando empieza el proceso evolutivo, el equipo de ingeniería del software gira alrededor de la espiral en la dirección de las agujas del reloj, comenzando por el centro, el primer circuito de la espiral produce el desarrollo de una especificación de productos; los siguientes en la espiral se podrían utilizar para desarrollar un prototipo y progresivamente versiones más sofisticadas del software. A diferencia del modelo del proceso clásico que termina cuando se entrega el software, el modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora. Se define un eje de punto de entrada en el proyecto. Cada uno de los cubos situados a lo largo del eje representan el punto de arranque para un tipo diferente de proyecto. Un proyecto de desarrollo de conceptos comienza en el centro de la espiral y continuará hasta que se completa el desarrollo del concepto. Si el concepto se va a desarrollar dentro de un producto real, el proceso procede a través del siguiente cubo y se inicia un nuevo proyecto de desarrollo. El producto evolucionará a través de iteraciones alrededor de la espiral siguiendo el camino que limita la región algo más brillante que el centro.


18

Determinantes de la calidad del software y de la efectividad de organización

Producto

Proceso

Características del cliente Condiciones

del negocio

Entorno de desarrollo

Tecnología Personas

Gestión de proyectos

El proceso de gestión del proyecto comienza con un conjunto de actividades que globalmente, se denominan planificación del proyecto. La gestión eficaz de un proyecto de software se centra en las cuatro P’s: personal, producto, proceso y proyecto. El orden no es arbitrario. El gestor que se olvida de que el trabajo de ingeniería de software es un esfuerzo humano intenso nunca tendrá éxito en la gestión de proyectos. Un gestor que no fomenta una minuciosa comunicación con el cliente al principio de la evolución del proyecto corre el riesgo de construir una elegante solución para un problema equivocado.

Si el gestor olvida que el trabajo de ingeniería de software es un esfuerzo humano intenso, nunca tendrá éxito en la gestión del proyecto.

1. El Personal Se tiene que contar con un personal para el desarrollo, altamente preparado, organizado, motivado y con ideas innovadoras. Participantes

• Gestores superiores: definen los aspectos de negocios importantes. • Gestores técnicos del proyecto: planifican , motivan, y controlan a los

profesionales para que realicen el trabajo de software.



19

Participantes, Continuación

• Profesionales: proporciona las capacidades técnicas necesarias para la ingeniería de un producto.

• Clientes: especifican los requisitos para la ingeniería de software. • Usuarios finales: interaccionan con el software una vez que se ha

entregado para la producción

Estructura del equipo

Descentralizado democrático (dd)

• Carece de jefe permanente • Se nombran coordinadores de tareas a corto plazo • Las decisiones sobre problemas se hacen por consenso • La comunicación entre los miembros es horizontal

Descentralizado controlado

• Tiene un jefe definido que coordina tareas especificas y jefes secundarios que tienen responsabilidades sobre subtareas

• La resolución de las tareas se hace en grupo, pero la implementación de soluciones se reparte entre subgrupos por el jefe del equipo.

• Hay comunicación vertical Centralizado controlado

• El jefe del equipo se encarga de resolver el problema a alto nivel y la coordinación interna del equipo.

• La comunicación es vertical.

Criterios para la elección de una estructura organizacional

• La dificultad del problema • El tamaño del programa • El tiempo que el equipo estará junto • El grado en que el problema puede ser modularizado • La calidad requerida y fiabilidad del sistema que se va a construir • La rigidez de la fecha de entrega. • El grado de comunicación requerido para el proyecto.



20

Gestión de proyectos, Continuación

2. El Producto Se requiere un análisis detallado de los requisitos del software, al menos debe

establecerse el ámbito del problema y delimitarlo.

Ámbito del software

El ámbito del software describe el control y los datos a procesar, la función, el rendimiento, las restricciones, las interfaces, y la fiabilidad. Se evalúan las funciones descritas en la declaración del ámbito, y en algunos casos se refinan para dar más detalles antes del comienzo de la estimación.

• Se evalúa la función y rendimiento que se le asigna al software. • Se debe considerar el tiempo de respuesta de procesamiento. • Se debe evaluar las restricciones o limitaciones del software

originados por el hardware con el que se cuenta.

Requerimientos del software

Los problemas que ha menudo tienen que resolver los ingenieros de software son extremadamente complejos. Comprender la naturaleza de los problemas puede ser muy difícil, especialmente si el sistema es nuevo. En consecuencia, es difícil establecer exactamente lo que el sistema debe hacer. Las descripciones de los servicios y restricciones son los requerimientos del sistema, y el proceso de descubrir, analizar, documentar y verificar estos servicios y restricciones se llama ingeniería de requerimientos. Los principales requerimientos se detallan a continuación:

1. los requerimientos del usuario: son declaraciones, en lenguaje natural y en diagramas, de los servicios que se espera que el sistema provea y de las restricciones bajo las cuales debe operar.

2. los requerimientos del sistema: establecen a detalle los servicios y restricciones del sistema. El documento de requerimientos del sistema, algunas veces denominado especificiación funcional, debe ser preciso. Éste sirve como un contrato entre el comprador del sistema y el desarrollador de software.

3. Una especificación del diseño del software : es una descripción abstracta del diseño del software que es una base para un diseño e implementación detallados. Esta especificación agrega detalle a la especificación de requerimientos del sistema.



21

Requerimientos del usuario

Especificación del diseño del software

Requerimientos del sistema

Administradores, clientes, usuarios finales del sistema, ingenieros clientes, administradores contratistas, arquitectos del sistema

Usuarios finales del sistema Ingenieros clientes Arquitectos del sistema Desarrolladores del software

Ingenieros clientes (quizás) Arquitectos del sistema Desarrolladores del software

Ámbito del software, Continuación

Requerimientos funcionales y no funcionales

A menudo, los requerimientos de sistemas de software se clasifican en funcionales y no funcionales, o como requerimientos de dominio:

1. Requerimientos funcionales: Son declaraciones de los servicios que proveerá el sistema. De la manera en que éste reaccionará a entradas particulares y de cómo se comportará en situaciones particulares.

2. Requerimientos no funcionales: son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo, estándares, etc.

requerimientos de dominio: son requerimientos que provienen del dominio de aplicación del sistema y que refleja las características de ese dominio. Éstos pueden ser funcionales o no funcionales.



22

Ámbito del software, Continuación

Procesos de Ingeniería de requerimientos

Existen cuatro actividades genéricas de alto nivel en el proceso de ingeniería de requerimientos. Éstas son el estudio de factibilidad, la obtención y el análisis de requerimientos, la especificación de éstos y su documentación.

Estudios de factibilidad (viabilidad)

En todos los sistemas nuevos, el proceso de ingeniería re requerimientos empieza con un estudio de factibilidad. La entrada de éste es una descripción resumida del sistema y de cómo de utilizará dentro de una organización. El resultado del estudio es un informe que recomienda si es conveniente llevar a cabo la ingeniería de requerimientos y el proceso de desarrollo del sistema. Un estudio de factibilidad es un estudio corto y orientado a resolver varias preguntas:

1. ¿El sistema contribuye a los objetivos generales de la organización? 2. ¿El sistema se puede implementar utilizando la tecnología actual y con

las restricciones de costo y tiempo? 3. ¿El sistema puede integrarse a otros que existen en la actualidad?

Llevar a cabo un estudio de factibilidad comprende la evaluación y recolección de la información, y la redacción de informes. La fase de la evaluación de la información identifica que dicha información requerida para contestar a las tres preguntas anteriores Algunos ejemplos de preguntas posibles son:

1. ¿Cómo se las arreglaría la organización si no se lleva a cabo este sistema?

2. ¿Cuáles son los problemas con los procesos actuales y cómo ayudaría el nuevo sistema a resolverlos?

3. ¿Cuál es la contribución directa que hará el sistema a los objetivos del negocio?

4. ¿La información se puede obtener y transferir a otros sistemas de la organización?

5. ¿El sistema requiere de tecnología que no se ha utilizado previamente en la organización?

6. ¿A que debe ayudar el sistema y a qué no necesita ayudar?



23

Estudios de factibilidad (viabilidad), Continuación

Una vez que se ha identificado el ámbito, es razonable preguntarse :

¿podemos construirlo de acuerdo a este ámbito?, ¿es factible el proyecto?. Descomposición del problema

Denominado a veces particionado o elaboración del problema, es una actividad que se asienta en el núcleo del análisis de requisitos del software. Aplicando la descomposición en dos áreas principales: 1.- la funcionalidad que debe entregarse y 2.- el proceso que se empleará para entregarlo.

3. El Proceso El gestor debe decidir que modelo de proceso es el mas adecuado para el proyecto (DRA., clásico, prototipos, etc.). La decisión se basará en:

• Los clientes que han solicitado el producto y la gente que realizará el trabajo

• Las características del producto en sí • El entorno del proyecto en el que trabaja el equipo de software.

Debe definirse un plan preliminar de actividades.

Se debe delimitar quien será el responsable de dicha actividad.

El proyecto Para gestionar un proyecto de software con éxito, debemos comprender qué

puede ir mal (para evitar esos problemas) y como hacerlo bien. John Reel define diez señales que indican que un proyecto de sistemas de información está en peligro:

1. La gente del software no comprende las necesidades de los clientes 2. El ámbito del producto está definido pobremente. 3. Los cambios están mal realizados. 4. La tecnología elegida cambia. 5. Las necesidades del negocia cambian (o están mal definidas) 6. Las fechas de entrega no son realistas.



24

El proyecto, Continuación

7. Los usuarios se resisten 8. Se pierden los patrocinadores (o nunca se obtuvieron adecuadamente) 9. El equipo del proyecto carece del personal con las habilidades

apropiadas. 10. Los gestores (y los desarrolladores) evitan buenas prácticas y sabias

lecciones. Los profesionales veteranos de la industria hacen referencia frecuentemente a la regla 90-90 cuando estudian proyectos de software particularmente difíciles: el primer 90 por 100 de un sistema absorbe el 90 por 100 del tiempo y del esfuerzo asignado. El último 10 por 100 se lleva el otro 90 por 100 del esfuerzo y del tiempo asignado.


25

3. Programación Orientada a Objetos

Programación orientada a objetos

La programación orientada a objetos es un método de implementación en el que los programas se organizan como colecciones cooperativas de objetos, cada uno de los cuales representa una instancia de alguna clase y cuyas clases son, todas ellas, miembros de una jerarquía de clases unidas mediante relaciones de herencia. Hay tres partes importantes en esta definición: la programación orientada a objetos

1. utiliza objetos, no algoritmos, como sus bloques lógicos de construcción fundamentales,

2. cada objeto es una instancia de alguna clase; y 3. las clases están relacionadas con otras clases por medio de relaciones

de herencia. La mayoría de los programadores trabajan en un lenguaje y utilizan sólo un estilo de programación. Programan bajo un paradigma apoyado por el lenguaje que usan. Se define un estilo de programación como una forma de organizar programas sobre las bases de algún modelo conceptual de programación. Hay cinco principales estilos de programación:

• Orientado a procedimientos Algoritmos • Orientados a objetos Clases y objetos • Orientados a lógica Objetivos, a menudo

expresados como cálculo de predicados.

• Orientado a reglas reglas si-entonces • Orientado a restricciones relaciones invariantes.

Cada uno de los estilos de programación se basa en su propio marco de referencia conceptual. Para todas las cosas orientadas a objetos el marco de referencia conceptual es el modelo de objetos. Hay cuatro elementos fundamentales en este modelo:

• Abstracción • Encapsulamiento • Modularidad • Jerarquía



26

Programación orientada a objetos, Continuación

Hay tres elementos secundarios del modelo de objetos:

• Tipos (tipificación) • Concurrencia • Persistencia

Por secundarios quiere decirse que cada uno de ellos es una parte útil del modelo de objetos, pero no es esencial.

Objeto Es la instancia de una clase (o categoría). Ejem. Persona. Un objeto cuenta con una estructura, es decir Atributos (propiedades) y Acciones (métodos). Las acciones son todas las actividades que el objeto es capaz de realizar. Los atributos y acciones en conjunto se conocen como características o rasgos.

Clase (Además de la categorización) Es una plantilla para fabricar objetos (molde). Características similares en grupos. Para modelar entre más atributos y acciones, mayor será la similitud de su modelo con la realidad.

Abstracción Una abstracción denota las características esenciales de un objeto que lo distinguen de todos los demás tipos de objeto y proporciona así formas conceptuales nítidamente definidas a la perspectiva del observador.

Herencia Es la capacidad de un objeto de recibir las características de la clase de la que proviene. Superclase Subclase

Polimorfismo Una operación tiene el mismo nombre en diferentes clases y funciona distinto en cada una.

Encapsulamiento Un objeto trae consigo su funcionalidad pero ésta se encuentra oculta. Ocultamiento de la información.

Envío de mensajes

Forma en que se comunican los objetos. Uno envía un mensaje a otro para realizar una operación.

Asociaciones Formas de relacionarse entre objetos. 3 Tipos Una dirección, en ambas, 1 a varios Agregación. Conjunto de elementos

Composición. Diversos componentes (el componente se considera sólo si forma parte de un todo).



27


Ejemplo

Ellos, llaman a cada una de estas parcelas reino, tipo, clase, especie, orden, familia, género, etc.; sin embargo, nosotros a todas las llamaremos del mismo modo: clase. Así, hablaremos de la clase animal, clase vegetal y clase mineral, o de la clase félidos y de las clases leo (león) y tigris (tigre). Cada clase posee unas cualidades que la diferencian de las otras. Así, por ejemplo, los vegetales se diferencian de los minerales -entre otras muchas cosas- en que los primeros son seres vivos y los minerales no. De los animales se diferencian en que las plantas son capaces de sintetizar clorofila a partir de la luz solar y los animales no. Como vemos, el ser humano tiende, de un modo natural a clasificar los objetos del mundo que le rodean en clases; son definiciones estructuralistas de la naturaleza.



28


Ejercicios

Ejercicio 1

Tome la clase león y especifique algunos de sus datos y de sus métodos

Datos Métodos

Ejercicio 2

Tomemos un cassette. Cómo lo definiríamos al estilo de POO

Datos Métodos



29

Ejercicios, continuación

Ejercicio 3

Pongamos otro ejemplo algo más próximo a los objetos que se suelen tratar en informática: un recuadro en la pantalla. El recuadro pertenecería a una clase a la llamaremos marco. Veamos sus datos y sus métodos.

Datos Métodos

Objetos de la clase marco



30

Ejemplo 3, Continuación

Los datos son los mismos, pero los valores que toman esos datos son

diferentes para cada objeto. Ahora, podemos aplicar los métodos a los datos. Estos métodos producirán distintos resultados según a qué datos se apliquen. Así, el objeto marco 1, al aplicarle el método Mostrarse, aparece en la parte izquierda, rectangular verticalmente y con línea doble, mientras que el objeto marco 2, al aplicarle el mismo método, aparece en la parte izquierda, cuadrado y con línea simple. Si quisiéramos ahora aplicarle el método Cambiar de posición al objeto marco 1, este método debería seguir los siguientes pasos y en este orden. Llamar al método Ocultarse para este objeto. Cambiar los datos de coordenadas para este objeto. Llamar al método Mostrarse para este objeto. Vemos así cómo un método de una clase puede llamar a otros métodos de su misma clase y cómo puede cambiar los valores de los datos de su misma clase. De hecho es así como debe hacerse: los datos de una clase sólo deben ser alterados por los métodos de su clase; y no de forma directa (que es como cambiamos los valores de las variables de un programa). Esta es una regla de oro que no debe olvidarse: todos los datos de una clase son privados y se accede a ellos mediante métodos públicos.


31

4. Introducción al Lenguaje Unificado de Modelado

Historia de UML

UML es probablemente, una de las innovaciones conceptuales en el mundo tecnológico del desarrollo de software que más expectativas y entusiasmos haya generado en muchos años, comparable a la aparición e implantación de lenguajes COBOL, BASIC, Pascal , C++, y más recientemente Java o XML. Además, todas las expectativas se han cumplido y han generado a su vez nuevas expectativas. UML es un estándar de la industria, pero no sólo de la industria de software sino, en general, de cualquier industria que requiera la construcción de modelos como condición previa para el diseño y posterior construcción de prototipos. En la primavera de 1995 con la unión de las metodologías Booch ’94 y OMT (Grady Booch y James Rumbaugh) presentaron a la comunidad informática el entonces denominado Unified Method versión 0.8. Posteriormente se unió al equipo Ivar Jacobson, creador a su vez del método OOSE y, sobre todo, del ingenioso concepto use case (casos de uso). La unión del equipo de “3 amigos”, como se les ha conocido, con inmenso prestigio en el mundo de la ingeniería de software que se propusieron construir un nuevo lenguaje de modelado, UML, cuya primera versión (1.1) se presentó para su estandarización al OMG (Object Management Group) en 1997 y que fue aceptada. Otra gran aportación, en este caso no sólo conceptual sino práctica en forma de herramientas fue la creación de una herramienta CASE denominada Racional CASE.

Resumen de UML

El lenguaje Unificado de Modelado (UML) es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software. Captura decisiones y conocimientos sobre los sistemas que se deben construir. Se usa para entender, diseñar, hojear, configurar, mantener y controlar la información sobre tales sistemas.



32

Resumen de UML, Continuación

UML capta la información sobre la estructura estática y el comportamiento

dinámico de un sistema. La estructura estática define los tipos de objetos importantes para un sistema y su implementación, así como las relaciones entre los objetos. El comportamiento dinámico define la historia de los objetos en el tiempo y la comunicación entre objetos para cumplir sus objetivos. El modelar un sistema desde varios puntos de vista, separados pero relacionados, permite entenderlo para diferentes propósitos. UML no es un lenguaje de programación. Las herramientas pueden ofrecer generadores de código de UML para una gran variedad de lenguajes de programación, así como construir modelos por ingeniería inversa a partir de programas existentes. UML ayuda al usuario a entender la realidad de la tecnología y la posibilidad de que reflexione antes de invertir y gastar grandes cantidades en proyectos que no estén seguros en su desarrollo, reduciendo el coste y el tiempo empleado en la construcción de las piezas que constituirán el modelo.

Objetivos en UML

UML es un lenguaje de modelado de propósito general que pueden usar los modeladores. No tiene propietario y está basado en el común acuerdo de gran parte de la comunidad informática. Esto significa incluir conceptos de los métodos líderes para que UML pueda usarse como su lenguaje de modelado.

UML no pretende ser un método de desarrollo completo. No incluye un proceso de desarrollo paso a paso. UML pretende trabajar correctamente con todos, o al menos con la mayoría de los procesos de desarrollo existentes.

Participantes en UML

Data Access Corporation : Tom Digree Digital Equipment Hewlett-Packard : Martin Griss IBM : Steve Brodsky, Steve Cook, Jos Warner ICON Computing: Desmond D’Souza i-Logix (David Harel) Intellicorp and James Martin & co. (James Odell)



33

Participantes en UML, Continuación

MCI Systemhouse Microsoft ObjecTime Oracle Corp. Platinium Technology Rational Software : Grady Booch, James Rumbaugh y Ivar Jacobson Sterling Software Taskon : Trygve Reenskaug Texas Instruments Unisys : Sridhar Iyengar, GK Khalsa

Modelo captura una vista de un sistema del mundo real. Es una abstracción de dicho sistema, considerando un cierto propósito. Así, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propósito del modelo, y a un apropiado nivel de detalle.

Diagrama una representación gráfica de una colección de elementos de modelado, a menudo dibujada como un grafo con vértices conectados por arcos.

Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de interés. El código fuente del sistema es el modelo más detallado del sistema (y además es ejecutable). Sin embargo, se requieren otros modelos. Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de trazabilidad entre los diferentes modelos


34

Vistas y diagramas en UML

Área Vista Diagramas Conceptos Principales

Vista estática Diagrama de clases Clase, asociación, generalización, dependencia, realización, interfaz.

Vista de casos de uso Diagrama de casos de uso

Casos de uso, actor, asociación, extensión, inclusión, generalización de casos de uso

Vista de implementación Diagrama de componentes

Componente, interfaz, dependencia, localización

Estructural

Vista de despliegue Diagrama de despliegue Nodo, componente, dependencia, localización

Vista de máquina de estados

Diagrama de estados Estado, evento, transición, acción.

Vista de actividad Diagrama de actividad Estado, actividad, transición de terminación, división, unión.

Diagrama de secuencia Interacción, objeto, mensaje, activación

Dinámica

Vista de interacción

Diagrama de colaboración

Colaboración, interacción, rol de colaboración, mensaje.

Gestión del modelo Vista de gestión del modelo

Diagrama de clases Paquete, subsistema, modelo

Extensión de UML Todas Todos Restricción, estereotipo, valores etiquetados

Diagramas de UML

• Diagrama de Casos de Uso • Diagrama de Clases • Diagrama de Objetos • Diagramas de Comportamiento:

o Diagrama de Estados o Diagrama de Actividad o Diagramas de Interacción:

Diagrama de Secuencia Diagrama de Colaboración

• Diagramas de implementación: o Diagrama de Componentes o Diagrama de Despliegue



35

Vistas y diagramas en UML, Continuación

Paquetes Los paquetes ofrecen un mecanismo general para la organización de los modelos/subsistemas agrupando elementos de modelado. Se representan gráficamente como:

Cada paquete corresponde a un submodelo (subsistema) del modelo (sistema). Un paquete puede contener otros paquetes, sin límite de anidamiento pero cada elemento pertenece a (está definido en) sólo un paquete. Una clase de un paquete puede aparecer en otro paquete por la importación a través de una relación de dependencia entre paquetes.

Todas las clases no son necesariamente visibles desde el exterior del paquete, es decir, un paquete encapsula a la vez que agrupa


Use Cas

Use Cas

Diagramas de Casos de Uso

Scenario

Scenario

Diagramas de Colaboración

State Diagra

State DiagraDiagramas de Componentes

Component

Component

Diagramas de Distribución

State Diagra

State DiagraDiagramas de

Objetos

Scenario

Scenario

Diagramas de Estados

Use Cas

Use Cas

Diagramas de Secuencia

State Diagra

State DiagraDiagramas de

Clases

Diagramas de Actividad

Modelo

Nombre de paquete


36

Paquete, Continuación

El operador “::” permite designar una clase definida en un contexto distinto del actual

Clases La clase define el ámbito de definición de un conjunto de objetos. Cada objeto pertenece a una clase. Los objetos se crean por instanciación de las clases. Representada por un rectángulo con tres divisiones, una clase escribe un conjunto de objetos con características y comportamiento idéntico.

Ejemplo de una clase

LavadoraIndustrial


Nombre (Entidad) Propiedades (Atributo) Métodos (Operaciones)

Motocicletacolorcilindradavelocidad máxima

arrancar()acelerar()frenar()


37

Encapsulamiento

Los niveles de encapsulación están heredados de los niveles de C++:

• (-) Privado : es el más fuerte. Esta parte es totalmente invisible (excepto para clases friends en terminología C++)

• (#) Los atributos/operaciones protegidos están visibles para las clases friends y para las clases derivadas de la original

• (+) Los atributos/operaciones públicos son visibles a otras clases (cuando se trata de atributos se está transgrediendo el principio de encapsulación)

Reglas de visibilidad

La clase lavadora con atributos y métodos Instanciación de una clase

Lavadora miLavadora:Lavadora Marca modelo numeroSerie capacidad

Marca = “Patito” Modelo = “Economica” NumeroSerie = “GL566” Capacidad = 16

agregarRopa() agregarDetergente() sacarRopa() activar()


Reglas de visibilidadAtributo público : IntegerAtributo protegido : IntegerAtributo privado : Integer

"Operación pública"()"Operación protegida"()"Operación privada"()


38

Clases, Continuación

Una clase con un nombre de ruta

Electrodomesticos : : Lavadora

Un atributo puede mostrar su tipo así como su valor predeterminado

Lavadora marca: string = “Patito” modelo:string numeroSerie :string capacidad : integer

Lista de operaciones de la clase

Lavadora Marca modelo numeroSerie capacidad agregarRopa() agregarDetergente() sacarRopa() activar()

Firmar una clase

Lavadora marca modelo numeroSerie capacidad agregarRopa(C:string) agregarDetergente(C:string) sacarRopa(D:integer) activar():boolean


Electrodomesticos


39


Abreviar una clase

Lavadora Lavadora

marca ...

agregarRopa() ...

Estereotipos para organizar una lista de atributos y operaciones Responsabilidades de una clase Restricción de un atributo

Lavadora <<info identificacion>> marca modelo numeroSerie <<info maquina>> capacidad <<relacionado con la ropa>> agregarRopa() agregarDetergente() sacarRopa() <<relacionado con la maquina>> activar() Recibe ropa sucia y devuelve ropa limpia

Notas adjuntas Proporciona mayor información respecto a la clase Una nota puede contener tanto una imagen como texto

Lavadora marca modelo numeroSerie capacidad agregarRopa() agregarDetergente() sacarRopa() activar()


{capacidad = 7,8 o 9 Kg}

Vease la norma NOM GHJ954


40


Qué es lo que hacen las clases y cómo encontrarlas

Las clases son el vocabulario y terminología de un área del conocimiento. En las entrevistas con los clientes se debe prestar atención a los sustantivos que utilizan para describir las entidades de sus negocios; ya que los sustantivos se convertirán en las clases del modelo. Los verbos constituyen las operaciones de las clases. Los atributos surgirán como sustantivos relacionados con los nombres de la clase.

Ejemplo. Modelo de baloncesto

Esta podría ser una entrevista con el entrenador. A: Entrenador ¿de que se trata el juego? E: “Consiste en arrojar en balón a través de un arco, conocido como cesto, y hacer una mayor puntuación que el oponente. Cada equipo consta de cinco jugadores: dos defensas, dos delanteros y un central. Cada equipo lleva el balón al cesto del equipo oponente con el objetivo de hacer que el balón sea encestado”. A: “¿Cómo se hace para llevar el balón al otro cesto?” E: “Mediante pases y dribles. Pero el equipo tendrá que encestar antes de que termine el lapso para tirar” A: “¿El lapso para tirar?” E: “Así es, son 24 segundos en el baloncesto profesional, 30 en un juego internacional, y 35 en el colegial para tirar el balón luego de que un equipo toma posesión de él” A: “¿Cómo funciona el puntaje?” E: “Cada canasta vale dos puntos, a menos que el tiro haya sido hecho detrás de la línea de los tres puntos. En tal caso, serán tres puntos. Un tiro libre contará como un punto. A propósito, un tiro libre es la penalización que paga un equipo por cometer una infracción. Si un jugador infracciona a un oponente, se detiene el juego y el oponente puede realizar diversos tiros al cesto desde la línea de tipo libre.” A: “Hábleme más acerca de lo que hace cada jugador.” E: “Quienes juegan de defensa son, en general, quines realizan la mayor parte de los dribles y pases: Por lo general tienen menor estatura que los delanteros, y éstos, a su vez, son menos altos que el central (poste). Se supone que todos los jugadores pueden burlar, pasar, tirar y rebotar. Los delanteros realizan la mayoría de los rebotes y los disparos de mediano alcance, mientras que el central se mantiene cerca del cesto y dispara desde un alcance corto” A: “¿Qué hay de las dimensiones de la cancha?”



41

clases, Continuación

E: “En un juego internacional, la cancha mide 28 metros de longitud y 15 de

ancho; el cesto se encuentra a 3.05 m. del piso. En un juego profesional, el juego dura 48 minutos, divididos en 4 cuartos de 12 minutos cada uno. En un juego colegial e internacional, la duración es de 40 minutos, divididos en 2 mitades de 20 minutos. Un cronómetro del juego lleva un control del tiempo restante.”

Ejercicio 4

Identifique las clases del juego de baloncesto

Diagrama de Clases

El Diagrama de Clases es el diagrama principal para el análisis y diseño. Un diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia La definición de clase incluye definiciones para atributos y operaciones El modelo de casos de uso aporta información para establecer las clases, objetos, atributos y operaciones



42

Uso de relaciones entre clases

• Asociaciones • Multiplicidad • Asociaciones calificadas • Asociaciones reflexivas • Herencia y generalización • Dependencias

Asociaciones Cuando las clases se conectan entre sí de forma conceptual.

Una asociación entre un jugador y un equipo

Jugador EquipoParticipa en

En una asociación cada clase juega un papel o rol

Jugador EquipoPart ic ipa en

Em pleadorEm pleado

Pueden aparecer 2 asociaciones entre clases en el mismo diagrama

EquipoJugador

Pa rt ic ipa en

Emplea

Pueden asociarse diversas clases con una en particular

Defens a

Delantero

Centro

Equipo

Participa en

Parti cipa en

Parti cipa en



43

Asociaciones entre clases, Continuación

Restricciones en las asociaciones

Reglas que deben seguir las asociaciones entre dos clases. Las restricciones se escriben entre llaves

La asociación atiende está restringida para que el cajero atienda en turno

Caj ero Cl ien teAtiende

{Ordenado}

La relación O entre dos asociaciones en una restricción

Clases de asociación

Una asociación, al igual que una clase, puede contener atributos y operaciones (métodos). Si este es el caso tendremos una clase de asociación. Una clase de asociación se trata como una clase estándar y por lo tanto puede tener asociaciones con otras clases.

Contrato es un atributo de la asociación

Equipo

Ju gadorPartic ip a e n

Contrato DirectorGeneralNegociado por

Vínculos Una asociación también cuenta con instancias de una clase. (Conecta a los

objetos en lugar de las clases).


Academ icoEs tudiante de educación m edia s uperior

Com ercia l

El ige

El ig e

{OR}


44

vínculos, Continuación

Deberá subrayar el nombre de un vínculo como se hace en el nombre de una clase

Multiplicidad La cantidad de objetos de una clase que se relacionan con un objeto de la clase asociada

Cuando la clase A tiene una multiplicidad de 1 a ninguno o uno con la clase B, la clase B se dice que es opcional para la clase A

Equipo

Jugador

15

Participa en

15

Posibles multiplicidades y como representarlas en UML

Una clase puede relacionarse con otra en un esquema de • Uno a uno • Uno a muchos • Uno a uno o más • Uno a ninguno o uno • Uno a un intervalo definido (a cinco o a diez) • Uno a exactamente n • Uno a un conjunto de opciones (a diez o nueve)

Se emplean:

( * ) para representar más y para representar muchos O se representa por dos puntos como: 1..* (uno o más) O se representa por una como 5, 10 (en otro contexto 5 o 10)


gustavoNajera:Jugador nacional:Equipo participa en


45

Multiplicidad, Continuación

Uno a uno Uno a muchos Uno a uno o más Uno a ninguno o uno Uno a un intervalo definido (a 5 o a 10) Uno a exactamente n Uno a un conjunto de opciones (a 10 o 9)

Es pos aEs pos o

11 11

Esta cadado con

EstudianteMaes tro

*1 *1

Enseña

ClienteCajero

1..*1 1..*1

Atiende

Chim eneaCas a

0,11 0,11

Tiene

Estud iantedeT iem poCom ple to Horas deCredi tos

12..181

Toma

12..181

Triciclo R uedas

31

Tiene

31

Huevera Huevos

12,2 41

Contiene

1 12,2 4



46

Asociaciones, Continuación

Asociaciones calificadas

Cuando la multiplicidad de una asociación es de uno a muchos, aparece la búsqueda, por lo tanto se requiere de un atributo para localizar un objeto, dicho atributo es un identificador. En el UML la información de identidad se conoce como calificador.

Asociaciones reflexivas

Una clase puede ser una asociación consigo misma, esto ocurre, cuando una clase tiene objetos que pueden jugar diversos papeles.

1 Localiza *Recepcionista Reservación Numero de confirmación

Conductor

OcupanteDeAutomovil 1

pasajero 0..4

Conduce

Compañíanombredirección

Personanombres.s.

0..1

*

jefe 0..1

Administra

empleado

*

0..1

0..1mujer

0..1

casado-con

marido

0..1

*

* trabaja-para*emplea-a

*


47

Herencia y generalización

En el UML la herencia se conoce como Generalización. Una clase (la secundaria o subclase) puede heredar los atributos y operaciones de otra (la principal o superclase). La clase principal (madre) es más genérica que la secundaria (hija). El UML representará la herencia con una línea que conecte a la clase principal con la secundaria. En la parte de la línea que se conecta con la clase principal, colocará un triángulo sin rellenar que apunte a la clase principal. Este tipo de conexión se interpreta con la frase ES UN TIPO DE.

Anim al

Anfib io Mam ifero Reptil

C aba llo

Cuando modele la herencia, debe asegurarse de que la clase secundaria

satisfaga la relación es un tipo de con la clase principal. Si no se cumple tal relación, tal vez una asociación de otro tipo podría ser más adecuada. Con frecuencia las clases secundarias agregan otras operaciones y atributos a los que han heredado.

Una clase puede no provenir de una clase principal, en cuyo caso será una clase BASE O CLASE RAÍZ.

Una clase podría no tener clases secundarias, en cuyo caso será una clase final o clase hoja.

Si una clase tiene exactamente una clase principal tendrá herencia simple.

Si una clase proviene de varias clases principales, tendrá una herencia múltiple.

Ventajas de la generalización

• Permite gestionar la complejidad mediante un ordenamiento taxonómico de clases

• Se obtiene usando los mecanismos de abstracción de Generalización y/o Especialización

• La Generalización consiste en factorizar las propiedades comunes de un conjunto de clases en una clase más general



48

Herencia y Generalización, Continuación

Práctica

Práctica Herencia múltiple


Funcionando Estropeado

Coche

Animal

Bípedo Cuadrúpedo

Con Pelos

Con Plumas

Con Escamas

Herbívoro

Carnívoro

cubertura

cobertura

cobertura

comida

nro patas nro patas

comida

Conejo


49

Diagrama de clases, Continuación

Polimorfismo El término polimorfismo se refiere a que una característica de una clase puede

tomar varias formas. El polimorfismo representa en nuestro caso la posibilidad de desencadenar operaciones distintas en respuesta a un mismo mensaje. Cada subclase hereda las operaciones pero tiene la posibilidad de modificar localmente el comportamiento de estas operaciones.

Ejemplo: todo animal duerme, pero cada clase lo hace de forma distinta

Solución


Animaldormir()

León Oso Tigre

Dormir() { sobre la espalda }

Dormir() { sobre el vientre }

Dormir() { }

Animal dormir()

León

dormir() Oso

dormir() Tigre

dormir()

Dormir() { en un árbol }


50

Ejercicio 5

Realice un diagrama de clases que muestre las relaciones de herencia entre las clases necesarias para realizar un programa orientado a objetos que opera con diferentes figuras geométricas. Tenga en cuenta las siguientes restricciones:

a) El círculo y el polígono se pueden rellenar con diferentes formas b) El arco, la línea, el polígono y el círculo se pueden reducir y ampliar c) Todas las figuras se pueden mover, seleccionar, rotar mostrar y ocultar d) El círculo se rota distinto a las demás figuras geométricas. e) Los bordes de todas las figuras tienen un color, un centro, un grosor

del borde f) El arco y la línea tienen además una orientación. g) La línea tiene coordenadas de sus extremos h) El arco tiene radio, ángulo de inicio y ángulo del arco. i) El número de caras y las coordenadas de los vértices son datos del

polígono j) Del círculo es necesario conocer el diámetro.



51


Clases abstractas Jugador es una clase abstracta

Funcionan como clases principales para clases secundarias importantes. Lo que nos interesa de las clases secundarias son las instancias que finalmente se generarán. Las clases que no proveen objetos se dice que son abstractas. Se distinguen por tener su nombre en cursivas.

Reloj es una clase abstracta


Jugadornom bretam añopesoVelocidadAlCorrersa l toVertica l

drib la r()pasar()rebotar()ti rar()

Delantero

Centro

encestarBa lon()

Defens a

correrA lFrente()qui ta rBa lon()

Reloj

contro larT iem po()

Cronom etroDelJuego Laps oDeTiro


52


Dependencias Es un tipo de relación en el que una clase utiliza a otra. Es uso más común de

una dependencia es mostrar que la firma de la operación de una clase utiliza a otra clase. Ejemplo: menú de llenado de formularios.

Sistem a

m ostrarForm ulario()

Form ulario

Otros tipos de asociaciones

• Agregaciones • Composiciones • Contextos • Interfaces y realizaciones

Agregaciones Una clase cuenta de otras clases.

-La agregación representa una relación parte_de entre objetos -En UML se proporciona una escasa caracterización de la agregación -Puede ser caracterizada con precisión determinando las relaciones de comportamiento y estructura que existen entre el objeto agregado y cada uno de sus objetos componentes.

Se puede representar una agregación como una jerarquía dentro de la clase completa en la parte superior y los componentes por debajo de ella. Se emplea una línea con rombo sin relleno.

Restricciones en las agregaciones

Cuando un conjunto de posibles componentes se establece dentro de una relación O.


Polígono Punto13..*

13..*{ordenado}

contiene


53

Agregaciones, Continuación

Ejemplo de agregación con restricción O

Ens aladaSopa PlatoFuerte Pos tre

Com ida

1

11 1 11 1

1

1 1{O}

Ejercicio 6

Completar el siguiente diagrama de clases con agregación, asociación y multiplicidad

UnidadDeDis co UnidadDeDis quette RAM CD-ROM TarjetaVideo Boton Bola

Monitor Raton

TarjetaSonido

GabineteBocinas Teclado

Eui poD eC om puto

Composición

Es un tipo especial de una agregación. Cada componente dentro de la composición puede pertenecer a un todo. El rombo está relleno.

SuperficieDeL aMesa

MesaDeCafe

11

Pata

1

4

1

4


54

Contextos Un diagrama de contexto es un mapa detallado de alguna sección de un mapa

de mayores dimensiones. Se emplea cuando aparecen agrupamientos de clases, como agregaciones o composiciones para enfocar la atención en un agrupamiento o en otro. (de composición, de sistema, etc.).

Ejercicio 7

Generar un diagrama de clase que muestre las asociaciones y la composición de las siguientes clases:

Diagrama de contexto

Camis a

Manga Talle Cuello

Botonadura

Boton Ojal

Un diagrama de contexto del sistema muestra los componentes de una clase y la forma en que la clase se relaciona con las otras que hay en el sistema


55

Ejercicio 8

Diseño

1. Decidir a que categoría: generalización, asociación simple o agregación, pertenecen las relaciones siguientes. Coloque una G en caso de Generalización, una A para la asociación simple y una C para la agregación.

2. Represente cada uno con un diagrama de clases independiente

empleando la notación gráfica de UML

a. __ Un cliente puede ser cliente de menudeo o de mayoreo. b. __ Un barco de vela puede o no tener motor y tiene un casco y

al menos una vela. c. __ Los hombres y las mujeres son seres humanos. Todo ser

humano es una forma viva. d. __ Los empleados asisten a reuniones dirigidas por un gerente. e. __ Una base de datos esta formada por un conjunto de archivos. f. __ Los alumnos realizan un examen final de una o mas

materias y obtienen una calificación de éste. g. __ Un vuelo conecta a dos aeropuertos. h. __ Las personas pueden ser empleadas o desempleadas. i. __ El corazón, las venas y las arterias son partes del sistema

circulatorio. j. __ Las tarjetas bancarias pueden ser de debito o de crédito pero

no de ambas.


56

Ejercicio 9

Realice el diagrama de clases del problema del juego de baloncesto

Ejercicio 10

Realice el diagrama de clases del siguiente problema. En un hotel se hospedan huéspedes mexicanos y extranjeros. El hotel cuenta con 250 habitaciones que pueden o no estar rentadas. Un huésped puede rentar una o más habitaciones, pero una habitación está rentada a nombre de un solo huésped.


57

Casos de uso Definición

Los diagramas de clases muestran una vista estática del sistema, ayudan a que el analista se comunique con el cliente. La idea dinámica ayudará al analista a comunicarse con un grupo de desarrolladores. Los casos de uso capturan los REQUISITOS del cliente. El caso de uso es una estructura que ayuda a los analistas a trabajar con los usuarios para determinar la forma en que se usará un sistema. Con una colección de casos de uso se puede hacer un bosquejo de un sistema en términos de lo que los usuarios intenten hacer con él. El caso de uso es una colección de situaciones respecto al uso de un sistema. Cada escenario describe una secuencia de eventos. Cada secuencia se inicia por una persona, una parte del HW o por el paso del tiempo. A las entidades que inician secuencias se les conoce como ACTORES.

Secuencia de pasos en los escenarios

Cada caso de uso es una colección de escenarios y cada escenario es una secuencia de pasos. Cada diagrama tendrá su propia página, de igual manera, cada escenario de caso de uso tendrá su propia página, donde se ilustrará a modo de texto a:

• El actor que inicia el caso de uso • Condiciones previas para el caso de uso. • Pasos en el escenario • Condiciones posteriores cuando se finaliza el escenario • El actor que se beneficia del caso de uso



58

Casos de uso, Continuación

Diagramas de caso de uso en el proceso de análisis Actores y casos de uso de alto nivel Modelos de casos de uso

Las entrevistas del cliente deberán iniciar el proceso. Estas entrevistas producirán diagramas de clases que fungirán como las bases de conocimiento para el dominio del sistema (el área en el cual resolverá los problemas). Una vez que se conozca la terminología general del área del cliente, estará listo para hablar con los usuarios. Las entrevistas con los usuarios comienzan con la terminología del dominio, aunque deberán alternarse hacia la terminología de los usuarios. Los resultados iniciales de las entrevistas deberán revelar a los actores y casos de uso de alto nivel que describirán los requerimientos funcionales en términos generales. Esta información establece los confines y ámbito del sistema. Las entrevistas posteriores con los usuarios profundizarán en estos requerimientos, lo que dará por resultado modelos de caso de uso que mostrarán escenarios y las secuencias detalladamente. Esto podría resultar en otros casos de uso que satisfagan las relaciones de inclusión y extensión. En esta fase, es importante confiar en su compresión del dominio (a partir de los diagramas de clases derivados de las entrevistas con el cliente). Si no comprende el dominio podría crear demasiados casos de uso.

Puntos clave de los casos de uso

1. Los Casos de Uso (Ivar Jacobson) describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el p.d.v. del usuario

2. Permiten definir los límites del sistema y las relaciones entre el sistema y el entorno

3. Los Casos de Uso son descripciones de la funcionalidad del sistema independientes de la implantación

4. Comparación con respecto a los Diagramas de Flujo de Datos del Enfoque Estructurado

Ejemplo


Actor A Caso de Uso A

Actor BCaso de Uso B


59


Actores Principales: personas que usan el sistema

Secundarios: personas que mantienen o administran el sistema Material externo: dispositivos materiales imprescindibles que forman

parte del ámbito de la aplicación y deben ser utilizados. Otros sistemas: sistemas con los que el sistema interactúa

La misma persona física puede interpretar varios papeles como actores distintos El nombre del actor describe el papel desempeñado

Relaciones UML define cuatro tipos de relación en los Diagramas de Casos de Uso

Comunicación un actor se comunica con un caso de uso

Inclusión una instancia del Caso de Uso origen incluye también el comportamiento descrito por el Caso de Uso destino

Extensión el Caso de Uso origen extiende el comportamiento del Caso de Uso destino

Herencia el Caso de Uso origen hereda la especificación del Caso de Uso destino y posiblemente la modifica y/o amplía


Actor C aso de U so

Caso de Uso Origen C aso de U so Desti no

<<include>>

Caso de Uso Origen C aso de U so Desti no

<<extend>>

Caso de Uso Hij o Caso de Uso Padre


60


Ejemplos de relaciones en los casos de uso

Construcción del caso de uso

1. Un caso de uso debe ser simple, inteligible, claro y conciso 2. Generalmente hay pocos actores asociados a cada Caso de Uso 3. Preguntas clave:

•¿cuáles son las tareas del actor? •¿qué información crea, guarda, modifica, destruye o lee el actor? •¿debe el actor notificar al sistema los cambios externos? •¿debe el sistema informar al actor de los cambios internos?


Ident ificación

Transferencia en Internet

ClienteTransferencia

<<include>>

<< extend>>

Place OrderSalesperson

*1 *1

Supply Customer Data

<<include>>

Order Product

<<include>>

Arrange Payment

<<include>>

Request Catalog

<<extend>>

the salesperson asks for the catalog


61


Qué comprende la descripción del Caso de Uso

•el inicio: ¿cuándo y qué actor lo produce? •el fin: ¿cuándo se produce y qué valor devuelve? •la interacción actor-caso de uso: ¿qué mensajes intercambian ambos? •objetivo del caso de uso: ¿qué lleva a cabo o intenta? •cronología y origen de las interacciones •repeticiones de comportamiento: ¿qué operaciones son iteradas? •situaciones opcionales: ¿qué ejecuciones alternativas se presentan en el caso de uso?

Ejemplo de caso de uso de alto nivel: Comprar producto

El caso de uso es un documento narrativo que describe la secuencia de eventos de un actor

Cajero ClienteComprar productos

Documentación del caso de uso

Caso de uso: Comprar productos Actores: Cliente, cajero Tipo: Primario Descripción: Un cliente llega a la caja registradora con los

artículos que comprará. El cajero registra los artículos y cobra el importe. Al terminar la operación, el Cliente se marcha con los productos.

Ejemplo de caso de uso expandido: Comprar productos con efectivo

Cajero ClienteComprar productos

Registra los datos

Paga o entega el cambio de los pro ductos comprados



62


Sección: Principal

Caso de uso: Comprar productos Actores: Cliente, cajero Propósito: Capturar una venta y su pago Tipo: Primario Descripción: Un cliente llega a la caja registradora con los

artículos que comprará. El cajero registra los artículos y cobra el importe. Al terminar la operación, el Cliente se marcha con los productos.

Referencias cruzadas:

Funciones: R1.1, R1.2, R1.3,

Curso normal de los eventos

Acción de los actores Respuesta del sistema 1. Este caso de uso comienza

cuando un Cliente llega a la caja con productos que desea comprar.

2. El Cajero registra los productos

3. Determina el precio del producto y agrega la información sobre él a la actual transacción de venta. Se muestran la descripción y el precio del producto actual.

4. Al terminar la captura de los productos, el Cajero indica a la terminal de venta que terminó la captura de los productos

5. Calcula y presenta el total de la venta.

6. El Cajero le indica el total al Cliente.

7. El Cliente escoge la forma de pago:

a. Si paga en efectivo, véase la sección Pagar en efectivo.



63


Acción de los actores Respuesta del sistema

b. Si paga con tarjeta de crédito, véase la sección Pagar con Tarjeta de crédito.

c. Si paga con cheque, véase la sección Pagar con cheque.

8. Registra la venta terminada 9. Actualiza los niveles de

inventario 10. Genera un recibo

11. El cajero entrega el recibo al cliente

12. El cliente se marcha con los productos comprados

Cursos Alternos: Línea 2: se introduce un identificador inválido del producto. Indique el error. Línea 7: el Cliente no pudo pagar. Cancele la transacción de venta. Sección: pagar en efectivo

Acción de los actores Respuesta del sistema 1. El cliente da un pago en

efectivo – el “efectivo ofrecido”-, posiblemente mayor que el total de la venta

2. El Cajero registra el efectivo ofrecido

3. Presenta la diferencia al cliente.

4. El cajero deposita el efectivo recibido y extrae la diferencia. El cajero le entrega el cambio al cliente.



64


Cursos alternos:

Línea 1: El Cliente no tiene suficiente efectivo. Puede cancelar o iniciar otro método de pago. Línea 4: La caja no contiene suficiente efectivo para pagar la diferencia. El cajero pide más efectivo al supervisor o le pide al Cliente otro billete de menor denominación u otra forma de pago.

Ejercicio 11

Realice las descripciones de las secciones: Pago con tarjeta de crédito y pago con cheque.


65


66

Ejercicio 12

Genere el diagrama de casos de uso y su descripción de retirar efectivo en un cajero automático.


67

Ejercicio 13

Genere el diagrama de casos de uso y su descripción de realizar una llamada telefónica.


68

Ejercicio 14

a) Elabore un diagrama de paquetes de casos de uso. b) Descomponga cada paquete en un diagrama de casos de uso.


69

Diagramas de interacción

Los objetos interactúan para realizar colectivamente los servicios ofrecidos por las aplicaciones. Los diagramas de interacción muestran cómo se comunican los objetos en una interacción. Existen dos tipos de diagramas de interacción: el diagrama de colaboración y el Diagrama de secuencia.

Mensajes Sintaxis para mensajes: predecesor / guarda secuencia: retorno := msg(args)

El Diagrama de Secuencia es más adecuado para observar la perspectiva cronológica de las interacciones. El Diagrama de Colaboración ofrece una mejor visión espacial mostrando los enlaces de comunicación entre objetos. El Diagrama de Colaboración puede obtenerse automáticamente a partir del correspondiente D. de Secuencia (o viceversa).

Diagrama de secuencia

o Muestra la secuencia de mensajes entre objetos durante un escenario concreto.

o Cada objeto viene dado por una barra vertical. o El tiempo transcurre de arriba abajo. o Cuando existe demora entre el envío y la atención se puede indicar

usando una línea oblicua.

Representación de un objeto en un diagrama de secuencia

: n o m b r e

Los objetos se colocan cerca de la parte superior del diagrama de izquierda a derecha y se acomodan de manera que simplifiquen el diagrama. La extensión que está debajo de cada objeto será una línea discontinua conocida como la línea de vida de un objeto. Junto con la línea de vida de un objeto se encuentra un pequeño rectángulo conocido como activación, el cual representa la ejecución de una operación que realiza el objeto. La longitud del rectángulo se interpreta como la duración de la activación.



70

Diagrama de Secuencias, Continuación

Mensaje Un mensaje que va de un objeto a otro pasa de la línea de vida de un objeto a

la de otro. Un objeto puede enviarse un mensaje a sí mismo. Un mensaje puede ser:

o Simple o Sincrónico o Asincrónico

Tiempo El diagrama representa el tiempo en dirección vertical. El tiempo se inicia en

la parte superior y avanza hacia la parte inferior. Un mensaje que esté más cerca de la parte superior ocurrirá antes que uno que esté cerca de la parte inferior. Con ello, el diagrama tiene dos dimensiones. La dimensión horizontal es la disposición de los objetos, y la dimensión vertical muestra el paso del tiempo.

:nombre1 :nombre2



71

Diagrama de secuencias, Continuación

Ejemplo de un diagrama de secuencias

Ejercicio 15

Genere el diagrama de secuencia del siguiente problema: Suponga que un usuario de una interfaz grafica (GUI) presiona una tecla alfanumérica, se especifica la siguiente secuencia de paso:

1. La GUI notifica al sistema operativo que se oprimió una tecla 2. El sistema operativo le notifica a la UCP 3. El sistema operativo actualiza la GUI 4. La UCP notifica a la tarjeta de video 5. La tarjeta de video envía un mensaje al monitor 6. EL monitor presenta el carácter alfanumérico en la pantalla, con lo

que se hará evidente al usuario

: Encargado :WInPréstamos :Socio :Video :Préstamo

prestar(video, socio)

verificar situación socio

verificar situación video

registrar préstamo

entregar recibo


72

Ejercicio 16

Máquina despachadora de refrescos. Suponga que comenzará a diseñar una máquina despachadora de refrescos. Un cliente desea comprar una lata de refresco. El Cliente deberá insertar el dinero, posteriormente realizará una selección. Si todo funciona bien la máquina contará con al menos una lata de refresco que proporcionará al cliente.

a. Genere un diagrama de casos de uso de la máquina despachadora de refrescos que incluya a los actores:

i. Cliente ii. Representante del proveedor

iii. Recolector b. Genere el diagrama de secuencias del caso de uso “Comprar

Refresco” que incluya a los objetos: i. Cliente (como actor)

ii. Fachada iii. Registrador (de dinero) iv. Dispensador (de refrescos)


73


74

Diagrama de colaboración

Son útiles en la fase exploratoria para identificar objetos. La distribución de los objetos en el diagrama permite observar adecuadamente la interacción de un objeto con respecto de los demás. La estructura estática viene dada por los enlaces; la dinámica por el envío de mensajes por los enlaces.

Mensajes Un mensaje desencadena una acción en el objeto destinatario.

sincronización Un mensaje se envía si han sido enviados los mensajes de una lista:

condiciones Un mensaje se envía de manera condicionada

Valores de retorno

Un mensaje que devuelve un resultado


A

B A.1, B.3 / 1:Mensaje

A B

[x>y] 1: Mensaje

A B

1: distancia:= mover(x,y)


75

Diagrama de colaboración, Continuación

Ejemplo de un diagrama de colaboración

Ejercicio 17

Genere el diagrama de colaboración del de secuencia del ejercicio 2.

: Encargado

:WInPréstamos

:Socio

:Video

:Préstamo

1: prestar(video, socio)

2: verificar situación socio

3: verificar situación video

4: registrar préstamo5: entregar recibo


76

Diagrama de estados

Muestra un cambio en un sistema, es decir, que los objetos que lo componen modificaron su estado como respuesta a los sucesos y al tiempo. Apagado –encendido. Cada objeto está en un estado en cierto instante. El estado está caracterizado parcialmente por los valores algunos de los atributos del objeto. El estado en el que se encuentra un objeto determina su comportamiento. Cada objeto sigue el comportamiento descrito en el D. de Estados asociado a su clase. Los D. De Estados y escenarios son complementarios

Símbolos UML en el diagrama de estados

Ejemplo de un Diagrama de Estados para la clase persona

Acciones Se puede especificar el ejecutar una acción como consecuencia de entrar, salir, estar en un estado, o por la ocurrencia de un evento


en el paro en activo

jub ilado

contratar

perder empleo

jubilarsejubilarse

estadoentry: acción por entrar exit: acción por salir do: acción mientras en estado on evento: acción


77

Diagrama de estados,Continuación

Los estados y transiciones de una interfaz gráfica de usuario

Encender la PC

Inicialización

do/ Arrancar

Operación ApagarApagado

Protector de pantalla

[ lapso transcurrido ] Teclazo o movimiento del ratón

Sub-estados secuenciales

Encender la PC

Inicialización

do/ Arrancar

OperaciónA la espera de

acción del Registro de una

acción del usuarioRepresentación de la

acc ión del usuario

ApagarApagado

Protector de pantalla

[ lapso transcurrido ] Teclazo o movimiento del ratón

A la espera de acción del

Registro de una acción del usuario

Representación de la acc ión del usuario


78

Ejercicio 18

Genere el diagrama de estados de una factura


79

Diagrama de actividades

Es una especialización del Diagrama de Estado, organizado respecto de las acciones y usado para especificar: •Un método •Un caso de uso •Un proceso de negocio (Workflow) Las actividades se enlazan por transiciones automáticas. Cuando una actividad termina se desencadena el paso a la siguiente actividad Permite especificar decisiones y concurrencia.

Decisiones en un diagrama de actividades

Despertar

Desayunar

[ hambriento ]

Volver a dormir

[ inapetente ]

Despertar

Desayunar Volver a dormir

[ inapetente ][ hambriento ]



80

Diagrama de actividades, Continuación

Ejemplo de un diagrama de actividades

Marcos de trabajo


B u s c a r B e b id a [ n o h a y c a fé ]

P o n e r c a fé e n filtro

A ñ ad ir a g u a a l d e p ós i to

C o g e r ta z a

P o n e r filtro e n m á q u in a

E n c e n d e r m áq u in a

C afé e n p re p a ra c ió n

/ c a fe t e ra .O n

S e rv ir c a fé B e b e r

C o g e r z u m o

[ h a y c a fé ]

in dic a do r d e fin

[ h a y z u m o ]

[ n o z u m o ]

S o lic ita r p a s a je

S e le c c io n a r v u e lo

P a g a r p a s a je

V e r if ic a r e x is te n c ia v u e lo

I n fo rm a r a lte rn a ti v a s y p re c io s

S o lic it a r p a g o

R e s e rv a r p l a z a s

E m itir b i ll e te

D a r d e ta lle s v u e lo

C o n firm a r p la z a re s e rv a d a

A ir l i neV e n d e d o rP a s a j e r o


81

Diagrama de actividades, Continuación

Ejercicio 19

Genere un diagrama de actividades que muestre como preparar un omelette con queso y cebolla.


82

Diagrama de componentes

Los diagramas de componentes describen los elementos físicos del sistema y sus relaciones. Muestran las opciones de realización incluyendo código fuente, binario y ejecutable. Los componentes representan todos los tipos de elementos software que entran en la fabricación de aplicaciones informáticas. Pueden ser simples archivos, paquetes de Ada, bibliotecas cargadas dinámicamente, etc. Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente utiliza los servicios ofrecidos por otro componente.

Interfaz de Terminal

Gestión de Cuentas Rutinas de conexión Acceso a BD

Control y Análisis


83

Diagramas de despliegue

Muestran la disposición física de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos

Estereotipos en los diagramas de despliegue

Los estereotipos permiten precisar la naturaleza del equipo: •Dispositivos •Procesadores •Memoria •Los nodos se interconectan mediante soportes bidireccionales que pueden a su vez estereotiparse

Diagrama de componentes y despliegue

Nodo

Terminal Punto de Venta

<<Cliente>>

Base de Datos

<<Servidor>>

Control

<<TCP/IP>>

<<RDSI>>

<<RDSI>>


84

Anexo A: Project

Capitulo 1

1.1 Introducción a Project 1.2 Planeación de proyectos 1.3 Seguimiento de proyectos


85

1.1 Introducción a Project

Introducción El control de proyectos es una tarea importante dentro de las

responsabilidades del planificador. La mayoría de los proyectos se siguen se manera informal: se tiene una línea o fecha de entrega y se monitorea el progreso del proyecto de manera intuitiva. El uso de herramientas computacionales, permite dar seguimiento y controlar un proyecto para aplicar medidas correctivas antes de que aparezcan los problemas.


86

Ingreso a Microsoft Project

Para cargar Project, haga doble click en el icono correspondiente

Cuando el mensaje de Bienvenida aparezca seleccione la opción Archivo|Nuevo para comenzar un proyecto. La pantalla de proyect está dividida en varias partes:

1. Abajo del menú se encuentra la barra de herramientas

2. A la izquierda de la pantalla se encuentra una hoja de opciones (seleccione el icono “Diagrama de Gantt”)

3. Al centro aparecer la barra de tareas

4. A la derecha aparece la gráfica de Gantt. Emplea barras horizontales que representan la agenda de tareas.

Para cambiar los tamaños relativos de cada parte de la

pantalla, arrastre sus límites (o fronteras) al nuevo tamaño que desee.


87

Inicialización del proyecto

Muchas opciones de apariencia y funcionalidad del proyecto pueden controlarse empleando del menú Herramientas|Opciones.... Para esta práctica, cambie los parámetros seleccionando en la pestaña Programación para que aparezcan de la siguiente forma:

deberá modificar

1. Mostrar el trabajo en: días 2. Tipo de tarea predeterminada: Duración fija


88

Funcionalidad y apariencia del proyecto

Mucha opciones de funcionalidad y apariencia del proyecto pueden controlarse utilizando el elemento del menú Herramientas|Opciones... Para esta práctica deberá cambiar algunos parámetros del proyecto. En la caja de dialogo de Opciones, seleccione la pestaña Programación, y cambie distintos parámetros para que aparezcan de la siguiente manera:

Deberá modificar:

1. Mostrar el trabajo en: días 2. Tipo de tarea predeterminada: duración fija

Cambiar la fecha de inicio del proyecto

Seleccione el elemento del menú Proyecto|Información del proyecto... Realice las siguientes modificaciones:

1. Fecha de comienzo: 04/03/03 (4 de marzo de 2003) 2. Fecha de hoy: 01/03/03 (1 de marzo de 2003)


89

Planeación del proyecto

La planeación de proyectos implica identificar las tareas relacionadas, su duración y las relaciones existentes entre ellas. MS Project calcula automáticamente la duración total del proyecto y otra información relacionada.

Agregar tareas Para agregar información de tareas, haga clic en una celda vacía dentro de la tabla de tareas, escriba el nombre de la tarea y presione “enter”. El nombre de la tarea aparece en la celda, y se le asigna por omisión un valor de duración de 1 día. Para cambiar este valor, haga clic en la celda en cuestión, escriba la duración correcta, y presione “enter”.


90

Ejercicio • Agregue una lista de tareas como aparece a continuación con la duración especificada

Para insertar una tarea nueva, seleccione dentro de la Tabla de Tareas el renglón debajo de donde desea insertar las nueva tarea. Seleccione el elemento del menú Insertar|Nueva Tarea (Ins) para generar un renglón en blanco en la Tabla de Tareas. Escriba una nueva tarea y su duración.

• Agregue dos tareas más: Inicio de proyecto al comienzo de la lista y Fin de proyecto en el último renglón de la lista. Asigne a ambas una duración de 0 días.

Una tarea especial denominada Hito tiene, usualmente, una duración de 1 ó 0 días, y representa un evento más que una tarea. Para crear un Hito, haga doble clic en la tarea. En la caja de dialogo de Información de la tarea, seleccione la pestaña Avanzado. Seleccione el recuadro indicado para marcarla como Hito.

• Inicio de proyecto y fin de proyecto son consideradas como Hitos. Se pueden crear Jerarquías de Tareas: Tareas principales y sus subtareas para crearlas utilice los botones de la barra de herramientas.



91

Ejercicio, Continuación

• Agregue una nueva tarea llamada T4 debajo de T3 con duración de 15

días. • Ponga T4, T5 y T6 como subtareas de T3

Para identificar la secuencia de tareas, haga doble clic en cada tarea y designe su predecesora: las que en orden lógico la preceden. En la caja de dialogo de Información de la Tarea seleccione la pestaña Predecesoras, se pueden asignar escribiendo el número de tarea directamente (separadas por comas cuando sean varias) o seleccionando una celda en blanco y el Nombre de la tarea y seleccionándola de la lista que presenta. Se crea una liga entre tareas y la gráfica de Gantt refleja estos cambios.



92


• Actualice las predecesoras de cada tarea de acuerdo a la siguiente lista

Para cambiar la Escala temporal de la gráfica de Gantt, seleccione del menú Formato|Escala Temporal ... En la caja de dialogo correspondiente actualice la escala Mayor y Menor de la siguiente forma:

Deberá modificar:

1. La escala mayor a trimestres 2. La escala menor a semanas



93


• La grafica de Gantt deberá verse de la siguiente forma:

Para cambiar la apariencia de la grafica seleccione del menú Formato|Asistente para diagramas de Gantt...para desplegar tareas criticas, por ejemplo, en el paso 2, seleccione Ruta Critica y haga clic en siguiente. En el paso 9, seleccione Fecha, y pase a siguiente. Selecciones siguiente en los pasos restantes, hasta Dar Formato. Seleccione Salir del asistente. La grafica resultante se verá así:

Las barras rojas indican que estas tareas son criticas: deben completarse en las fechas especificas o todo el proyecto se retrasará. En ocasiones Project NO marca la ruta critica por lo que debe inspeccionarse todo el proyecto visualmente. La relación por omisión entre una tarea predecesor y una sucesor es la siguiente: Cuando el predecesor Finaliza el sucesor Comienza (FC). Esto no siempre es lo que se requiere. Por ejemplo, 5 días después de que el predecesor Comience, se desea que Comience el sucesor (CC, con 5 días de diferencia).



94


Para cambiar la relación entre 2 tareas ligadas, haga doble clic en la tarea

sucesora. En Información de la tarea, seleccione la pestaña Predecesoras. Haga clic en el renglón tipo y seleccione de la lista mostrada la relación deseada. En la columna Pos escriba la cantidad de días.

• Actualice la tarea T7 para que Comience 5 días después de que inicie la tarea T6. Note que la duración de todo el proyecto se reduce.

Una vez que la agenda inicial se determina, podrá grabarse como Plan de Base, los ajustes futuros a la agenda podrán compararse con esta línea. Para realizar esto seleccione Herramientas|Seguimiento|Guardar línea de base en la caja resultante podrá seleccionar línea de base o todo el proyecto, haga clic en el botón aceptar.

La vista actual también puede imprimirse (Archivo|vista preliminar) o copiarse y pegarse en un documento de Word: Para copiar la gráfica, seleccione las tareas que desea que se incluyan en la foto a copiar. Haga clic en el botón de la barra de herramientas y en la caja de dialogo resultante podrá seleccionar Pantalla, Impresora o Archivo de imagen GIFF. El archivo de imagen podrá insertarlo en cualquier documento. Para grabar la información del proyecto, Utilice Archivo|Grabar como para la primera vez, y Archvo|grabar en las siguientes. Para salir de la aplicación, utilice Archivo|Salir.


95

Seguimiento de proyectos

Para dar seguimiento a proyectos, debe distinguirse entre lo planeado, lo actual y la información de la agenda disponible de las tareas. Las fechas de tareas planificadas (comienzo, fin, duración) son aquellas que se asignan en la agenda inicial. A medida que el proyecto progresa, las fechas cambian; pueden o no ser distintas de las planeadas. En respuesta a circunstancias cambiantes, el proyecto deberá re-agendarse. Esta nueva información cambiará las fechas actuales. Los 3 tipos de información diferente pueden seguirse en project. Dado que es posible “simular” el seguimiento de una sesión futura, el primer paso consiste en modificar la fecha actual del proyecto. Seleccione del menú el elemento Proyecto|Información del proyecto....

• Actualice la Fecha de hoy: (para este ejercicio 01/04/03) A continuación, deberá completar la información de las tareas que se encuentra concluidas hasta el momento o el porcentaje de avance actual. Seleccione Herramientas|Seguimiento|Actualizar tareas... en la caja de dialogo en % completado escriba el avance de cada tarea.

• T1 finalizó el 17, T2 y T5 estarán concluidas en 100% y T4 estará al 60%. Asigne los valores correspondientes.

• Aparecerá una barra en cada tarea mostrando el avance específico. Si el proyecto está en agenda (en tiempo), todas las tareas deberán estar concluidas antes de la fecha de hoy (simulada). Si la barra de concluida no cruza toda la tarea, significa que existe un problema como en T4 donde el avance se encuentra por debajo de la fecha actual



96

Para ajustar la agenda (suponiendo que no tenemos más gente para trabajar en

el proyecto): Incremente el tiempo especificado para la tarea para que el avance del 60% sea representativo de los días que aún faltan para concluirla. Haga clic en la tarea T4, y seleccione Herramientas|Seguimiento|Actualizar tareas... En la ventana resultante incremente la duración restante: 10 y presione aceptar. La barra de la tarea se hará grande pero la barra de avance permanecerá antes que la línea que marca la fecha actual. Seleccione nuevamente Herramientas|Seguimiento|Actualizar tareas... y actualice % completado al 60%. La gráfica deberá verse aproximadamente así:

Se puede seleccionar una vista de la gráfica distinta para verificar los cambios del proyecto. Seleccione Ver|Más vistas... en la ventana resultante seleccione Gantt de seguimiento y la opción de aplicar. Cambie la Escala temporal (en la forma en que lo realizó previamente, la mayor y la menor a trimestres y semanas)

Las barras grises representan la agenda base, que ahora pueden compararse con las barras actuales.


97

Capitulo 2

2.1 Recursos 2.2 Asignaciones 2.3 Costos


98

2.1 Recursos Una vez que se ha determinado que se requieren recursos en el proyecto

deben plantearse las siguientes preguntas:

• ¿Qué tipo de recursos se requieren? • ¿Cuántos de estos recursos se necesitan? • ¿Dónde obtengo los recursos? • ¿Cómo puedo determinar cuánto costará el proyecto?

MS Project clasifica los recursos en dos tipos: trabajo (work) y materiales (material). Los recursos de trabajo completan tareas invirtiendo tiempo en ellas (personas y gente). Los recursos materiales son provisiones y valores requeridos para completar el proyecto. Cuando un conjunto de recursos está disponible para trabajar con ellos se crea un banco de recursos (pool) . Después de determinar el conjunto de recursos disponibles se deberá establecer el tiempo y la disponibilidad de cada recurso. En el caso de los recursos de trabajo, la cantidad de tiempo que cada uno de ellos puede trabajar, especificada en horas, días, meses o años y la cantidad (unidades de medida) de cada recurso. El siguiente paso es asignar estos recursos a sus respectivas tareas (denominada asignación) . Una vez concluido este paso Project recalcula la agenda para acomodar los tiempos de trabajo de los recursos asignados. Pueden identificarse vacaciones y días no laborables y indicarse para cada recurso. Esto permite identificar cuando se tiene sobrecarga en un recurso. (asignación de un mismo recurso a diferentes tareas en los mismos periodos de tiempo o cuando a un recurso se le asigna más trabaja del que puede completar en cierto tiempo.



99

Agregar información de recursos al proyecto

Se emplea la ventana de gráfica de asignación de recursos:

Crear un banco de recursos 1. Haga clic en el botón de asignar recursos o seleccione del menú

Herramientas|Recursos|Asignar recursos ... Alt+F10 2. Seleccione una celda y en la columna Nombre escriba el responsable.

Presione “Enter”. 3. Repita el paso 2 hasta que haya concluido con la lista de nombres de

recursos. 4. Seleccione asignar.

Los nombres de recursos no pueden contener ( / ), ( [ ] ) ni ( , )

Otra manera de especificar una lista de recurso es a través de la hoja de vista

de recursos

1. Seleccione la hoja de recursos 2. Capture la información

La columna de capacidad máxima contiene la capacidad máxima disponible de cada recurso que acompaña a una Tarea en un periodo especifico. El formato por omisión está dado en porcentajes. Por ejemplo si las unidades de asignación están al 100% esto implica que el recurso trabajará 8 horas al día. Si la unidad de asignación esta al 50% el recurso trabajará 4 horas por día. En caso de que el banco de recursos consiste de 5 trabajadores, sus unidades máximas serán 500% o en valor decimal 5. El formato por omisión puede cambiarse a decimales empleando Herramientas|Opciones|Programación (pestaña) |Mostrar las unidades de asignación como: decimal.


100

Ventana de información de recursos

Haciendo doble clic sobre el nombre de un recurso podrá desplegar la ventana de información, provee datos Generales adicionales como su disponibilidad, las unidades máximas, el equipo de trabajo, tipo de recurso.

Asignación de calendario base distinto al que proporciona project

Acceda a la ventana de información del recurso, seleccione la pestaña de horario de trabajo para realizar los cambio deseados.

Edición del calendario de recursos

Seleccione Herramientas|Cambiar calendario laboral ... seleccione el recurso y el calendario del recurso a editar.

2.2 Asignación Asignación de un recurso a una tarea

1. Abra la vista de la gráfica de Gantt y posicionado en la tarea a la que desea asignar el recurso

2. Escriba Alt + F10 3. Seleccione el recurso deseado 4. Seleccione asignar

El trabajo es la cantidad de tiempo o esfuerzo que un recurso de trabajo invierte en una tarea, ejem. 16 horas en T2, 5 horas en T3, etc. La duración es la cantidad de tiempo entre el inicio y el fin de una tarea. Así que, Trabajo = Duración * Unidades ( T = D * U ) Para una tarea especifica Tx, si su duración fuera de 5 días y se le asignan 3 recursos que trabajan en 100% unidades. Considerando que las horas normales de trabajo son 8, cada uno de estos recursos trabajará 8 horas en 5 días. En caso de que se tomen las unidades al 50%, entonces cada uno trabajara 4 horas al día. Esto traerá por resultado que el trabajo se concluirá antes de los 5 días estipulados y la cantidad de tiempo esperado para los 3 recursos decrecerá. En este caso Project deberá recalcular la agenda.



101

Asignación de un recurso a una tarea (continúa)

Dado que puede elegirse entre duración, trabajo y unidades, Project siempre modificará la duración del proyecto. Puede tenerse un mayor control empleando los Tipos de Tareas que se verán a continuación.

Tipos de Tareas Project define 3 tipos de tareas que pueden ayudar a recalcular variables

cuando se le asignan a un proyecto:

1. Unidades Fijas 2. Trabajo Fijo 3. Duración Fija

La definición de cada tarea está basada en una variable que se convierte en constante. Para las tareas de tipo Unidades Fijas, Project recalcula el trabajo o la duración cuando sea necesario, pero las unidades de trabajo permanecerán fijas. De manera similar cuando las tareas son con duración fija, si cambian las unidades, el trabajo deberá modificarse en consecuencia. El encargado del proyecto deberá analizar cada tarea y seleccionar un tipo. El valor por omisión de las tareas es Unidades Fijas.

Para modificar el tipo de tarea

1. Herramientas|Opciones| 2. Seleccionar la pestaña de Programación 3. Cambiar Tipo de tarea predeterminada.

Aún cuando la se modifiquen los valores predeterminados de una tarea. Su duración es totalmente dependiente de los recursos que se le asignen. Si se modifica la cantidad de recursos después de su asignación inicial, Project recalcula la duración pero deja el trabajo solo. Se puede seleccionar Herramientas|Opciones|Programación (pestaña) y desactivar la caja en la opción “Las tareas nuevas están condicionas por el esfuerzo”.


102

Asignación de recursos de trabajo a tareas

La Forma de Tareas puede desplegar la información detallada de la asignación de recursos como Unidades y Trabajo. Para desplegar la Forma de Tareas en la gráfica de Gantt.

1. Seleccione en las Vistas el Diagrama de Gantt 2. Seleccione el elemento del menú Ventana|Dividir. La Forma de la

Tarea se despliega de manera automática en la parte inferior. 3. Haciendo clic con el botón derecho se desplegará el menú de teclas

rápidas

Asignar recursos de trabajo desde la Forma de Tareas

1. Seleccione la tarea en la vista de la gráfica de Gantt 2. En la Forma de Tareas, seleccione un recurso desde la lista de

nombres de recursos. 3. En las columnas de Unidades y Trabajo seleccione las cantidades

empleando las flechas. 4. Repita los pasos 2 al 3 hasta que todos los recursos hayan sido

asignados a todas las tareas. También pueden asignarse empleando la ventana de Asignación de Recursos en la forma en que se describió previamente.


103

Asignación de recursos materiales a tareas

Cuando se asignan recursos materiales, se debe especificar la forma en que estos se consumen. Al seleccionar “Consumo de material variable” cambia la duración de la tarea (consumo de material variable no la cambia).

Asignación de recursos materiales a tareas en la Gráfica de Gantt

1. Seleccione la tarea en la gráfica de Gantt 2. Seleccione el campo del nombre del recurso en la Forma de Tareas 3. Seleccione el Recurso de la lista que aparece 4. Seleccione el campo unidad y las unidades deseadas. Si se deja en

blanco Project lo asigna a 1 por omisión. 5. Project abrirá la etiqueta de material para entrada decimal 6. Entradas en el campo de trabajo: Para valores de consumo fijo, el

valor en el campo trabajo y en el campo unidades deberá ser el mismo, para consumo variables, el valor en el campo Trabajo deberá ser el valor del campo Unidades multiplicado por la duración de la tarea.

7. Después de asignar todos los recursos a las tareas, presione clic.

Si intenta eliminar una asignación a una Tarea, seleccione la tarea, después el nombre del recurso a eleiminar y presione la tecla Supr.

2.3 Costos Definición y control de costos

Project multiplica el número de horas de un recurso y el valor de costo por hora para definir el costo total. Si se tienen múltiples recursos sus costos se suman. El número de unidades utilizadas refleja el costo de materiales.

Método acumulativo

El método acumulativo describe la forma en la se calculan los costos. Algunas veces, se desea pagar un recurso totalmente antes de comenzar el trabajo, en este caso el método acumulativo adoptado es “Comienzo”. Cuando los pagos se hacen solo después de Finalizada la tarea el método empleado es “Fin”, para tareas parcialmente completadas, los costos estimados se Prorratean. Por ejemplo, si el trabajo se encuentra realizado al 20% el costo hasta el momento deberá estimarse en ese porcentaje.


104

Agregar información de costos

En la tabla de recursos podrá introducir hasta 5 diferentes valores de costos por cada recurso que se tenga. (Tasa horas extras, hora estándar, costo/uso, etc.) –pestañas A, B, C, etc.

Asignar costos a un recurso 1. Abra la hoja de información de recursos

2. Abra la ventana de información de recursos (doble clic sobre él) 3. Seleccione la pestaña Costos. 4. La fecha efectiva del costo será la misma que la fecha de inicio del

proyecto. En caso contrario podrá especificar una fecha distinta. 5. Introduzca la tasa estándar . Para recursos de trabajo el valor por

omisión está dado $ / h, (costo por hora) pero el tipo puede darse en /a, /m en caso de ser necesario. Para recursos materiales emplee la pestaña para especificar (galones o cajas).

6. Para tasa horas extras se aplican los mismos criterios que el punto 3. 7. Introduzca cualquier costo adicional en Costo/uso como envíos o

cualquier otro. 8. Si sabe que los costos cambiarán en el transcurso del proyecto podrá

emplear otra pestaña para actualizar los costos. (B, C, D, o E modificando la fecha efectiva).

9. Si los recursos tienen métodos acumulativos distintos, seleccione la opción de la lista de Acumulación de costos.

Se permiten costos Fijos y Variables. Los Fijos no cambiarán durante la vida de un proyecto. Para Costos Fijos seleccione del menú Ver|Tabla: Resumen|Costo seleccione la columna Costo Fijo para un recurso e introduzca su valor. Para Costos Variables:

1. Del menú Formato|Detalles|Costos de recursos 2. Seleccione la tarea y cambié su Tipo de Tarea a duración fija. 3. Introduzca el nombre del Recurso y escriba % en el campo Unidad. 4. Presione Aceptar 5. Introduzca los valores en el campo Costo. 6. Presione Aceptar.


105

PRÁCTICA No. 2

1. Genere un banco de 10 recursos R1, R2, etc. 2. Cambie la capacidad máxima a unidades de asignación a DECIMAL. 3. Asigne los recursos a las tareas de la siguiente manera:

Tarea Recurso T1 T2 T3 T4 T5 T6 T7

R1, R2 R4 R3 R5,R6 R5,R9 R7,R8 R10

4. Modifique el tipo de tareas desactivando la opción de que “las tareas estén condicionadas por el esfuerzo”

5. Asigne las siguientes unidades y trabajo a cada recurso:

Recurso Unidad Trabajo R1 R2 R3 R4 R5 R6 R7 R8 R9 R10

5 2 1 4 1 2 2 1 1 1

8h 8h 8h 8h 4h 8h 8h 8h 8h 4h

6. Asigne Costos prorrateados a cada recurso, excepto a R6 y R7 para el

primero Comienzo y para el segundo Fin. (los valores de los costos defínalos usted).


106

Capitulo 3

3.1 Formato de vistas 3.2 Publicación de Proyectos en la Web o Intranet 3.3 Hipervínculo


107

3.1 Formato de Vistas

Existen una docena de vistas predeterminadas en Project, pueden modificarse en tamaño o adecuarse a todas las necesidades. Se pueden seleccionar las escalas y el texto para darles un mejor formato, se pueden realizar acercamientos, etc.

Formato en Texto

Se puede emplear la barra de botones para dar formato o emplear el elemento del menú Formato.

1. Seleccione la celda a la que se le dará formato 2. Seleccione Formato|Fuente 3. Seleccione un nuevo tipo de letra, cambie el estilo, el tamaño o el

color Formato de escalas temporales

El área de escala temporal en una gráfica de Gantt permite el despliegue en dos niveles de unidades de tiempo:

• Escala Primaria • Escala Secundaria

Para modificar el área de la escala temporal:

1. Empleando la vista de la gráfica de Gantt, seleccione Formato|Escala temporal ...

2. En la ventana podrá seleccionar los valores de las escalas deseadas

3. Cada conjunto de unidades tiene una etiqueta y una forma para alineación. Seleccione los valores deseados y presione aceptar.

Formato de líneas guía

Cuando la información se despliega mediante líneas y columnas, el uso de líneas guías apropiado es importante para obtener una vista adecuada. Seleccione Formato|Cuadrícula... para abrir la ventana de líneas guía.

1. Seleccione la línea que se desea cambiar de la lista. 2. En la sección Normal seleccione el tipo y patrón de la línea. 3. Para emplear una línea existente selecciónelo de la lista. 4. Seleccione el Intervalo, Tipo y Color. 5. En el sección de Intervalo, seleccione ninguno para desplegar todas

las líneas (o intervalo para algunas en especifico). 6. Presione aceptar.

Siguiendo este mismo método se puede dar formato a Tablas, Campos y Otras vistas.



108

Impresión de vistas

Antes de imprimir una vista, es importante seleccionar el tipo de vista, modificar los formatos necesarios y cambiar orientaciones de páginas. Para modificar los parámetros de impresión de una vista activa, de una página o un archivo, deberá desplegar la ventana de dialogo correspondiente. Para imprimir una gráfica de Gantt

1. Puede elegir imprimir todas las columnas de una hoja de la gráfica de Gantt que quepan en una página o especificar un número de columnas en varias páginas.

2. Se pueden imprimir las notas de las tareas en una página separada 3. Modifique la escala temporal para extender todo el margen derecho.

Impresión de reportes

Pueden imprimirse todos los reportes acerca de los distintos aspectos que controla project: Tareas criticas, Hitos, Días trabajados, Costos, Asignaciones, etc.

1. Seleccione Ver|Informes... y aparecerá la siguiente pantalla:

2. Haga doble clic en un reporte y project abrirá la ventana de impresión preliminar.

3. Presione Imprimir.

3.1 Publicación de proyectos en WEB o Intranet

Al igual que en la gran mayoría de aplicaciones de Office, project permite grabar un proyecto como HTML que puede revisarse en un Browser o navegador. Lo que puede hacerse con project es lo siguiente:

• Usar un hipervínculo • Seleccionar una tarea específica, recurso y asignación empleando un

mapa para Importar/exportar y publicarlo en un documento HTML. • Ajustar el documento de HTML para incluir gráficos. • Dar seguimiento al proyecto mediante la comunicación con el equipo

vía la Intranet corporativa.


109

Para guardar un proyecto como documento HTML: 1. Seleccione del menú, Archivo|Guardar como HTML... 2. Haga clic en el botón Guardar 3. Aparecerá la ventana que contiene el formato de exportación.

Este formato permite seleccionar el mapa que será la base del documento. Este mapa de instrucciones especifica el tipo de información que se almacena en el documento. Project cuenta con 12 mapas predefinidos, pero almacena el documento con la extensión . html por omisión.

4. Desde la opción Datos seleccionados marque Lista de tareas con filas de asignación incrustadas y haga clic en el botón de guardar.

Para ver el documento ábralo en cualquier browser.



110

Además de los 12 mapas definidos por project para crear uno propio y

exportarlo, haga lo siguiente:

1. Siga los pasos de 1-3 de la explicación anterior 2. Asignándole el nombre al documento de TareasCriticas . 3. Seleccione el botón Nueva Equivalencia 4. En la ventana de Definir equivalencia de campos de importación

exportación, en la pestaña Opciones seleccione tareas 5. Seleccione la pestaña equivalencia de tareas.

6. En el titulo de la tabla HTML de destino seleccione un nombre deseado (en este caso Tareas_Criticas)

7. En la lista de Filtro de Exportación, seleccione Tareas Criticas. 8. Haga clic en el botón A partir de la tabla...



111

9. Seleccione programación de la lista presentada y presione Aceptar para agregar todos los campos.

10. Presione el botón Guardar y podrá ver el documento en cualquier Browser.

Desplegar la gráfica de Gantt en una página Web

1. Seleccione la vista de la gráfica de Gantt en la barra estándar, haga clic en el botón de copiar la imagen.

2. Seleccione el formato GIF. 3. En la sección de escala temporal, seleccione los rangos de fechas o la

opción “Como aparece en pantalla” para capturar la escala actual. 4. Presione Aceptar 5. En el menú Archivo, grabe el documento como HTML, seleccione el

nombre y ubicación. 6. En la ventana para exportar seleccione el archivo de mapa a modificar

y haga clic en Editar. 7. En la pestaña de Opciones, seleccione la opción de “Incluir archivo de

imagen en la página HTML”. 8. Agregue la trayectoria 9. Grabe el documento


112

3.3 Hipervínculo

Los campos de hipervínculos permiten navegar hacia otro documento o sitio Web desde su proyecto. Se pueden agregar hipervínculos a tareas, recursos o asignarlas en cualquier vista.

Para agregar un hipervínculo

1. Abra una vista 2. Seleccione la tarea, recurso o asignación a la que se desea agregar un

vínculo, del menú en Insertar|Hipervículo... abra la ventana

3. Introduzca un sitio Web mediante el URL o un archivo desde Word o Excel en el tipo de archivo.

4. Presione Aceptar. 5. Una marca en el área de información permitirá acceder al documento

directamente desde el proyecto


113

Anexo B: Prácticas Rational Rose


114

Guía de Prácticas Diagramas de UML en Rational Rose

Actividad 1

a) Con el botón derecho del ratón y estando en el navegador sobre el paquete de la Vista de Casos de Uso, haga new-package y cree un paquete que se llame Actividad 1.

b) Estando sobre el paquete recién creado haga click con el botón derecho y cree dos nuevos

paquetes que se llaman Ventanas y Editor, estos se crearán como paquetes dentro del paquete Actividad 1.

c) Repita la operación anterior y cree los subpaquetes Motif y MSWindows como subpaquetes

de Ventanas y Controlador, Dominio, Elementos, Núcleo Motif, Núcleo Windows como subpaquetes de Editor.

d) Sobre el paquete Actividad 1 realice new-Use Case Diagram, creando el diagrama

Actividad 1. Haga doble click en el icono del diagrama e introduzca el diagrama mostrado en la Figura 1.1. Para ello arrastre desde el navegador los paquetes involucrados.

e) Repita el paso anterior para los paquetes Ventanas y Editor obteniendo los diagramas

mostrados en las Figuras 1.2 y 1.3, respectivamente. En cada oportunidad arrastre desde el navegador los paquetes indicados. Consejo: Cuando quiera asociar un nuevo diagrama a un paquete basta con hacer doble clic sobre él y luego renombrar el diagrama obtenido (por defecto se denomina Main). Consejo: Utilice los botones para ir al diagrama padre o al diagrama anterior, respectivamente.

Edit or Ventanas

Figura 1.1: Diagrama Actividad 1


115

MSWindows

Motif

Figura 1.2: Diagrama Ventanas

Contro lador

Dom inio

Elem entos

Núcleo M oti f

Núcleo Windows

MSWindow

(from Ventanas)

M oti f

(from Ventanas)

Figura 1.3 Diagrama Editor


116

Actividad 2

a) Estando en el navegador sobre el paquete de la Vista de Casos de Uso, con el botón derecho del ratón haga new-package y cree un paquete que se llame Actividad 2.

b) Con el botón derecho del ratón y estando en el navegador sobre el paquete recién creado haga

new-Use Case Diagram y cree un diagrama que se llame Actividad 2. c) Dibuje en el diagrama Actividad 2 lo mostrado en la figura 2.1.

Verificar Operación

Reintegro Cuenta Corriente

Cliente

Reintegro Cuenta de Crédito

<<include>>

<<include>>


Observaciones: Los estereotipos se introducen en la especificación del símbolo de generalización

(hacer doble clic sobre el símbolo para abrir su especificación) La opción Navigable establece la dirección en una asociación (puede habilitarse o

deshabilitarse con el botón derecho sobre el símbolo)


117

Actividad 3

a) Estando en el navegador sobre el paquete de la Vista de Casos de Uso, con el botón derecho del ratón haga new-package y cree un paquete que se llame Actividad 3.

b) En el paquete recién haga new-Use Case Diagram y cree un diagrama que se llame

Actividad 3. Dibuje en el diagrama Actividad 3 lo mostrado en la figura 3.1.


Observación: Puede arrastrar el actor Cliente desde el paquete Actividad 2.

c) Con el botón derecho del ratón y estando en el navegador sobre el Caso de Uso Reintegro

haga new-Sequence Diagram y cree un diagrama que se llame Reintegro Saldo Insuficiente.

d) Haga doble clic en el diagrama Reintegro Saldo Insuficiente y dibuje el diagrama mostrado

en la Figura 3.2

: Cliente :Cajero automático

:cuenta

tarjeta

solicitar número secreto

número

solicitar cantidad

realizar transacción(cantidad)

saldo insuficiente

saldo insuficiente

cantidad

Figura 3.2: Diagrama Reintegro Saldo Insuficiente

Cliente Reintegro


118

d) Haga Browse-Create Collaboration Diagram para obtener automáticamente el Diagrama

de Colaboración asociado.


119

Actividad 4

a) Crear el paquete Actividad 4 en la Vista Lógica. b) Dentro de este paquete crear las clases: avión, motor, avión militar, avión comercial,

vuelo, piloto, reserva, línea aérea, avión de carga, avión de pasajeros, vendedor de billetes.

c) Cree dentro de la Actividad 4 el Diagrama de Clases Actividad 4, mostrado de la Figura

4.1.

Avión militar Avión comercial

Avión de carga Avión de pasajeros

Motor Vendedor de billetes

Avión

1..4

1

1..4

1

Piloto

Reserva

n

1

n

1

Línea aérea

Vuelon1 n1

1..2

n

1..2

nn1 n1

1

n

1

n{ disjunta, completa }

{ disjunta, completa }



120

Actividad 5

a) En la Vista Lógica cree el paquete Actividad 5. Dentro de este paquete cree un Diagrama

de Clases que se llame Actividad 5. b) Incluya una única clase dentro de este diagrama que se llame Alumno y complete según

lo mostrado en la Figura 5.1.

AlumnoDNI : char[10]número_exp : intnombre : char[50]

alta()poner_nota(asignatura : char *, año : int, nota : float)matricular(cursos : asignatura, año : int)listar_expediente()


Observación: Pregunte al profesor si no consigue onbtener la presentación mostrada en la Figura 5.1.


121

Actividad 6

a) En la Vista Lógica cree un paquete denominado Actividad 6. b) Asociado al paquete Actividad 6 cree el Diagrama de Clases Actividad 6 e inserte las

clases Departamento y Profesor y asócielas tal como se muestra en la Figura 6.1.

c) Modifique la visibilidad de los roles eligiendo entre Público (+): el rol es visible fuera del ámbito del paquete y puede referenciarse en otras partes del modelo; Implementación (sin símbolo asociado): visible sólo en el paquete en el que se define; Protected (#): accesible a la clase misma, a las subclases o friends; Private (-): accesible solo a la propia clase o friends.

ProfesorDepartamento

10..1director

1dirige0..1

0..*área_conocimiento : char *

1 profesores0..*

depto1

área_conocimiento : char *



122

Actividad 7

a) Cree el paquete Actividad 7 y dentro de él introduzca el diagrama de clases Actividad 7 con las clases Empresa, Empleado y Cargo. Defina en la clase Cargo los atributos Nombre y Sueldo.

b) Establezca la asociación entre Empresa y Empledo, mostrada en la figura 7.1.

Empresa Empleado

1..** 1..**

trabajadoresempleador

Cargonombresueldo 0..1

1..*

superior

subordinado 1..*

0..1


Observación: Use el símbolo de la barra de herramientas denominado “Link Attribute” para enlazar la clase Cargo con la asociación entre Empresa y Empleado.


123

Actividad 8

a) Cree el paquete Actividad 8. b) Cree en el navegador las clases: Trabajador, Directivo, Administrativo, Obrero,

Vehículo, Vehículo impulsado por viento, Vehículo Terrestre, Vehículo impulsado por motor, Vehículo acuático, Camión, Velero, Cuenta, Cuenta rentable y Cuenta no rentable.

c) Cree el Diagrama de Clases llamado Actividad 8.1 según se muestra en la Figura 8.1.

d) Repita la operación para las Figuras 8.2 y 8.3.

Trabajador

Directivo Administrativo Obrero

{ disjunta, completa }

Figura 8.1: Diagrama Actividad 8.1

Vehículo

Vehículo impulsado por viento Vehículo impulsado por motor

VehículoTerrestreVehículo acuático

Velero

Camión

impulsado por

medio


124


Cuenta

Cuenta rentable Cuenta no rentable

{ dis junta, incompleta }

saldo_medio > 1000 saldo_medio < 500

saldo



125

Actividad 9

a) Cree el paquete Actividad 9. b) Cree en este paquete la clase Socio en un Diagrama de Clases que se llame Actividad 9.

La Figura 9.1 da el detalle de la estructura de la clase.

c) Asocie a la clase anterior el Diagrama de Transición de Estados de la Figura 9.2. Para ello, desde el navegador seleccionando la clase en cuestión y con el botón derecho del ratón escoja la opción Open State Diagram.

Socionúmero : intnombre : char[50]número_prestamos : int = 0

alta()baja()prestar(código_libro : int, fecha : date)devolver(código_libro : int, fecha : date)


con préstamos

sin préstamos

prestar devolver[ número_prés tamos = 1 ]

pres tar

devolver[ número_préstamos > 1 ]

alta baja

número_préstamos = 0

número_préstamos > 0

Figura 9.2: Diagrama de Estados


126

Actividad 10

a) Cree en la Vista de Componentes un paquete que se llame Actividad 10 y dibuje el

diagrama que se muestra en la Figura 10.1. Una relación de dependencia entre componentes viene dado porque un componente usa las facilidades de otro. Esto se reduce a dependencias de compilación entre componentes. Consulte en el Help los estereotipos para los componentes.

b) Dibuje el Diagrama de Despliegue de la Figura 10.2. Una Connection representa p.e. un

cable RS232, comunicación vía satélite, etc. Un Processor representa hardware con capacidad de computación. Un Device incluye dispositivos hardware como terminales, modems, etc.

Interfaz de Terminal Control y

Análisis

Gest ión de Cuentas

Rut inas de Conexión

Acceso a DB

Figura 10.1


127

Punto de Venta

Servidor Central Gestor de Datos

Terminal de Venta

Figura 10.2


128

Actividad 11

a) Cree un nuevo modelo y renombre el diagrama Main de la Vista de Casos de Uso por ACME.

b) Haga doble click sobre el icono del diagrama ACME y dibujando, introduzca los

subpaquetes Publicidad, Ventas, Inventario y Contabilidad. El resultado se muestra en la Figura 11.1

Publicidad Ventas

Inventario Contabilidad

Figura 11.1: Diagrama ACME

c) Haga doble click sobre el paquete Ventas en el Diagrama ACME e introduzca el diagrama

de casos de uso mostrado en la Figura 11.2. d) Con el botón derecho sobre el diagrama llamado Main bajo el paquete Ventas renómbrelo

por Ventas. e) Asociado al paquete Realizar Venta crear un diagrama de casos de uso llamado Realizar

Venta. Hacer doble click sobre el icono que representa el paquete Realizar Venta e introduzca el diagrama mostrado en la Figura 11.3.

f) Renombre como Realizar Venta el diagrama Main bajo el paquete Realizar Venta. El

resultado hasta este punto puede verse en la Figura 11.4.


129

Supervisor Verificar Situación del Cliente

Administrativo Sistema Inventario

Preparar Catálogo

Realizar Venta

Figura 11.2: Diagrama Ventas

Venta Normal

Venta de RebajaVendedor

Venta de Oferta

Figura 11.3: Diagrama Realizar Venta

En los D. de Casos de Uso no existe el concepto de “explosión” tal como se tiene en los DFDs (Diagramas de Flujo de Datos). La funcionalidad representada por un caso de uso es “atómica” (aunque en Rational Rose 98 a un caso de uso se le puede asociar un nuevo D. de Casos de Uso!!). En UML el concepto de paquete permite organizar de manera jerárquica un modelo, y en este caso, un paquete puede tener asociado un nuevo diagrama.


130

Figura 11.4: Estado de la Práctica al terminar el paso f)

g) Documente los casos de uso Venta Normal, Venta Rebajas, Venta Ofertas a partir de la

información siguiente, presentada en tres estilos distintos (“secuencia de pasos”, “condiciones pre-post de la aplicación del caso de uso” y, por último “descripción narrativa”).

Venta Normal Cree un fichero word con el siguiente contenido: Caso de Uso Venta Normal

1. El cliente se identifica mostrando su tarjeta y el DNI 2. El vendedor revisa los datos del cliente 3. El vendedor introduce su código de vendedor e indica al sistema que se trata de una

venta normal 4. El sistema muestra la pantalla para introducir los datos de la venta 5. El vendedor introduce los artículos mediante un lector de código de barras o

directamente por teclado. Pueden ser varios artículos en una misma venta. 6. El vendedor solicita la emisión del recibo 7. El sistema imprime el recibo

Haga doble click sobre el caso de uso Venta Normal del diagrama y en la pestaña Files con el botón derecho realice Insert File, asociando el fichero word recién creado.


131

Venta en Oferta Haciendo doble click en el caso de uso Venta en Oferta y dentro del cuadro denominado documentación, introducir:

Precondiciones - Los artículos de la venta deben estar en oferta - El pago debe hacerse en efectivo - El artículo debe tener el suficiente stock para satisfacer la venta Postcondiciones - El stock del artículo se decrementa con la venta realizada - Se registran todos sus datos en la base de datos

Venta en Rebajas Seleccionando el caso de uso Venta en Rebajas, introducir en el cuadro de documentación (bajo el browser) el siguiente texto: En el periodo de rebajas los precios tienen una disminución de precio tanto de forma individual como por grupos de artículos. Los descuentos se detallan en la correspondiente tabla de descuentos por grupo.


132

Actividad 12

a) Cree un nuevo modelo y renombre el diagrama Main de la Vista de Casos de Uso por Video Club.

b) Introduzca en el Diagrama Video Club el modelo de la figura 12.1.

Encargado Prestar Video

Figura 12.1: Diagrama Video Club

c) Cree un Diagrama de Secuencia asociado al Caso de Uso Prestar Video y denomínelo

Prestar con Éxito. Arrastre desde el navegador el actor Encargado y complete el Diagrama de Secuencia según lo mostrado en la Figura 12.2. Los objetos utilizados en este diagrama son anónimos, es decir, sólo se indica la clase a la cual pertenecen, pero no se les asigna un nombre específico.

d) Deshabilite la opción Focus of Control en Tools-Options-Diagrams y observe el efecto. e) Cree el Diagrama de Colaboración asociado al Diagrama de Secuencia dibujado mediante

Browse-Create Collaboration Diagram. La Figura 12.3 muestra el diagrama de colaboración que se debe obtener.

: Encargado :WInPréstamos :Socio :Video :Préstamo

prestar(video, socio)

verificar situación socio

verificar situación video

registrar préstamo

entregar recibo


133

Figura 12.2: Diagrama Prestar con Éxito

: Encargado

:WInPréstamos

:Socio

:Video

:Préstamo

1: prestar(video, socio)

2: verificar situación socio

3: verificar situación video

4: registrar préstamo5: entregar recibo

Figura 12.3: Diagrama Obtenido a partir del Diagrama Prestar con Éxito

Documents

Tabla de Contenido - ozarate.net · Universidad Tecnológica de Jalisco Manual de Análisis y diseño I 2 Vistas y diagramas en UML