Manual Ads1 PDF

Tabla de Contenido
1 Introduccin ........................................................................................................................ 1 2 Introduccin a los sistemas de informacin............................................................................. 2 e ingeniera de SW ...................................................................................................................... 2 Sistema.................................................................................................................................... 2 Tipos comunes de sistemas..................................................................................................... 2 Tipos comunes de sistemas, Continuacin ............................................................................. 3 Conceptos de anlisis y diseo de sistemas ............................................................................ 4 Ingeniera de SW..................................................................................................................... 6 Capas de la ingeniera de software.......................................................................................... 7 Fases genricas de la Ingeniera de SW.................................................................................. 7 Fases complementarias ........................................................................................................................ 9 Modelos de procesos de SW ................................................................................................. 10 1. El modelo lineal secuencial .............................................................................................. 10 2. El modelo de construccin de prototipos.......................................................................... 12 3. El modelo DRA................................................................................................................. 13 4. El modelo incremental ...................................................................................................... 14 5. El modelo en espiral.......................................................................................................... 16 Gestin de proyectos............................................................................................................. 18 Requerimientos del software................................................................................................. 20 Requerimientos funcionales y no funcionales ...................................................................... 21 Procesos de Ingeniera de requerimientos........................................................................................ 22 Debe definirse un plan preliminar de actividades................................................................. 23 3. Programacin Orientada a Objetos ....................................................................................... 25 Programacin orientada a objetos......................................................................................... 25 Objeto.................................................................................................................................... 26 Clase...................................................................................................................................... 26 Abstraccin ........................................................................................................................... 26 Herencia ................................................................................................................................ 26 Polimorfismo .......................................................................................................................... 26 Encapsulamiento .......................................................................................................................... 26 Envo de mensajes................................................................................................................. 26 Asociaciones ........................................................................................................................... 26
Ejercicios....................................................................................................................... 28
4. Introduccin 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
Academia de Ingeniera de Software Ana E. Romo Gonzlez
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 cmo encontrarlas............................................................. 40 Diagrama de Clases............................................................................................................... 41 Uso de relaciones entre clases............................................................................................... 42 Asociaciones ........................................................................................................................... 42 Vnculos ................................................................................................................................ 43 Posibles multiplicidades y como representarlas en UML .................................................................... 44 Asociaciones calificadas .......................................................................................................... 46 Asociaciones reflexivas............................................................................................................ 46 Herencia y generalizacin ............................................................................................................ 47 Ventajas de la generalizacin ....................................................................................................... 47 Clases abstractas...................................................................................................................... 51 Dependencias .......................................................................................................................... 52 Agregaciones .......................................................................................................................... 52 Restricciones en las agregaciones ............................................................................................. 52 Ejemplo de agregacin con restriccin O................................................................................... 53 Composicin ........................................................................................................................... 53 Contextos................................................................................................................................ 54 Casos de uso ........................................................................................................................... 57 Secuencia de pasos en los escenarios ........................................................................................ 57 Diagramas de caso de uso en el proceso de anlisis .................................................................... 58 Puntos clave de los casos de uso ............................................................................................... 58 Actores ................................................................................................................................... 59 Relaciones .............................................................................................................................. 59 Comunicacin ........................................................................................................................... 59 Inclusin ................................................................................................................................. 59 Extensin ................................................................................................................................ 59 Herencia ................................................................................................................................. 59 Construccin del caso de uso .................................................................................................... 60 Qu comprende la descripcin del Caso de Uso ......................................................................... 61 Diagramas de interaccin ......................................................................................................... 69 Mensajes ................................................................................................................................. 69 Diagrama de secuencia............................................................................................................. 69 Representacin de un objeto en un diagrama de secuencia.................................................................. 69 Mensaje .................................................................................................................................. 70 Tiempo ................................................................................................................................... 70 Diagrama de colaboracin ........................................................................................................ 74
Universidad Tecnolgica de Jalisco Manual de Anlisis y diseo I
Mensajes ................................................................................................................................. 74
sincronizacin ........................................................................................................................... 74
condiciones ............................................................................................................................. 74 Valores de retorno ................................................................................................................... 74 Diagrama de estados ................................................................................................................ 76 Smbolos 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: Prcticas Rational Rose .......................................................................................... 113
1 Introduccin
Esta primera versin del manual de anlisis y diseo surgi por la necesidad de estructurar un curso que se encuentra colmado de informacin, con la intencin de presentar una metodologa que sirva de gua a los alumnos que toman el curso inicial de la materia. Este curso permite generar las bases para la construccin de programas de complejidad media a mayor. Quiero mencionar que fue de gran ayuda la participacin de los alumnos a quienes les impart de forma inicial el curso, ya que sus comentarios y sugerencias fueron la principal motivacin 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 enseanza aprendizaje que permita alcanzar las metas que de forma general y particular cada uno de nosotros nos hemos propuesto.
2 Introduccin a los sistemas de informacin e ingeniera de SW

Sistema Tipos comunes de sistemas Grupo de elementos interdependientes o que interactan regularmente formando un todo. Dado que nuestro objetivo son los sistemas computacionales, empezaremos por dividir los sistemas en dos categoras: sistemas naturales, y sistemas hechos por el hombre. 1. Sistemas naturales La gran mayora de los sistemas no estn 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 comunicacin etc. 3. Sistemas automatizados Son sistemas hechos por el hombre que interactan con o son controlados por una o ms computadoras Una gran divisin en categoras ms til de los sistemas automatizados es la siguiente: Sistemas en lnea Sistemas de tiempo real Sistemas de apoyo a decisiones Sistemas basados en el conocimiento
Contina en la siguiente pgina
Tipos comunes de sistemas, Continuacin
Sistemas en lnea Un sistema en lnea es aquel que acepta material de entrada directamente del rea donde se cre. Tambin es el sistema en el que el material de salida, o el resultado de la computacin, 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, procesndolos y devolvindolos 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 informacin que se crean son sistemas operacionales que ayudan a llevar a cabo los detalles del trabajo cotidiano de una organizacin. Estos sistemas incluyen ejemplos como el sistema de nomina, de contabilidad, etc. Sistemas basados en el conocimiento La meta de los cientficos de la computacin que trabajan en el campo de la inteligencia artificial es producir programas capaces de imitar el desempeo humano en una gran variedad de tareas inteligentes. Sistemas expertos Son programas de computadora que contienen el conocimiento y la capacidad necesarios para desempearse en un nivel de experto. Manejo de la informacin 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 informacin se ha colocado en un lugar adecuado como recurso principal.
Conceptos de anlisis y diseo de sistemas
Los sistemas de informacin son desarrollados con propsitos diferentes dependiendo de las necesidades del negocio. Sistemas de procesamiento de transacciones (TPS) Son sistemas de informacin computarizada desarrollados para procesar gran cantidad de datos para transacciones rutinarias de los negocios, tales como nmina e inventario. estos sistemas reducen el tiempo que alguna vez se requiri para ejecutarlas manualmente. Sistemas de automatizacin de oficina y sistemas de manejo de conocimiento.
Al nivel de conocimiento de la organizacin hay dos clases de sistemas. Los sistemas de automatizacin de oficina (OAS) que dan soporte a los trabajadores de datos, quienes, por lo general, no crean un nuevo conocimiento sino que usan la informacin para analizarla y transformar datos, o para manejarla en alguna forma y luego compartirla con toda la organizacin y algunas veces ms all de ella. Los aspectos familiares de los OAS incluyen procesamiento de palabras, hojas de calculo, editor de publicaciones, calendarizacin electrnica y comunicacin mediante correo de voz, correo electrnico y videoconferencias Los sistemas de manejo de conocimiento (KWS) dan soporte a los trabajadores profesionales, tales como cientficos que contribuyan a la organizacin o a toda la sociedad. Sistemas de informacin 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 informacin que trabajan debido a la interaccin resuelta entre gentes y computadoras, requiere que las gentes, el software y el hardware trabajen al unsono. Los sistemas de informacin dan soporte a un espectro ms amplio de tareas organizacionales que los sistemas de procesamiento de transacciones. Para poder ligar la informacin, los usuarios de un sistema de informacin gerencial comparten una base de datos comn. La base de datos guarda modelos que ayudan a los usuarios a interpretar y aplicar esos mismos datos.
Conceptos de anlisis y diseo de sistemas, Continuacin
Sistemas de apoyo a decisiones:(DSS) Una clase de ms alto nivel en los sistemas de informacin computarizada son los sistemas de apoyo a decisiones, ste es similar al sistema de informacin gerencial tradicional en que ambos dependen de una base de datos como fuente. Un sistema de apoyo a decisiones se aparta del sistema de informacin gerencial tradicional en que enfatiza el apoyo a la toma de decisiones en todas sus fases, aunque la decisin actual todava es del dominio del tomador de decisiones. Los sistemas de apoyo a decisiones estn ms hechos a la medida de la persona o grupo que los usa que los sistemas de informacin 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 mquinas que se comporten de forma inteligente. Dos caminos de investigacin de la AI son la comprensin del lenguaje natural y el anlisis de la habilidad para razonar un problema y llegar a conclusiones lgicas. Los componentes bsicos de un sistema experto son la base de conocimiento, una mquina 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 solucin. Los sistemas de apoyo a decisiones de grupo permiten que los miembros de un grupo interacten con apoyo electrnico, 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 grficos y comunicaciones en lugares accesibles tales como salas de juntas u oficinas personales corporativas.
Ingeniera de SW Fritz Bauer
Planeacin completa de sistemas. La ingeniera de SW es el establecimiento y uso de principios robustos de la ingeniera a fin de obtener econmicamente software que sea fiable y que funcione eficientemente sobre mquinas reales. La aplicacin de un enfoque sistemtico, disciplinado y cuantificable hacia el desarrollo, operacin y mantenimiento del SW. Brinda herramientas para: la estimacin y planificacin de proyectos y tcnicas para analizar, documentar y disear sistemas. el diseo de entradas, salidas, BD, programas, interfaz. prueba e implantacin de los sistemas. Da pautas para el control de calidad de todo el proceso de ingeniera. Provee tcnicas para la codificacin eficiente de programas. Incluye el mantenimiento de programas Reflejan su comportamiento durante su ejecucin y en la escritura y organizacin del programa fuente y en la documentacin apropiada. Sommerville. Cap. 1. Pg. 13
IEEE
Utilidad de la Ingeniera de SW
Atributos esenciales de un buen SW
Capas de la ingeniera de software
La ingeniera de SW es una tecnologa multicapa
herramientas mtodos proceso Un enfoque de calidad
Proceso
Mantiene juntas las capas de tecnologa. Define un marco de trabajo para un conjunto de reas clave de proceso (ACPs: base del control de gestin de proyectos, establecen el contexto en el que se aplican los mtodos tcnicos, se producen los resultados de trabajo, se asegura la calidad, etc.) Indican cmo construir tcnicamente el SW . Incluye anlisis, diseo, construccin de programas, pruebas y mantenimiento. Proporcionan un soporte automtico o semiautomtico para el proceso y para los mtodos. CASE (ingeniera de software asistida por computadora: computer-aided software engineering). Fase de definicin (se centra sobre el qu) Fase de desarrollo (se centra en el cmo) Fase de mantenimiento (se centra en el cambio) o Correccin o Adaptacin o Mejora o Prevencin (reingeniera del sw)
Mtodos
Herramientas
Fases genricas de la Ingeniera de SW
Fases genricas de la ingeniera de SW, Continuacin
La fase de definicin
se centra en el que. Es decir, durante la definicin, el que desarrolla el software intenta identificar qu informacin ha de ser procesada, que funcin y rendimiento se desea, qu comportamiento del sistema, que interfaces van a ser establecidas, que restricciones de diseo existen y que criterios de validacin se necesitan para definir un sistema correcto. se centra en el cmo. Es decir, durante el desarrollo un ingeniero de software intenta definir cmo han de disearse las estructuras de datos, cmo ha de implementarse la funcin como una arquitectura del software, cmo han de implementarse detalles procedimentales, cmo han de caracterizarse las interfaces, cmo ha de traducirse el diseo en un lenguaje de programacin y cmo ha de desarrollarse la prueba. se centra en el cambio que va asociado a la correccin 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.
La fase de desarrollo
La fase de mantenimiento
Durante el proceso de mantenimiento encuentran cuatro tipos de cambios:
se
Correccin. Incluso llevando a cabo las mejores actividades de garanta de calidad, es muy probable que el cliente descubra defectos en el software. El mantenimiento modifica el software para corregir los defectos. Adaptacin. Con el paso del tiempo, es probable que cambie el entorno original (p.e. CPU, el sistema operativo, las reglas de empresa, las caractersticas externas de productos) para el desarroll del software. El mantenimiento adaptativo produce modificacin 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 ms all de sus requisitos funcionales originales. Prevencin. El software de computadora se deteriora debido al cambio, y por esto al mantenimiento preventivo tambin llamado reingeniera de software, se debe conducir para permitir que el software sirva para las necesidades de los usuarios finales.
Fases complementarias
Seguimiento y control del proyecto Preparacin de SW documentos Revisiones tcnicas formales Garanta de calidad del SW Gestin de configuracin del SW
El proceso del software
produccin
de
Gestin de reutilizacin Mediciones Gestin de riesgos
Se establece un marco comn del proceso definiendo un pequeo nmero de actividades del marco de trabajo que son aplicables a todos los proyectos del software, con independencia de su tamao o complejidad. Un nmero de conjunto de tareas cada una es una coleccin de tareas de trabajo de ingeniera del software, hitos de proyectos, productos de trabajo, y puntos de garanta de calidad permitiendo que las actividades se adapten a las caractersticas del proyecto y a los requisitos del proyecto.
Marco de trabajo comn del proceso

