UML Ingeniera Sw Ejemplos

Analisis.ppt Pag. 1

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

• Instructor• Ing. y M.A. Francisco Javier Mariscal Flores [email protected]

Analisis.ppt Pag. 2

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

• Bibliografía

Using UML. Software Engineering with objects and Components

Perdita Stevens, Rob Pooley

Addison Wesley. Updated Edition 2000. http://www.dcs.ed.ac.uk/home/pxs/Book/

The Object-Oriented Thought Process

Matt Weisfeld Sams Publishing, 2000

Aprendiendo UML en 24 Horas Joseph Schmuller Editorial Prentice Hall, Primera Edición 1999

Advanced Object-Oriented Analysis & Design Using UML

James J. Odell Cambridge University Press. 1998

UML y Patrones. Introducción al análisis y diseño orientado a objetos.

Craig Larman Prentice Hall. 1999

Análisis y Diseño de Sistemas Kendall & Kendall Prentice Hall. Pearson Educación. Tercera Edición. 1995

UML gota a gota Martin Fowler con Kendal Scott

Addison Wesley. Pearson. 1999

Analisis.ppt Pag. 3

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. 4


• Problemas:• Hay sistemas que no cumplen con las necesidades de los usuarios

y/o tienen fallas técnicas.

• Generalmente, los sistemas no están actualizados ni cuando se están diseñando.

• Aún existe el “error de la computadora” como excusa a un mal servicio a los clientes.

• 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.

• EL SOFTWARE NO SIEMPRE ES UTILIZABLE, ÚTIL, CONFIABLE O DISPONIBLE.

• La falta de FLEXIBILIDAD también resulta evidente, como lo muestran el problema del milenio y la adecuación de todos los sistemas viejos (legacy) a procesos de negocios cambiantes.

• 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.ppt Pag. 5


• Problemas aún más drásticos.• 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, no permitía al aeropuerto abrir a tiempo.

• 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. Wayt Gibbs en Software’s chronic crisis. Scientific American (International Ed.) pp 72-81, Sep. 1994. dice:• En promedio, los proyectos grandes toman 50% más de tiempo de lo

planeado;

• 75% de los proyectos grandes tienen fallas operacionales;

• 25% de los proyectos grandes son cancelados

Analisis.ppt Pag. 6


• Promesas, promesas• Cada nueva tecnología promete reducir los tiempos de desarrollo e

incrementar los promedios de éxito de los proyectos.

• Todos lo dudamos.

• Según Frederick P. Brooks (The mythical man-month, Addison-Wesley 1975/1995), 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, porque cada persona tiene más gente con quién comunicarse. Cuando un proyecto empieza a quedarse atrás en el tiempo, el poner más gente por lo general falla.

• El Departamento de Defensa de EU, intentó resolver la crisis del software y comisionó el diseño del lenguaje de programación ADA, el cual se estandarizó en 1983, el cual soportaba lo mejor de los conceptos de análisis, diseño y programación estructurados, la modularidad y la encapsulación fueron conceptos clave en el diseño del lenguaje, pero aún esta enorme inversión ha fracasado.

Analisis.ppt Pag. 7


• ¿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, son realizados mediante “programación heroica” en la cual una sola persona pretende recordar todo lo relevante acerca del sistema. Pero en general esto es imposible.

• La evolución del entendimiento de un problema seria como sigue:• 1.- 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. 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. En el sentido más general, un módulo puede ser cualquier “bit” identificable de un sistema por lo cual tiene sentido considerarlo en forma separada. Los módulos pueden ser:• Archivos• Subrutinas• Funciones de biblioteca• Clases, en un lenguaje orientado a objetos.• Otras partes conocidas como módulos o similares• Programas o subsistemas independientes o semi-independientes.

Analisis.ppt Pag. 8


• ¿Cómo son los sistemas considerados buenos? (cont.)• 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, 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.

• La dependencia es conocida a veces como acoplamiento. Un sistema con muchas dependencias tiene un acoplamiento grande. Los sistemas buenos tienen un acoplamiento bajo, porque los cambios a una parte del sistema son menos propensos a propagarse a través del sistema

Analisis.ppt Pag. 9


• 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.

• Tenemos que conocer cuales cambios dentro de un módulo pueden afectar el resto del sistema.

• Para tomar ventaja del acoplamiento bajo de un sistema, es importante ser capaz de identificar cuales módulos están acoplados, de otra forma se tendrá que gastar esfuerzo verificando si hay que hacer cambios a un módulo, lo cual es un costo aún cuando no fue necesario el cambio. Nos gustaría tener certeza sobre los cambios.

• Una vez que las fronteras entre los módulos de nuestro sistema están definidas, hay dos clases de información que puede ser útil:• 1.- ¿Qué suposiciones de un módulo dado pueden los clientes hacer

acerca de él? Contestando, nos permitirá conocer que clase de cambios a un módulo pueden ser peligrosos (servicios que provee?)

• 2.- ¿Cuáles módulos son clientes de un módulo dado? Contestando, nos dice cuáles módulos tendrán que cambiar, si hacemos un cambio peligroso a un módulo.

Analisis.ppt Pag. 10


• Encapsulamiento: Acoplamiento bajo (Cont.)• Interfases

• Una interfase a un módulo define algunas características del módulo sobre las cuáles sus clientes pueden depender.

• El resto del sistema solo puede usar el módulo en formas permitidas por las interfases; esto es, una interfase ENCAPSULA el conocimiento acerca de los módulos. “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; entonces debemos documentar tales suposiciones en interfases y verificar su validez.

• Si documentamos bien todas las suposiciones en la interfase, seremos capaces de decir: “Si un módulo cambia internamente sin cambiar su interfase, este cambio no necesitará otros cambios en otras partes del sistema”.

• 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, y también de que el módulo siempre justifica las suposiciones que están documentadas.

• En un lenguaje de programación, mientras más permita que esas verificaciones sean automáticas, se dice que más soporta la modularidad y la encapsulación.



• Encapsulamiento: Acoplamiento bajo (Cont.)• Dependencias del contexto

• Existen varias razones para querer conocer no solo qué dependencias pudieran existir (esto es, qué características están documentadas en las interfases de los módulos del sistema) sino también qué dependencias existen realmente.

• Sabemos que un cambio en un módulo puede afectar a sus clientes; sus clientes (por definición) son aquellos módulos que pueden necesitar un cambio, entonces es importante ser capaz de decir cuáles son ellos.

• Suponga que quiere reusar un módulo. Es necesario saber no solo qué servicios provee (cual es su interfase) sino también qué servicios requiere para trabajar. Los servicios que un módulo requiere son llamados sus dependencias de contexto. Ellos pueden a su vez ser expresados en términos de interfases; el módulo puede garantizar que si ciertas interfases le son provistas, entonces él a su vez proveerá sus propias interfases.

• Entre ellos, las dependencias de contexto de un módulo y la propia interfase del módulo garantiza que proveerá los servicios descritos en su interfase.



• Encapsulamiento: Acoplamiento bajo (Cont.)• Beneficios de la modularidad con interfases definidas.

• 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. 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, la gente desarrollando código que usa un

módulo, solo deberá entender la interfase del módulo, no cómo trabaja, entonces serían más productivos.

• Debido a que los desarrolladores pueden ignorar en forma segura algunos aspectos del sistema, tendrán un mejor entendimiento de los aspectos que sí necesitan conocer, entonces se introducirán menos errores.

• Los errores deberán ser más fáciles de encontrar (en desarrollo y mantenimiento), porque se evitará el examinar módulos irrelevantes.

• Una vez que existe un módulo, con documentación de lo que provee y lo que requiere, es posible considerar reusarlo.

