Análisis y Diseño de Sistemas de Información

Temario

Temario

• • • •

• • • • •

Ingeniería de Software Estructuras de Objetos Diagramas Estáticos • Diagramas de Clases • Diagramas de Casos de Uso Diagramas Dinámicos • Diagramas de Estado • Diagramas de Actividades • Diagramas de Secuencias • Diagramas de Colaboración Diagramas de Implementación • Diagramas de Componentes • Diagramas de Distribución Casos de estudio Patrones de Diseño Metodologías Ing. y M.A. Francisco Javier Mariscal Flores fmarisc@uach.mx

Instructor

Analisis.ppt

Pag. 1

Análisis y Diseño de Sistemas de Información

Bibliografía

Bibliografía

Using UM with obje
Analisis.ppt
Pag. 2

Análisis y Diseño de Sistemas de Información

Ingeniería de Software

¿Qué es un BUEN SISTEMA?

Un buen sistema (o uno de alta calidad) es aquél que cumple con las necesidades del cliente. El sistema debe ser:
• UTIL y UTILIZABLE: Un buen software hace más fácil o mejor la vida a las personas. • CONFIABLE: Un buen software tiene pocos errores. • FLEXIBLE: Las necesidades cambian con el tiempo, aún cuando el software se está

desarrollando, entonces es importante poder hacer cambios posteriores al software. Debe podérsele dar mantenimiento después de liberado. • ACCESIBLE: tanto para comprar como para mantener. Debe ser razonablemente fácil y rápido poderlo desarrollar o darle mantenimiento. • DISPONIBLE: De otra forma no importa que tan bueno es. Debe ser capaz de ejecutarse el el hardware disponible y con el sistema operativo disponible, etc. Debe existir y entregarse el software prometido.

¿Tenemos buenos sistemas?

Existen avances satisfactorios en sistemas de software modernos: contabilidad, bancos, búsqueda de información, etc. Lo que indica que estamos haciendo las cosas correctamente.

Analisis.ppt

Pag. 3

ÚTIL. CONFIABLE O DISPONIBLE. Generalmente.Análisis y Diseño de Sistemas de Información Ingeniería de Software • Problemas: • • • • • • • Hay sistemas que no cumplen con las necesidades de los usuarios y/o tienen fallas técnicas. los sistemas no están actualizados ni cuando se están diseñando. 4 .ppt Pag. La falta de FLEXIBILIDAD también resulta evidente. La COSTEABILIDAD se relaciona mucho con la confiabilidad y la flexibilidad debido a que el costo de corregir y mantener es el más alto costo asociado con el software Analisis. La mayoría de los usuarios de PCs esperan que sus aplicaciones y aún el sistema operativo se “caiga” o “congele” de vez en cuando. Aún existe el “error de la computadora” como excusa a un mal servicio a los clientes. EL SOFTWARE NO SIEMPRE ES UTILIZABLE. como lo muestran el problema del milenio y la adecuación de todos los sistemas viejos (legacy) a procesos de negocios cambiantes.

ppt Pag. no permitía al aeropuerto abrir a tiempo. Sep. • 25% de los proyectos grandes son cancelados Analisis. dice: • En promedio. los proyectos grandes toman 50% más de tiempo de lo planeado. • A veces las fallas en algunos de los atributos deseables de los sistemas han provocado catástrofes como las siguientes: • Ariane 5: Fallas de software hacen explotar la nave (1996) • Taurus: Mercado accionario londinense no pudieron terminar proyecto de software y tuvieron grandes pérdidas (1993) • Manejo de maletas de Denver: Fallas del sistema y el alto costo de corregirlo. Wayt Gibbs en Software’s chronic crisis. 5 . • 75% de los proyectos grandes tienen fallas operacionales. Scientific American (International Ed.Análisis y Diseño de Sistemas de Información Ingeniería de Software • Problemas aún más drásticos.) pp 72-81. 1994. • Sistema de Ambulancias de Londres: Fallas de diseño y de ejecución provocaron la muerte de gente por falta de ambulancias (1992) • Therac-25: Sobredosis radioactivas por fallas en el software de la máquina a varias personas (1987) • Según W.

la modularidad y la encapsulación fueron conceptos clave en el diseño del lenguaje. el cual soportaba lo mejor de los conceptos de análisis. Brooks (The mythical man-month. Cuando un proyecto empieza a quedarse atrás en el tiempo. El Departamento de Defensa de EU. 6 . AddisonWesley 1975/1995). diseño y programación estructurados. intentó resolver la crisis del software y comisionó el diseño del lenguaje de programación ADA. mientras más grande sea el proyecto. mayor será la proporción del costo y tiempo del proyecto gastado en la comunicación entre la gente del proyecto. Según Frederick P. el cual se estandarizó en 1983. porque cada persona tiene más gente con quién comunicarse.Análisis y Diseño de Sistemas de Información Ingeniería de Software • Promesas. Todos lo dudamos. Analisis.ppt Pag. pero aún esta enorme inversión ha fracasado. el poner más gente por lo general falla. promesas • • • • Cada nueva tecnología promete reducir los tiempos de desarrollo e incrementar los promedios de éxito de los proyectos.

en un lenguaje orientado a objetos.Análisis y Diseño de Sistemas de Información Ingeniería de Software • ¿Cómo son los sistemas considerados buenos? • • • El problema fundamental para comprenderlos es: • Hay un límite de cuánto puede entender un humano en un momento dado Los sistemas pequeños. En el sentido más general. 7 .. son realizados mediante “programación heroica” en la cual una sola persona pretende recordar todo lo relevante acerca del sistema. un módulo puede ser cualquier “bit” identificable de un sistema por lo cual tiene sentido considerarlo en forma separada. Si el GOTO esta eliminado. esto se facilitaría porque no habría “código espagueti” • 2.Un sistema es un conjunto de módulos y existen algunas dependencias entre ellos. La evolución del entendimiento de un problema seria como sigue: • 1. Pero en general esto es imposible.ppt Pag.. • Otras partes conocidas como módulos o similares • Programas o subsistemas independientes o semi-independientes. Analisis. Los módulos pueden ser: • Archivos • Subrutinas • Funciones de biblioteca • Clases.Los sistemas son muy complejos y no se puede centrar solo en el código cercano al cambio por realizar sino que se debe entender partes más lejanas.