Actividades del marco de trabajo
Conjuntos de tareas
Tareas Hitos, entregas Puntos SQA
Actividades de proteccin
El proceso del software

Modelos de procesos de SW
1. 2. 3. 4. 5. 6. 7. 8.
El modelo lineal secuencial El modelo de construccin de prototipos El modelo DRA El modelo incremental El modelo en espiral El modelo de ensamblaje de componentes El modelo de desarrollo concurrente El modelo de mtodos formales
1. El modelo lineal secuencial
Llamado algunas veces ciclo de vida bsico o modelo en cascada este modelo sugiere el enfoque sistemtico, secuencial del desarrollo del software que comienza en un nivel de sistemas y progresa con el anlisis, diseo, codificacin, pruebas y mantenimiento. El modelo lineal secuencial acompaa a las siguientes actividades:
Ingeniera de sistemas/ informacin Anlisis Diseo Cdigo Prueba

Mantenimiento
Ingeniera y modelado de sistemas/informacin
Como el software siempre forma parte de un sistema ms grande (o empresa), el trabajo comienza estableciendo requisitos de todos los elementos del sistema y asignndole al software algn subgrupo de estos requisitos.
10
Modelo lineal secuencial, Continuacin

Anlisis de los requisitos del software Diseo
El proceso de reunin de requisitos se intensifica y se centra especialmente en el software. 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 diseo se documenta y se hace parte de la configuracin del software. El diseo se debe traducir a una forma legible por la mquina. Una vez que se ha generado un cdigo, comienzan las pruebas del programa. El proceso se centra en los procesos lgicos internos del software, asegurando que todas las sentencias se han comprobado. El software indudablemente sufrir cambios despus de ser entregado al cliente. 1. Los proyectos reales raras veces siguen el modelo secuencial que propone el modelo. 2. A menudo es difcil que el cliente exponga explcitamente todos los requisitos. 3. El cliente debe tener paciencia. Una versin 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.
Generacin de cdigo Pruebas
Mantenimiento
Desventajas del modelo lineal secuencial
11
Modelos de procesos de SW, Continuacin

2. El modelo de construccin 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 construccin de prototipos comienza con la recoleccin 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 ms definicin. Entonces aparece un diseo rpido. El diseo rpido se centra en una representacin de esos aspectos del software que sern visibles para el usuario/cliente. El prototipo lo evala el cliente y lo utiliza para refinar los requisitos del software a desarrollar. La interaccin 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 mayora 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 versin rediseada en la que se resuelvan estos problemas.
Escuchar al cliente
Construir/revisar maqueta
El cliente aprueba la maqueta
12
El modelo de construccin de prototipos, Continuacin

Desventajas del modelo de construccin de prototipos
1. El cliente ve lo que parece ser una versin 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 implementacin para hacer que el prototipo funcione rpidamente. Se puede utilizar un sistema operativo o lenguaje de programacin inadecuado simplemente por que esta disponible y es conocido.
3. El modelo DRA
El desarrollo Rpido 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 adaptacin a alta velocidad del modelo lineal secuencial en el que se logra el desarrollo rpido utilizando un enfoque de construccin basado en componentes.
Equipo 2
Modelado y gestin
Equipo 1
Equipo 3
Model ado y gestin Modelado de datos Model ado de datos Model ado de proces
Genera cin de aplicaci Prueba sy volume
Modelado y gestin
Modelado de datos
Modelado de procesos Generacin de aplicaciones
Modelado de procesos Generaci n de aplicacion es
Pruebas y volumen
Pruebas y volumen
De 30 a 60 das

13
Fases del modelo DRA , Continuacin

Modelado de gestin
El flujo de informacin entre las funciones de gestin se modela de forma que responda a las preguntas: qu informacin conduce al proceso de gestin? qu informacin se genera? quin la genera? a dnde va la informacin? quin la procesa? El flujo de informacin definido como parte de la fase de modelado de gestin se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las caractersticas (llamadas atributos) de cada uno de los objetos y las relaciones entre ellos. Los objetos de datos definidos quedan transformados para lograr el flujo de informacin necesario para implementar una funcin de gestin. Las descripciones se crean para aadir, modificar, suprimir, o recuperar un objeto de datos. El DRA asume la utilizacin de tcnicas de cuarta generacin, utilizando componentes de programas existentes o crear componentes reutilizables. Como el proceso DRA enfatiza la reutilizacin, 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. 1. Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el nmero correcto de equipos. 2. DRA requiere clientes y desarrolladores comprometidos en las rpidas actividades necesarias para completar un sistema en un marco de tiempo abreviado.
Modelado de datos
Modelado de proceso
Generacin de aplicaciones Pruebas y entrega
Desventajas del modelo DRA
4. El modelo incremental
Este modelo combina elementos del modelo lineal secuencial con la filosofa interactiva de construccin 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.
14
El modelo incremental, Continuacin

Cuando se utiliza un modelo incremental, el primer incremento a menudo es un producto esencial (ncleo). Es decir, se afrontan requisitos bsicos pero muchas funciones suplementarias (algunas conocidas, otras no) quedan sin extraer. El cliente utilzale producto central. Como resultado de utilizacin y/o evaluacin, se desarrolla un plan para el incremento siguiente. El plan afronta la modificacin del producto central a fin de cumplir mejor las necesidades del cliente y la entrega de funciones, y caractersticas adicionales. Este proceso se repite siguiendo la entrega de cada incremento, hasta que se elabore el producto completo.
Ingeniera de sistemas/ informacin
Anlisis
Diseo
Cdigo
Prueba
Entrega de 1 incremento
Incremento 2
Anlisis
Diseo
Cdigo
Prueba
Entrega de Incremento 2
Incremento 3
Anlisis
Diseo
Cdigo
Prueba
Entrega de Incremento 3
Incremento 4
Anlisis
Diseo
Cdigo
Prueba
Tiempo de calendario
15
El modelo incremental, continuacin

El modelo de proceso incremental, como la construccin de prototipos y otros enfoques evolutivos, es interactivo por naturaleza. Pero a diferencia de la construccin 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 dotacin de personal no est disponible para una implementacin completa en cuanto a de la fecha limite de gestin 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 aadir ms 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 acompaa la naturaleza interactiva de construccin de prototipos con los aspectos controlados y sistemticos del modelo lineal secuencial. Se proporciona el potencial para el desarrollo rpido 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 versin incremental podra ser un modelo en papel o un prototipo. Durante las ltimas iteraciones se producen versiones cada vez ms completas de ingeniera del sistema. El modelo en espiral se divide en un nmero de actividades estructurales, tambin llamadas regiones o reas, generalmente existen entre tres y seis regiones de tareas:
16
El modelo en espiral, Continuacin

Comunicacin con el cliente Planificacin
Las tareas requeridas para establecer comunicacin entre el desarrollador y el cliente. Las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto. Las tareas requeridas para evaluar riesgos tcnicos y de gestin. Ingeniera. Las tareas requeridas para construir una o ms representaciones de la aplicacin. Las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario. Las tareas requeridas para obtener la reaccin del cliente segn la evaluacin de las representaciones del software creadas durante la etapa de ingeniera e implementada durante la etapa de instalacin. Cuando empieza el proceso evolutivo, el equipo de ingeniera del software gira alrededor de la espiral en la direccin de las agujas del reloj, comenzando por el centro, el primer circuito de la espiral produce el desarrollo de una especificacin de productos; los siguientes en la espiral se podran utilizar para desarrollar un prototipo y progresivamente versiones ms sofisticadas del software. A diferencia del modelo del proceso clsico 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 travs del siguiente cubo y se inicia un nuevo proyecto de desarrollo. El producto evolucionar a travs de iteraciones alrededor de la espiral siguiendo el camino que limita la regin algo ms brillante que el centro.
Anlisis de riesgo
Construccin y adaptacin Evaluacin del cliente
17
Gestin de proyectos
El proceso de gestin del proyecto comienza con un conjunto de actividades que globalmente, se denominan planificacin del proyecto. La gestin eficaz de un proyecto de software se centra en las cuatro Ps: personal, producto, proceso y proyecto. El orden no es arbitrario. El gestor que se olvida de que el trabajo de ingeniera de software es un esfuerzo humano intenso nunca tendr xito en la gestin de proyectos. Un gestor que no fomenta una minuciosa comunicacin con el cliente al principio de la evolucin del proyecto corre el riesgo de construir una elegante solucin para un problema equivocado.
Producto
Caractersticas del cliente
Proceso
Condiciones del negocio
Personas
Entorno de desarrollo
Tecnologa
Determinantes de la calidad del software y de la efectividad de organizacin
Si el gestor olvida que el trabajo de ingeniera de software es un esfuerzo humano intenso, nunca tendr xito en la gestin 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 tcnicos del proyecto: planifican , motivan, y controlan a los profesionales para que realicen el trabajo de software.
18
Participantes, Continuacin

Estructura del equipo
Profesionales: proporciona las capacidades tcnicas necesarias para la ingeniera de un producto. Clientes: especifican los requisitos para la ingeniera de software. Usuarios finales: interaccionan con el software una vez que se ha entregado para la produccin
Descentralizado democrtico (dd) Carece de jefe permanente Se nombran coordinadores de tareas a corto plazo Las decisiones sobre problemas se hacen por consenso La comunicacin entre los miembros es horizontal
Descentralizado controlado Tiene un jefe definido que coordina tareas especificas y jefes secundarios que tienen responsabilidades sobre subtareas La resolucin de las tareas se hace en grupo, pero la implementacin de soluciones se reparte entre subgrupos por el jefe del equipo. Hay comunicacin vertical
Centralizado controlado
Criterios para la eleccin de una estructura organizacional
El jefe del equipo se encarga de resolver el problema a alto nivel y la coordinacin interna del equipo. La comunicacin es vertical. La dificultad del problema El tamao 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 comunicacin requerido para el proyecto.
19
Gestin de proyectos, Continuacin

2. El Producto
Se requiere un anlisis 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 funcin, el rendimiento, las restricciones, las interfaces, y la fiabilidad. Se evalan las funciones descritas en la declaracin del mbito, y en algunos casos se refinan para dar ms detalles antes del comienzo de la estimacin. Se evala la funcin 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.
Requerimien tos 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 difcil, especialmente si el sistema es nuevo. En consecuencia, es difcil 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 ingeniera de requerimientos. Los principales requerimientos se detallan a continuacin: 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 especificiacin funcional, debe ser preciso. ste sirve como un contrato entre el comprador del sistema y el desarrollador de software. 3. Una especificacin del diseo del software : es una descripcin abstracta del diseo del software que es una base para un diseo e implementacin detallados. Esta especificacin agrega detalle a la especificacin de requerimientos del sistema.
20
mbito del software, Continuacin
Requerimientos del usuario
Administradores, clientes, usuarios finales del sistema, ingenieros clientes, administradores contratistas, arquitectos del sistema
Requerimientos del sistema
Usuarios finales del sistema Ingenieros clientes Arquitectos del sistema Desarrolladores del software
Especificacin del diseo del software
Ingenieros clientes (quizs) Arquitectos del sistema Desarrolladores del software
Requerimien tos 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 cmo 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, estndares, etc. requerimientos de dominio: son requerimientos que provienen del dominio de aplicacin del sistema y que refleja las caractersticas de ese dominio. stos pueden ser funcionales o no funcionales.
21
mbito del software, Continuacin