• El reto real, es definir buenos módulos con las cosas correctas en sus interfases. Solo entonces se pueden lograr los beneficios completos.



• Encapsulamiento: Acoplamiento bajo (Cont.)• Un módulo puede tener varias interfases

• A veces es necesario documentar los servicios que un módulo provee con varias y diferentes interfases, de un modo que podamos ser más precisos acerca de que servicios un cliente dado necesita. Esto es a la vez útil para el mantenimiento y para el reuso.

• Ya tenemos una respuesta parcial a la pregunta de ¿Cómo son los sistemas considerados buenos?

• Un buen sistema consiste de módulos encapsulados



• Abstracción: Alta Cohesión.• 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. Tales módulos se dice que tienen una alta cohesión.

• La interfase realiza una abstracción de las cosas que el desarrollador no tiene que entender para usar el módulo, dejando una figura coherente de lo que el usuario de un módulo quiere conocer.

• El desarrollador está protegido de información irrelevante acerca de cómo el módulo hace lo que hace. 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, lo cual va dirigido a la prevención de que el desarrollador use información escondida.

• Abstracción es cuando un cliente de un módulo no necesita saber más de lo que está en la interfase.

• Encapsulación es cuando un cliente de un módulo no es capaz de conocer más de lo que está en la interfase.• Si un módulo, de cualquier tamaño y complejidad, es una buena abstracción

(tiene una alta cohesión y un acoplamiento bajo) puede ser factible de reusarlo en posteriores sistemas, o de reemplazo en sistemas ya existentes.

• Estaríamos hablando de un componente insertable o conectable (“pluggable component”)



• Arquitectura y componentes• La arquitectura donde se desarrolla y aquella dónde se va a usar.

• En los 80s y principios de los 90s, la tecnología orientada a objetos iba a ser la solución a la crisis en desarrollo de software.

• Componente• Es una cosa que se puede reusar o reemplazar

• Desarrollo Basado en Componentes (CBD, Component Based Development)• Un módulo con propiedades que lo hacen reusable y reemplazable.

• ¿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.

• Ejemplo de un factor no técnico de reuso: Recompensar al programador por el número de líneas que escriben.

• Los factores técnicos involucran decisiones de arquitectura y más alto nivel.



• Diseño basado en componentes: Insertabilidad, conectabilidad (pluggability)• La forma ideal de construir un nuevo sistema es tomar algunos

componentes existentes y juntarlos.

• Pluggability es la propiedad que tienen los componentes de poder ser juntados.

• Los componentes tienen que ser partes que llenan o cumplen necesidades en un sistema completo.

• Las partes tienen que ser compatibles unas con otras y eso depende de la presencia de una arquitectura adecuada.

• Las decisiones importantes acerca de la arquitectura:• Deben ser tomadas lo más pronto en el proyecto.

• Son afectadas por la naturaleza de los componentes en la arquitectura

• Pueden ser influenciadas por el medio ambiente del proyecto



• ¿Cómo se construyen los buenos sistemas?• Usar un PROCESO definido con FASES claras, 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, 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.

• Usar un almacén de CONOCIMIENTOS, ARQUITECTURAS y COMPONENTES relevantes.

• Hacer un uso sensible de herramientas.



• Proceso de desarrollo• Método tradicional para el desarrollo de Sistemas

• Cada fase se realiza hasta que se completó la anterior. Supone que no se vuelve a entrar en las fases terminadas.

• Administración de riesgos implica:• 1.- Cada vez que se toma una decisión se tiene el riesgo de que sea incorrecta.

Mientras más se tarde en detectar un error más difícil es corregirlo. Evaluaciones frecuentes ayudan a corregir.

• 2.- Un riesgo mayor es que los desarrolladores malinterpreten los requerimientos. La elaboración de prototipos permite reafirmarlos.

• Espiral de desarrollo:

• Metodología Unificada.• Gran cantidad de metodologías orientadas a objetos han salido a la luz y las de Grady

Booch, James Rumbaugh, 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.

Análisis

Diseño

Implementación

Pruebas

Mantenimiento

AnálisisDiseño

Construcción Transición



• Proceso de desarrollo (cont.)• Procesos donde utilizar UML.

• Los procesos iterativos deberán tener un plan de que serán las iteraciones y que será cubierto por cada una de ellas.

• 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 elaboración da la arquitectura básica de el sistema, un plan para el acuerdo de construcción, identifica todos los riesgos significantes, entendimiento cabal de los mayores riesgos para no estar preocupados.

• La construcción termina con una versión beta del sistema.• Transición es el proceso de introducir el sistema a sus usuarios.

• Otros procesos han adoptado UML como su lenguaje de modelación: Catalysis, Rational Unified Process, etc.


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. Normalmente un caso de uso es un proceso relativamente largo, no un paso individual o transacción. Cada caso de uso necesita representar una tarea, o una unidad coherente de funcionalidad, la cuál necesita ser soportada por el sistema.

• Una vez identificado los casos de uso se pueden crear diagramas de casos de uso para colocar el caso de uso en contexto. 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.

• En las etapas iniciales de desarrollo del proyecto, los diagramas de casos de uso describen las actividades del mundo real y las motivaciones. Se puede afinar los diagramas en etapas posteriores para reflejar las interfases de usuario y los detalles de diseño.

• Cuando se tienen varios subsistemas es común dibujar la frontera del sistema, pero generalmente se omite.

Sist. de Informaciónde Biblioteca

Recursos para Prestamo

UsuarioBibliotecario

Agregarrecursos

RegresarRecursos



• Casos de Uso (cont.)• Interacciones con sistemas externos:

• Las opiniones de incluir a los sistemas externos como casos de uso o no, varían:

1.- Algunos sienten que todas las interacciones con sistemas remotos deben aparecer en el diagrama. Si requiere acceso a Reuters se debería indicar.

2.- Algunas personas consideran que sólo se deben mostrar los casos de uso con una interacción externa, cuando quien inicia el contacto es otro sistema. Contabilidad solo se mostraría si dicho sistema invocara algún proceso que le dijera al sistema fuente que lo hiciera.

3.- Algunas personas consideran que solo se deben mostrar los actores del sistema cuando ellos sean los que necesiten el caso de uso. Si se genera un archivo cada noche que después es recogido por el sistema de contabilidad, entonces éste es el actor que corresponde, por necesitar de dicho archivo.

4.- Otros más sienten que constituye un enfoque equivocado considerar que un sistema es un actor.



• Casos de Uso (cont.)• Un actor en un caso de uso representa un rol que alguien debe jugar,

en vez de representar a alguien en individual.

• 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; solo significa que puede estarlo, dependiendo de las circunstancias.

• 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.

• Actores no humanos, como otros a sistemas o en algunos casos se pueden identificar diferentes dispositivos externos al sistema.



• Casos de Uso (cont.)• Utilización de los casos de uso.

• 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.

• Casos de uso a través del desarrollo.• Planeación. Antes de que se haga un proceso de estimación y planeación para el

proyecto completo, es necesario hacer una lista de los casos de uso del sistema, 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.

• Aspectos políticos. 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.

• Aspectos técnicos. Debemos sacar adelante primero los casos de uso con mayor riesgo, 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.

• Validación del Sistema. Tomar cada caso de uso y verificar que el diseño permitirá completarlo, igualmente se deben diseñar pruebas para cada caso de uso.



• Casos de Uso (cont.)• Posibles problemas con los casos de uso.

• Peligro de construir sistemas no orientados a objetos. Al enfocarnos en casos de uso, podemos perder de vista la arquitectura del sistema y la estructura de objetos estáticos, podemos terminar desarrollando sistemas top-down orientados a funciones, difíciles de mantener e inflexibles. Para evitarlo debemos administrar correctamente el inicio de cada etapa, si la etapa previa dejó alguna situación insatisfactoria deberá volverse a producir.