La dependencia es conocida a veces como acoplamiento. Un sistema con muchas dependencias tiene un acoplamiento grande. Los sistemas buenos tienen un acoplamiento bajo.ppt Pag.) • • • Características de los módulos para que el desarrollo y mantenimiento del sistema sea lo más fácil. barato y confiable posible: • dependencia (dependency) • acoplamiento (coupling) Bajo • cohesión (cohesion) Alta • interfase (interface) Definida • encapsulación (encapsulation) Módulos • abstracción (abstraction) Alta cohesión • Componente (component) Insertable.Análisis y Diseño de Sistemas de Información Ingeniería de Software • ¿Cómo son los sistemas considerados buenos? (cont. 8 . porque los cambios a una parte del sistema son menos propensos a propagarse a través del sistema Analisis. reusable El módulo A depende del módulo B si un cambio en el módulo B significa que el módulo A también necesita ser modificado.

9 ... Analisis. nos permitirá conocer que clase de cambios a un módulo pueden ser peligrosos (servicios que provee?) • 2. Una vez que las fronteras entre los módulos de nuestro sistema están definidas. Nos gustaría tener certeza sobre los cambios. nos dice cuáles módulos tendrán que cambiar. hay dos clases de información que puede ser útil: • 1. Para tomar ventaja del acoplamiento bajo de un sistema.¿Qué suposiciones de un módulo dado pueden los clientes hacer acerca de él? Contestando. es importante ser capaz de identificar cuales módulos están acoplados. si hacemos un cambio peligroso a un módulo.Análisis y Diseño de Sistemas de Información Ingeniería de Software • Encapsulamiento: Acoplamiento bajo • • • • Queremos minimizar el numero de casos en los cuales un cambio a un módulo genera un cambio en otro módulo. lo cual es un costo aún cuando no fue necesario el cambio. Tenemos que conocer cuales cambios dentro de un módulo pueden afectar el resto del sistema.¿Cuáles módulos son clientes de un módulo dado? Contestando. de otra forma se tendrá que gastar esfuerzo verificando si hay que hacer cambios a un módulo.ppt Pag.

y también de que el módulo siempre justifica las suposiciones que están documentadas. El resto del sistema solo puede usar el módulo en formas permitidas por las interfases. una interfase ENCAPSULA el conocimiento acerca de los módulos. mientras más permita que esas verificaciones sean automáticas. este cambio no necesitará otros cambios en otras partes del sistema”. Si documentamos bien todas las suposiciones en la interfase.) • Interfases • Una interfase a un módulo define algunas características del módulo • sobre las cuáles sus clientes pueden depender. 10 • • • • Analisis. Pag. “Las conexiones entre módulos son las suposiciones que hacen los módulos unos acerca de otros” Cualquier suposición que un cliente hace acerca de un servidor corre el riesgo de ser incorrecta. esto es. se dice que más soporta la modularidad y la encapsulación. En un lenguaje de programación.ppt . Idealmente debería haber una verificación automática de que otros módulos no hacen suposiciones que no están documentadas en esta interfase.Análisis y Diseño de Sistemas de Información Ingeniería de Software • Encapsulamiento: Acoplamiento bajo (Cont. seremos capaces de decir: “Si un módulo cambia internamente sin cambiar su interfase. entonces debemos documentar tales suposiciones en interfases y verificar su validez.

qué características están documentadas en las interfases de los módulos del sistema) sino también qué dependencias existen realmente. Analisis. entonces es importante ser capaz de decir cuáles son ellos. el módulo puede garantizar que si ciertas interfases le son provistas. Ellos pueden a su vez ser expresados en términos de interfases. las dependencias de contexto de un módulo y la propia interfase del módulo garantiza que proveerá los servicios descritos en su interfase. • Sabemos que un cambio en un módulo puede afectar a sus clientes. • Entre ellos. sus clientes (por definición) son aquellos módulos que pueden necesitar un cambio.) • Dependencias del contexto • Existen varias razones para querer conocer no solo qué dependencias pudieran existir (esto es.Análisis y Diseño de Sistemas de Información Ingeniería de Software • Encapsulamiento: Acoplamiento bajo (Cont. 11 . entonces él a su vez proveerá sus propias interfases.ppt Pag. Los servicios que un módulo requiere son llamados sus dependencias de contexto. Es necesario saber no solo qué servicios provee (cual es su interfase) sino también qué servicios requiere para trabajar. • Suponga que quiere reusar un módulo.

Solo entonces se pueden lograr los beneficios completos. entonces serían más productivos. • El reto real. es definir buenos módulos con las cosas correctas en sus interfases. Analisis. solo deberá entender la interfase del módulo. • Los errores deberán ser más fáciles de encontrar (en desarrollo y mantenimiento). • Debido a que los desarrolladores pueden ignorar en forma segura algunos aspectos del sistema. con documentación de lo que provee y lo que requiere.) • Beneficios de la modularidad con interfases definidas.ppt Pag. la gente desarrollando código que usa un módulo. Porqué? • Cualquier elemento que reduzca lo que tiene que ser conocido acerca de un módulo es benéfico en varias formas: • En un equipo de desarrollo. 12 . tendrán un mejor entendimiento de los aspectos que sí necesitan conocer. no cómo trabaja. porque se evitará el examinar módulos irrelevantes. entonces se introducirán menos errores.Análisis y Diseño de Sistemas de Información Ingeniería de Software • Encapsulamiento: Acoplamiento bajo (Cont. es posible considerar reusarlo. • Una vez que existe un módulo. • Aún una interfase muy pobre para un módulo incorrectamente seleccionado puede hacer a un sistema más fácil de entender y modificar.

) • Un módulo puede tener varias interfases • A veces es necesario documentar los servicios que un módulo provee con varias y diferentes interfases.ppt Pag. • Ya tenemos una respuesta parcial a la pregunta de ¿Cómo son los sistemas considerados buenos? • Un buen sistema consiste de módulos encapsulados Analisis.Análisis y Diseño de Sistemas de Información Ingeniería de Software • Encapsulamiento: Acoplamiento bajo (Cont. 13 . Esto es a la vez útil para el mantenimiento y para el reuso. de un modo que podamos ser más precisos acerca de que servicios un cliente dado necesita.

El desarrollador está protegido de información irrelevante acerca de cómo el módulo hace lo que hace. Tales módulos se dice que tienen una alta cohesión. • • Si un módulo.Análisis y Diseño de Sistemas de Información Ingeniería de Software • Abstracción: Alta Cohesión. Esta preocupación de permitir al desarrollador concentrarse en lo esencial es ligeramente diferente a la preocupación de encapsulación para lograr un acoplamiento bajo. Encapsulación es cuando un cliente de un módulo no es capaz de conocer más de lo que está en la interfase. Abstracción es cuando un cliente de un módulo no necesita saber más de lo que está en la interfase.ppt Pag. o de reemplazo en sistemas ya existentes. lo cual va dirigido a la prevención de que el desarrollador use información escondida. dejando una figura coherente de lo que el usuario de un módulo quiere conocer. • • • • • Los buenos módulos tienen la propiedad de que sus interfases proveen una abstracción de alguna cosa que se entiende intuitivamente la cual sin embargo puede ser compleja de implantar. es una buena abstracción (tiene una alta cohesión y un acoplamiento bajo) puede ser factible de reusarlo en posteriores sistemas. de cualquier tamaño y complejidad. Estaríamos hablando de un componente insertable o conectable (“pluggable component”) Analisis. 14 . La interfase realiza una abstracción de las cosas que el desarrollador no tiene que entender para usar el módulo.

la tecnología orientada a objetos iba a ser la solución a la crisis en desarrollo de software. • Los factores técnicos involucran decisiones de arquitectura y más alto nivel. 15 . • Ejemplo de un factor no técnico de reuso: Recompensar al programador por el número de líneas que escriben. Component Based Development) • Un módulo con propiedades que lo hacen reusable y reemplazable. En los 80s y principios de los 90s.ppt Pag. • ¿Qué determina cuando un módulo es reusable? • Tiene una cohesión alta • Acoplamiento bajo con el resto del sistema • Interfase bien definida • Abstracción encapsulada de una cosa bien entendida • Si un módulo es reusable depende del contexto en que se desarrolló y en el cual va a ser reusado.Análisis y Diseño de Sistemas de Información Ingeniería de Software • Arquitectura y componentes • • • • La arquitectura donde se desarrolla y aquella dónde se va a usar. Componente • Es una cosa que se puede reusar o reemplazar Desarrollo Basado en Componentes (CBD. Analisis.

conectabilidad (pluggability) • • • • • La forma ideal de construir un nuevo sistema es tomar algunos componentes existentes y juntarlos.ppt Pag. Los componentes tienen que ser partes que llenan o cumplen necesidades en un sistema completo. 16 . • Son afectadas por la naturaleza de los componentes en la arquitectura • Pueden ser influenciadas por el medio ambiente del proyecto Analisis. Pluggability es la propiedad que tienen los componentes de poder ser juntados. Las decisiones importantes acerca de la arquitectura: • Deben ser tomadas lo más pronto en el proyecto. Las partes tienen que ser compatibles unas con otras y eso depende de la presencia de una arquitectura adecuada.Análisis y Diseño de Sistemas de Información Ingeniería de Software • Diseño basado en componentes: Insertabilidad.

Analisis. cada una de las cuales tiene un PRODUCTO FINAL (puede ser un documento o tal vez un prototipo) Preocuparse por cumplir con un conjunto claro de requerimientos. Hacer un uso sensible de herramientas. que se definen tan pronto como sea posible Preocuparse por formas de verificación y validación. tan esenciales como construir el producto en sí mismo. ARQUITECTURAS y COMPONENTES relevantes.Análisis y Diseño de Sistemas de Información Ingeniería de Software • ¿Cómo se construyen los buenos sistemas? • • • • • Usar un PROCESO definido con FASES claras. 17 . Usar un almacén de CONOCIMIENTOS.ppt Pag.

. 18 Analisis. Ivar Jacobson se unieron para formar el Lenguaje de Modelación Unificado (UML) y fue adoptado por el Object Management Group (OMG) como el estándar para cuestiones orientadas a objetos. • Gran cantidad de metodologías orientadas a objetos han salido a la luz y las de Grady Booch. • 2. Evaluaciones frecuentes ayudan a corregir.Cada vez que se toma una decisión se tiene el riesgo de que sea incorrecta. • Espiral de desarrollo: Construcción Diseño Transición Análisis • Metodología Unificada.. • Administración de riesgos implica: • 1. Pag. Supone que no se vuelve a entrar en las fases terminadas.Análisis y Diseño de Sistemas de Información Ingeniería de Software • Proceso de desarrollo • Método tradicional para el desarrollo de Sistemas Análisis Diseño Implementación Pruebas Mantenimiento • Cada fase se realiza hasta que se completó la anterior. James Rumbaugh.Un riesgo mayor es que los desarrolladores malinterpreten los requerimientos. Mientras más se tarde en detectar un error más difícil es corregirlo. La elaboración de prototipos permite reafirmarlos.ppt .

Rational Unified Process. etc.Análisis y Diseño de Sistemas de Información Ingeniería de Software • Proceso de desarrollo (cont. identifica todos los riesgos significantes. Analisis. • En la fase de construcción: • El comienzo proporciona el compromiso del patrocinador del proyecto de seguir adelante se conoce el caso de negocios y su factibilidad y alcance básicos. • La construcción termina con una versión beta del sistema. • Los procesos iterativos deberán tener un plan de que serán las iteraciones y que será cubierto por cada una de ellas.ppt Pag. • Otros procesos han adoptado UML como su lenguaje de modelación: Catalysis. entendimiento cabal de los mayores riesgos para no estar preocupados. 19 .) • Procesos donde utilizar UML. • La elaboración da la arquitectura básica de el sistema. un plan para el acuerdo de construcción. • Transición es el proceso de introducir el sistema a sus usuarios.

ppt . Pag. la cuál necesita ser soportada por el sistema. Sist. pero generalmente se omite. Normalmente un caso de uso es un proceso relativamente largo. no un paso individual o transacción. 20 Analisis.Análisis y Diseño de Sistemas de Información Diagramas Estáticos • Casos de Uso • • Es una colección de situaciones que ocurren cuando un actor usa un sistema para completar un proceso. de Información de Biblioteca Recursos para Prestamo Agregar recursos Regresar Recursos Bibliotecario Usuario • • En las etapas iniciales de desarrollo del proyecto. o una unidad coherente de funcionalidad. Involucrando las fronteras del sistema para un conjunto de casos de uso y definiendo las líneas de comunicación entre un actor particular y el caso de uso. Una vez identificado los casos de uso se pueden crear diagramas de casos de uso para colocar el caso de uso en contexto. Cada caso de uso necesita representar una tarea. Cuando se tienen varios subsistemas es común dibujar la frontera del sistema. Se puede afinar los diagramas en etapas posteriores para reflejar las interfases de usuario y los detalles de diseño. los diagramas de casos de uso describen las actividades del mundo real y las motivaciones.

entonces éste es el actor que corresponde.. varían: 1.. por necesitar de dicho archivo. cuando quien inicia el contacto es otro sistema. Si requiere acceso a Reuters se debería indicar.Análisis y Diseño de Sistemas de Información Diagramas Estáticos • Casos de Uso (cont..Algunas personas consideran que solo se deben mostrar los actores del sistema cuando ellos sean los que necesiten el caso de uso.) • Interacciones con sistemas externos: • Las opiniones de incluir a los sistemas externos como casos de uso o no. Si se genera un archivo cada noche que después es recogido por el sistema de contabilidad.Otros más sienten que constituye un enfoque equivocado considerar que un sistema es un actor.Algunos sienten que todas las interacciones con sistemas remotos deben aparecer en el diagrama. 3. Contabilidad solo se mostraría si dicho sistema invocara algún proceso que le dijera al sistema fuente que lo hiciera.Algunas personas consideran que sólo se deben mostrar los casos de uso con una interacción externa.. 4. Analisis. 21 . 2.ppt Pag.

Análisis y Diseño de Sistemas de Información Diagramas Estáticos • Casos de Uso (cont. Una relación de comunicación entre un actor y un caso de uso no significa que alguien en ése rol necesariamente tenga que estar involucrado en sacar la tarea adelante. Analisis. como otros a sistemas o en algunos casos se pueden identificar diferentes dispositivos externos al sistema. en vez de representar a alguien en individual. dependiendo de las circunstancias. solo significa que puede estarlo.) • • • • Un actor en un caso de uso representa un rol que alguien debe jugar. 22 . Actores no humanos.ppt Pag. El beneficiario de un caso de uso es un actor para el que el caso de uso tiene algún valor. Se puede diferenciar entre quienes necesitan el caso de uso y quienes están involucrados con él sin obtener ningún beneficio.

para eliminar el riesgo más grande aún cuando tengamos contingencias para poderlas eliminar y no que quedemos atorados en un diseño que no nos permita manejar los casos de uso más riesgoso.ppt Pag. Analisis.) • Utilización de los casos de uso. es necesario hacer una lista de los casos de uso del sistema. • Validación del Sistema. • Aspectos técnicos. • Los casos de uso sirven a capturar los requerimientos al proporcionar una forma • estructurada de: • Identificar a los actores • Para cada actor encontrar qué necesitan del sistema (qué casos de uso tienen valor para ellos) y encontrar cualquier otra interacción que esperen tener con el sistema. • Planeación. • Aspectos políticos. Debemos sacar adelante primero los casos de uso con mayor riesgo. Casos de uso a través del desarrollo. junto con: • Una buena idea de lo que significa cada uno • Entender quién quiere cada uno y qué tanto lo desea. • Conocer cuál caso de uso acarrea más riesgo • Un plan de que tanto tomará implementar cada caso de uso. Antes de que se haga un proceso de estimación y planeación para el proyecto completo. Tomar cada caso de uso y verificar que el diseño permitirá completarlo. igualmente se deben diseñar pruebas para cada caso de uso. Recuerde que el 25% de los sistemas nunca se terminan. Debemos poder demostrar que el sistema hace algo útil primeramente para la gente más influyente. 23 .Análisis y Diseño de Sistemas de Información Diagramas Estáticos • Casos de Uso (cont.

• Peligro de equivocar el diseño de los requerimientos. 24 . Por ejemplo al equivocar el involucramiento de actores en casos de uso que no los benefician. Se puede minimizar el error al hacer paralelamente el análisis de casos de uso y el modelado conceptual de clases. • Perder requerimientos si se pone mucha confianza en el proceso sugerido de encontrar los actores y luego encontrar los casos de uso que necesita cada actor. Es importante que los desarrolladores distingan entre requerimientos de diseño y candidatos. difíciles de mantener e inflexibles. Analisis.) • Posibles problemas con los casos de uso. podemos perder de vista la arquitectura del sistema y la estructura de objetos estáticos.Análisis y Diseño de Sistemas de Información Diagramas Estáticos • Casos de Uso (cont. podemos terminar desarrollando sistemas top-down orientados a funciones. Para evitarlo debemos administrar correctamente el inicio de cada etapa.ppt Pag. Al enfocarnos en casos de uso. • Peligro de construir sistemas no orientados a objetos. si la etapa previa dejó alguna situación insatisfactoria deberá volverse a producir.

• La inclusión permite volver a utilizar los pasos de un caso de uso dentro de otro Recolectar dinero «incluir» Exhibir el interior «incluir» Cubrir el interior • Al reusar los casos de uso se tienen las siguientes ventajas: o evitar duplicidades. 25 • Buena forma de registrar la conveniencia de se usara un componente . • Al hacer en forma externa partes del caso de uso puede hacerlo más corto y fácil de entender • Al identificar funcionalidad en común entre los casos de uso al principio puede ser una forma de descubrir la posibilidad de reusar un componente que implemente la funcionalidad compartida. • Sin embargo se tienen las siguientes desventajas: • Peligro de buscar funcionalidad y al hallarla fomentar la elaboración de un sistema basado en funciones.ppt Pag.Análisis y Diseño de Sistemas de Información Diagramas Estáticos • Casos de Uso (cont. • Es difícil para alguien no adiestrado en UML entender la notación de «incluir» Analisis.) • Relaciones entre casos de uso. top-down con sistemas inflexibles.

permite crear un caso mediante la adición de pasos a uno existente.) • La extensión. 26 . Se dice que el nuevo caso de uso extiende al original dado que agrega otros pasos a la secuencia del caso de uso original. Un caso de uso secundario hereda las acciones y significado del primario y además agrega sus propias acciones.(cont.) • Relaciones entre casos de uso.Análisis y Diseño de Sistemas de Información Diagramas Estáticos • Casos de Uso (cont. Comprar gaseosa Comprar un vaso de gaseosa Analisis.ppt Pag. que se conoce como el caso de uso base. Reabastecer Punto de extensión llenar los compartimientos «incluir» Exhibir el interior «incluir» «extender» (llenar los Compartimientos) Reabastecer de Acuerdo a las ventas Cubrir el interior • Generalización.

una ruta que muestra una particular combinación de condiciones dentro de dicho caso de uso. por ejemplo para un proyecto de 10 personas-año se esperarían 20 casos de uso ó 100 casos dependiendo del nivel de detalle. es necesario estar siempre pendiente de ellos.) • Relaciones entre casos de uso.ppt Pag.) • Las reglas para aplicar «incluir» o «extender» son: • Utilice extender cuando describa una variación de conducta normal. la palabra escenario se refiere a una sola ruta a través de un caso de uso. La mayoría se generan durante la captura de requerimientos. • Se puede tener diferente grado de granularidad. no se podrá planear como manejarlo en el proyecto. • Cuando emplear los casos de uso • Todo caso de uso es un requerimiento potencial y hasta que no haya sido capturado. pero se irán descubriendo otros conforme se avance en el proyecto.Análisis y Diseño de Sistemas de Información Diagramas Estáticos • Casos de Uso (cont. pero en el contexto de UML. • Emplee incluir para repetir cuando se trate de uno o varios casos de uso y desee evitar repeticiones • Algunas veces el termino escenario es usado como sinónimo de casos de uso. Analisis.(cont. • El modelado conceptual junto con los usuarios ayuda a descubrir los casos de uso. 27 .

Representación UML de un objeto (Diagrama de Clase): Empleado . El como se comporte dependerá del estado interno actual del objeto.Direccion:String .RFC:String + TomarNombre:String + TomarRFC:String + TomarDireccion:String Analisis. 28 . El estado de un objeto se representa mediante los datos almacenados en el mismo.Sexo:Boolean . los cuales son llamados atributos. los cuáles se invocan enviándoles mensajes.Nombre:String . un objeto es una cosa con la que se puede interactuar: Se le pueden mandar varios mensajes y reaccionará.Análisis y Diseño de Sistemas de Información Estructuras de Objetos • ¿Qué es un objeto? • • • • Conceptualmente. El comportamiento de un objeto es lo que éste puede hacer y se encuentra contenido en métodos.ppt Pag. Un objeto tiene una identidad la cual lo distingue de todos los demás objetos.

“Las aplicaciones de gestión están constituidas mayoritariamente por objetos degenerados” Analisis. actualizar y borrar (Que se correspondería con las estructuras de datos tradicionales). • • Un sistema construido con objetos degenerados no es un sistema verdaderamente orientado a objetos. 29 . Que sería lo mismo que una biblioteca de funciones. recuperar. • Un objeto sin métodos.ppt Pag. con solo operaciones del tipo crear.Análisis y Diseño de Sistemas de Información Estructuras de Objetos • Problemas con la definición de objetos • Se pueden crear objetos degenerados como: • Un objeto sin datos.

Análisis y Diseño de Sistemas de Información Estructuras de Objetos • • • • • Clases • Es un tipo (o plantilla) de objeto. Son los datos que están encapsulados dentro del objeto y determinan su estado. 30 . el cual describe un conjunto de objetos que tienen un rol equivalente en un sistema. La interfase pública de un objeto define cuáles mensajes aceptará sin importar de donde provengan. Cuando se manda un mensaje a un objeto se le esta ordenando que ejecute un método y generalmente se desconoce el código que ejecutará porque está encapsulado. La interfase describe completamente cómo van a interactuar con la clase los usuarios de la clase.ej: un empleado puede cambiar de dirección). cada instancia de objeto proveniente de la clase tendrá éstos métodos.ej: el RFC de un empleado) Son una implementación del comportamiento requerido por una clase. otros son inmutables y deben conservar el mismo valor durante la vida del objeto (p. Para crear una instancia de un objeto se usa la clase como la base para determinar como formar el objeto. Podrán ser llamados por otros objetos o internamente. Los objetos responden o actúan en función a los mensajes que reciben y el estado actual de sus atributos.ppt Pag. Algunos pueden cambiar (p. Es el medio fundamental de comunicación entre los objetos. Atributos • Métodos • Mensajes • Interfases • Analisis.

facilitando de esta forma la reutilización del código y permitiendo crear nuevas clases mediante la abstracción de los atributos y métodos comunes. 31 Analisis.ppt .Análisis y Diseño de Sistemas de Información Estructuras de Objetos • Herencia • Permite a una clase heredar los atributos y métodos de otra clase. Mamíferos .colorOjos: int + TomarColorOjos: int Superclase Perro -frecuenciaLadrido: int + Ladrar: int gato -frecuenciaMaullido:int + Maullar: int Subclases • • Las clases Perro y Gato heredan de la clase Mamíferos. esto significa que la clase Perro tiene los siguientes atributos: Heredada de la clase Mamíferos • colorOjos Definida solo para la clase Perro • frecuenciaLadrido y los siguientes métodos: Heredada de la clase Mamíferos • tomarColorOjos Definida solo para la clase Perro • Ladrar Pag.

Se oculta la funcionalidad de los objetos. Polimorfismo • • • • Encapsulamiento • • • Asociaciones Composiciones Analisis. La asignación dinámica permitirá que al mandar un mensaje a un objeto se asignará dinámicamente dependiendo del código del método que haya definido la instancia de dicho objeto que puede ser uno propio o heredado.ppt Pag.Análisis y Diseño de Sistemas de Información Estructuras de Objetos • • Abstracción • • Quitar las propiedades y acciones de un objeto para dejar sólo aquellas que sean necesarias. Un objeto puede estar relacionado con uno o más objetos La agregación de objetos permite definir composiciones. En orientación a objetos una variable polimórfica puede referirse a diferentes objetos en diferentes tiempos. 32 . Significa tener muchas formas. en las que cada componente se considera como tal sólo como parte del objeto compuesto. evitando que otros objetos o el mundo exterior puedan ver sus operaciones internas. Las subclases pueden hacer caso omiso de los métodos o atributos de las superclases y definir los suyos propios. En lenguajes de programación significa que una entidad puede tener uno de muchos tipos.

como el desempeño y la disponibilidad. • El modelo dinámico que describe el comportamiento del sistema a través del tiempo.Cuales partes correrán en la misma computadora? Analisis. que captura un aspecto de el diseño de una forma que puede ser discutida.Análisis y Diseño de Sistemas de Información Estructuras de Objetos • Diagramas • • • Para describir el diseño de un sistema. • podremos tomar una: • Vista lógica nos permitirá alcanzar los requerimientos funcionales. 33 . sino una representación de un modelo de el diseño. Cuáles necesidades de control hay? Qué actividades pueden ser concurrentes? Qué sincronización debe haber? • Vista de desarrollo ayuda a administrar el proyecto. haciendo una vista más concreta que la de proceso.ppt Pag. Los modelos de diagramas a considerar son: • El modelo de casos de uso que describe el sistema requerido desde el punto de vista de los usuarios. • El modelo estático que describe los elementos de el sistema y sus relaciones. porque la experiencia nos ha mostrado que es así como pensamos en los sistemas. el lenguaje que usemos debe estar basado en diagramas. Cuál parte hará cada elemento del equipo de gente? Que partes pueden reusarse? • Vista física ayuda a alcanzar los requerimientos no-funcionales. Cuáles partes van juntas? Cuáles son las clases y sus relaciones? • Vista de proceso ayuda a lograr los requerimientos no-funcionales. No es el diseño.

34 CODIGO CODIGO .ppt Pag.Análisis y Diseño de Sistemas de Información Estructuras de Objetos • Diagramas UML • La relación existente entre los diversos diagramas de UML se muestra a continuación: Diagrama de Diagrama de Clases Clases Casos de Casos de Uso Uso Diagrama de Diagrama de Secuencias Secuencias Diagrama de Diagrama de Estados Estados Diagrama de Diagrama de Distribución Distribución Diagrama de Diagrama de Colaboración Colaboración Diagrama de Diagrama de Componentes Componentes Diagrama de Diagrama de Actividad Actividad Analisis.

son un evento o una operación. • Construir rápidamente y lo más barato posible el sistema que alcance nuestros requerimientos. • • • • Cada pieza de comportamiento requerida por el sistema deberá ser proporcionada de una manera sensible. Analisis. son meta-lenguaje. renombrando las clases restantes si es necesario Pueden descartar candidatos por: redundancia. Descarte los candidatos que sean inapropiados por alguna razón. están fuera del alcance del sistema. 35 .Análisis y Diseño de Sistemas de Información Diagramas Estáticos • Objetos y Clases • Identificar las clases que deben existir en nuestro sistema. vaguedad. por los objetos de las clases que elijamos.ppt Pag. es la parte mas grande del trabajo de diseñar sistemas orientados a objetos. los cuales no dependen de la funcionalidad particular requerida actualmente Una técnica es la identificación de sustantivos. Un buen modelo de clases consiste de clases de los objetos principales. son un atributo. • Construir un sistema que sea fácil de mantener y adaptar para los requerimientos futuros.

Mayor. MesadeJuego Venta. LineaAerea Venta. ReglasdeJuego Tienda.) • Las cosas que pueden ser clases se refieren a: cosas tangibles (libro. Jugador Tienda. RodarDados Objetos físicos o tangibles Especificaciones. 36 . Existencia ManualdePersonal. Robo. pero pueden estarlo) Reglas y políticas Catálogos Registros de finanzas. bibliotecario). Vuelo. solicitud). eventos (llegada. Dado EspecicacióndeProducto. ReservacionAsiento A menudo no están representados como conceptos. Cesto. copia. Libro SistemaAutorizacionTarjetasdeCredito Hambre. Interacciones (reunión. de asuntos legales Instrumentos y servicios financieros Manuales y libros PoliticadeReembolso. Pago. Apuesta VentasLineadeProducto Cajero. Reservacion. Suerte DepartamentodeVentas. Gerente. PoliticadeCancelaciones CatalogodeProductos. de contratos.ppt Pag. diseño o descripciones de cosas Lugares Transacciones Línea o renglón de un elemento de transacciones Rol de las personas Contenedores de otras cosas Cosas dentro de un contenedor Otros sistemas de cómputo o electromecánicos externos al sistema Conceptos de nombres abstractos Organizaciones Eventos Procesos VentaUnProducto. ManualdeReparaciones Analisis.Análisis y Diseño de Sistemas de Información Diagramas Estáticos • Objetos y Clases (cont. maestro. intersección) Categoría del concepto Ejemplos TDPV. Biblioteca Producto. ContratodeEmpleo LineadeCredito. de trabajo. CatalogodeLibros Recibo. Accidente. partida. Junta. roles (estudiante. curso).

37 . Le esta pidiendo que ejecute una operación • Los atributos y las operaciones pueden tener diferente visibilidad.. • Las propiedades se indican mediante llaves. se definen como públicos(+) ..ppt Pag.privados(-) ó protegidos (#) • Una restricción es un texto que especifica una o varias reglas que sigue la clase.) • Diagramas de clases • Describe la vista estática de un sistema en términos de clases y relaciones entre las clases.Análisis y Diseño de Sistemas de Información Diagramas Estáticos • Objetos y Clases (cont. Operaciones . se indica mediante un texto libre encerrado entre llaves {}. Existe el OCL que define de manera formal las restricciones en UML.. Automóvil + Placa:String -Datos:DatosAutomóvil + Velocidad:Integer + Dirección: Dirección +Manejar(vel:Integer. Es visible si puede ser referenciado desde otras clases diferentes a donde esta definido. dir:Dirección) + tomarDatos(): DatosAutomóvil Nombre de la clase Atributos de la clase: son los datos contenidos en un objeto de la clase Operaciones de la clase: definen la forma en La cual los objetos pueden interactuar.. Analisis. dando propiedades a los elementos donde se haya n incluido estas. la representación de una clase es con: Nombre • ejemplo: Atributos . Cuando un objeto manda un mensaje a otro.

ppt Pag. Analisis.Análisis y Diseño de Sistemas de Información Diagramas Estáticos • Objetos y Clases (cont. post-condición algoritmo y el efecto que tiene sobre un objeto. Normalmente son llamadas funciones. Una de las violaciones más comunes a esta regla consiste en agregar atributos como llaves foráneas. • Un objeto se especifica con una firma o con precondición. La post-condición debe ser cierta después de que la operación sea ejecutada. Algunos lenguajes proveen un constructor default para las clases en caso de que no se proporcione. solamente para describir estos conceptos. se utilizan generalmente para inicializar la memoria requerida por el objeto y para colocarlo en un estado inicial estable. 38 . • Una clase persistente es aquella cuyos objetos existen aún después de que el programa que los creó ha salido. • Se conoce como la firma de la operación a el nombre de la operación su tipo de valor que regresa y los parámetros que utiliza.) • Los atributos no deberían usarse para relacionar conceptos en el modelo conceptual. Se describe la persistencia poniendo la propiedad de “persistent ” dentro del compartimiento del nombre. pero están dentro de una clase y pueden aplicarse solo a objetos de esa clase. Estas especificaciones son como propiedades para una operación.) • Diagramas de clases (cont. Las propiedades usualmente no se muestran directamente en los diagramas de clases. • Un constructor es una operación que comparte el mismo nombre que la clase y no tiene tipo definido de retorno. • • • La precondición debe ser cierta antes de que la operación pueda ejecutarse. • Las operaciones son utilizadas para manipular los atributos o realizar otras acciones.

una asociación es una relación que describe un conjunto de ligas. lo que significa que también es una conexión entre los objetos de esas clases. • Corresponden a los verbos. que están definidas como una conexión semántica entre un conjunto de objetos. • Normalmente una asociación es bidireccional. 39 . ambos objetos se conocen uno al otro. permiten que se siga cierta regla: Cajero Atiende {Ordenado} Cliente Un cajero atiende a un cliente. • Asociación.Análisis y Diseño de Sistemas de Información Diagramas Estáticos • Relaciones entre clases. Existen instancias de asociación. • Asociación normal: Usa Autor Computadora Un autor usa una computadora • Las restricciones en las asociaciones. pero cada cliente es atendido en el orden en que se encuentre en la formación Analisis. lo que significa que si un objeto está asociado con otro objeto.ppt Pag. En UML. es una conexión entre clases.

.* Persona Posee Poseído por 0.) • Hay asociaciones que establecen una relación en ambas direcciones • La multiplicidad es la cantidad de objetos de una clase que se relacionan con un objeto de la clase asociada: 1. una conexión entre objetos de la misma clase * conecta Nodo Un nodo se conecta a muchos nodos y estos a su vez se conectan con varios mas.ppt Pag.* Carro Un carro puede tener uno o mas dueños..Análisis y Diseño de Sistemas de Información Diagramas Estáticos • Relaciones entre clases (cont. (en una red de cómputo * Analisis. una persona puede tener cero o más carros • La asociación recursiva es una asociación de una clase a sí misma. 40 .

* esposa Asegurado Persona esposo casado con Analisis.* tiene 1.1 Refiere a Compañía Aseguradora 1 Asegurador Está expresado 1 en un tiene Refiere a 0..) • Los roles en una asociación especifican el papel que juega un objeto en una relación.. Póliza de Seguros 0.ppt Pag. se indica con un string colocado cerca de la terminal de la asociación siguiente a la clase a la cual se aplica.Análisis y Diseño de Sistemas de Información Diagramas Estáticos • Relaciones entre clases (cont. 41 ..* Contrato de Seguros 0..

) Categoría de la asociación A es una parte física de B A es una parte lógica de B A está físicamente contenido en B A está contenido lógicamente en B A es una descripción de B A es un elemento de línea (o renglón) en una transacción o reporte B A se conoce/ introduce/ registra/ presenta/ captura en B A es miembro de B A es una unidad organizacional de B A usa o dirige a B A se comunica con B A se relaciona con una transacción B A es una transacción relacionada con otra transacción B A es propiedad de B Analisis.ppt Ejemplos Caja-TPDV VentasLíneadeProducto -Venta TPDV-Tienda. Producto-Estante DescripcióndeProducto -Catálogo DescripcióndeProducto -Producto VentasLíneadeProducto -Venta Venta-TPDV Cajero-Tienda Departamento-Tienda Cajero-TPDV Cliente-Cajero Pago-Venta Pago-Venta TPDV-Tienda Pag. 42 .Análisis y Diseño de Sistemas de Información Diagramas Estáticos • Relaciones entre clases (cont.

43 . Representa la información de identidad y reduce la multiplicidad de uno a muchos por una de uno a uno. En algunos modelos no todas las combinaciones de asociación son válidas Elige Estudiante de {Or} Educación Media Superior Académico Elige Comercial • Asociación Ordenada {ordered}.3} columna:{1. Cuando los enlaces entre objetos pueden tener un orden implícito {ordered} {ordenadas por incremento de tiempo}. renglón:{1.2. Analisis.Análisis y Diseño de Sistemas de Información Diagramas Estáticos • Tipos de asociaciones • Asociación calificada (Qualified association).2.3} 1 1 Tablero Cuadro • Asociación Or {or}.ppt Pag.

ppt Pag.. Compañía Aseguradora 1 Asegurador 0.Análisis y Diseño de Sistemas de Información Diagramas Estáticos • Tipos de asociaciones • Clase de Asociación. 44 .* 0.. el tiempo en que el link fue creado... Una clase puede estar unida a una asociación. por ejemplo.1 1. Más de dos clases pueden asociarse con otra.* Asegurado Póliza de Seguros Persona Analisis. Cada enlace está asociado a un objeto de la clase de asociación. Jugador Participa en Equipo Negociado por Contrato Director General • Asociación ternaria (Ternary association). la asociación ternaria asocia tres clases. Se usa para agregar información extra sobre un enlace.* Contrato de Seguros 0.

indica que la relación entre las clases es de alguna forma parte de un “todo”. los cuadros solo tienen sentido si están formando parte del tablero Analisis. • Se puede tener una restricción en una agregación.ppt Pag.Análisis y Diseño de Sistemas de Información Diagramas Estáticos • Tipos de asociaciones (cont. Se describen diferentes niveles de abstracción.) • Una agregación. Se representa con diamante sólido. Tablero 1 9 Cuadros • En un juego del gato. Se indica con rombo en blanco en el lado de la clase que agrupa a las demás. es un caso especial de asociación. como en la relación {O} que se indica con línea punteada Comida 1 1 {O} 1 1 1 Comida Ensalada PlatoFuerte Postre • Una composición es una agregación donde cada componente puede pertenecer tan solo a un todo. 45 .

Análisis y Diseño de Sistemas de Información

Diagramas Estáticos

Tipos de asociaciones (cont.)
• La generalización es una relación entre un elemento más general y uno
más específico. El elemento más específico puede tener solo información adicional. Se utiliza sobre tipos, nunca sobre instancias (una clase puede heredar otra clase, pero un objeto no puede heredar otro objeto). • La clase específica o subclase, hereda todo de la clase general, llamada superclase. Los atributos, operaciones y todas las asociaciones son heredadas. Una clase puede ser superclase y subclase si esta en una jerarquía de clases. En gráficas de jerarquía, las clases están conectadas unas con otras, vía relaciones de generalización.

Vehículo

Carro

Bote

Camión

Analisis.ppt

Pag. 46

Análisis y Diseño de Sistemas de Información

Diagramas Estáticos

Interfaces y realizaciones

Una interfaz es un conjunto de operaciones que especifica cierto aspecto de la funcionalidad de una clase, y es un conjunto de operaciones que una clase presenta a otras. Se usa el símbolo de clase pero sin atributos, solamente con las operaciones:
Teclado
marca cantidadDeteclas Ctrl() Alt() RePag() AvPag() ...

«interfaz» MaquinaDeEscribir
Teclazo()

Adicionalmente la interfaz puede ser representada como un circulo MaquinaDeEscribir conectado con una línea a la clase
Teclado

Analisis.ppt

Pag. 47

Análisis y Diseño de Sistemas de Información

Diagramas Estáticos

Diagrama de objetos
• Un diagrama de objetos en UML usa la misma notación que los diagramas
de clases, ya que los objetos solo son instancias de la misma clase.

Autor Clases: nombre: String edad: Integer 0..*

Usa 1..*

Computadora nombre: String memoria: Integer

Juan: Autor Objetos: nombre= “Juan P.” edad = 33

Bob1:Computadora nombre=“IBM 128” Memoria=128

Analisis.ppt

Pag. 48

.* Describe Producto Contenidas-en 1 * 1 Capturas terminadas 1 1 Contiene 1 TPDV Venta Fecha Hora Pagado-por 1 1 1 Iniciado-por 1 Capturadas-en 1 Gerente Registra-ventas-en 1 Iniciado-por 1 Pago Monto Analisis.ppt Cliente Cajero Pag.Análisis y Diseño de Sistemas de Información Diagramas Estáticos • Diagrama de Clases • Modelo Conceptual de Punto de Venta Registra-venta-de Descritas-por 1 Catalogo deProducto * 1 * 1 Contiene 1.1 VentasLinea deProducto cantidad 1.* Especificacion deProducto Descripcion Precio Codigode barras 1 * 0... 49 ..* Usado-por Almacena 1 * Tienda Dirección Nombre 1 1.

Análisis y Diseño de Sistemas de Información Diagramas Dinámicos • Diagramas de estados • • Presenta los estados en los que puede encontrarse un objeto junto con las transiciones entre los estados. y muestra los puntos inicial y final de una secuencia de cambios de estado. Los símbolos UML en un diagrama de estados son: Estado Nombre Inicio Transición Evento que dispara Variables de estado Actividades Fin Transición • Las actividades cuentan con sucesos y acciones de entrada (qué sucede cuando el sistema entra al estado). salida (Qué pasa cuando el sistema sale del estado) y de hacer (que sucede cuando el sistema está en el estado) Analisis. 50 .ppt Pag.

51 . Operación Apagado Apagar Inicialización Hacer/Arrancar [lapso transcurrido] Teclazo o movimiento del ratón Protector De pantalla Analisis.ppt Pag.Análisis y Diseño de Sistemas de Información Diagramas Dinámicos • Diagramas de estados (cont. Encender la PC Inicialización Operación Apagado Apagar Hacer/Arrancar • Las condiciones de seguridad permiten establecer una relación entre Encender la PC estados que dependen de que se cumpla dicha condición.) • Se puede agregar ciertos detalles a las líneas de transición. para indicar un suceso que provoca una transición (la que desencadena un suceso) y la actividad de cómputo que se ejecute y haga que suceda la modificación de estado.

Se representan dentro del estado original. Cuando un estado se encuentra dentro de otro estado. • También has subestados concurrentes cuando pueden ocurrir al mismo tiempo. • Se dice que pueden suceder en forma secuencial cuando suceden uno tras de otro y se representan dentro del cuadro de estado original.ppt Pag. Operación A la espera de acción del usuario Registro de una acción del usuario Representación de la acción del usuario Verificar el conómetro del sistema [lapso transcurrido] Actualizar despliegue Analisis. ligados secuencialmente. se conocen como subestados. 52 . separados por línea punteada.) • Subestados.Análisis y Diseño de Sistemas de Información Diagramas Dinámicos • Diagramas de estados (cont.

Se dice de los estados compuestos que pueden recordar su subestado activo cuando el objeto trasciende fuera de tal estado compuesto.Análisis y Diseño de Sistemas de Información Diagramas Dinámicos • Diagramas de estados (cont.) • Estados históricos. • Se representa con una H y en caso de subestados anidados se dice que es histórico profundo cuando alcanza a recordar varios niveles (H*) en caso contrario se dice que es superficial • H A la espera de acción del usuario Operación Registro de una acción del usuario Representación de la acción del usuario Verificar el conómetro del sistema [lapso transcurrido] Actualizar despliegue [lapso transcurrido] Teclazo o movimiento del ratón Pag.ppt . 53 Analisis.

• En caso de que se desee representar las secuencias general de acciones de vario objetos y casos de uso. debido a que tienen el tipo de comportamiento que es útil describir mediante diagramas de estado. Analisis. pero se sugiere hacerlos solo para aquellos que presenten un estado interesante y cuando la construcción de tales diagramas ayude a aclarar lo que sucede. es mejor utilizar el diagrama de actividades.ppt Pag. • Algunos sugieren usarlos en los objetos de interfaz de usuario y de control.Análisis y Diseño de Sistemas de Información Diagramas Dinámicos • Diagramas de estados (cont.) • Cuando utilizar los diagramas de estados: • Se tendría que hacer uno por cada clase del sistema. 54 .

Elementos de un diagrama de actividades: • La actividad se muestra como una caja con nombre con las esquinas muy redondeadas.Análisis y Diseño de Sistemas de Información Diagramas Dinámicos • Diagramas de actividades • • Describen como se coordinan las actividades. 55 . representa cuando la actividad ha terminado Actividad • La transición se muestra como una flecha. normalmente no se les pone etiqueta.ppt Pag. muestran como puede ser implementada una operación que debe realizar muchas tareas diferentes y se desea mostrar cuales son las dependencias esenciales entre ellas. Actividad 1 Actividad 2 Analisis. a menos que se tenga una condición.

56 . Se utilizan para la ejecución de actividades en paralelo.ppt Pag.) • Barras de sincronización. Fin de la jornada Baño Descanso Analisis. indica coordinación de actividades y no se puede pasar de la barra hasta que todas las actividades previas a la barra han sido terminadas.Análisis y Diseño de Sistemas de Información Diagramas Dinámicos • Diagramas de actividades (cont.

Tecleo (canal) Oprimir numero de canal Fin de la jornada Cambiar(canal) Cambiar(canal) Oprimir numero de canal Analisis. usando un pentágono convexo para el envío del un evento y uno cóncavo para la recepción del evento. Televisión Remoto. permiten que se ejecuten otras actividades.Análisis y Diseño de Sistemas de Información Diagramas Dinámicos • Diagramas de actividades (cont.) • Las indicaciones. 57 .ppt Pag.

Al poner muchas actividades relacionadas entre sí.Análisis y Diseño de Sistemas de Información Diagramas Dinámicos • Diagramas de actividades (cont. 58 . • Las actividades se pretende que se continúen a lo largo del diagrama sin quedarse estancadas.ppt Pag. o a cuál caso de uso pertenecen • Las principales diferencias entre los diagramas de estado y los diagramas de actividades son: • Los diagramas de actividades normalmente NO incluyen eventos. • Marcas de inicio y fin se usan para indicar donde empieza el diagrama y donde termina. Analisis. para separar transiciones dejando el mismo estado. porque los únicos eventos de interés es la terminación de las actividades. • Particiones y líneas de responsabilidad. se pueden colocar de acuerdo al objeto o al actor que las ejecuta.) • Diamantes de decisión se usan para mostrar decisiones como una alternativa a las condiciones.

miembro [prestatario] [regresador] bibliotecario Encontrar libro en gaveta Esperar en la fila [obteniendo prestado] [regresando] Registrar el regreso Poner el libro de Regreso en gaveta Registrar el préstamo Preparar para el siguiente miembro Analisis. 59 .Análisis y Diseño de Sistemas de Información Diagramas Dinámicos • Diagramas de actividades (cont.) • Ejemplo de un diagrama de actividades en una biblioteca.ppt Pag.

Analisis.Análisis y Diseño de Sistemas de Información Diagramas Dinámicos • Diagramas de actividades (cont. 60 . Para representar y entender el comportamiento de las interacciones entre los casos de uso. • Cuando se trata de aplicaciones multihilos. son una herramienta muy útil para el modelado de flujo de trabajo y para la programación multihilos.ppt Pag. Usar mejor diagramas de secuencia o colaboración.) • Cuando utilizar diagramas de actividades: • Debido a que manejan y promueven el comportamiento en paralelo. Para comprender qué acciones deben ocurrir y cuáles son las dependencias de comportamiento. • Se recomienda usarlos para: • El análisis de un caso de uso. Asignando posteriormente los métodos a los objetos y mostrando tales asignaciones mediante diagramas de secuencia o colaboración. • Para tratar de ver como se comporta un objeto durante su período de vida. Es mejor usar un diagrama de estados. a través de numerosos casos de uso. Ayuda a aclarar situaciones dominadas por flujo de trabajo. • La comprensión del flujo de trabajo. Son adecuados en éste uso • No sirven para: • Tratar de ver como colaboran los objetos.

• • Muestra la forma en que los objetos se comunican entre sí al transcurrir el tiempo. Los mensajes van de un objeto a otro se representan con líneas.ppt Pag. Constan de objetos y representando en una línea vertical el tiempo. sincrónicos (esperan respuesta) o asincrónicos (no espera respuesta) :Objeto 1 :Objeto 2 Analisis. se indican las operaciones que ejecuta el objeto o activación se representan mediante un rectángulo cuya altura va en relación a la duración de la operación.Análisis y Diseño de Sistemas de Información Diagramas Dinámicos • Diagrama de secuencias. 61 . Pueden ser simples (transfieren control).

Si esta revisión devuelve “verdadero”. Analisis. • El Pedido envía entonces un mensaje “prepara” a cada línea de pedido dentro del Pedido. • Si no sucede así. que según Fowler. • En el diagrama siguiente se muestra el diagrama de secuencia omitiendo las activaciones.) • Para ilustrar los diagramas de secuencia se usará el siguiente caso de uso: • La ventana Entrada de pedido envía un mensaje “prepara” a Pedido. (cont.Análisis y Diseño de Sistemas de Información Diagramas Dinámicos • Diagrama de secuencias. quiere decir que la cantidad del Artículo de inventario ha caído más abajo del nivel de reorden y entonces dicho Artículo de inventario solicita una nueva entrega. • Cada Línea de pedido revisa el Artículo de inventario correspondiente. la Línea de pedido descuenta la cantidad apropiada de Artículo de inventario del almacén.ppt Pag. • . 62 . no aportan mucho a la ejecución de procedimientos y solamente sugiere usarlas en situaciones concurrentes.

Análisis y Diseño de Sistemas de Información Diagramas Dinámicos • Diagrama de secuencias.) • El siguiente ejemplo muestra unPedido Una Línea de Pedido Un artículo de inventario Ventana de Entrada de Pedidos prepara() Objeto Iteración *[para cada línea de pedido] prepara() Mensaje Condición hayExistencia:= revisa() [hayExistencia] descuenta() necesitaReorden:= necesitareordenar() Autodelegación [necesitaReorden] nuevo Un Artículo de reorden Regreso Creación [hayExistencia] nuevo() Un Artículo para entrega Analisis. 63 . (cont.ppt Pag.

Análisis y Diseño de Sistemas de Información Diagramas Dinámicos • Diagrama de secuencias. Fowler recomienda usarlo solamente cuando ayuden a aumentar la claridad. Los objetos pueden autodestruirse o pueden ser destruidos mediante otro mensaje.ppt Pag. 64 . como sucedería cuando se itera sobre una colección. Una condición indica cuándo se envía un mensaje. Una iteración muestra cuando un mensaje se envía varias veces a varios objetos receptores. (cont. El regreso indica el regreso de un mensaje. no un nuevo mensaje. Los mensajes representados por líneas están en orden de arriba hacia abajo. Los regresos SATURAN los diagramas y tienden a oscurecer el flujo. el cual se enviará solo si la condición es verdadera. La autodelegación es un mensaje que un objeto se manda a sí mismo. Analisis.) • • • • • • De el objeto se desprende una línea vertical conocida como línea de vida del objeto y representa el tiempo de duración del objeto durante la interacción. El borrado de un objeto se muestra con una X grande.

El coordinador comprueba si todos los revisores respondieron. ésta crea un Coordinador de transacción que coordina el trámite de la transacción. Analisis. entonces el coordinador notifica a la Transacción que todo está bien. (cont. como en este ejemplo. no hace nada.ppt Pag. dos) de objetos Revisor de Transacción. • Cuando termina un revisor de transacción. Ejemplo de una transacción bancaria: • Cuando se crea una Transacción. 65 . cada uno de los cuales es responsable de una revisión particular. Este proceso permitirá añadir con facilidad otros proceso de revisión. de no ser así. Este coordinador crea una cantidad (en el ejemplo. porque cada registro es llamado asincrónicamente y opera en paralelo. se le notifica al coordinador de transacción.) • • Otra ilustración adicional nos permitirá visualizar las activaciones y la creación de objetos.Análisis y Diseño de Sistemas de Información Diagramas Dinámicos • Diagrama de secuencias. Si todos han respondido indicando terminaciones exitosas.

ppt Pag. (cont.) nuevo Una Transacción nuevo unCoordinador de transacciones nuevo Activación un primer Revisor de transacción nuevo un segundo Revisor de transacción Mensaje asíncrono bien se suprimen las demás transacciones ¿todo terminado? bien el objeto se borra a sí mismo es Válido ¿todo terminado? Autodelegación Analisis. 66 .Análisis y Diseño de Sistemas de Información Diagramas Dinámicos • Diagrama de secuencias.

(cont.Análisis y Diseño de Sistemas de Información Diagramas Dinámicos • Diagramas de secuencias. se sugiere usar mejor diagramas separados para cada una de las condiciones • No sirve para ver el comportamiento de un solo objeto a través de muchos casos de uso (usar mejor un diagrama de estados) • Si quiere ver el comportamiento a través de muchos casos de uso o muchos proceso mejor utilice un diagrama de actividad. Analisis. se sugieren para: • Son útiles para ver la interacción entre los objetos.ppt Pag. 67 . • Cuando se desee ver el comportamiento de varios objetos en un caso de uso y la secuencia de los mensajes. • No se sugieren para: • No son convenientes para representar el comportamiento condicional. debido a que pone énfasis en la secuencia y es fácil apreciar el orden en el que ocurren las cosas. debido a que son para mostrar un comportamiento simple.) • Cuando utilizar los diagramas de secuencias.

• Muestra los objetos. • El mensaje le indicará al objeto receptor que ejecute una de sus operaciones. • Un diagrama de secuencias puede ser convertido en uno de colaboraciones y viceversa. 68 .las relaciones entre ellos. Esta flecha apunta al objeto receptor. :Nombre1 1:Agregar() 3:Actualizar() :Nombre2 :Nombre3 Analisis.ppt 2:Modificar() Pag. • El mensaje se representa como una flecha cerca de la línea de asociación entre dos objetos. los mensajes que se envían los objetos entre sí.Análisis y Diseño de Sistemas de Información Diagramas Dinámicos • Diagramas de colaboraciones. • Se agregará una cifra al mensaje para indicar la secuencia propia del mensaje. El tipo de mensaje se mostrará en una etiqueta cerca de la flecha.

69 . se inicia la siguiente secuencia: • • • • • • La GUI notifica al sistema operativo que se oprimió la tecla El sistema operativo le notifica a la CPU El sistema operativo actualiza la GUI La CPU notifica a la tarjeta de video La tarjeta de video envía un mensaje al monitor El monitor presenta el carácter alfanumérico en la pantalla. con lo que se hará evidente al usuario.Análisis y Diseño de Sistemas de Información Diagramas Dinámicos • Diagramas de colaboraciones.) • Ejemplo de un diagrama de colaboraciones: • El actor es el usuario quien inicia la interacción al oprimir una tecla. (cont. Tecleo :GUI 6:respuesta() 1:notificar(tecleo) 3:actualizar(tecleo) :Sistema operativo 2:actualizar(tecleo) :Monitor 5:mostrar(tecleo) :CPU 4:notificar(tecleo) :Tarjeta de video Analisis.ppt Pag.

ppt Pag. se sugieren para: • Es la mejor forma si se quiere mostrar los objetos y mostrar como se reconectan estáticamente unos con otros. • Sirven para mostrar la colaboración entre los objetos. • Cuando se desee ver el comportamiento de varios objetos en un caso de uso. 70 .Análisis y Diseño de Sistemas de Información Diagramas Dinámicos • Diagramas de colaboraciones. no sirven tan bien para la definición precisa del comportamiento • No se sugieren para: • No son convenientes para representar el comportamiento condicional. se sugiere usar mejor diagramas separados para cada una de las condiciones • No sirve para ver el comportamiento de un solo objeto a través de muchos casos de uso (usar mejor un diagrama de estados) • Si quiere ver el comportamiento a través de muchos casos de uso o muchos proceso mejor utilice un diagrama de actividad. sin embargo. (cont. debido a que son para mostrar un comportamiento simple. Analisis.) • Cuando utilizar los diagramas de colaboración.

la cuál puede depender de otros programas ejecutables al tiempo de ejecución. 71 . por ejemplo: «archivo» . se pueden usar estereotipos como «compilar» ó «ligar». Clasificándolos en relación con el proceso de compilación un componente podría ser: • Código fuente. «documento» Analisis. «tabla». Su representación es: calculadora. (biblioteca de clases) que depende de cualquier código objeto al cuál se ligara desde un programa ejecutable.ppt Pag. • Los detalles dependen del lenguaje de programación usado. igualmente se pueden usar estereotipos para diferenciar los diferentes tipos de componentes.java • Hay diferentes tipos de componentes y cada uno con diferentes tipos de dependencia . • Código objeto binario. • Una aplicación ejecutable. «ejecutable» .Análisis y Diseño de Sistemas de Información Diagramas de Implementación • Diagramas de componentes • Un componente es la implementación de un subsistema. la cual da las especificaciones (en términos de casos de uso) y una estructura de clases que lleva a cabo la especificación. «biblioteca» . el cual depende de que otros componentes estén disponibles al momento de compilación.

Analisis. Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente se refiere a los servicios ofrecidos por otro. En el caso de clases parametrizables se puede dar una especificación genérica.Análisis y Diseño de Sistemas de Información Diagramas de Implementación • Diagramas de componentes (cont.) • • • • • Cada clase del modelo lógico se realiza en dos componentes: la especificación y el cuerpo.ppt Pag. La especificación contiene la interfaz de la clase mientras que el cuerpo contiene la realización de la clase. Son paquetes estereotipados en «subsistemas» para incorporar la noción de biblioteca de compilación y de gestión de configuración. Los distintos componentes pueden agruparse en paquetes según un criterio lógico y con vistas a simplificar la implementación. 72 .

ppt Pag.o «biblioteca» MiEntradaSalida «compilar» MiAplicación «ejecutable» • La interfaz se puede representar por una línea con un círculo Programa de búsqueda Resultado de la búsqueda Analisis.) • Un diagrama de componentes mostrando las dependencias de tiempo de compilación: «ligar» streams. 73 .Análisis y Diseño de Sistemas de Información Diagramas de Implementación • Diagramas de componentes (cont.

Análisis y Diseño de Sistemas de Información Diagramas de Implementación • Diagramas de componentes (cont. 74 .exe ProcesadorTextos VerificadorOrtografico ContadorPalabras Analisis.ppt Pag.) • Si un componente implementa clases se puede establecer la relación entre el componente y las clases como sigue: ProcesadorTextos.exe Clases: ProcesadorTextos VerificadorOrtografico ContadorPalabras ó ProcesadorTextos.

La relación entre un componente y su interfase se conoce como realización. al que accede a un servicio se dice que utiliza una interfaz de importación. «Interfaz» ElementoDeEscucha cambioAlEstadoDelElemento() AWTEventMulticaster • Se puede sustituir un componente por otro si el nuevo contiene las mismas interfases que el anterior.ppt . al que proporciona el servicio se dice que provee una interfaz de exportación. 75 Analisis.) • Solo se podrán ejecutar las operaciones dentro de un componente a través de su interfase.Análisis y Diseño de Sistemas de Información Diagramas de Implementación • Diagramas de componentes (cont. Pag. Un componente puede acceder a los servicios de otro componente mediante el uso de su interfase. Se puede reutilizar un componente en otro sistema si éste puede acceder al componente reutilizado mediante sus interfases.

gif «ActiveX» CuadroCombCronometro «ActiveX» CuadroCombDistancia Analisis.ppt Pag.alx «ActiveX» BotonEjecutar «ActiveX» ImagenEsfera «ActiveX» BotonDetener «ActiveX» CronometroEsfera «ActiveX» BotonReinicar Esfera. 76 .) • Página Web con controles ActiveX.htm VBScript «ActiveX» DisposicionAnimacion. Animacion.Análisis y Diseño de Sistemas de Información Diagramas de Implementación • Diagramas de componentes (cont.

ppt Pag.Análisis y Diseño de Sistemas de Información Diagramas de Implementación • Diagramas de distribución. Analisis. Un nodo representa todo tipo de equipo de cómputo y se representa por un cubo: Nodo • Los estereotipos permiten precisar la naturaleza del equipo: • Dispositivos • Procesadores • Memoria • Etc. 77 . • • Los diagramas de distribución muestran la disposición física de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos.

ppt Pag. 78 .Análisis y Diseño de Sistemas de Información Diagramas de Implementación • Diagramas de distribución. Se pueden mostrar los componentes en relaciones de dependencia con un nodo: Servidor Directorio telefónico corporativo Programa de búsqueda Resultado de la búsqueda Analisis. • • Los nodos se interconectan mediante soportes bidireccionales (en principio) que puede a su vez estereotiparse.

(cont. 79 .Análisis y Diseño de Sistemas de Información Diagramas de Implementación • Diagramas de distribución.) • Las conexiones entre nodos se puede poner mediante una relación Servidor Directorio telefónico corporativo Programa de búsqueda Resultado de la búsqueda «Comunicación» Cliente Programa de Presentación Analisis.ppt Pag.

net «Dispositivo» Terminador «Dispositivo» Terminador Pag. • Un equipo de cómputo casero podría ser como sigue: «Dispositivo» Monitor Daewoo CMC-1505 «Dispositivo» Impresora HP Deskjet 610L «Dispositivo» Impresora HP Lasejet 5L «Dispositivo» Camara Digital Polaroid Flash640 «Dispositivo» Scanner Microtek SlimScanC3 PC Pentium 300Mhz Windows 95 PC Pentium 300Mhz Windows 95 Office 2000 Internet Explorer Office 2000 Visio 5Enterprise «Dispositivo» Modem ESS 336V «Dispositivo» Conector T «Dispositivo» Conector T «Dispositivo» Monitor PackardBell Internet Analisis.) • Aplicación de los diagramas de distribución. (cont. 80 .Análisis y Diseño de Sistemas de Información Diagramas de Implementación • Diagramas de distribución.ppt «Procesador» ISP Infosel.

El coordinador CS4 (CCS4) actualiza otras partes de cada manual y checa los apuntes producidos por los profesores adjuntos. 81 Analisis. Pag. muy tarde para que los adjuntos puedan saber cuántas copias deben preparar de su material. se consulta al DdE del estudiante y se puede tener una plática con el estudiante. El OEP verifica que cada estudiante que se inscriba. El OEP mantiene la lista maestra de todos los eCS4 y actualiza las listas de correo de los estudiantes tomando cursos CS4. la cual se conoce por la dirección de correo cs4class. Al final de cada año el Jefe del Departamento fija actividades para los miembros del cuerpo de maestros y otros. El OEP produce luego las listas para los adjuntos de los estudiantes que tomarán sus módulos. Los apuntes de los módulos están escritos en el lenguaje de formato LATEX. Al final de cada año académico. en particular a una persona es asignada para enseñar cada uno de los módulos que se supone van a estar disponibles para el próximo año (adjunto) Cada profesor adjunto actualiza los apuntes en el manual del curso de su módulo. ya sea que este o no inscrito para un grado en ciencias computacionales. El CCS3 proporciona una lista de los estudiantes entrando a CS4 provenientes de CS3 al CCS4 y al OEP. Alguien en la Oficina de Enseñanza Profesional (OEP) produce la versión en papel de cada manual de curso. el CCS4 produce la versión HTML ejecutando la aplicación latex2html sobre la fuente LATEX. Los estudiantes se inscriben en forma provisional en los módulos llenando una forma y entregándola en la Oficina de Enseñanza Profesional . es cualquier estudiante que esta tomando cualquier módulo de cuarto año en el departamento de ciencias computacionales.ppt . y cada eCS4 es inscrito en un numero razonable de módulos. En caso de duda.Análisis y Diseño de Sistemas de Información Caso de Estudio (CS4) • Presentación del caso. esté listado como un eCS4. Un DdE se asigna a un estudiante en su primer año de estudios y permanece con ésa función hasta que termina. Esto es. El CCS4 le dice al OEP acerca de cualquier otro estudiante que provenga de de otros cursos que no sean CS3. Cada estudiante es avisado por un miembro del cuerpo de maestros que actúa como Director de Estudios (DdE). • • • • • • • • • • Administración CS4 Un estudiante CS4 (eCS4). Estas listas no pueden llegarles a los adjuntos antes de la semana 3. el Comité Académico de el Departamento de Ciencias Computacionales determina qué módulos estarán disponibles para los eCS4 en el siguiente año.

ppt Pag. muchos módulos se aceptan en varios diferentes cursos de grado. Ciencias Computacionales e Inteligencia Artificial. Los detalles de la asesoría y las reglas acerca de cuáles combinaciones de módulos son aceptables. etc. los principales cursos existentes son: Ciencias Computacionales. debido a que los otros departamentos producen sus propios manuales) Se pide desarrollar un sistema que permita: • • • • • Disminuir la cantidad de trabajo rutinario para todo el staff. Sin embargo. automatizando su producción. • Deberá poder dar información sobre los módulos. cuales cursos de grado esta llevando un eCS4. Cada estudiante se inscribe para un curso de grado y recibe el manual de curso apropiado. El CCS4 de producir todos los manuales de cursos (en los casos de alumnos adjuntos que lleven los cursos es posible que reciban duplicado el manual. Hacer que la información tal como los manuales de cursos y las listas de los estudiantes que toman los cursos estén disponibles cuanto antes. qué módulos está tomando el estudiante. especialmente el CCS4. Permitir a los estudiantes inscribirse en los módulos en línea.Análisis y Diseño de Sistemas de Información Caso de Estudio (CS4) • Administración CS4 (cont.) • • • • • • Cada uno de los cursos de grado tiene su propio manual de curso. y en cada caso la descripción de cada curso es igual en cada manual. Analisis. 82 . • El sistema de administración CS4 deberá poder producir un informe sobre cada eCS4 indicando si es de 4to año o aún no se gradúa. Ciencias Computacionales y la Ingeniería Electrónica. de que curso forman parte y que estudiantes los están tomando. son diferentes para cada grado. Mejorar el seguimiento de dicha información. Que el OEP pueda obtener fácilmente información actualizada y confiable. igualmente hay manuales separados para cada uno de ellos. o cuál miembro del staff es el DdE de un eCS4. quiénes los imparten.

83 .ppt Pag. Producir la lista CS4 Organizador Cursos CS3 CCS4 Producir el manual del curso OEP Adjunto CS4 Inscribir en los Módulos eCS4 Director de estudios CS4 Analisis. Y se dejará fuera de la respuesta.Análisis y Diseño de Sistemas de Información Caso de Estudio (CS4) • Diagrama de casos de uso (CS4) • Las consultas pueden ser realizadas mediante una base de datos y usando técnicas estándar para hacer objetos persistentes. quedando pues los siguientes casos de uso: • Producir el manual del curso • Producir la lista CS4 • Inscribir en los módulos.

ppt Pag. el cual imprime y actualiza la pagina Web del mismo. • Desarrolle las descripciones de los casos de uso para: • Producir la lista CS4 • Inscribir en los módulos. • El adjunto de cada módulo. el sistema envía el texto completo del manual por correo electrónico al OEP. Una vez que se hicieron todas las actualizaciones. El sistema conserva el registro de cuáles cambios se han hecho. actualizándolo y regresándolo al sistema. • Estas actualizaciones pueden suceder en cualquier orden. • El organizador de CS4 actualiza las secciones principales de cada manual de curso obteniendo el texto actual del sistema. actualiza la descripción del módulo tomándolo del sistema. modificándolo y regresándolo modificado al sistema. 84 .Análisis y Diseño de Sistemas de Información Caso de Estudio (CS4) • Diagrama de casos de uso (CS4) • Descripción de caso de uso: Producir el manual del curso • Este caso de uso se puede usarse solamente cuando el comité académico ha determinado el conjunto de módulos que estarán disponibles y que el jefe de departamento ha asignado los adjuntos. Analisis.

..* 1. sin incluir actividades y operaciones: Adjunto 1 Imparte 0. 85 .ppt Pag.Análisis y Diseño de Sistemas de Información Caso de Estudio (CS4) • Diagrama de clases (CS4) • Un diagrama de clases a nivel conceptual...* Estudiante Cursos Grado esta en 1 Estudiante otros años Estudiante 4to año 0.* Director de Estudios 1 dirige 1.* Analisis..* 0..* Módulo 6 toma 6.

quien los imparte.Análisis y Diseño de Sistemas de Información Caso de Estudio (CS4) • Diagrama de actividad (CS4) • El siguiente diagrama muestra el flujo de trabajo requerido para determinar qué cursos hay.ppt Pag. generar los manuales de los cursos: Jefe de Departamento Adjunto OEP CCS4 Actualizar secciones principales Comité Académico Determinar los módulos Asignar Adjuntos Actualizar registro de módulo Imprimir manual Generar versión HTML Analisis. 86 .

que deje a la gente darse el gusto y que mejore los resultados para el cliente. Si no hay reservación deja su nombre y puede ir al bar a tomar algo antes de comer o esperar sentado en área de espera. 87 .A. lo almacenamos en el guardarropa y le damos un boleto para solicitarlo posteriormente. Entra el cliente [Tiene abrigo y/o sombrero] Ayudar a quitárselo [Prefiere el bar] Espera en el bar Guardarlo [Lista de espera] [No hizo reservación] Dejar su nombre [Prefiere el área de espera] Aguarda en el Área de espera Analisis. en cuyo caso lo pasamos lo más pronto posible. ha hecho una encuesta sobre el mundo de los restaurantes y ha llegado a sorprendentes conclusiones: a la gente le gusta comer fuera. Y deciden construir el restaurante del futuro. se forma? R: Se le pregunta si hizo reservación. • Las empresa Restaurantes.ppt Pag. pero no disfruta algunos momentos de ésa experiencia.le ayudamos a quitárselo.Análisis y Diseño de Sistemas de Información Caso de Estudio (Restaurante) • Presentación del caso. Lo mismo hacemos con el sombrero. • • • Entrevista de Análisis ¿Qué sucede cuando un cliente entra al restaurante? R: Si el cliente tiene un abrigo. ¿Y si hay línea de espera.S.

• • • • Analisis.ppt Pag. caliente a todos los comensales en la mesa al mismo tiempo. Un mozo de piso debe cambiar el mantel usado por el cliente anterior y acomodar la mesa. el chef prepara el entremés y el mesero se lo lleva al cliente. Cuando el cliente llama la atención del mesero. ¿Cómo deciden los clientes qué van a consumir? R: El mesero propone siempre a los clientes la sugerencia del día y les da de 5 a 10 minutos para que decidan. Los meseros tienen asignadas sus áreas de servicio y saben cuando está lista una mesa. para ello. éste regresa a tomarle su orden. Debido a que generalmente la cocina está muy ocupada y el chef tiene que dar prioridad a las comandas en el orden que hayan llegado. Luego llama a un “asistente” quién coloca una charola con pan y mantequilla. ¿Por qué es tan importante la prioridad? R: La mayoría de las comidas incluyen un entremés antes del plato fuerte. Cuando esta lista el capitán de meseros lleva al cliente a su mesa y luego llama a un mesero. A la mayoría de la gente le gusta comer el plato fuerte caliente.) ¿Cuando le llega el turno al cliente. El reto está en llevar el plato fuerte. deberá ser limpiada. ¿Luego que ocurre? R: El mesero llega a la mesa. 88 .Análisis y Diseño de Sistemas de Información Caso de Estudio (Restaurante) • Presentación del caso. la elección y la hora. (cont. es hora de sentarlo? R: La mesa deberá estar lista. Y luego lo notifica al chef. entrega un menú a cada comensal y les pregunta si desean alguna bebida mientras deciden. Mediante la transcripción de la elección en un formulario. llamado comanda.) • • Entrevista de Análisis (cont. se podrá llevar su bebida. Si alguien ha pedido una bebida el mesero la traerá. ¿Qué contiene la comanda? R: La mesa. si el cliente estaba bebiendo en el bar.

Análisis y Diseño de Sistemas de Información Caso de Estudio (Restaurante) Diagrama: “Servir a un cliente” Entra el cliente [Tiene abrigo y/o sombrero] Ayudar a quitárselo Guardarlo [Lista de [No hizo espera] reservación] [Prefiere el bar] Espera en el bar Aguarda en el Área de espera Dejar su nombre [Prefiere el área de espera] Sentar al cliente Alistar la mesa [Desea bebida] Llamar al mesero Mostrar el menú Llamar al asistente Tomar un pedido de bebidas Servir Pan y agua Traer bebida Ir por las bebidas Sugerir platillo Leer Menú Elegir Notificar al chef Traer entremes Analisis.ppt Preparar platillo Modelado en un diagrama Por separado Pag. 89 .

En caso de no desearlo pregunta si desean café.ppt Pag.) • • ¿Cómo le sirven al cliente? R: El chef preparará el plato fuerte y el mesero lo recogerá cuando se dé cuenta de que los comensales han terminado con el entremés. y el mesero regresará al menos una vez para verificar si todo está bien. Si no desean nada. los clientes dejarán una propina. Luego regresará y obtendrá el pago en efectivo o en tarjeta de crédito. Luego traerá el cambio o los vouchers. en caso de aceptarlo. ¿Qué debe hacer el mesero cuando el cliente salga? R: Llamar al mozo de piso para limpiar la mesa. traerá el café. Los comensales ingerirán sus alimentos.Análisis y Diseño de Sistemas de Información Caso de Estudio (Restaurante) • Entrevista de Análisis (cont. ¿Qué sucede cuando los clientes terminan de comer? R: El mesero regresa y pregunta si desean postre. después el mesero lleva el plato fuerte a la mesa. tazas y les servirá. traerá la cuenta. • Analisis. recogerán sus abrigos y se irán. en cuyo caso el mesero dará el menú de postres y tomará las órdenes. la preparará y estará lista para los siguientes comensales. 90 .

Análisis y Diseño de Sistemas de Información Caso de Estudio (Restaurante) Diagrama de “Servir a un cliente” (cont.) Traer entremés Ingerir entremés Traer el plato fuerte Preparar platillo Modelado en un diagrama Por separado [Desea café] Servir café Ingerir plato fuerte Beber café [Desea postre] Traer el menú de postres Traer postres Ingerir postres [Guardar abrigo/sombrero] Trae la cuenta Salir Recoger abrigo o sombrero Liquidar cuenta Dejar propina Analisis. 91 .ppt Pag.

en momentos distintos. El chef recibe la comanda y empieza a preparar los entremeses y el plato fuerte. Entre el mesero y el chef se coordinan para traerles a todos los platos fuertes al mismo tiempo. 92 . y le avisa al chef que ya casi están listos para el plato fuerte. el chef termina su preparación. El chef luego de dar el entremés al mesero.ppt Pag. El mesero va a la cocina.Análisis y Diseño de Sistemas de Información Caso de Estudio (Restaurante) • Preparación de platillos • ¿Cómo se coordina el chef para tener los platillos a tiempo? R: La gente en una mesa casi siempre termina sus entremeses. espera que este le avise cuando la mayoría de los comensales ya casi ha terminado con sus entremeses para poderle dar el toque final a cada plato fuerte. cuando esta terminado el entremés. el mesero va a la cocina. ¿Cómo se entera el mesero que ya están listos los entremeses? R: El mesero va a la cocina de vez en cuando. los toma y los lleva a la mesa. El mesero los toma y los lleva a la mesa • Analisis.

93 .Análisis y Diseño de Sistemas de Información Caso de Estudio (Restaurante) • Preparación de platillos Recibir comanda Preparar entremeses Iniciar la preparación Del plato fuerte Coordinar la preparación de otros pedidos Recibir la notificación de que los Entremeses casi se han consumido Llevar entremeses Ingerir entremeses Finaliza la preparación de plato fuete Tomar el plato fuerte Llevar Plato fuerte Analisis.ppt Pag.

Análisis y Diseño de Sistemas de Información

Caso de Estudio (Restaurante)

Clases y asociaciones
• El cliente se asocia con una gran cantidad de clases, como muestran las
asociaciones a continuación:
Postre
1

Cuenta
1

Propina
1

Reservación
1

Ingiere Liquida
1 1 1

Deja
1 1..* 1 1

Hace Es atendido por Da a guardar
1

Cliente

Mesero Sombrero
0..* 1

1

1

1

1

Da a guardar

1

Encargado del Guardarropa

Elige del Ingiere Hace
1 1 1

0..*

Abrigo

Elige del

1

Menú

Alimento

Menú del postre

Orden

Analisis.ppt

Pag. 94

Análisis y Diseño de Sistemas de Información

Caso de Estudio (Restaurante)

Detalle de las clases

Cliente, sus atributos serían:
Cliente nombre horallegada orden horaservicio ingerir() beber() ordenar() pagar()

Analisis.ppt

Pag. 95

Análisis y Diseño de Sistemas de Información

Caso de Estudio (Restaurante)

Detalle de las clases • Empleado es una clase abstracta que puede contener la información de los
empleados y como clases secundarias, se pueden tener Mesero, Chef, Gerente, Asistente.
Empleado nombre domicilio RFC añosExperiencia fechaContratación salario

Asistente trabajaCon preparar() cocinar() servirPan() servirAgua()

Mesero

Chef

Gerente

llevar() servir() recoger( llamar() verificarEstado() DeLaOrden()

preparar() cocinar() darPrioridad() crearReceta()

monitor() operaRestaurante() asignar() rotar()

Analisis.ppt

Pag. 96

«Dispositivo» Computadora palmtop Inalámbrico «Dispositivo» Red «Dispositivo» PC de la cocina «Dispositivo» PC del gerente Analisis.Análisis y Diseño de Sistemas de Información Caso de Estudio (Restaurante) • Diagrama de distribución. La cocina tendrá una terminal de escritorio y una o varias pantallas. El gerente tendrá una en su oficina. Restaurante • Los meseros contarán con una computadora palmtop y la utilizarán para comunicarse con la cocina y con los mozos de piso. Estos últimos también tendrán palmtops para comunicarse.ppt Pag. 97 .

ppt Pag. 98 .Análisis y Diseño de Sistemas de Información Caso de Estudio (Restaurante) • Casos de uso • El paquete mesero Mesero Totalizar Una cuenta Transmitir una Orden al bar Notificar al chef del progreso de los clientes En sus alimentos Obtener un acuse De recibo Sondear el progreso De la orden Tomar una orden Tomar una orden De bebida Incluir Transmitir la orden a la cocina Recibir una notificación de la cocina Llamar a un mozo de piso Imprimir una cuenta Cambiar una orden Incluir Llamar a un Asistente Recibir una notificación del bar Analisis.

Sign up to vote on this title
UsefulNot useful