Procesos de Ingeniera de requerimientos
Existen cuatro actividades genricas de alto nivel en el proceso de ingeniera de requerimientos. stas son el estudio de factibilidad, la obtencin y el anlisis de requerimientos, la especificacin de stos y su documentacin. Estudios de factibilidad (viabilidad) En todos los sistemas nuevos, el proceso de ingeniera re requerimientos empieza con un estudio de factibilidad. La entrada de ste es una descripcin resumida del sistema y de cmo de utilizar dentro de una organizacin. El resultado del estudio es un informe que recomienda si es conveniente llevar a cabo la ingeniera 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 organizacin? 2. El sistema se puede implementar utilizando la tecnologa 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 evaluacin y recoleccin de la informacin, y la redaccin de informes. La fase de la evaluacin de la informacin identifica que dicha informacin requerida para contestar a las tres preguntas anteriores Algunos ejemplos de preguntas posibles son: 1. Cmo se las arreglara la organizacin si no se lleva a cabo este sistema? 2. Cules son los problemas con los procesos actuales y cmo ayudara el nuevo sistema a resolverlos? 3. Cul es la contribucin directa que har el sistema a los objetivos del negocio? 4. La informacin se puede obtener y transferir a otros sistemas de la organizacin? 5. El sistema requiere de tecnologa que no se ha utilizado previamente en la organizacin? 6. A que debe ayudar el sistema y a qu no necesita ayudar?
22
Estudios de factibilidad (viabilidad), Continuacin

Una vez que se ha identificado el mbito, es razonable preguntarse : podemos construirlo de acuerdo a este mbito?, es factible el proyecto?. Descomposicin del problema Denominado a veces particionado o elaboracin del problema, es una actividad que se asienta en el ncleo del anlisis de requisitos del software. Aplicando la descomposicin 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., clsico, prototipos, etc.). La decisin se basar en: Los clientes que han solicitado el producto y la gente que realizar el trabajo Las caractersticas 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 seales que indican que un proyecto de sistemas de informacin est en peligro: 1. 2. 3. 4. 5. 6. La gente del software no comprende las necesidades de los clientes El mbito del producto est definido pobremente. Los cambios estn mal realizados. La tecnologa elegida cambia. Las necesidades del negocia cambian (o estn mal definidas) Las fechas de entrega no son realistas.
23
El proyecto, Continuacin
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 prcticas y sabias lecciones. Los profesionales veteranos de la industria hacen referencia frecuentemente a la regla 90-90 cuando estudian proyectos de software particularmente difciles: 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.
24
3. Programacin Orientada a Objetos

Programacin orientada a objetos La programacin orientada a objetos es un mtodo de implementacin 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 jerarqua de clases unidas mediante relaciones de herencia. Hay tres partes importantes en esta definicin: la programacin orientada a objetos 1. utiliza objetos, no algoritmos, como sus bloques lgicos de construccin fundamentales, 2. cada objeto es una instancia de alguna clase; y 3. las clases estn relacionadas con otras clases por medio de relaciones de herencia. La mayora de los programadores trabajan en un lenguaje y utilizan slo un estilo de programacin. Programan bajo un paradigma apoyado por el lenguaje que usan. Se define un estilo de programacin como una forma de organizar programas sobre las bases de algn modelo conceptual de programacin. Hay cinco principales estilos de programacin: Orientado a procedimientos Algoritmos Orientados a objetos Clases y objetos Orientados a lgica Objetivos, a menudo expresados como clculo de predicados. Orientado a reglas reglas si-entonces Orientado a restricciones relaciones invariantes. Cada uno de los estilos de programacin 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: Abstraccin Encapsulamiento Modularidad Jerarqua
25
Programacin orientada a objetos, Continuacin

Hay tres elementos secundarios del modelo de objetos: Tipos (tipificacin) 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 categora). Ejem. Persona. Un objeto cuenta con una estructura, es decir Atributos (propiedades) y Acciones (mtodos). Las acciones son todas las actividades que el objeto es capaz de realizar. Los atributos y acciones en conjunto se conocen como caractersticas o rasgos. (Adems de la categorizacin) Es una plantilla para fabricar objetos (molde). Caractersticas similares en grupos. Para modelar entre ms atributos y acciones, mayor ser la similitud de su modelo con la realidad. Una abstraccin denota las caractersticas esenciales de un objeto que lo distinguen de todos los dems tipos de objeto y proporciona as formas conceptuales ntidamente definidas a la perspectiva del observador. Es la capacidad de un objeto de recibir las caractersticas de la clase de la que proviene. Superclase Subclase Una operacin tiene el mismo nombre en diferentes clases y funciona distinto en cada una. Un objeto trae consigo su funcionalidad pero sta se encuentra oculta. Ocultamiento de la informacin. Forma en que se comunican los objetos. Uno enva un mensaje a otro para realizar una operacin. Formas de relacionarse entre objetos. 3 Tipos Una direccin, en ambas, 1 a varios Agregacin. Conjunto de elementos Composicin. Diversos componentes (el componente se considera slo si forma parte de un todo).
Clase
Abstraccin
Herencia
Polimorfismo
Encapsulamiento
Envo de mensajes
Asociaciones
26

Ejemplo
Ellos, llaman a cada una de estas parcelas reino, tipo, clase, especie, orden, familia, gnero, 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 flidos y de las clases leo (len) 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.
27
Ejercicios
Tome la clase len y especifique algunos de sus datos y de sus mtodos
Ejercicio 1
Datos
Mtodos
Tomemos un cassette. Cmo lo definiramos al estilo de POO

Ejercicio 2
Datos
Mtodos
28
Ejercicios, continuacin
Pongamos otro ejemplo algo ms prximo a los objetos que se suelen tratar en informtica: un recuadro en la pantalla. El recuadro pertenecera a una clase a la llamaremos marco. Veamos sus datos y sus mtodos.
Ejercicio 3
Datos
Mtodos
Objetos de la clase marco

29
Ejemplo 3, Continuacin
Los datos son los mismos, pero los valores que toman esos datos son diferentes para cada objeto. Ahora, podemos aplicar los mtodos a los datos. Estos mtodos producirn distintos resultados segn a qu datos se apliquen. As, el objeto marco 1, al aplicarle el mtodo Mostrarse, aparece en la parte izquierda, rectangular verticalmente y con lnea doble, mientras que el objeto marco 2, al aplicarle el mismo mtodo, aparece en la parte izquierda, cuadrado y con lnea simple. Si quisiramos ahora aplicarle el mtodo Cambiar de posicin al objeto marco 1, este mtodo debera seguir los siguientes pasos y en este orden. Llamar al mtodo Ocultarse para este objeto. Cambiar los datos de coordenadas para este objeto. Llamar al mtodo Mostrarse para este objeto. Vemos as cmo un mtodo de una clase puede llamar a otros mtodos de su misma clase y cmo puede cambiar los valores de los datos de su misma clase. De hecho es as como debe hacerse: los datos de una clase slo deben ser alterados por los mtodos 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 mtodos pblicos.
30
4. Introduccin al Lenguaje Unificado de Modelado

Historia de UML UML es probablemente, una de las innovaciones conceptuales en el mundo tecnolgico del desarrollo de software que ms expectativas y entusiasmos haya generado en muchos aos, comparable a la aparicin e implantacin de lenguajes COBOL, BASIC, Pascal , C++, y ms recientemente Java o XML. Adems, todas las expectativas se han cumplido y han generado a su vez nuevas expectativas. UML es un estndar de la industria, pero no slo de la industria de software sino, en general, de cualquier industria que requiera la construccin de modelos como condicin previa para el diseo y posterior construccin de prototipos. En la primavera de 1995 con la unin de las metodologas Booch 94 y OMT (Grady Booch y James Rumbaugh) presentaron a la comunidad informtica el entonces denominado Unified Method versin 0.8. Posteriormente se uni al equipo Ivar Jacobson, creador a su vez del mtodo OOSE y, sobre todo, del ingenioso concepto use case (casos de uso). La unin del equipo de 3 amigos, como se les ha conocido, con inmenso prestigio en el mundo de la ingeniera de software que se propusieron construir un nuevo lenguaje de modelado, UML, cuya primera versin (1.1) se present para su estandarizacin al OMG (Object Management Group) en 1997 y que fue aceptada. Otra gran aportacin, en este caso no slo conceptual sino prctica en forma de herramientas fue la creacin 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, disear, hojear, configurar, mantener y controlar la informacin sobre tales sistemas.
31
Resumen de UML, Continuacin

UML capta la informacin sobre la estructura esttica y el comportamiento dinmico de un sistema. La estructura esttica define los tipos de objetos importantes para un sistema y su implementacin, as como las relaciones entre los objetos. El comportamiento dinmico define la historia de los objetos en el tiempo y la comunicacin entre objetos para cumplir sus objetivos. El modelar un sistema desde varios puntos de vista, separados pero relacionados, permite entenderlo para diferentes propsitos. UML no es un lenguaje de programacin. Las herramientas pueden ofrecer generadores de cdigo de UML para una gran variedad de lenguajes de programacin, as como construir modelos por ingeniera inversa a partir de programas existentes. UML ayuda al usuario a entender la realidad de la tecnologa y la posibilidad de que reflexione antes de invertir y gastar grandes cantidades en proyectos que no estn seguros en su desarrollo, reduciendo el coste y el tiempo empleado en la construccin de las piezas que constituirn el modelo. Objetivos en UML UML es un lenguaje de modelado de propsito general que pueden usar los modeladores. No tiene propietario y est basado en el comn acuerdo de gran parte de la comunidad informtica. Esto significa incluir conceptos de los mtodos lderes para que UML pueda usarse como su lenguaje de modelado. UML no pretende ser un mtodo de desarrollo completo. No incluye un proceso de desarrollo paso a paso. UML pretende trabajar correctamente con todos, o al menos con la mayora 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 DSouza i-Logix (David Harel) Intellicorp and James Martin & co. (James Odell)
32
Participantes en UML, Continuacin
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 abstraccin de dicho sistema, considerando un cierto propsito. As, el modelo describe completamente aquellos aspectos del sistema que son relevantes al propsito del modelo, y a un apropiado nivel de detalle. una representacin grfica de una coleccin de elementos de modelado, a menudo dibujada como un grafo con vrtices 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 inters. El cdigo fuente del sistema es el modelo ms detallado del sistema (y adems es ejecutable). Sin embargo, se requieren otros modelos.
Diagrama
Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de trazabilidad entre los diferentes modelos
33
Vistas y diagramas en UML
rea Estructural
Vista Vista esttica Vista de casos de uso Vista de implementacin Vista de despliegue
Diagramas Diagrama de clases Diagrama de casos de uso Diagrama de componentes Diagrama de despliegue Diagrama de estados Diagrama de actividad Diagrama de secuencia Diagrama de colaboracin Diagrama de clases Todos
Dinmica
Vista de mquina de estados Vista de actividad Vista de interaccin
Conceptos Principales Clase, asociacin, generalizacin, dependencia, realizacin, interfaz. Casos de uso, actor, asociacin, extensin, inclusin, generalizacin de casos de uso Componente, interfaz, dependencia, localizacin Nodo, componente, dependencia, localizacin Estado, evento, transicin, accin. Estado, actividad, transicin de terminacin, divisin, unin. Interaccin, objeto, mensaje, activacin Colaboracin, interaccin, rol de colaboracin, mensaje. Paquete, subsistema, modelo Restriccin, estereotipo, valores etiquetados
Gestin del modelo Extensin de UML
Vista de gestin del modelo Todas
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 Interaccin: Diagrama de Secuencia Diagrama de Colaboracin Diagramas de implementacin: o Diagrama de Componentes o Diagrama de Despliegue
34
Vistas y diagramas en UML, Continuacin
Diagramas de Secuencia
Use Use Cas Cas
Use Diagramas Use de Casos de Uso Cas Cas
State Diagramas State de Clases Diagra Diagra
State Diagramas State de Objetos Diagra Diagra State Diagramas State de Componentes Diagra Diagra
Scenari Diagramas de Scenari Colaboracin oo Scenari Diagramas de Scenari Estados oo