• Peligro de equivocar el diseño de los requerimientos. Por ejemplo al equivocar el involucramiento de actores en casos de uso que no los benefician. Es importante que los desarrolladores distingan entre requerimientos de diseño y candidatos.

• 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. Se puede minimizar el error al hacer paralelamente el análisis de casos de uso y el modelado conceptual de clases.



• Casos de Uso (cont.)• Relaciones entre casos de uso.

• La inclusión permite volver a utilizar los pasos de un caso de uso dentro de otro

• Al reusar los casos de uso se tienen las siguientes ventajas:• Buena forma de registrar la conveniencia de se usara un componente

o evitar duplicidades.• 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, top-down con sistemas inflexibles.

• Es difícil para alguien no adiestrado en UML entender la notación de «incluir»

Recolectardinero

Exhibirel interior

Cubrir el interior

«incluir»

«incluir»



• Casos de Uso (cont.)• Relaciones entre casos de uso.(cont.)

• La extensión, permite crear un caso mediante la adición de pasos a uno existente, Se dice que el nuevo caso de uso extiende al original dado que agrega otros pasos a la secuencia del caso de uso original, que se conoce como el caso de uso base.

• Generalización. Un caso de uso secundario hereda las acciones y significado del primario y además agrega sus propias acciones.

Comprar gaseosa

Comprar un vasode gaseosa

ReabastecerPunto de extensión llenar

los compartimientos

Exhibirel interior

Cubrir el interior

«incluir»

«incluir»

Reabastecer de Acuerdo a las ventas

«extender»(llenar los Compartimientos)



• Casos de Uso (cont.)• Relaciones entre casos de uso.(cont.)

• Las reglas para aplicar «incluir» o «extender» son:• Utilice extender cuando describa una variación de conducta normal.• 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, pero en el contexto de UML, la palabra escenario se refiere a una sola ruta a través de un caso de uso, una ruta que muestra una particular combinación de condiciones dentro de dicho caso de uso.

• Cuando emplear los casos de uso• Todo caso de uso es un requerimiento potencial y hasta que no haya

sido capturado, no se podrá planear como manejarlo en el proyecto. La mayoría se generan durante la captura de requerimientos, pero se irán descubriendo otros conforme se avance en el proyecto, es necesario estar siempre pendiente de ellos.

• El modelado conceptual junto con los usuarios ayuda a descubrir los casos de uso.

• Se puede tener diferente grado de granularidad, por ejemplo para un proyecto de 10 personas-año se esperarían 20 casos de uso ó 100 casos dependiendo del nivel de detalle.


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

• ¿Qué es un objeto?• Conceptualmente, un objeto es una cosa con la que se puede

interactuar: Se le pueden mandar varios mensajes y reaccionará. El como se comporte dependerá del estado interno actual del objeto. Un objeto tiene una identidad la cual lo distingue de todos los demás objetos.

• El estado de un objeto se representa mediante los datos almacenados en el mismo, los cuales son llamados atributos.

• El comportamiento de un objeto es lo que éste puede hacer y se encuentra contenido en métodos, los cuáles se invocan enviándoles mensajes.

• Representación UML de un objeto (Diagrama de Clase):

Empleado

- Nombre:String - Sexo:Boolean - Direccion:String - RFC:String

+ TomarNombre:String + TomarRFC:String + TomarDireccion:String



• Problemas con la definición de objetos• Se pueden crear objetos degenerados como:

• Un objeto sin datos. Que sería lo mismo que una biblioteca de funciones.

• Un objeto sin métodos, con solo operaciones del tipo crear, recuperar, 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.

• “Las aplicaciones de gestión están constituidas mayoritariamente por objetos degenerados”



• Clases• Es un tipo (o plantilla) de objeto, el cual describe un conjunto de objetos que

tienen un rol equivalente en un sistema. Para crear una instancia de un objeto se usa la clase como la base para determinar como formar el objeto.

• Atributos• Son los datos que están encapsulados dentro del objeto y determinan su

estado. Algunos pueden cambiar (p.ej: un empleado puede cambiar de dirección), otros son inmutables y deben conservar el mismo valor durante la vida del objeto (p.ej: el RFC de un empleado)

• Métodos• Son una implementación del comportamiento requerido por una clase, cada

instancia de objeto proveniente de la clase tendrá éstos métodos. Podrán ser llamados por otros objetos o internamente.

• Mensajes• Los objetos responden o actúan en función a los mensajes que reciben y el

estado actual de sus atributos. 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.

• Interfases• Es el medio fundamental de comunicación entre los objetos. La interfase

describe completamente cómo van a interactuar con la clase los usuarios de la clase. La interfase pública de un objeto define cuáles mensajes aceptará sin importar de donde provengan.



• Herencia• Permite a una clase heredar los atributos y métodos de otra clase,

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.

• Las clases Perro y Gato heredan de la clase Mamíferos, esto significa que la clase Perro tiene los siguientes atributos:• colorOjos Heredada de la clase Mamíferos• frecuenciaLadrido Definida solo para la clase Perro

• y los siguientes métodos:• tomarColorOjos Heredada de la clase Mamíferos• Ladrar Definida solo para la clase Perro

Superclase

Subclases

Mamíferos

- colorOjos: int

+ TomarColorOjos: int

Perro

-frecuenciaLadrido: int

+ Ladrar: int

gato

-frecuenciaMaullido:int

+ Maullar: int



• Abstracción• Quitar las propiedades y acciones de un objeto para dejar sólo aquellas que

sean necesarias.

• Polimorfismo• Significa tener muchas formas. En lenguajes de programación significa que

una entidad puede tener uno de muchos tipos. En orientación a objetos una variable polimórfica puede referirse a diferentes objetos en diferentes tiempos. Las subclases pueden hacer caso omiso de los métodos o atributos de las superclases y definir los suyos propios.

• 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.

• Encapsulamiento• Se oculta la funcionalidad de los objetos, evitando que otros objetos o el

mundo exterior puedan ver sus operaciones internas.

• Asociaciones• Un objeto puede estar relacionado con uno o más objetos

• Composiciones• La agregación de objetos permite definir composiciones, en las que cada

componente se considera como tal sólo como parte del objeto compuesto.



• Diagramas• Para describir el diseño de un sistema, el lenguaje que usemos debe estar

basado en diagramas, porque la experiencia nos ha mostrado que es así como pensamos en los sistemas.

• No es el diseño, sino una representación de un modelo de el diseño, que captura un aspecto de el diseño de una forma que puede ser discutida.

• 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.

• El modelo dinámico que describe el comportamiento del sistema a través del tiempo.

• podremos tomar una:• Vista lógica nos permitirá alcanzar los requerimientos funcionales. Cuáles partes

van juntas? Cuáles son las clases y sus relaciones?

• Vista de proceso ayuda a lograr los requerimientos no-funcionales, como el desempeño y la disponibilidad. Cuáles necesidades de control hay? Qué actividades pueden ser concurrentes? Qué sincronización debe haber?

• Vista de desarrollo ayuda a administrar el proyecto. Cuál parte hará cada elemento del equipo de gente? Que partes pueden reusarse?

• Vista física ayuda a alcanzar los requerimientos no-funcionales, haciendo una vista más concreta que la de proceso.Cuales partes correrán en la misma computadora?



• Diagramas UML• La relación existente entre los diversos diagramas de UML se

muestra a continuación:

Casos de Uso

Casos de Uso

Diagrama deSecuencias

Diagrama deSecuencias

Diagrama deColaboración

Diagrama deColaboración