Paquetes
Modelo
Diagramas de Actividad
Compone Compone Diagramas de nt Distribucin nt
Los paquetes ofrecen un mecanismo general para la organizacin de los modelos/subsistemas agrupando elementos de modelado. Se representan grficamente como:
Nombre de paquete
Cada paquete corresponde a un submodelo (subsistema) del modelo (sistema). Un paquete puede contener otros paquetes, sin lmite de anidamiento pero cada elemento pertenece a (est definido en) slo un paquete. Una clase de un paquete puede aparecer en otro paquete por la importacin a travs de una relacin 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

35
Paquete, Continuacin
El operador :: permite designar una clase definida en un contexto distinto del actual
Clases
La clase define el mbito de definicin de un conjunto de objetos. Cada objeto pertenece a una clase. Los objetos se crean por instanciacin de las clases. Representada por un rectngulo con tres divisiones, una clase escribe un conjunto de objetos con caractersticas y comportamiento idntico. Nombre Propiedades Mtodos (Entidad) (Atributo) (Operaciones)
Ejemplo de una clase
LavadoraIndustrial
Motocicleta color cilindrada velocidad mxima arrancar() acelerar() frenar()
36
Encapsulamiento
Los niveles de encapsulacin estn heredados de los niveles de C++: (-) Privado : es el ms fuerte. Esta parte es totalmente invisible (excepto para clases friends en terminologa C++) (#) Los atributos/operaciones protegidos estn visibles para las clases friends y para las clases derivadas de la original (+) Los atributos/operaciones pblicos son visibles a otras clases (cuando se trata de atributos se est transgrediendo el principio de encapsulacin)
Reglas de visibilidad
Reglas de visibilidad Atributo pblico : Integer Atributo protegido : Integer Atributo privado : Integer "Operacin pblica"() "Operacin protegida"() "Operacin privada"()
La clase lavadora con atributos y mtodos
Instanciacin de una clase
Lavadora Marca modelo numeroSerie capacidad agregarRopa() agregarDetergente() sacarRopa() activar()
miLavadora:Lavadora Marca = Patito Modelo = Economica NumeroSerie = GL566 Capacidad = 16
37
Clases, Continuacin
Una clase con un nombre de ruta
Electrodomesticos
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() Lavadora marca modelo numeroSerie capacidad agregarRopa(C:string) agregarDetergente(C:string) sacarRopa(D:integer) activar():boolean
Firmar una clase
38
Clases, Continuacin
Abreviar una clase
Lavadora
Lavadora marca ... agregarRopa() ...
Estereotipos para organizar una lista de atributos y operaciones
Responsabilida des de una clase Restriccin 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
{capacidad = 7,8 o 9 Kg}
Notas adjuntas
Proporciona mayor informacin respecto a la clase Una nota puede contener tanto una imagen como texto
Lavadora marca modelo numeroSerie capacidad agregarRopa() agregarDetergente() sacarRopa() activar()
Vease la norma NOM GHJ954

39
Clases, Continuacin
Qu es lo que hacen las clases y cmo encontrarlas
Ejemplo. Modelo de baloncesto
Las clases son el vocabulario y terminologa de un rea del conocimiento. En las entrevistas con los clientes se debe prestar atencin a los sustantivos que utilizan para describir las entidades de sus negocios; ya que los sustantivos se convertirn en las clases del modelo. Los verbos constituyen las operaciones de las clases. Los atributos surgirn como sustantivos relacionados con los nombres de la clase. Esta podra ser una entrevista con el entrenador. A: Entrenador de que se trata el juego? E: Consiste en arrojar en baln a travs de un arco, conocido como cesto, y hacer una mayor puntuacin que el oponente. Cada equipo consta de cinco jugadores: dos defensas, dos delanteros y un central. Cada equipo lleva el baln al cesto del equipo oponente con el objetivo de hacer que el baln sea encestado. A: Cmo se hace para llevar el baln 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 baln luego de que un equipo toma posesin de l A: Cmo funciona el puntaje? E: Cada canasta vale dos puntos, a menos que el tiro haya sido hecho detrs de la lnea de los tres puntos. En tal caso, sern tres puntos. Un tiro libre contar como un punto. A propsito, un tiro libre es la penalizacin que paga un equipo por cometer una infraccin. Si un jugador infracciona a un oponente, se detiene el juego y el oponente puede realizar diversos tiros al cesto desde la lnea de tipo libre. A: Hbleme ms 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 mayora 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?
40
clases, Continuacin
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 duracin es de 40 minutos, divididos en 2 mitades de 20 minutos. Un cronmetro del juego lleva un control del tiempo restante. Identifique las clases del juego de baloncesto
Ejercicio 4
Diagrama de Clases
El Diagrama de Clases es el diagrama principal para el anlisis y diseo. Un diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia La definicin de clase incluye definiciones para atributos y operaciones El modelo de casos de uso aporta informacin para establecer las clases, objetos, atributos y operaciones
41
Uso de relaciones entre clases
Asociaciones Multiplicidad Asociaciones calificadas Asociaciones reflexivas Herencia y generalizacin Dependencias
Asociaciones Una asociacin entre un jugador y un equipo En una asociacin cada clase juega un papel o rol Pueden aparecer 2 asociaciones entre clases en el mismo diagrama Pueden asociarse diversas clases con una en particular
Cuando las clases se conectan entre s de forma conceptual.
Jugador
Participa en
Equipo
Partic ipa en
Ju g a d o r Em pleado
Ju g a d o r
Pa rt ic ipa en Emplea
Equipo Em pleador
Equipo
D efen s a
P a rti ci p a e n
Eq uip o
P a rti ci p a e n
D e lan te ro
P a rti ci p a e n
C en tro
42
Asociaciones entre clases, Continuacin

Restricciones en las asociaciones La asociacin atiende est restringida para que el cajero atienda en turno La relacin O entre dos asociaciones en una restriccin Reglas que deben seguir las asociaciones entre dos clases. Las restricciones se escriben entre llaves
A ti e n d e
C aj ero
C l ien te
{Ordenado}
Es tudiante de educacin m edia s uperior
Elige
Academ ico
{OR }
E l ig e
C om er cia l
Clases de asociacin
Una asociacin, al igual que una clase, puede contener atributos y operaciones (mtodos). Si este es el caso tendremos una clase de asociacin. Una clase de asociacin se trata como una clase estndar y por lo tanto puede tener asociaciones con otras clases.
Contrato es un atributo de la asociacin
Ju gador
P a rtic ip a e n
Equipo
Ne g o ci a d o p o r
C ontrato
D irectorGeneral
Vnculos
Una asociacin tambin cuenta con instancias de una clase. (Conecta a los objetos en lugar de las clases).
43
vnculos, Continuacin
Deber subrayar el nombre de un vnculo como se hace en el nombre de una clase Multiplicidad
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
gustavoNajera:Jugador
participa en
nacional:Equipo
La cantidad de objetos de una clase que se relacionan con un objeto de la clase asociada
P a rti ci p a e n
Eq uipo
Jug ad or 5
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 ms 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 ms y para representar muchos O se representa por dos puntos como: 1..* (uno o ms) O se representa por una como 5, 10 (en otro contexto 5 o 10)
44
Multiplicidad, Continuacin
Uno a uno
Es pos o 1
E sta ca d a d o co n
Es pos a 1
Uno a muchos
Maes tro 1
E n se a
Estudiante *
Uno a uno o ms 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)
C ajero 1
A ti e n d e
C liente 1..*
C as a 1
Ti e n e
C him enea 0,1
E stu d i a n te d e T i e m p o Co m p l e to
To ma
Hor as deC r edi tos 12..18
Triciclo 1
Ti e n e
R uedas 3
H uevera 1
Co n ti e n e
H uevos 12,2 4
45
Asociaciones, Continuacin
marido casado-con mujer

0..1 0..1
Persona nombre s.s.
emplea-a
Compaa trabaja-para nombre direccin *
jefe Administra
0.. 1
empleado
Asociaciones calificadas
Cuando la multiplicidad de una asociacin es de uno a muchos, aparece la bsqueda, por lo tanto se requiere de un atributo para localizar un objeto, dicho atributo es un identificador. En el UML la informacin de identidad se conoce como calificador.
Recepcionista
Numero de confirmacin 1 Localiza *
Reservacin
Asociaciones reflexivas
Una clase puede ser una asociacin consigo misma, esto ocurre, cuando una clase tiene objetos que pueden jugar diversos papeles. 1 Conductor
Conduce 0..4
OcupanteDeAutomovil
pasajero
46
Herencia y generalizacin
En el UML la herencia se conoce como Generalizacin. Una clase (la secundaria o subclase) puede heredar los atributos y operaciones de otra (la principal o superclase). La clase principal (madre) es ms genrica que la secundaria (hija). El UML representar la herencia con una lnea que conecte a la clase principal con la secundaria. En la parte de la lnea que se conecta con la clase principal, colocar un tringulo sin rellenar que apunte a la clase principal. Este tipo de conexin se interpreta con la frase ES UN TIPO DE.
Anim al
Anfib io
Mam ifero
R ep til
C aba llo
Cuando modele la herencia, debe asegurarse de que la clase secundaria satisfaga la relacin es un tipo de con la clase principal. Si no se cumple tal relacin, tal vez una asociacin de otro tipo podra ser ms 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 RAZ. Una clase podra 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 mltiple.
Ventajas de la generalizacin
Permite gestionar la complejidad mediante un ordenamiento taxonmico de clases Se obtiene usando los mecanismos de abstraccin de Generalizacin y/o Especializacin La Generalizacin consiste en factorizar las propiedades comunes de un conjunto de clases en una clase ms general
47
Herencia y Generalizacin, Continuacin

Prctica
Coche
Funcionando
Est ropeado
Prctica Herencia mltiple
Bpedo
Cuadrpedo
nro patas Con Pelos cubertura Con Plumas cobertura cobertura Con Escamas Animal
nro patas Herbvoro comida
comida Carnvoro
Conejo
48
Diagrama de clases, Continuacin

Polimorfismo
El trmino polimorfismo se refiere a que una caracterstica 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
Animal dormir()
Len
Oso
Tigre
Solucin
Dormir() { }
Animal dormir()
Len dormir() Dormir() { sobre el vientre }
Oso dormir() Dormir() { sobre la espalda }
Tigre dormir() Dormir() { en un rbol }
49
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 geomtricas. Tenga en cuenta las siguientes restricciones: a) b) c) d) e) f) g) h) i) j) El crculo y el polgono se pueden rellenar con diferentes formas El arco, la lnea, el polgono y el crculo se pueden reducir y ampliar Todas las figuras se pueden mover, seleccionar, rotar mostrar y ocultar El crculo se rota distinto a las dems figuras geomtricas. Los bordes de todas las figuras tienen un color, un centro, un grosor del borde El arco y la lnea tienen adems una orientacin. La lnea tiene coordenadas de sus extremos El arco tiene radio, ngulo de inicio y ngulo del arco. El nmero de caras y las coordenadas de los vrtices son datos del polgono Del crculo es necesario conocer el dimetro.
50
Clases, Continuacin
Clases abstractas
Funcionan como clases principales para clases secundarias importantes. Lo que nos interesa de las clases secundarias son las instancias que finalmente se generarn. Las clases que no proveen objetos se dice que son abstractas. Se distinguen por tener su nombre en cursivas.
Jugador
Jugador es una clase abstracta
n o m b re ta m a o p e so V e l o ci d a d A l Co rre r sa l to V e rti ca l d ri b l a r() p a sa r() re b o ta r() ti ra r()
Defens a
co rre rA l Fre n te () q u i ta rB a l o n ()
C entro D elantero
e n ce sta rB a l o n ()
Reloj es una clase abstracta
R eloj
co n tro l a rT i e m p o ()
C ronom etroD elJuego
Laps oD eTiro
51
Clases, Continuacin
Dependencias
Es un tipo de relacin en el que una clase utiliza a otra. Es uso ms comn de una dependencia es mostrar que la firma de la operacin de una clase utiliza a otra clase. Ejemplo: men de llenado de formularios.
S i ste m a
m os trarF orm ulario()
Fo rm u l a ri o
Otros tipos de asociaciones
Agregaciones Composiciones Contextos Interfaces y realizaciones
Agregaciones
Una clase cuenta de otras clases. -La agregacin representa una relacin parte_de entre objetos -En UML se proporciona una escasa caracterizacin de la agregacin -Puede ser caracterizada con precisin determinando las relaciones de comportamiento y estructura que existen entre el objeto agregado y cada uno de sus objetos componentes. Se puede representar una agregacin como una jerarqua dentro de la clase completa en la parte superior y los componentes por debajo de ella. Se emplea una lnea con rombo sin relleno.
Polgono contiene {ordenado}
3..*
Punto
Restricciones en las agregaciones
Cuando un conjunto de posibles componentes se establece dentro de una relacin O.
52
Agregaciones, Continuacin
Ejemplo de agregacin con restriccin O
C o m id a 1
1 Sop a
{O} 1 En s alad a
1 PlatoFu erte
1 Po s tre
Completar el siguiente diagrama de clases con agregacin, asociacin y multiplicidad

Ejercicio 6
Eui poD eC om puto
Bocinas
Gabinete
Teclado
Monitor
R aton
U nidadD eD is co
U nidadD eD is quette
R AM
C D -R OM
TarjetaVideo
TarjetaSonido
Boton
Bola
Composicin
Es un tipo especial de una agregacin. Cada componente dentro de la composicin puede pertenecer a un todo. El rombo est relleno.
MesaDeCafe 1
1
SuperficieDeL aMesa
4 Pata
53
Contextos
Un diagrama de contexto es un mapa detallado de alguna seccin de un mapa de mayores dimensiones. Se emplea cuando aparecen agrupamientos de clases, como agregaciones o composiciones para enfocar la atencin en un agrupamiento o en otro. (de composicin, de sistema, etc.). Generar un diagrama de clase que muestre las asociaciones y la composicin de las siguientes clases:
Ejercicio 7
Diagrama de contexto
Manga
Camis a
Talle
Cuello
Botonadura
Bo ton
Oj al
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
54
Ejercicio 8
Diseo
1. Decidir a que categora: generalizacin, asociacin simple o agregacin, pertenecen las relaciones siguientes. Coloque una G en caso de Generalizacin, una A para la asociacin simple y una C para la agregacin. 2. Represente cada uno con un diagrama de clases independiente empleando la notacin grfica 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 calificacin de ste. g. __ Un vuelo conecta a dos aeropuertos. h. __ Las personas pueden ser empleadas o desempleadas. i. __ El corazn, las venas y las arterias son partes del sistema circulatorio. j. __ Las tarjetas bancarias pueden ser de debito o de crdito pero no de ambas.
55
Realice el diagrama de clases del problema del juego de baloncesto

Ejercicio 9
Ejercicio 10
Realice el diagrama de clases del siguiente problema. En un hotel se hospedan huspedes mexicanos y extranjeros. El hotel cuenta con 250 habitaciones que pueden o no estar rentadas. Un husped puede rentar una o ms habitaciones, pero una habitacin est rentada a nombre de un solo husped.
56
Casos de uso
Los diagramas de clases muestran una vista esttica del sistema, ayudan a que el analista se comunique con el cliente. La idea dinmica ayudar al analista a comunicarse con un grupo de desarrolladores. Los casos de uso capturan los REQUISITOS del cliente.
Definicin
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 coleccin de casos de uso se puede hacer un bosquejo de un sistema en trminos de lo que los usuarios intenten hacer con l. El caso de uso es una coleccin 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 coleccin de escenarios y cada escenario es una secuencia de pasos. Cada diagrama tendr su propia pgina, de igual manera, cada escenario de caso de uso tendr su propia pgina, 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
57
Casos de uso, Continuacin

Diagramas de caso de uso en el proceso de anlisis
Las entrevistas del cliente debern iniciar el proceso. Estas entrevistas producirn diagramas de clases que fungirn como las bases de conocimiento para el dominio del sistema (el rea en el cual resolver los problemas). Una vez que se conozca la terminologa general del rea del cliente, estar listo para hablar con los usuarios.
Las entrevistas con los usuarios comienzan con la terminologa del dominio, Actores y casos aunque debern alternarse hacia la terminologa de los usuarios. Los de uso de alto resultados iniciales de las entrevistas debern revelar a los actores y casos de nivel uso de alto nivel que describirn los requerimientos funcionales en trminos generales. Esta informacin establece los confines y mbito del sistema. Modelos de casos de uso Las entrevistas posteriores con los usuarios profundizarn en estos requerimientos, lo que dar por resultado modelos de caso de uso que mostrarn escenarios y las secuencias detalladamente. Esto podra resultar en otros casos de uso que satisfagan las relaciones de inclusin y extensin. En esta fase, es importante confiar en su compresin del dominio (a partir de los diagramas de clases derivados de las entrevistas con el cliente). Si no comprende el dominio podra crear demasiados 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 lmites 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 implantacin 4. Comparacin con respecto a los Diagramas de Flujo de Datos del Enfoque Estructurado
Puntos clave de los casos de uso
Ejemplo
Actor A
Caso de Uso A
Caso de Uso B
Actor B
58

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 aplicacin y deben ser utilizados. Otros sistemas: sistemas con los que el sistema interacta La misma persona fsica puede interpretar varios papeles como actores distintos El nombre del actor describe el papel desempeado
Relaciones
Comunicacin
UML define cuatro tipos de relacin en los Diagramas de Casos de Uso un actor se comunica con un caso de uso
C aso de U so
Actor
Inclusin
una instancia del Caso de Uso origen incluye tambin el comportamiento descrito por el Caso de Uso destino
<<include>>
Caso de Uso Origen
C aso de U so Desti no
Extensin
el Caso de Uso origen extiende el comportamiento del Caso de Uso destino

<<extend>>
Caso de Uso Origen
C aso de U so Desti no
Herencia
el Caso de Uso origen hereda la especificacin del Caso de Uso destino y posiblemente la modifica y/o ampla
Caso de Uso Hij o
Caso de Uso Padre
59

Ejemplos de relaciones en los casos de uso
<<include>> Ide n tf i i caci n
Cliente
Transferencia
<< e xten d >>
Transferencia en Internet
Supply Custome r Data
Orde r Product
Arrange Payment
<<include >>
<<include >>
<<include >>
the sa le spe rson a sks for the c a ta l og
1 Salesperson
* Place Order
<<e x te nd>>
Re que st Catalog
Construccin 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: cules son las tareas del actor? qu informacin 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?
60

Qu comprende la descripcin del Caso de Uso
el inicio: cundo y qu actor lo produce? el fin: cundo se produce y qu valor devuelve? la interaccin actor-caso de uso: qu mensajes intercambian ambos? objetivo del caso de uso: qu lleva a cabo o intenta? cronologa y origen de las interacciones repeticiones de comportamiento: qu operaciones son iteradas? situaciones opcionales: qu ejecuciones alternativas se presentan en el caso de uso? El caso de uso es un documento narrativo que describe la secuencia de eventos de un actor
Ejemplo de caso de uso de alto nivel:
Comprar producto
Ca jero
Comprar productos
Cliente
Documentacin del caso de uso
Caso de uso: Actores: Tipo: Descripcin:
Comprar productos Cliente, cajero Primario Un cliente llega a la caja registradora con los artculos que comprar. El cajero registra los artculos y cobra el importe. Al terminar la operacin, el Cliente se marcha con los productos.
Ejemplo de caso de uso expandido:
Comprar productos con efectivo
Cajero
Comprar productos
Cliente
Registra los datos
Paga o entega el cambio de los pro duct os comprados

61
Seccin: Principal
Caso de uso: Actores: Propsito: Tipo: Descripcin: Comprar productos Cliente, cajero Capturar una venta y su pago Primario Un cliente llega a la caja registradora con los artculos que comprar. El cajero registra los artculos y cobra el importe. Al terminar la operacin, el Cliente se marcha con los productos. Funciones: R1.1, R1.2, R1.3,
Referencias cruzadas:
Curso normal de los eventos Accin de los actores 1. Este caso de uso comienza cuando un Cliente llega a la caja con productos que desea comprar. 2. El Cajero registra los productos
Respuesta del sistema
4. Al terminar la captura de los productos, el Cajero indica a la terminal de venta que termin la captura de los productos 6. El Cajero le indica el total al Cliente. 7. El Cliente escoge la forma de pago: a. Si paga en efectivo, vase la seccin Pagar en efectivo.
3. Determina el precio del producto y agrega la informacin sobre l a la actual transaccin de venta. Se muestran la descripcin y el precio del producto actual. 5. Calcula y presenta el total de la venta.
62

Accin de los actores b. Si paga con tarjeta de crdito, vase la seccin Pagar con Tarjeta de crdito. c. Si paga con cheque, vase la seccin Pagar con cheque. Respuesta del sistema
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: Lnea 2: se introduce un identificador invlido del producto. Indique el error. Lnea 7: el Cliente no pudo pagar. Cancele la transaccin de venta.
Seccin: pagar en efectivo

Accin de los actores 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 4. El cajero deposita el efectivo recibido y extrae la diferencia. El cajero le entrega el cambio al cliente. Respuesta del sistema
3. Presenta cliente.
la
diferencia
al
63

Cursos alternos: Lnea 1: El Cliente no tiene suficiente efectivo. Puede cancelar o iniciar otro mtodo de pago. Lnea 4: La caja no contiene suficiente efectivo para pagar la diferencia. El cajero pide ms efectivo al supervisor o le pide al Cliente otro billete de menor denominacin u otra forma de pago. Realice las descripciones de las secciones: Pago con tarjeta de crdito y pago con cheque.
Ejercicio 11
64
65
Genere el diagrama de casos de uso y su descripcin de retirar efectivo en un cajero automtico.

Ejercicio 12
66
Genere el diagrama de casos de uso y su descripcin de realizar una llamada telefnica.

Ejercicio 13
67
a) Elabore un diagrama de paquetes de casos de uso. b) Descomponga cada paquete en un diagrama de casos de uso.
Ejercicio 14
68
Diagramas de interaccin
Los objetos interactan para realizar colectivamente los servicios ofrecidos por las aplicaciones. Los diagramas de interaccin muestran cmo se comunican los objetos en una interaccin. Existen dos tipos de diagramas de interaccin: el diagrama de colaboracin y el Diagrama de secuencia.
Mensajes
Sintaxis para mensajes: predecesor / guarda secuencia: retorno := msg(args) El Diagrama de Secuencia es ms adecuado para observar la perspectiva cronolgica de las interacciones. El Diagrama de Colaboracin ofrece una mejor visin espacial mostrando los enlaces de comunicacin entre objetos. El Diagrama de Colaboracin puede obtenerse automticamente 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 envo y la atencin se puede indicar usando una lnea oblicua.
: n o m b re
Representacin de un objeto en un diagrama de secuencia
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 extensin que est debajo de cada objeto ser una lnea discontinua conocida como la lnea de vida de un objeto. Junto con la lnea de vida de un objeto se encuentra un pequeo rectngulo conocido como activacin, el cual representa la ejecucin de una operacin que realiza el objeto. La longitud del rectngulo se interpreta como la duracin de la activacin.
69
Diagrama de Secuencias, Continuacin

Mensaje
Un mensaje que va de un objeto a otro pasa de la lnea 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 Sincrnico o Asincrnico
Tiempo
El diagrama representa el tiempo en direccin vertical. El tiempo se inicia en la parte superior y avanza hacia la parte inferior. Un mensaje que est ms cerca de la parte superior ocurrir antes que uno que est cerca de la parte inferior. Con ello, el diagrama tiene dos dimensiones. La dimensin horizontal es la disposicin de los objetos, y la dimensin vertical muestra el paso del tiempo.
:nombre1
:nombre2
70
Diagrama de secuencias, Continuacin

Ejemplo de un diagrama de secuencias
: Encargado
: WInP rstamos
:Socio
:Video
: Prstamo
prestar(video, socio) verificar situacin socio verificar situacin video registrar prstamo entregar recibo
Ejercicio 15
Genere el diagrama de secuencia del siguiente problema: Suponga que un usuario de una interfaz grafica (GUI) presiona una tecla alfanumrica, 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 enva un mensaje al monitor 6. EL monitor presenta el carcter alfanumrico en la pantalla, con lo que se har evidente al usuario
71
Mquina despachadora de refrescos.