Diagrama deClases

Diagrama deClases

Diagrama deEstados

Diagrama deEstados

Diagrama deActividad

Diagrama deActividad

Diagrama deDistribución

Diagrama deDistribución

Diagrama deComponentes

Diagrama deComponentes

CO

DIG

OC

OD

IGO



• Objetos y Clases• Identificar las clases que deben existir en nuestro sistema, es la parte

mas grande del trabajo de diseñar sistemas orientados a objetos.• Construir rápidamente y lo más barato posible el sistema que alcance

nuestros requerimientos.

• Construir un sistema que sea fácil de mantener y adaptar para los requerimientos futuros.

• Cada pieza de comportamiento requerida por el sistema deberá ser proporcionada de una manera sensible, por los objetos de las clases que elijamos.

• Un buen modelo de clases consiste de clases de los objetos principales, los cuales no dependen de la funcionalidad particular requerida actualmente

• Una técnica es la identificación de sustantivos. Descarte los candidatos que sean inapropiados por alguna razón, renombrando las clases restantes si es necesario

• Pueden descartar candidatos por: redundancia, vaguedad, son un evento o una operación, son meta-lenguaje, están fuera del alcance del sistema, son un atributo.



• Objetos y Clases (cont.)• Las cosas que pueden ser clases se refieren a: cosas tangibles (libro,

copia, curso), roles (estudiante, maestro, bibliotecario), eventos (llegada, partida, solicitud), Interacciones (reunión, intersección)

Categoría del concepto Ejemplos

Objetos físicos o tangibles TDPV, Dado

Especificaciones, diseño o descripciones de cosas EspecicacióndeProducto, ReglasdeJuego

Lugares Tienda, MesadeJuego

Transacciones Venta, Pago, Reservacion, Apuesta

Línea o renglón de un elemento de transacciones VentasLineadeProducto

Rol de las personas Cajero, Gerente, Jugador

Contenedores de otras cosas Tienda, Cesto, Biblioteca

Cosas dentro de un contenedor Producto, Libro

Otros sistemas de cómputo o electromecánicos externos al sistema SistemaAutorizacionTarjetasdeCredito

Conceptos de nombres abstractos Hambre, Suerte

Organizaciones DepartamentodeVentas, LineaAerea

Eventos Venta, Robo, Junta, Vuelo, Accidente, RodarDados

Procesos A menudo no están representados como conceptos, pero pueden estarlo)

VentaUnProducto, ReservacionAsiento

Reglas y políticas PoliticadeReembolso, PoliticadeCancelaciones

Catálogos CatalogodeProductos, CatalogodeLibros

Registros de finanzas, de trabajo, de contratos, de asuntos legales Recibo, Mayor, ContratodeEmpleo

Instrumentos y servicios financieros LineadeCredito, Existencia

Manuales y libros ManualdePersonal, ManualdeReparaciones



• Objetos y Clases (cont.)• Diagramas de clases

• Describe la vista estática de un sistema en términos de clases y relaciones entre las clases, la representación de una clase es con:

• ejemplo:

• Los atributos y las operaciones pueden tener diferente visibilidad. Es visible si puede ser referenciado desde otras clases diferentes a donde esta definido, se definen como públicos(+) ,privados(-) ó protegidos (#)

• Una restricción es un texto que especifica una o varias reglas que sigue la clase, se indica mediante un texto libre encerrado entre llaves {}. Existe el OCL que define de manera formal las restricciones en UML.

• Las propiedades se indican mediante llaves, dando propiedades a los elementos donde se haya n incluido estas.

Nombre

Atributos ...

Operaciones ...

Automóvil+ Placa:String-Datos:DatosAutomóvil+ Velocidad:Integer+ Dirección: Dirección+Manejar(vel:Integer, 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, Cuando un objeto manda un mensaje a otro,Le esta pidiendo que ejecute una operación



• Objetos y Clases (cont.)• Diagramas de clases (cont.)

• Los atributos no deberían usarse para relacionar conceptos en el modelo conceptual, solamente para describir estos conceptos. Una de las violaciones más comunes a esta regla consiste en agregar atributos como llaves foráneas.

• Las operaciones son utilizadas para manipular los atributos o realizar otras acciones. Normalmente son llamadas funciones, pero están dentro de una clase y pueden aplicarse solo a objetos de esa clase.

• 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.

• Un objeto se especifica con una firma o con precondición, post-condición algoritmo y el efecto que tiene sobre un objeto.

• La precondición debe ser cierta antes de que la operación pueda ejecutarse.• La post-condición debe ser cierta después de que la operación sea ejecutada.• Estas especificaciones son como propiedades para una operación. Las propiedades

usualmente no se muestran directamente en los diagramas de clases.

• Una clase persistente es aquella cuyos objetos existen aún después de que el programa que los creó ha salido. Se describe la persistencia poniendo la propiedad de “persistent ” dentro del compartimiento del nombre.

• Un constructor es una operación que comparte el mismo nombre que la clase y no tiene tipo definido de retorno, se utilizan generalmente para inicializar la memoria requerida por el objeto y para colocarlo en un estado inicial estable. Algunos lenguajes proveen un constructor default para las clases en caso de que no se proporcione.



• Relaciones entre clases.• Asociación, es una conexión entre clases, lo que significa que también es

una conexión entre los objetos de esas clases. En UML, una asociación es una relación que describe un conjunto de ligas, que están definidas como una conexión semántica entre un conjunto de objetos.

• Corresponden a los verbos. Existen instancias de asociación.

• Normalmente una asociación es bidireccional, lo que significa que si un objeto está asociado con otro objeto, ambos objetos se conocen uno al otro.

• Asociación normal:

• Las restricciones en las asociaciones, permiten que se siga cierta regla:

ComputadoraAutorUsa

Un autor usa una computadora

ClienteCajeroAtiende

Un cajero atiende a un cliente, pero cada cliente es atendido en el orden en que se encuentre en la formación

{Ordenado}



• Relaciones entre clases (cont.)• 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:

• La asociación recursiva es una asociación de una clase a sí misma, una conexión entre objetos de la misma clase

CarroPersonaPosee

Un carro puede tener uno o mas dueños, una persona puede tener cero o más carros

Poseído por

1..* 0..*

Nodo

*

*

conecta

Un nodo se conecta a muchos nodos y estos a su vez se conectan con varios mas. (en una red de cómputo



• Relaciones entre clases (cont.)• Los roles en una asociación especifican el papel que juega un objeto en

una relación, se indica con un string colocado cerca de la terminal de la asociación siguiente a la clase a la cual se aplica.

Contrato deSeguros

CompañíaAseguradora

tieneAsegurador Refiere a

1 0..*

Póliza deSeguros

0..1

1Refiere a Está expresado

en un

0..*

1..*

tiene

Persona

Asegurado

casado con

esposo

esposa



• Relaciones entre clases (cont.)

Categoría de la asociación Ejemplos

A es una parte física de B Caja-TPDV

A es una parte lógica de B VentasLíneadeProducto-Venta

A está físicamente contenido en B TPDV-Tienda, Producto-Estante

A está contenido lógicamente en B DescripcióndeProducto-Catálogo

A es una descripción de B DescripcióndeProducto-Producto

A es un elemento de línea (o renglón) en una transacción o reporte B

VentasLíneadeProducto-Venta

A se conoce/ introduce/ registra/ presenta/ captura en B

Venta-TPDV

A es miembro de B Cajero-Tienda

A es una unidad organizacional de B Departamento-Tienda

A usa o dirige a B Cajero-TPDV

A se comunica con B Cliente-Cajero

A se relaciona con una transacción B Pago-Venta

A es una transacción relacionada con otra transacción B

Pago-Venta

A es propiedad de B TPDV-Tienda



• Tipos de asociaciones• Asociación calificada (Qualified association). Representa la información

de identidad y reduce la multiplicidad de uno a muchos por una de uno a uno.

• Asociación Or {or}. En algunos modelos no todas las combinaciones de asociación son válidas

• Asociación Ordenada {ordered}. Cuando los enlaces entre objetos pueden tener un orden implícito {ordered} {ordenadas por incremento de tiempo}.

CuadroTablero1 1renglón:{1,2,3}

columna:{1,2,3}

AcadémicoEstudiante de

EducaciónMedia Superior

Elige

ComercialElige

{Or}



• Tipos de asociaciones• Clase de Asociación. Una clase puede estar unida a una asociación. Se

usa para agregar información extra sobre un enlace; por ejemplo, el tiempo en que el link fue creado. Cada enlace está asociado a un objeto de la clase de asociación.

• Asociación ternaria (Ternary association). Más de dos clases pueden asociarse con otra, la asociación ternaria asocia tres clases.

Contrato deSeguros

CompañíaAseguradora Asegurador

1 0..*

0..*

1..*

Persona

Asegurado

Póliza de Seguros

0..1

EquipoJugador Participa en

ContratoDirectorGeneral

Negociado por


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

• Tipos de asociaciones (cont.)• Una agregación, es un caso especial de asociación, indica que la relación

entre las clases es de alguna forma parte de un “todo”. Se describen diferentes niveles de abstracción. Se indica con rombo en blanco en el lado de la clase que agrupa a las demás.

• Se puede tener una restricción en una agregación, como en la relación {O} que se indica con línea punteada

• Una composición es una agregación donde cada componente puede pertenecer tan solo a un todo. Se representa con diamante sólido.

• En un juego del gato, los cuadros solo tienen sentido si están formando parte del tablero

Diagramas Estáticos

Comida

1

EnsaladaComida PlatoFuerte Postre1 1 1 1

{O}

Tablero1

Cuadros9



• 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



• 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:

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

Teclado

marcacantidadDeteclas

Ctrl()Alt()RePag()AvPag()...

«interfaz»MaquinaDeEscribir

Teclazo()

Teclado

MaquinaDeEscribir



• 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.

Usa

0..* 1..*

Autor

nombre: Stringedad: Integer

Computadora

nombre: Stringmemoria: Integer

Juan: Autor

nombre= “Juan P.”edad = 33

Bob1:Computadora

nombre=“IBM 128”Memoria=128

Clases:

Objetos:



• Diagrama de Clases• Modelo Conceptual de Punto de Venta

VentasLineadeProducto

cantidad

VentaFechaHora

Pago

Monto

Cliente

TPDV

TiendaDirecciónNombre

CatalogodeProducto

EspecificaciondeProducto

DescripcionPrecioCodigode barras

Producto

Gerente

Cajero

Pagado-por Iniciado-por

Contenidas-en

Capturadas-en

Capturas terminadas

Registra-ventas-en

Iniciado-por

Almacena

Usado-por

Contiene

Describe

Descritas-por

Registra-venta-de

0..1

1

1

1

1

1

1

1..*

*1

1

1

*

1

1..*Contiene

1

1

1

1

1..*

*1

1*

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:

• 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)

Nombre

Variables de estado

Actividades

Inicio

TransiciónEvento quedispara

Estado

Transición

Fin



• Diagramas de estados (cont.)• 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.

• Las condiciones de seguridad permiten establecer una relación entre

estados que dependen de que se cumpla dicha condición.

Inicialización

Hacer/Arrancar

Encender la PC

ApagadoOperación Apagar

Inicialización

Hacer/Arrancar

Encender la PC ApagadoOperación Apagar

ProtectorDe

pantalla

[lapso transcurrido] Teclazo o movimientodel ratón



• Diagramas de estados (cont.)• Subestados. Cuando un estado se encuentra dentro de otro estado,

se conocen como subestados. • Se dice que pueden suceder en forma secuencial cuando suceden uno

tras de otro y se representan dentro del cuadro de estado original, ligados secuencialmente.

• También has subestados concurrentes cuando pueden ocurrir al mismo tiempo. Se representan dentro del estado original, separados por línea punteada.

A la esperade acción del usuario

Registro deuna accióndel usuario

Representación de la accióndel usuario

Verificar el conómetrodel sistema

Actualizardespliegue

[lapso transcurrido]

Operación



• Diagramas de estados (cont.)• Estados históricos.

• Se dice de los estados compuestos que pueden recordar su subestado activo cuando el objeto trasciende fuera de tal estado compuesto.

• 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

A la esperade acción del usuario

Registro deuna accióndel usuario

Representación de la accióndel usuario

Verificar el conómetrodel sistema

Actualizardespliegue


OperaciónH

Teclazoo movimientodel ratón




• Diagramas de estados (cont.)• Cuando utilizar los diagramas de estados:

• Se tendría que hacer uno por cada clase del sistema, 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.

• Algunos sugieren usarlos en los objetos de interfaz de usuario y de control, debido a que tienen el tipo de comportamiento que es útil describir mediante diagramas de estado.

• En caso de que se desee representar las secuencias general de acciones de vario objetos y casos de uso, es mejor utilizar el diagrama de actividades.



• Diagramas de actividades• Describen como se coordinan las actividades, 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.

• Elementos de un diagrama de actividades:• La actividad se muestra como una caja con nombre con las esquinas muy

redondeadas, representa cuando la actividad ha terminado

• La transición se muestra como una flecha, normalmente no se les pone etiqueta, a menos que se tenga una condición.

Actividad

Actividad 1 Actividad 2



• Diagramas de actividades (cont.)• Barras de sincronización, 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. Se utilizan para la ejecución de actividades en paralelo.

Fin de la jornada

Baño Descanso



• Diagramas de actividades (cont.)• Las indicaciones, permiten que se ejecuten otras actividades, usando

un pentágono convexo para el envío del un evento y uno cóncavo para la recepción del evento.

Oprimir numero de canal

Cambiar(canal)Cambiar(canal)

Fin de la jornada

Televisión Remoto.Tecleo (canal)

Oprimir numero de canal



• Diagramas de actividades (cont.)• Diamantes de decisión se usan para mostrar decisiones como una

alternativa a las condiciones, para separar transiciones dejando el mismo estado.

• Marcas de inicio y fin se usan para indicar donde empieza el diagrama y donde termina.

• Particiones y líneas de responsabilidad, Al poner muchas actividades relacionadas entre sí, se pueden colocar de acuerdo al objeto o al actor que las ejecuta, 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, porque

los únicos eventos de interés es la terminación de las actividades.

• Las actividades se pretende que se continúen a lo largo del diagrama sin quedarse estancadas.



• Diagramas de actividades (cont.)• Ejemplo de un diagrama de actividades en una biblioteca.

Encontrar libro en gaveta

[prestatario]

Esperar en la fila

[regresador]

Registrar el regreso

Poner el libro de Regreso en gaveta

Registrar el préstamo

Preparar parael siguiente miembro

miembro bibliotecario

[regresando]

[obteniendo prestado]



• Diagramas de actividades (cont.)• Cuando utilizar diagramas de actividades:

• Debido a que manejan y promueven el comportamiento en paralelo, son una herramienta muy útil para el modelado de flujo de trabajo y para la programación multihilos.

• Se recomienda usarlos para:• El análisis de un caso de uso. Para comprender qué acciones deben

ocurrir y cuáles son las dependencias de comportamiento. Asignando posteriormente los métodos a los objetos y mostrando tales asignaciones mediante diagramas de secuencia o colaboración.

• La comprensión del flujo de trabajo, a través de numerosos casos de uso. Para representar y entender el comportamiento de las interacciones entre los casos de uso. Ayuda a aclarar situaciones dominadas por flujo de trabajo.

• Cuando se trata de aplicaciones multihilos. Son adecuados en éste uso

• No sirven para:• Tratar de ver como colaboran los objetos. Usar mejor 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.



• Diagrama de secuencias.• Muestra la forma en que los objetos se comunican entre sí al

transcurrir el tiempo. Constan de objetos y representando en una línea vertical el tiempo, 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.

• Los mensajes van de un objeto a otro se representan con líneas. Pueden ser simples (transfieren control), sincrónicos (esperan respuesta) o asincrónicos (no espera respuesta)

:Objeto 1 :Objeto 2



• Diagrama de secuencias. (cont.)• 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.• El Pedido envía entonces un mensaje “prepara” a cada línea de

pedido dentro del Pedido.• Cada Línea de pedido revisa el Artículo de inventario

correspondiente.• - Si esta revisión devuelve “verdadero”, la Línea de pedido

descuenta la cantidad apropiada de Artículo de inventario del almacén.

• Si no sucede así, 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.

• En el diagrama siguiente se muestra el diagrama de secuencia omitiendo las activaciones, que según Fowler, no aportan mucho a la ejecución de procedimientos y solamente sugiere usarlas en situaciones concurrentes.



• Diagrama de secuencias. (cont.)• El siguiente ejemplo muestra

Ventana de Entrada de Pedidos

unPedido

prepara()

Una Línea de Pedido

Un artículo de inventario

*[para cada línea de pedido]prepara()

hayExistencia:=revisa()

[hayExistencia]descuenta()

necesitaReorden:=necesitareordenar()

Un Artículode reorden

[necesitaReorden]nuevo

Un Artículopara entrega

[hayExistencia]nuevo()

Objeto

Iteración

Mensaje

Condición

Autodelegación

Creación

Regreso



• Diagrama de secuencias. (cont.)• 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.

• Los mensajes representados por líneas están en orden de arriba hacia abajo. La autodelegación es un mensaje que un objeto se manda a sí mismo.

• Una condición indica cuándo se envía un mensaje, el cual se enviará solo si la condición es verdadera.

• Una iteración muestra cuando un mensaje se envía varias veces a varios objetos receptores, como sucedería cuando se itera sobre una colección.

• El regreso indica el regreso de un mensaje, no un nuevo mensaje. Los regresos SATURAN los diagramas y tienden a oscurecer el flujo, Fowler recomienda usarlo solamente cuando ayuden a aumentar la claridad.

• El borrado de un objeto se muestra con una X grande. Los objetos pueden autodestruirse o pueden ser destruidos mediante otro mensaje.



• Diagrama de secuencias. (cont.)• Otra ilustración adicional nos permitirá visualizar las activaciones y

la creación de objetos.

• Ejemplo de una transacción bancaria:• Cuando se crea una Transacción, ésta crea un Coordinador de

transacción que coordina el trámite de la transacción. Este coordinador crea una cantidad (en el ejemplo, dos) de objetos Revisor de Transacción, cada uno de los cuales es responsable de una revisión particular. Este proceso permitirá añadir con facilidad otros proceso de revisión, porque cada registro es llamado asincrónicamente y opera en paralelo.

• Cuando termina un revisor de transacción, se le notifica al coordinador de transacción. El coordinador comprueba si todos los revisores respondieron; de no ser así, no hace nada. Si todos han respondido indicando terminaciones exitosas, como en este ejemplo, entonces el coordinador notifica a la Transacción que todo está bien.



• Diagrama de secuencias. (cont.)

UnaTransacción

nuevo

nuevo unCoordinadorde transacciones

nuevo un primer Revisor

de transacción

nuevoun segundo

Revisor de transacción

bien

bien

¿todo terminado?

¿todo terminado?es Válido

se suprimen las demástransacciones

el objetose borra a sí mismo

Autodelegación

Activación

Mensaje asíncrono



• Diagramas de secuencias. (cont.)• Cuando utilizar los diagramas de secuencias, se sugieren para:

• Son útiles para ver la interacción entre los objetos, debido a que pone énfasis en la secuencia y es fácil apreciar el orden en el que ocurren las cosas.

• 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 son para mostrar un comportamiento simple, 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.



• Diagramas de colaboraciones.• Muestra los objetos,las relaciones entre ellos, los mensajes que se

envían los objetos entre sí.• El mensaje se representa como una flecha cerca de la línea de asociación

entre dos objetos. Esta flecha apunta al objeto receptor. El tipo de mensaje se mostrará en una etiqueta cerca de la flecha.

• 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.

• Se agregará una cifra al mensaje para indicar la secuencia propia del mensaje.

:Nombre1

:Nombre2

:Nombre3

1:Agregar()

3:Actualizar()

2:Modificar()



• Diagramas de colaboraciones. (cont.)• Ejemplo de un diagrama de colaboraciones:

• El actor es el usuario quien inicia la interacción al oprimir una tecla, 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.

:GUI

:Sistema operativo

:CPU

:Tarjeta de video

:Monitor

Tecleo

1:notificar(tecleo)

3:actualizar(tecleo)

2:actualizar(tecleo)

4:notificar(tecleo)

5:mostrar(tecleo)

6:respuesta()



• Diagramas de colaboraciones. (cont.)• Cuando utilizar los diagramas de colaboración, se sugieren para:

• Es la mejor forma si se quiere mostrar los objetos y mostrar como se reconectan estáticamente unos con otros.

• Cuando se desee ver el comportamiento de varios objetos en un caso de uso.

• Sirven para mostrar la colaboración entre los objetos, sin embargo, no sirven tan bien para la definición precisa del comportamiento

• No se sugieren para:• No son convenientes para representar el comportamiento condicional,

debido a que son para mostrar un comportamiento simple, 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.


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. Su representación es:

• Hay diferentes tipos de componentes y cada uno con diferentes tipos de dependencia , Clasificándolos en relación con el proceso de compilación un componente podría ser:• Código fuente, el cual depende de que otros componentes estén disponibles al

momento de compilación.

• Código objeto binario, (biblioteca de clases) que depende de cualquier código objeto al cuál se ligara desde un programa ejecutable.

• Una aplicación ejecutable, la cuál puede depender de otros programas ejecutables al tiempo de ejecución.

• Los detalles dependen del lenguaje de programación usado, se pueden usar estereotipos como «compilar» ó «ligar», igualmente se pueden usar estereotipos para diferenciar los diferentes tipos de componentes, por ejemplo: «archivo» , «biblioteca» , «ejecutable» , «tabla», «documento»

calculadora.java



• Diagramas de componentes (cont.)• Cada clase del modelo lógico se realiza en dos componentes: la

especificación y el cuerpo.

• La especificación contiene la interfaz de la clase mientras que el cuerpo contiene la realización de la clase.

• En el caso de clases parametrizables se puede dar una especificación genérica.

• Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente se refiere a los servicios ofrecidos por otro.

• Los distintos componentes pueden agruparse en paquetes según un criterio lógico y con vistas a simplificar la implementación. Son paquetes estereotipados en «subsistemas» para incorporar la noción de biblioteca de compilación y de gestión de configuración.



• Diagramas de componentes (cont.)• Un diagrama de componentes mostrando las dependencias de

tiempo de compilación:

• La interfaz se puede representar por una línea con un círculo

streams.o«biblioteca» MiEntradaSalida

MiAplicación«ejecutable»

«compilar»

«ligar»

Programade búsqueda

Resultado dela búsqueda



• Diagramas de componentes (cont.)• Si un componente implementa clases se puede establecer la relación

entre el componente y las clases como sigue:

ProcesadorTextos.exeClases:

ProcesadorTextosVerificadorOrtografico

ContadorPalabras

ó

ProcesadorTextos.exe

ProcesadorTextos VerificadorOrtografico ContadorPalabras



• Diagramas de componentes (cont.)• Solo se podrán ejecutar las operaciones dentro de un componente a

través de su interfase. La relación entre un componente y su interfase se conoce como realización. Un componente puede acceder a los servicios de otro componente mediante el uso de su interfase, al que proporciona el servicio se dice que provee una interfaz de exportación, al que accede a un servicio se dice que utiliza una interfaz de importación.

• Se puede sustituir un componente por otro si el nuevo contiene las mismas interfases que el anterior. Se puede reutilizar un componente en otro sistema si éste puede acceder al componente reutilizado mediante sus interfases.

AWTEventMulticaster«Interfaz»

ElementoDeEscucha

cambioAlEstadoDelElemento()



• Diagramas de componentes (cont.)• Página Web con controles ActiveX.

VBScript

Animacion.htm

«ActiveX»DisposicionAnimacion.alx

«ActiveX»ImagenEsfera

«ActiveX»CronometroEsfera

«ActiveX»CuadroCombCronometro

«ActiveX»BotonReinicar

«ActiveX»CuadroCombDistancia

«ActiveX»BotonDetener

«ActiveX»BotonEjecutar

Esfera.gif



• Diagramas de distribución.• 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.

• Un nodo representa todo tipo de equipo de cómputo y se representa por un cubo:

• Los estereotipos permiten precisar la naturaleza del equipo:• Dispositivos

• Procesadores

• Memoria

• Etc.

Nodo



• Diagramas de distribución.• Los nodos se interconectan mediante soportes bidireccionales (en

principio) que puede a su vez estereotiparse.

• Se pueden mostrar los componentes en relaciones de dependencia con un nodo:

Servidor

Directorio telefónicocorporativo

Programa debúsqueda




• Diagramas de distribución. (cont.)• Las conexiones entre nodos se puede poner mediante una relación

Cliente

Programa de Presentación

Servidor

Directorio telefónicocorporativo

Programa debúsqueda


«Comunicación»



• Diagramas de distribución. (cont.)• Aplicación de los diagramas de distribución.

• Un equipo de cómputo casero podría ser como sigue:

PCPentium 300Mhz

Windows 95

Office 2000 Visio 5Enterprise

PCPentium 300Mhz

Windows 95

Office 2000 Internet Explorer

«Dispositivo»Scanner Microtek

SlimScanC3

«Dispositivo»Monitor Daewoo

CMC-1505

«Dispositivo»Impresora

HP Deskjet 610L

«Dispositivo»Impresora

HP Lasejet 5L

«Dispositivo»Camara Digital

Polaroid Flash640

«Dispositivo»Modem ESS 336V

«Dispositivo»Monitor

PackardBell

«Dispositivo»Conector T

«Dispositivo»Conector T

«Dispositivo»Terminador

«Dispositivo»Terminador

«Procesador»ISP Infosel.net

Internet


Análisis y Diseño de Sistemas de Información Caso de Estudio (CS4)

• Presentación del caso.• Administración CS4• Un estudiante CS4 (eCS4), es cualquier estudiante que esta tomando cualquier módulo

de cuarto año en el departamento de ciencias computacionales, ya sea que este o no inscrito para un grado en ciencias computacionales.

• Al final de cada año académico, 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.

• Al final de cada año el Jefe del Departamento fija actividades para los miembros del cuerpo de maestros y otros, 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. El coordinador CS4 (CCS4) actualiza otras partes de cada manual y checa los apuntes producidos por los profesores adjuntos. Los apuntes de los módulos están escritos en el lenguaje de formato LATEX.

• 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.

• El CCS3 proporciona una lista de los estudiantes entrando a CS4 provenientes de CS3 al CCS4 y al OEP. El CCS4 le dice al OEP acerca de cualquier otro estudiante que provenga de de otros cursos que no sean CS3. 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.

• Cada estudiante es avisado por un miembro del cuerpo de maestros que actúa como Director de Estudios (DdE). Un DdE se asigna a un estudiante en su primer año de estudios y permanece con ésa función hasta que termina.

• Los estudiantes se inscriben en forma provisional en los módulos llenando una forma y entregándola en la Oficina de Enseñanza Profesional . El OEP verifica que cada estudiante que se inscriba, esté listado como un eCS4, y cada eCS4 es inscrito en un numero razonable de módulos. En caso de duda, se consulta al DdE del estudiante y se puede tener una plática con el estudiante.

• El OEP produce luego las listas para los adjuntos de los estudiantes que tomarán sus módulos. Estas listas no pueden llegarles a los adjuntos antes de la semana 3. Esto es, muy tarde para que los adjuntos puedan saber cuántas copias deben preparar de su material.



• Administración CS4 (cont.)• Cada uno de los cursos de grado tiene su propio manual de curso, los principales cursos

existentes son: Ciencias Computacionales, Ciencias Computacionales e Inteligencia Artificial, Ciencias Computacionales y la Ingeniería Electrónica, etc.

• Los detalles de la asesoría y las reglas acerca de cuáles combinaciones de módulos son aceptables, son diferentes para cada grado, igualmente hay manuales separados para cada uno de ellos.

• Sin embargo, muchos módulos se aceptan en varios diferentes cursos de grado, y en cada caso la descripción de cada curso es igual en cada manual.

• 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, 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, especialmente el CCS4.• Permitir a los estudiantes inscribirse en los módulos en línea.• Que el OEP pueda obtener fácilmente información actualizada y confiable.• Mejorar el seguimiento de dicha información.• 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, automatizando su producción.

• 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, qué módulos está tomando el estudiante, cuales cursos de grado esta llevando un eCS4, o cuál miembro del staff es el DdE de un eCS4.

• Deberá poder dar información sobre los módulos, quiénes los imparten, de que curso forman parte y que estudiantes los están tomando.



• 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. Y se dejará fuera de la respuesta, quedando pues los siguientes casos de uso:

• Producir el manual del curso

• Producir la lista CS4

• Inscribir en los módulos.

Producir la lista CS4

Producir elmanual del curso

Inscribir en losMódulos

Organizador Cursos CS3 CCS4

OEP Adjunto CS4

eCS4 Director de estudios 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.

• El organizador de CS4 actualiza las secciones principales de cada manual de curso obteniendo el texto actual del sistema, modificándolo y regresándolo modificado al sistema.

• El adjunto de cada módulo, actualiza la descripción del módulo tomándolo del sistema, actualizándolo y regresándolo al sistema.

• Estas actualizaciones pueden suceder en cualquier orden. El sistema conserva el registro de cuáles cambios se han hecho. Una vez que se hicieron todas las actualizaciones, el sistema envía el texto completo del manual por correo electrónico al OEP, 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.



• Diagrama de clases (CS4)• Un diagrama de clases a nivel conceptual, sin incluir actividades y

operaciones:

Adjunto

Módulo

Cursos Grado

Estudiante 4to año

Estudiante otros años

Estudiante

Director deEstudios

1

1

0..*

6..*

1..*

6

1..*

0..*

0..*

1

Imparte

toma

dirige

esta en



• Diagrama de actividad (CS4)• El siguiente diagrama muestra el flujo de trabajo requerido para

determinar qué cursos hay, quien los imparte, generar los manuales de los cursos:

Determinar los módulos

Comité Académico

AsignarAdjuntos

Jefe deDepartamento

Adjunto OEP CCS4

Imprimir manual

Generar versiónHTML

Actualizar seccionesprincipales

Actualizar registro de módulo


Análisis y Diseño de Sistemas de Información Caso de Estudio (Restaurante)

• Presentación del caso.• Las empresa Restaurantes,S.A. ha hecho una encuesta sobre el mundo de los

restaurantes y ha llegado a sorprendentes conclusiones: a la gente le gusta comer fuera, pero no disfruta algunos momentos de ésa experiencia. Y deciden construir el restaurante del futuro, que deje a la gente darse el gusto y que mejore los resultados para el cliente.

• Entrevista de Análisis• ¿Qué sucede cuando un cliente entra al restaurante? R: Si el cliente tiene un abrigo,le

ayudamos a quitárselo, lo almacenamos en el guardarropa y le damos un boleto para solicitarlo posteriormente. Lo mismo hacemos con el sombrero.

• ¿Y si hay línea de espera, se forma? R: Se le pregunta si hizo reservación, en cuyo caso lo pasamos lo más pronto posible. 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.

[Prefiere el área de espera]

Entra el cliente

Ayudar a quitárselo Guardarlo

Dejar su nombre

Espera en el bar

Aguarda en el Área de espera

[Tiene abrigo y/o sombrero]

[Lista de espera]

[No hizo reservación]

[Prefiere el bar]



• Presentación del caso. (cont.)• Entrevista de Análisis (cont.)• ¿Cuando le llega el turno al cliente, es hora de sentarlo? R: La mesa deberá estar lista;

para ello, deberá ser limpiada. Un mozo de piso debe cambiar el mantel usado por el cliente anterior y acomodar la mesa. Cuando esta lista el capitán de meseros lleva al cliente a su mesa y luego llama a un mesero, si el cliente estaba bebiendo en el bar, se podrá llevar su bebida. Los meseros tienen asignadas sus áreas de servicio y saben cuando está lista una mesa.

• ¿Luego que ocurre? R: El mesero llega a la mesa, entrega un menú a cada comensal y les pregunta si desean alguna bebida mientras deciden. Luego llama a un “asistente” quién coloca una charola con pan y mantequilla. Si alguien ha pedido una bebida el mesero la traerá.

• ¿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. Cuando el cliente llama la atención del mesero, éste regresa a tomarle su orden. Y luego lo notifica al chef. Mediante la transcripción de la elección en un formulario, llamado comanda.

• ¿Qué contiene la comanda? R: La mesa, la elección y la hora. 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.

• ¿Por qué es tan importante la prioridad? R: La mayoría de las comidas incluyen un entremés antes del plato fuerte. A la mayoría de la gente le gusta comer el plato fuerte caliente, el chef prepara el entremés y el mesero se lo lleva al cliente. El reto está en llevar el plato fuerte, caliente a todos los comensales en la mesa al mismo tiempo.



Diagrama: “Servir a un cliente”

[Prefiere el área de espera]

Entra el cliente

Ayudar a quitárselo Guardarlo

Dejar su nombre

Espera en el bar

Aguarda en el Área de espera

[Tiene abrigo y/o sombrero]

[Lista de espera]

[No hizo reservación]

[Prefiere el bar]

Alistar la mesaSentar al cliente

Llamar al mesero Mostrar el menú

Tomar un pedido de bebidas

[Desea bebida]

Llamar al asistenteIr por las bebidas

Servir Pan y aguaTraer bebida

Sugerir platillo Leer Menú Elegir Notificar al chef

Traer entremes Preparar platillo

Modelado enun diagramaPor separado



• Entrevista de Análisis (cont.)• ¿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; después el mesero lleva el plato fuerte a la mesa. Los comensales ingerirán sus alimentos, y el mesero regresará al menos una vez para verificar si todo está bien.

• ¿Qué sucede cuando los clientes terminan de comer? R: El mesero regresa y pregunta si desean postre, en cuyo caso el mesero dará el menú de postres y tomará las órdenes. En caso de no desearlo pregunta si desean café, en caso de aceptarlo, traerá el café, tazas y les servirá. Si no desean nada, traerá la cuenta. Luego regresará y obtendrá el pago en efectivo o en tarjeta de crédito. Luego traerá el cambio o los vouchers, los clientes dejarán una propina, recogerán sus abrigos y se irán.

• ¿Qué debe hacer el mesero cuando el cliente salga? R: Llamar al mozo de piso para limpiar la mesa, la preparará y estará lista para los siguientes comensales.



Diagrama de “Servir a un cliente” (cont.)

Traer entremés Preparar platilloModelado enun diagramaPor separado

Traer el plato fuerteIngerir entremés

Ingerir plato fuerte

Traer el menú de postres

[Desea postre]

Traer postres

Ingerir postres

Servir café

Beber café

[Desea café]

Trae la cuenta

Liquidar cuentaDejar propinaRecoger abrigo

o sombrero

[Guardar abrigo/sombrero]

Salir



• 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, en momentos distintos. Entre el mesero y el chef se coordinan para traerles a todos los platos fuertes al mismo tiempo. El chef recibe la comanda y empieza a preparar los entremeses y el plato fuerte, cuando esta terminado el entremés, el mesero va a la cocina, los toma y los lleva a la mesa.

• ¿Cómo se entera el mesero que ya están listos los entremeses? R: El mesero va a la cocina de vez en cuando. El chef luego de dar el entremés al mesero, 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. El mesero va a la cocina, y le avisa al chef que ya casi están listos para el plato fuerte, el chef termina su preparación. El mesero los toma y los lleva a la mesa



• Preparación de platillos

Recibir comanda

Preparar entremeses Iniciar la preparación Del plato fuerte

Coordinar la preparación de otros pedidos

Llevar entremeses

Ingerir entremesesRecibir la notificación de que los

Entremeses casi se han consumido

Finaliza la preparación de plato fuete

Tomar el plato fuerte

Llevar Plato fuerte



• Clases y asociaciones• El cliente se asocia con una gran cantidad de clases, como muestran las

asociaciones a continuación:

Cliente

Postre

Ingiere

Cuenta

Liquida

Propina

Deja

Reservación

Hace

MeseroEs atendido por

Sombrero

Abrigo

Da a guardar

Encargado del Guardarropa

Orden

Hace

Menú

Elige del

Alimento

Ingiere

Menú del postre

Elige del

1

1

1

1

1

1

1

1

1..*1

1

0..*

1

1

Da a guardar 1

0..*

1

1111

1 11



• Detalle de las clases• Cliente, sus atributos serían:

Cliente

nombrehorallegadaordenhoraservicio

ingerir()beber()ordenar()pagar()



• 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

nombredomicilioRFCañosExperienciafechaContrataciónsalario

Asistente

trabajaCon

preparar()cocinar()servirPan()servirAgua()

Mesero

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

Chef

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

Gerente

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



• Diagrama de distribución, 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. La cocina tendrá una terminal de escritorio y una o varias pantallas. El gerente tendrá una en su oficina.

«Dispositivo»Computadora

palmtop

«Dispositivo»Red

Inalámbrico

«Dispositivo»PC de la cocina

«Dispositivo»PC delgerente



• Casos de uso• El paquete mesero

Mesero

Tomar una orden

Cambiaruna orden

Transmitir la ordena la cocina

Incluir

Incluir

Llamar a un Asistente

Sondear el progresoDe la orden

TotalizarUna cuenta

Transmitir unaOrden al bar

Notificar al chef del progreso de los clientes

En sus alimentos

Tomar una ordenDe bebida

Llamar a un mozode piso

Recibir una notificaciónde la cocina

Recibir una notificacióndel bar

Imprimiruna cuenta

Obtener un acuseDe recibo

Documents

UML Ingeniera Sw Ejemplos