Ejercicio 16
Suponga que comenzar a disear una mquina despachadora de refrescos. Un cliente desea comprar una lata de refresco. El Cliente deber insertar el dinero, posteriormente realizar una seleccin. Si todo funciona bien la mquina contar con al menos una lata de refresco que proporcionar al cliente. a. Genere un diagrama de casos de uso de la mquina 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)
72
73
Diagrama de colaboracin
Son tiles en la fase exploratoria para identificar objetos. La distribucin de los objetos en el diagrama permite observar adecuadamente la interaccin de un objeto con respecto de los dems. La estructura esttica viene dada por los enlaces; la dinmica por el envo de mensajes por los enlaces.
Mensajes
sincronizacin
Un mensaje desencadena una accin en el objeto destinatario. Un mensaje se enva si han sido enviados los mensajes de una lista:
A.1, B.3 / 1:Mensaje
A
condiciones
Un mensaje se enva de manera condicionada
[x>y] 1: Mensaje
A
Valores de retorno
Un mensaje que devuelve un resultado
1: distancia:= mover(x,y)
B A
74
Diagrama de colaboracin, Continuacin

Ejemplo de un diagrama de colaboracin
:Socio
:Video 2: verificar situacin socio
1: prestar(video, socio) :WInPrstamos 5: entregar recibo : Encargado
3: verificar situacin video
4: registrar prstamo
:Prstamo
Genere el diagrama de colaboracin del de secuencia del ejercicio 2.

Ejercicio 17
75
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
Smbolos UML en el diagrama de estados
Ejemplo de un Diagrama de Estados para la clase persona
c ontratar en el paro perder em pleo jubilarse jubil arse jub ilado en ac tivo
Acciones
Se puede especificar el ejecutar una accin como consecuencia de entrar, salir, estar en un estado, o por la ocurrencia de un evento
estado
entry: accin por entrar exit: accin por salir do: accin mientras en estado on evento: accin
76
Diagrama de estados,Continuacin
Los estados y transiciones de una interfaz grfica de usuario
Encender la PC
Inicializacin do/ Arrancar

[ lapso transcurrido ]
Operacin
Apagado
Apagar
Teclazo o movimiento del ratn
Protector de pantalla
Sub-estados secuenciales
Encender la PC
A la espera de accin del Inicializacin do/ Arrancar
Operacin Registro de una accin del usuario
Representacin de la acc in del us uario Apagado Apagar
[ lapso transcurrido ]
Teclazo o movimiento del ratn
Protector de pantalla
77
Genere el diagrama de estados de una factura

Ejercicio 18
78
Diagrama de actividades
Es una especializacin del Diagrama de Estado, organizado respecto de las acciones y usado para especificar: Un mtodo Un caso de uso Un proceso de negocio (Workflow) Las actividades se enlazan por transiciones automticas. Cuando una actividad termina se desencadena el paso a la siguiente actividad Permite especificar decisiones y concurrencia.
Decisiones en un diagrama de actividades

Despertar
[ hambriento ]
[ inapetente ]
Desayunar
Volver a dormir
Despertar
[ hambriento ]
[ inape tente ]
Desayunar
Volver a dormir
79
Diagrama de actividades, Continuacin

Ejemplo de un diagrama de actividades
B u s c a r B e b id a [ h a y c a f ] [ hay z um o ] P o n e r c a f e n filtro P o n e r filtro e n m q u in a A ad i r a g u a a l d e p s i to C o g e r ta z a C oger zumo [ n o h a y c a f ]
[ no zumo ]
E ncender m q u in a / c a fe t e ra .O n C af e n p re p a ra c i n i n d i c a d o r d e fi n S e rv ir c a f B eber
Marcos de trabajo
P a s a j e ro
V ende do r
A i r l i ne
S o lic it a r p a s a je
V e r if ic a r e x is t e n c ia v u e lo
D a r d e t a lle s v u e lo
I n f o r m a r a lte r n a t i v a s y p r e c io s S e le c c io n a r v u e lo
S o lic it a r pago Pagar p a s a je
R e s e rv a r pla z as C o n fir m a r p la z a re s e rv a d a
E m it ir b i ll e t e
80
Diagrama de actividades, Continuacin

Genere un diagrama de actividades que muestre como preparar un omelette con queso y cebolla.
Ejercicio 19
81
Diagrama de componentes
Los diagramas de componentes describen los elementos fsicos del sistema y sus relaciones. Muestran las opciones de realizacin incluyendo cdigo fuente, binario y ejecutable. Los componentes representan todos los tipos de elementos software que entran en la fabricacin de aplicaciones informticas. Pueden ser simples archivos, paquetes de Ada, bibliotecas cargadas dinmicamente, 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
Control y Anlisis
Gestin de Cuentas
Rutinas de conexin
Acceso a BD
82
Diagramas de despliegue
Muestran la disposicin fsica de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos
N o do
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
<<Cliente>> Terminal Punto de Venta <<Servidor>> <<TCP/IP>> Base de Datos
<<RDSI>>
Control
<<RDSI>>
Diagrama de componentes y despliegue
83
Anexo A: Project
Capitulo 1
1.1 1.2 1.3
Introduccin a Project Planeacin de proyectos Seguimiento de proyectos
84
1.1 Introduccin a Project

Introduccin
El control de proyectos es una tarea importante dentro de las responsabilidades del planificador. La mayora de los proyectos se siguen se manera informal: se tiene una lnea 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.
85
Ingreso a Microsoft Project

Para cargar Project, haga doble click en el icono correspondiente
Cuando el mensaje de Bienvenida aparezca seleccione la opcin 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 grfica de Gantt. Emplea barras horizontales que representan la agenda de tareas.
Para cambiar los tamaos relativos de cada parte de la pantalla, arrastre sus lmites (o fronteras) al nuevo tamao que desee.
86
Inicializacin del proyecto
Muchas opciones de apariencia y funcionalidad del proyecto pueden controlarse empleando del men Herramientas|Opciones.... Para esta prctica, cambie los parmetros seleccionando en la pestaa Programacin para que aparezcan de la siguiente forma:
deber modificar 1. Mostrar el trabajo en: das 2. Tipo de tarea predeterminada: Duracin fija
87
Funcionalidad y apariencia del proyecto
Mucha opciones de funcionalidad y apariencia del proyecto pueden controlarse utilizando el elemento del men Herramientas|Opciones... Para esta prctica deber cambiar algunos parmetros del proyecto. En la caja de dialogo de Opciones, seleccione la pestaa Programacin, y cambie distintos parmetros para que aparezcan de la siguiente manera:
Deber modificar: 1. Mostrar el trabajo en: das 2. Tipo de tarea predeterminada: duracin fija Seleccione el elemento del men Proyecto|Informacin 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)
Cambiar la fecha de inicio del proyecto
88
Planeacin del proyecto
Agregar tareas
La planeacin de proyectos implica identificar las tareas relacionadas, su duracin y las relaciones existentes entre ellas. MS Project calcula automticamente la duracin total del proyecto y otra informacin relacionada. Para agregar informacin de tareas, haga clic en una celda vaca 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 omisin un valor de duracin de 1 da. Para cambiar este valor, haga clic en la celda en cuestin, escriba la duracin correcta, y presione enter.
89
Ejercicio
Agregue una lista de tareas como aparece a continuacin con la duracin especificada
Para insertar una tarea nueva, seleccione dentro de la Tabla de Tareas el rengln debajo de donde desea insertar las nueva tarea. Seleccione el elemento del men Insertar|Nueva Tarea (Ins) para generar un rengln en blanco en la Tabla de Tareas. Escriba una nueva tarea y su duracin. Agregue dos tareas ms: Inicio de proyecto al comienzo de la lista y Fin de proyecto en el ltimo rengln de la lista. Asigne a ambas una duracin de 0 das.
Una tarea especial denominada Hito tiene, usualmente, una duracin de 1 0 das, y representa un evento ms que una tarea. Para crear un Hito, haga doble clic en la tarea. En la caja de dialogo de Informacin de la tarea, seleccione la pestaa Avanzado. Seleccione el recuadro indicado para marcarla como Hito.
Inicio de proyecto y fin de proyecto son consideradas como Hitos.
Se pueden crear Jerarquas de Tareas: Tareas principales y sus subtareas de la barra de herramientas. para crearlas utilice los botones
90
Ejercicio, Continuacin

Agregue una nueva tarea llamada T4 debajo de T3 con duracin de 15 das. 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 lgico la preceden. En la caja de dialogo de Informacin de la Tarea seleccione la pestaa Predecesoras, se pueden asignar escribiendo el nmero de tarea directamente (separadas por comas cuando sean varias) o seleccionando una celda en blanco y el Nombre de la tarea y seleccionndola de la lista que presenta. Se crea una liga entre tareas y la grfica de Gantt refleja estos cambios.

91
Actualice las predecesoras de cada tarea de acuerdo a la siguiente lista
Para cambiar la Escala temporal de la grfica 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
92
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 relacin por omisin 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 das despus de que el predecesor Comience, se desea que Comience el sucesor (CC, con 5 das de diferencia).

93
Para cambiar la relacin entre 2 tareas ligadas, haga doble clic en la tarea sucesora. En Informacin de la tarea, seleccione la pestaa Predecesoras. Haga clic en el rengln tipo y seleccione de la lista mostrada la relacin deseada. En la columna Pos escriba la cantidad de das. Actualice la tarea T7 para que Comience 5 das despus de que inicie la tarea T6. Note que la duracin 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 podrn compararse con esta lnea. Para realizar esto seleccione Herramientas|Seguimiento|Guardar lnea de base en la caja resultante podr seleccionar lnea de base o todo el proyecto, haga clic en el botn aceptar. La vista actual tambin puede imprimirse (Archivo|vista preliminar) o copiarse y pegarse en un documento de Word: Para copiar la grfica, seleccione las tareas que desea que se incluyan en la de la barra de herramientas y en la foto a copiar. Haga clic en el botn 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 informacin del proyecto, Utilice Archivo|Grabar como para la primera vez, y Archvo|grabar en las siguientes. Para salir de la aplicacin, utilice Archivo|Salir.
94
Seguimiento de proyectos
Para dar seguimiento a proyectos, debe distinguirse entre lo planeado, lo actual y la informacin de la agenda disponible de las tareas. Las fechas de tareas planificadas (comienzo, fin, duracin) 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 informacin cambiar las fechas actuales. Los 3 tipos de informacin diferente pueden seguirse en project. Dado que es posible simular el seguimiento de una sesin futura, el primer paso consiste en modificar la fecha actual del proyecto. Seleccione del men el elemento Proyecto|Informacin del proyecto.... Actualice la Fecha de hoy: (para este ejercicio 01/04/03)
A continuacin, deber completar la informacin 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 estarn concluidas en 100% y T4 estar al 60%. Asigne los valores correspondientes. Aparecer una barra en cada tarea mostrando el avance especfico. Si el proyecto est en agenda (en tiempo), todas las tareas debern 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

95
Para ajustar la agenda (suponiendo que no tenemos ms gente para trabajar en el proyecto): Incremente el tiempo especificado para la tarea para que el avance del 60% sea representativo de los das que an faltan para concluirla. Haga clic en la tarea T4, y seleccione Herramientas|Seguimiento|Actualizar tareas... En la ventana resultante incremente la duracin restante: 10 y presione aceptar. La barra de la tarea se har grande pero la barra de avance permanecer antes que la lnea que marca la fecha actual. Seleccione nuevamente Herramientas|Seguimiento|Actualizar tareas... y actualice % completado al 60%. La grfica deber verse aproximadamente as:
Se puede seleccionar una vista de la grfica distinta para verificar los cambios del proyecto. Seleccione Ver|Ms vistas... en la ventana resultante seleccione Gantt de seguimiento y la opcin 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.
96
Capitulo 2
2.1 2.2 2.3
Recursos Asignaciones Costos
97
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? Cuntos de estos recursos se necesitan? Dnde obtengo los recursos? Cmo puedo determinar cunto 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) . Despus 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, das, meses o aos y la cantidad (unidades de medida) de cada recurso. El siguiente paso es asignar estos recursos a sus respectivas tareas (denominada asignacin) . Una vez concluido este paso Project recalcula la agenda para acomodar los tiempos de trabajo de los recursos asignados. Pueden identificarse vacaciones y das no laborables y indicarse para cada recurso. Esto permite identificar cuando se tiene sobrecarga en un recurso. (asignacin de un mismo recurso a diferentes tareas en los mismos periodos de tiempo o cuando a un recurso se le asigna ms trabaja del que puede completar en cierto tiempo.
98
Agregar informacin de recursos al proyecto
Se emplea la ventana de grfica de asignacin de recursos:
Crear un banco de recursos
1. Haga clic en el botn 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 travs de la hoja de vista de recursos 1. Seleccione la hoja de recursos 2. Capture la informacin
La columna de capacidad mxima contiene la capacidad mxima disponible de cada recurso que acompaa a una Tarea en un periodo especifico. El formato por omisin est dado en porcentajes. Por ejemplo si las unidades de asignacin estn al 100% esto implica que el recurso trabajar 8 horas al da. Si la unidad de asignacin esta al 50% el recurso trabajar 4 horas por da. En caso de que el banco de recursos consiste de 5 trabajadores, sus unidades mximas sern 500% o en valor decimal 5. El formato por omisin puede cambiarse a decimales empleando Herramientas|Opciones|Programacin (pestaa) |Mostrar las unidades de asignacin como: decimal.
99
Ventana de informacin de recursos
Haciendo doble clic sobre el nombre de un recurso podr desplegar la ventana de informacin, provee datos Generales adicionales como su disponibilidad, las unidades mximas, el equipo de trabajo, tipo de recurso. Acceda a la ventana de informacin del recurso, seleccione la pestaa de horario de trabajo para realizar los cambio deseados.
Asignacin de calendario base distinto al que proporciona project Edicin del calendario de recursos 2.2 Asignacin Asignacin de un recurso a una tarea
Seleccione Herramientas|Cambiar calendario laboral ... seleccione el recurso y el calendario del recurso a editar.
1. Abra la vista de la grfica 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 duracin es la cantidad de tiempo entre el inicio y el fin de una tarea. As que, Trabajo = Duracin * Unidades (T=D*U) Para una tarea especifica Tx, si su duracin fuera de 5 das 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 das. En caso de que se tomen las unidades al 50%, entonces cada uno trabajara 4 horas al da. Esto traer por resultado que el trabajo se concluir antes de los 5 das estipulados y la cantidad de tiempo esperado para los 3 recursos decrecer. En este caso Project deber recalcular la agenda.
100
Asignacin de un recurso a una tarea (contina)
Dado que puede elegirse entre duracin, trabajo y unidades, Project siempre modificar la duracin del proyecto. Puede tenerse un mayor control empleando los Tipos de Tareas que se vern a continuacin.
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. Duracin Fija La definicin 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 duracin cuando sea necesario, pero las unidades de trabajo permanecern fijas. De manera similar cuando las tareas son con duracin 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 omisin de las tareas es Unidades Fijas.
Para modificar el tipo de tarea
1. Herramientas|Opciones| 2. Seleccionar la pestaa de Programacin 3. Cambiar Tipo de tarea predeterminada. An cuando la se modifiquen los valores predeterminados de una tarea. Su duracin es totalmente dependiente de los recursos que se le asignen. Si se modifica la cantidad de recursos despus de su asignacin inicial, Project recalcula la duracin pero deja el trabajo solo. Se puede seleccionar Herramientas|Opciones|Programacin (pestaa) y desactivar la caja en la opcin Las tareas nuevas estn condicionas por el esfuerzo.
101
Asignacin de recursos de trabajo a tareas
La Forma de Tareas puede desplegar la informacin detallada de la asignacin de recursos como Unidades y Trabajo. Para desplegar la Forma de Tareas en la grfica 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 automtica en la parte inferior. 3. Haciendo clic con el botn derecho se desplegar el men de teclas rpidas
Asignar recursos de trabajo desde la Forma de Tareas
1. Seleccione la tarea en la vista de la grfica 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. Tambin pueden asignarse empleando la ventana de Asignacin de Recursos en la forma en que se describi previamente.
102
Asignacin de recursos materiales a tareas Asignacin de recursos materiales a tareas en la Grfica de Gantt
Cuando se asignan recursos materiales, se debe especificar la forma en que estos se consumen. Al seleccionar Consumo de material variable cambia la duracin de la tarea (consumo de material variable no la cambia). Seleccione la tarea en la grfica de Gantt Seleccione el campo del nombre del recurso en la Forma de Tareas Seleccione el Recurso de la lista que aparece Seleccione el campo unidad y las unidades deseadas. Si se deja en blanco Project lo asigna a 1 por omisin. 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 duracin de la tarea. 7. Despus de asignar todos los recursos a las tareas, presione clic. Si intenta eliminar una asignacin a una Tarea, seleccione la tarea, despus el nombre del recurso a eleiminar y presione la tecla Supr. 1. 2. 3. 4.
2.3 Costos Definicin y control de costos
Project multiplica el nmero de horas de un recurso y el valor de costo por hora para definir el costo total. Si se tienen mltiples recursos sus costos se suman. El nmero de unidades utilizadas refleja el costo de materiales. El mtodo 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 mtodo acumulativo adoptado es Comienzo. Cuando los pagos se hacen solo despus de Finalizada la tarea el mtodo 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.
Mtodo acumulativo
103
Agregar informacin 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 estndar, costo/uso, etc.) pestaas A, B, C, etc.
Asignar costos a un recurso
1. 2. 3. 4. 5.
6. 7. 8. 9.
Abra la hoja de informacin de recursos Abra la ventana de informacin de recursos (doble clic sobre l) Seleccione la pestaa Costos. La fecha efectiva del costo ser la misma que la fecha de inicio del proyecto. En caso contrario podr especificar una fecha distinta. Introduzca la tasa estndar . Para recursos de trabajo el valor por omisin est dado $ / h, (costo por hora) pero el tipo puede darse en /a, /m en caso de ser necesario. Para recursos materiales emplee la pestaa para especificar (galones o cajas). Para tasa horas extras se aplican los mismos criterios que el punto 3. Introduzca cualquier costo adicional en Costo/uso como envos o cualquier otro. Si sabe que los costos cambiarn en el transcurso del proyecto podr emplear otra pestaa para actualizar los costos. (B, C, D, o E modificando la fecha efectiva). Si los recursos tienen mtodos acumulativos distintos, seleccione la opcin de la lista de Acumulacin de costos.
Se permiten costos Fijos y Variables. Los Fijos no cambiarn 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. 2. 3. 4. 5. 6. Del men Formato|Detalles|Costos de recursos Seleccione la tarea y cambi su Tipo de Tarea a duracin fija. Introduzca el nombre del Recurso y escriba % en el campo Unidad. Presione Aceptar Introduzca los valores en el campo Costo. Presione Aceptar.
104
PRCTICA No. 2
1. Genere un banco de 10 recursos R1, R2, etc. 2. Cambie la capacidad mxima a unidades de asignacin a DECIMAL. 3. Asigne los recursos a las tareas de la siguiente manera: Tarea T1 T2 T3 T4 T5 T6 T7 Recurso R1, R2 R4 R3 R5,R6 R5,R9 R7,R8 R10
4. Modifique el tipo de tareas desactivando la opcin de que las tareas estn condicionadas por el esfuerzo 5. Asigne las siguientes unidades y trabajo a cada recurso: Recurso R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 Unidad 5 2 1 4 1 2 2 1 1 1 Trabajo 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 defnalos usted).
105
Capitulo 3
3.1 3.2 3.3
Formato de vistas Publicacin de Proyectos en la Web o Intranet Hipervnculo
106
3.1 Formato de Vistas
Existen una docena de vistas predeterminadas en Project, pueden modificarse en tamao o adecuarse a todas las necesidades. Se pueden seleccionar las escalas y el texto para darles un mejor formato, se pueden realizar acercamientos, etc. 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 tamao o el color El rea de escala temporal en una grfica 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 grfica 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 alineacin. Seleccione los valores deseados y presione aceptar.
Formato en Texto
Formato de escalas temporales
Formato de lneas gua
Cuando la informacin se despliega mediante lneas y columnas, el uso de lneas guas apropiado es importante para obtener una vista adecuada. Seleccione Formato|Cuadrcula... para abrir la ventana de lneas gua. Seleccione la lnea que se desea cambiar de la lista. En la seccin Normal seleccione el tipo y patrn de la lnea. Para emplear una lnea existente seleccinelo de la lista. Seleccione el Intervalo, Tipo y Color. En el seccin de Intervalo, seleccione ninguno para desplegar todas las lneas (o intervalo para algunas en especifico). 6. Presione aceptar. Siguiendo este mismo mtodo se puede dar formato a Tablas, Campos y Otras vistas.
1. 2. 3. 4. 5.
107
Impresin de vistas
Antes de imprimir una vista, es importante seleccionar el tipo de vista, modificar los formatos necesarios y cambiar orientaciones de pginas. Para modificar los parmetros de impresin de una vista activa, de una pgina o un archivo, deber desplegar la ventana de dialogo correspondiente. Para imprimir una grfica de Gantt 1. Puede elegir imprimir todas las columnas de una hoja de la grfica de Gantt que quepan en una pgina o especificar un nmero de columnas en varias pginas. 2. Se pueden imprimir las notas de las tareas en una pgina separada 3. Modifique la escala temporal para extender todo el margen derecho.
Impresin de reportes
Pueden imprimirse todos los reportes acerca de los distintos aspectos que controla project: Tareas criticas, Hitos, Das 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 impresin preliminar. 3. Presione Imprimir.
3.1 Publicacin de proyectos en WEB o Intranet
Al igual que en la gran mayora 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 hipervnculo Seleccionar una tarea especfica, recurso y asignacin empleando un mapa para Importar/exportar y publicarlo en un documento HTML. Ajustar el documento de HTML para incluir grficos. Dar seguimiento al proyecto mediante la comunicacin con el equipo va la Intranet corporativa.
108
Para guardar un proyecto como documento HTML: 1. Seleccione del men, Archivo|Guardar como HTML... 2. Haga clic en el botn Guardar 3. Aparecer la ventana que contiene el formato de exportacin. Este formato permite seleccionar el mapa que ser la base del documento. Este mapa de instrucciones especifica el tipo de informacin que se almacena en el documento. Project cuenta con 12 mapas predefinidos, pero almacena el documento con la extensin . html por omisin.
4. Desde la opcin Datos seleccionados marque Lista de tareas con filas de asignacin incrustadas y haga clic en el botn de guardar. Para ver el documento bralo en cualquier browser.
109
Adems de los 12 mapas definidos por project para crear uno propio y exportarlo, haga lo siguiente: Siga los pasos de 1-3 de la explicacin anterior Asignndole el nombre al documento de TareasCriticas . Seleccione el botn Nueva Equivalencia En la ventana de Definir equivalencia de campos de importacin exportacin, en la pestaa Opciones seleccione tareas 5. Seleccione la pestaa equivalencia de tareas. 1. 2. 3. 4.
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 Exportacin, seleccione Tareas Criticas. 8. Haga clic en el botn A partir de la tabla...
110
9. Seleccione programacin de la lista presentada y presione Aceptar para agregar todos los campos.
10. Presione el botn Guardar y podr ver el documento en cualquier Browser.

Desplegar la grfica de Gantt en una pgina Web
1. Seleccione la vista de la grfica de Gantt en la barra estndar, haga clic en el botn de copiar la imagen. 2. Seleccione el formato GIF. 3. En la seccin de escala temporal, seleccione los rangos de fechas o la opcin 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 ubicacin. 6. En la ventana para exportar seleccione el archivo de mapa a modificar y haga clic en Editar. 7. En la pestaa de Opciones, seleccione la opcin de Incluir archivo de imagen en la pgina HTML. 8. Agregue la trayectoria 9. Grabe el documento
111
3.3 Hipervnculo
Los campos de hipervnculos permiten navegar hacia otro documento o sitio Web desde su proyecto. Se pueden agregar hipervnculos a tareas, recursos o asignarlas en cualquier vista. 1. Abra una vista 2. Seleccione la tarea, recurso o asignacin a la que se desea agregar un vnculo, del men en Insertar|Hipervculo... abra la ventana
Para agregar un hipervnculo
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 informacin permitir acceder al documento directamente desde el proyecto
112
Anexo B: Prcticas Rational Rose
113
Gua de Prcticas Diagramas de UML en Rational Rose
Actividad 1
a) Con el botn derecho del ratn 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 recin creado haga click con el botn derecho y cree dos nuevos paquetes que se llaman Ventanas y Editor, estos se crearn como paquetes dentro del paquete Actividad 1. c) Repita la operacin anterior y cree los subpaquetes Motif y MSWindows como subpaquetes de Ventanas y Controlador, Dominio, Elementos, Ncleo Motif, Ncleo 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). para ir al diagrama padre o al diagrama anterior, Consejo: Utilice los botones respectivamente.
E dit or
V entanas
Figura 1.1: Diagrama Actividad 1
114
Motif
MSWindows
Figura 1.2: Diagrama Ventanas
Co n tro l a d o r E l e m e n to s
Do m i n i o N cl e o Wi n d o ws
N cl e o M o ti f
MS W indow (fro m V e n ta n a s) M o ti f (fro m V e n ta n a s)
Figura 1.3 Diagrama Editor
115
Actividad 2
a) Estando en el navegador sobre el paquete de la Vista de Casos de Uso, con el botn derecho
del ratn haga new-package y cree un paquete que se llame Actividad 2.

b) Con el botn derecho del ratn y estando en el navegador sobre el paquete recin 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.
Reintegro Cuenta Corriente
<<include>>
Cliente
Verificar Operacin <<include>>
Reintegro Cuenta de Crdito
Observaciones: Los estereotipos se introducen en la especificacin del smbolo de generalizacin (hacer doble clic sobre el smbolo para abrir su especificacin) La opcin Navigable establece la direccin en una asociacin (puede habilitarse o deshabilitarse con el botn derecho sobre el smbolo)
116
Actividad 3
a) Estando en el navegador sobre el paquete de la Vista de Casos de Uso, con el botn derecho del ratn haga new-package y cree un paquete que se llame Actividad 3. b) En el paquete recin 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.
Cliente
Reintegro
Observacin: Puede arrastrar el actor Cliente desde el paquete Actividad 2. c) Con el botn derecho del ratn 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 tarjeta
:Cajero automtico
:cuenta
solicitar nmero secret o nmero
solicitar cantidad cantidad realizar transaccin(cantidad) saldo insuficiente saldo insuficiente
Figura 3.2: Diagrama Reintegro Saldo Insuficiente

117
d) Haga Browse-Create Collaboration Diagram para obtener automticamente el Diagrama
de Colaboracin asociado.
118
Actividad 4
a) Crear el paquete Actividad 4 en la Vista Lgica. b) Dentro de este paquete crear las clases: avin, motor, avin militar, avin comercial, vuelo, piloto, reserva, lnea area, avin de carga, avin de pasajeros, vendedor de billetes. c) Cree dentro de la Actividad 4 el Diagrama de Clases Actividad 4, mostrado de la Figura 4.1.
Motor 1..4
Piloto 1..2
Vendedor de billetes 1
1 Avin 1 n
n Vuelo n 1 n
n Reserva
{ disjunta, completa }
1 Avin militar Avin comercial Lnea area
Avin de carga
Avin de pasajeros
119
Actividad 5
a) En la Vista Lgica 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 segn lo mostrado en la Figura 5.1.
Alumno DNI : char[10] nmero_exp : int nombre : char[50] alta() poner_nota(asignatura : char *, ao : int, nota : float) matricular(cursos : asignatura, ao : int) listar_expediente()
Observacin: Pregunte al profesor si no consigue onbtener la presentacin mostrada en la Figura 5.1.
120
Actividad 6
a) En la Vista Lgica 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 ascielas tal como se muestra en la Figura 6.1. c) Modifique la visibilidad de los roles eligiendo entre Pblico (+): el rol es visible fuera del mbito del paquete y puede referenciarse en otras partes del modelo; Implementacin (sin smbolo asociado): visible slo 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.
Departamento
depto
rea_conocimiento : char * dirige
profesores 0..* director
Profesor
0.. 1
121
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 asociacin entre Empresa y Empledo, mostrada en la figura 7.1.
empleador * trabajadores 1..*
Empresa
Empleado
Cargo nombre sueldo subordinado 1..*
superior 0..1
Observacin: Use el smbolo de la barra de herramientas denominado Link Attribute para enlazar la clase Cargo con la asociacin entre Empresa y Empleado.
122
Actividad 8
a) Cree el paquete Actividad 8. b) Cree en el navegador las clases: Trabajador, Directivo, Administrativo, Obrero, Vehculo, Vehculo impulsado por viento, Vehculo Terrestre, Vehculo impulsado por motor, Vehculo acutico, Camin, Velero, Cuenta, Cuenta rentable y Cuenta no rentable. c) Cree el Diagrama de Clases llamado Actividad 8.1 segn se muestra en la Figura 8.1. d) Repita la operacin para las Figuras 8.2 y 8.3.
Trabajador
Directivo
Administrativo
Obrero
Figura 8.1: Diagrama Actividad 8.1
Vehculo acutico
VehculoTerrestre
medio Velero Vehculo Camin impulsado por
Vehculo impulsado por viento
Vehculo impulsado por motor
123
Cuenta
{ dis junt a, incompleta } saldo_medio > 1000
saldo saldo_medio < 500
Cuenta rent able
Cuenta no rentable
124
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 Transicin de Estados de la Figura 9.2. Para ello, desde el navegador seleccionando la clase en cuestin y con el botn derecho del ratn escoja la opcin Open State Diagram.
Socio nmero : int nombre : char[50] nmero_prestamos : int = 0 alta() baja() prestar(cdigo_libro : int, fecha : date) devolver(cdigo_libro : int, fecha : date)
alta
baja nmero_prstamos = 0
sin prstamos
prestar
devolver[ nmero_prs tamos = 1 ]
nmero_prst amos > 0 c on prst amos pres tar devolver[ nmero_prstamos > 1 ]
Figura 9.2: Diagrama de Estados

125
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 relacin de dependencia entre componentes viene dado porque un componente usa las facilidades de otro. Esto se reduce a dependencias de compilacin 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, comunicacin va satlite, etc. Un Processor representa hardware con capacidad de computacin. Un Device incluye dispositivos hardware como terminales, modems, etc.
Int erfaz de Terminal
Control y Anlisis
Gest in de Cuentas
Rut inas de Conexin
Acceso a DB
Figura 10.1
126
Servidor Cent ral
Gestor de Datos
Punto de Venta
Terminal de Venta
Figura 10.2
127
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
V entas
Inventario
C ontabilidad
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 botn derecho sobre el diagrama llamado Main bajo el paquete Ventas renmbrelo 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.
128
Supervisor
Verificar Situacin del Cliente
Administrativo
Preparar Catlogo
Sistema Inventario
Realizar Venta
Figura 11.2: Diagrama Ventas
Venta Normal
Vendedor
Venta de Rebaja
Venta de Oferta
Figura 11.3: Diagrama Realizar Venta
En los D. de Casos de Uso no existe el concepto de explosin tal como se tiene en los DFDs (Diagramas de Flujo de Datos). La funcionalidad representada por un caso de uso es atmica (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 jerrquica un modelo, y en este caso, un paquete puede tener asociado un nuevo diagrama.
129
Figura 11.4: Estado de la Prctica al terminar el paso f)
g) Documente los casos de uso Venta Normal, Venta Rebajas, Venta Ofertas a partir de la informacin siguiente, presentada en tres estilos distintos (secuencia de pasos, condiciones pre-post de la aplicacin del caso de uso y, por ltimo descripcin 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 cdigo 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 artculos mediante un lector de cdigo de barras o directamente por teclado. Pueden ser varios artculos en una misma venta. 6. El vendedor solicita la emisin del recibo 7. El sistema imprime el recibo Haga doble click sobre el caso de uso Venta Normal del diagrama y en la pestaa Files con el botn derecho realice Insert File, asociando el fichero word recin creado. 130
Venta en Oferta Haciendo doble click en el caso de uso Venta en Oferta y dentro del cuadro denominado documentacin, introducir: Precondiciones - Los artculos de la venta deben estar en oferta - El pago debe hacerse en efectivo - El artculo debe tener el suficiente stock para satisfacer la venta Postcondiciones - El stock del artculo 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 documentacin (bajo el browser) el siguiente texto: En el periodo de rebajas los precios tienen una disminucin de precio tanto de forma individual como por grupos de artculos. Los descuentos se detallan en la correspondiente tabla de descuentos por grupo.
131
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 denomnelo Prestar con xito. Arrastre desde el navegador el actor Encargado y complete el Diagrama de Secuencia segn lo mostrado en la Figura 12.2. Los objetos utilizados en este diagrama son annimos, es decir, slo se indica la clase a la cual pertenecen, pero no se les asigna un nombre especfico. d) Deshabilite la opcin Focus of Control en Tools-Options-Diagrams y observe el efecto. e) Cree el Diagrama de Colaboracin asociado al Diagrama de Secuencia dibujado mediante Browse-Create Collaboration Diagram. La Figura 12.3 muestra el diagrama de colaboracin que se debe obtener.
: Encargado
: WInP rstamos
:Socio
:Video
: Prstamo
prestar(video, socio) verificar situacin socio verificar situacin video registrar prstamo entregar recibo
132
Figura 12.2: Diagrama Prestar con xito
:Socio
:Video 2: verificar situacin socio
1: prestar(video, socio) :WInPrstamos 5: entregar recibo : Encargado
3: verificar situacin video
4: registrar prstamo
:Prstamo
Figura 12.3: Diagrama Obtenido a partir del Diagrama Prestar con xito
133

Manual Ads1 PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Manual Ads1 PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Tabla de Contenido

Universidad Tecnolgica de Jalisco Manual de Anlisis y diseo I

Academia de Ingeniera de Software Ana E. Romo Gonzlez

Universidad Tecnolgica de Jalisco Manual de Anlisis y diseo I

Academia de Ingeniera de Software Ana E. Romo Gonzlez

2 Introduccin a los sistemas de informacin e ingeniera de SW

Contina en la siguiente pgina

Universidad Tecnolgica de Jalisco Manual de Anlisis y diseo I

Tipos comunes de sistemas, Continuacin

Academia de Ingeniera de Software Ana E. Romo Gonzlez

Conceptos de anlisis y diseo de sistemas

Contina en la siguiente pgina

Universidad Tecnolgica de Jalisco Manual de Anlisis y diseo I

Conceptos de anlisis y diseo de sistemas, Continuacin

Academia de Ingeniera de Software Ana E. Romo Gonzlez

Ingeniera de SW Fritz Bauer

Atributos esenciales de un buen SW

Universidad Tecnolgica de Jalisco Manual de Anlisis y diseo I

Capas de la ingeniera de software

La ingeniera de SW es una tecnologa multicapa

herramientas mtodos proceso Un enfoque de calidad

Fases genricas de la Ingeniera de SW

Contina en la siguiente pgina

Academia de Ingeniera de Software Ana E. Romo Gonzlez

Fases genricas de la ingeniera de SW, Continuacin

Durante el proceso de mantenimiento encuentran cuatro tipos de cambios:

Universidad Tecnolgica de Jalisco Manual de Anlisis y diseo I

Gestin de reutilizacin Mediciones Gestin de riesgos

Marco de trabajo comn del proceso

El proceso del software

1. El modelo lineal secuencial

Ingeniera de sistemas/ informacin Anlisis Diseo Cdigo Prueba

Ingeniera y modelado de sistemas/informacin

Universidad Tecnolgica de Jalisco Manual de Anlisis y diseo I

Modelo lineal secuencial, Continuacin

Generacin de cdigo Pruebas

Desventajas del modelo lineal secuencial

Academia de Ingeniera de Software Ana E. Romo Gonzlez

Modelos de procesos de SW, Continuacin

El cliente aprueba la maqueta

Contina en la siguiente pgina

Universidad Tecnolgica de Jalisco Manual de Anlisis y diseo I

El modelo de construccin de prototipos, Continuacin

Modelado de procesos Generacin de aplicaciones

Modelado de procesos Generaci n de aplicacion es

Contina en la siguiente pgina

Fases del modelo DRA , Continuacin

Generacin de aplicaciones Pruebas y entrega

Desventajas del modelo DRA

Contina en la siguiente pgina

Universidad Tecnolgica de Jalisco Manual de Anlisis y diseo I

El modelo incremental, Continuacin

Ingeniera de sistemas/ informacin

Contina en la siguiente pgina

Academia de Ingeniera de Software Ana E. Romo Gonzlez

El modelo incremental, continuacin

Contina en la siguiente pgina

Universidad Tecnolgica de Jalisco Manual de Anlisis y diseo I

El modelo en espiral, Continuacin

Construccin y adaptacin Evaluacin del cliente

Academia de Ingeniera de Software Ana E. Romo Gonzlez

Caractersticas del cliente

Condiciones del negocio