Analisis 101018120712 Phpapp02

Anlisis y Diseo de Sistemas de Informacin
Temario
Temario
Ingeniera de Software Estructuras de Objetos Diagramas Estticos Diagramas de Clases Diagramas de Casos de Uso Diagramas Dinmicos Diagramas de Estado Diagramas de Actividades Diagramas de Secuencias Diagramas de Colaboracin Diagramas de Implementacin Diagramas de Componentes Diagramas de Distribucin Casos de estudio Patrones de Diseo Metodologas
Analisis.ppt
Pag. 1
Bibliografa
Bibliografa
Perdita Stevens, Rob Pooley Matt Weisfeld Joseph Schmuller James J. Odell Craig La rman Kendall & Kendall Martin Fowler con Kendal Scott Addison Wesley. Updated Edition 2000. http://www.dcs.ed.ac.uk/home/pxs/Book/ Sams Publishing, 2000 Editorial Prentice Hall, Primera Edicin 1999 Cambridge University Press. 1998 Prentice Hall. 1999 Prentice Hall. Pearson Educacin. Tercera Edicin. 1995 Addison Wesley. Pearson. 1999
Using UML. Software Engineering with objects and Components The Object -Oriented Thought Process Aprendiendo UML e n 24 Horas Advanced Object -Oriented Analysis & Design Using UML UML y Patrones. Introduccin al anlisis y diseo orientado a objetos. Anlisis y Diseo de Sistemas UML gota a gota
Analisis.ppt
Pag. 2
Ingeniera de Software
Qu es un BUEN SISTEMA?
Un buen sistema (o uno de alta calidad) es aqul que cumple con las necesidades del cliente. El sistema debe ser:
UTIL y UTILIZABLE: Un buen software hace ms fcil o mejor la vida a las personas. CONFIABLE: Un buen software tiene pocos errores. FLEXIBLE: Las necesidades cambian con el tiempo, an cuando el software se est
desarrollando, entonces es importante poder hacer cambios posteriores al software. Debe podrsele dar mantenimiento despus de liberado. ACCESIBLE: tanto para comprar como para mantener. Debe ser razonablemente fcil y rpido 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, bsqueda de informacin, etc. Lo que indica que estamos haciendo las cosas correctamente.
Analisis.ppt
Pag. 3
Problemas:
Hay sistemas que no cumplen con las necesidades de los usuarios y/o tienen fallas tcnicas. Generalmente, los sistemas no estn actualizados ni cuando se estn diseando. An existe el error de la computadora como excusa a un mal servicio a los clientes. La mayora de los usuarios de PCs esperan que sus aplicaciones y an 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 tambin resulta evidente, como lo muestran el problema del milenio y la adecuacin 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 ms alto costo asociado con el software
Analisis.ppt
Pag. 4
Problemas an ms drsticos.
A veces las fallas en algunos de los atributos deseables de los sistemas han provocado catstrofes 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 prdidas (1993) Manejo de maletas de Denver: Fallas del sistema y el alto costo de corregirlo, no permita al aeropuerto abrir a tiempo. Sistema de Ambulancias de Londres: Fallas de diseo y de ejecucin provocaron la muerte de gente por falta de ambulancias (1992) Therac-25: Sobredosis radioactivas por fallas en el software de la mquina a varias personas (1987)
Segn W. Wayt Gibbs en Softwares chronic crisis. Scientific American (International Ed.) pp 72-81, Sep. 1994. dice: En promedio, los proyectos grandes toman 50% ms de tiempo de lo
planeado; 75% de los proyectos grandes tienen fallas operacionales; 25% de los proyectos grandes son cancelados
Analisis.ppt
Pag. 5
Promesas, promesas
Cada nueva tecnologa promete reducir los tiempos de desarrollo e incrementar los promedios de xito de los proyectos. Todos lo dudamos. Segn Frederick P. Brooks (The mythical man-month, AddisonWesley 1975/1995), mientras ms grande sea el proyecto, mayor ser la proporcin del costo y tiempo del proyecto gastado en la comunicacin entre la gente del proyecto, porque cada persona tiene ms gente con quin comunicarse. Cuando un proyecto empieza a quedarse atrs en el tiempo, el poner ms gente por lo general falla. El Departamento de Defensa de EU, intent resolver la crisis del software y comision el diseo del lenguaje de programacin ADA, el cual se estandariz en 1983, el cual soportaba lo mejor de los conceptos de anlisis, diseo y programacin estructurados, la modularidad y la encapsulacin fueron conceptos clave en el diseo del lenguaje, pero an esta enorme inversin ha fracasado.
Analisis.ppt
Pag. 6
Cmo son los sistemas considerados buenos?
El problema fundamental para comprenderlos es: Hay un lmite de cunto puede entender un humano en un momento dado Los sistemas pequeos, son realizados mediante programacin heroica en la cual una sola persona pretende recordar todo lo relevante acerca del sistema. Pero en general esto es imposible. La evolucin del entendimiento de un problema seria como sigue: 1.- Los sistemas son muy complejos y no se puede centrar solo en el
cdigo cercano al cambio por realizar sino que se debe entender partes ms lejanas. Si el GOTO esta eliminado, esto se facilitara porque no habra cdigo espagueti 2.- Un sistema es un conjunto de mdulos y existen algunas dependencias entre ellos. En el sentido ms general, un mdulo puede ser cualquier bit identificable de un sistema por lo cual tiene sentido considerarlo en forma separada. Los mdulos pueden ser: Archivos Subrutinas Funciones de biblioteca Clases, en un lenguaje orientado a objetos. Otras partes conocidas como mdulos o similares Programas o subsistemas independientes o semi-independientes.
Analisis.ppt
Pag. 7
Cmo son los sistemas considerados buenos? (cont.)
Caractersticas de los mdulos para que el desarrollo y mantenimiento del sistema sea lo ms fcil, barato y confiable posible: dependencia (dependency) acoplamiento (coupling) Bajo cohesin (cohesion) Alta interfase (interface) Definida encapsulacin (encapsulation) Mdulos abstraccin (abstraction) Alta cohesin Componente (component) Insertable, reusable El mdulo A depende del mdulo B si un cambio en el mdulo B significa que el mdulo A tambin 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 travs del sistema
Analisis.ppt
Pag. 8
Encapsulamiento: Acoplamiento bajo
Queremos minimizar el numero de casos en los cuales un cambio a un mdulo genera un cambio en otro mdulo. Tenemos que conocer cuales cambios dentro de un mdulo pueden afectar el resto del sistema. Para tomar ventaja del acoplamiento bajo de un sistema, es importante ser capaz de identificar cuales mdulos estn acoplados, de otra forma se tendr que gastar esfuerzo verificando si hay que hacer cambios a un mdulo, lo cual es un costo an cuando no fue necesario el cambio. Nos gustara tener certeza sobre los cambios. Una vez que las fronteras entre los mdulos de nuestro sistema estn definidas, hay dos clases de informacin que puede ser til: 1.- Qu suposiciones de un mdulo dado pueden los clientes hacer
acerca de l? Contestando, nos permitir conocer que clase de cambios a un mdulo pueden ser peligrosos (servicios que provee?) 2.- Cules mdulos son clientes de un mdulo dado? Contestando, nos dice cules mdulos tendrn que cambiar, si hacemos un cambio peligroso a un mdulo.
Analisis.ppt
Pag. 9
Encapsulamiento: Acoplamiento bajo (Cont.)
Interfases Una interfase a un mdulo define algunas caractersticas del mdulo
sobre las cules sus clientes pueden depender. El resto del sistema solo puede usar el mdulo en formas permitidas por las interfases; esto es, una interfase ENCAPSULA el conocimiento acerca de los mdulos. Las conexiones entre mdulos son las suposiciones que hacen los mdulos unos acerca de otros Cualquier suposicin 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 mdulo cambia internamente sin cambiar su interfase, este cambio no necesitar otros cambios en otras partes del sistema. Idealmente debera haber una verificacin automtica de que otros mdulos no hacen suposiciones que no estn documentadas en esta interfase, y tambin de que el mdulo siempre justifica las suposiciones que estn documentadas. En un lenguaje de programacin, mientras ms permita que esas verificaciones sean automticas, se dice que ms soporta la modularidad y la encapsulacin.
Pag. 10
Analisis.ppt
Dependencias del contexto Existen varias razones para querer conocer no solo qu dependencias
pudieran existir (esto es, qu caractersticas estn documentadas en las interfases de los mdulos del sistema) sino tambin qu dependencias existen realmente. Sabemos que un cambio en un mdulo puede afectar a sus clientes; sus clientes (por definicin) son aquellos mdulos que pueden necesitar un cambio, entonces es importante ser capaz de decir cules son ellos. Suponga que quiere reusar un mdulo. Es necesario saber no solo qu servicios provee (cual es su interfase) sino tambin qu servicios requiere para trabajar. Los servicios que un mdulo requiere son llamados sus dependencias de contexto. Ellos pueden a su vez ser expresados en trminos de interfases; el mdulo 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 mdulo y la propia interfase del mdulo garantiza que proveer los servicios descritos en su interfase.
Analisis.ppt
Pag. 11
Beneficios de la modularidad con interfases definidas. An una interfase muy pobre para un mdulo incorrectamente
seleccionado puede hacer a un sistema ms fcil de entender y modificar. Porqu? Cualquier elemento que reduzca lo que tiene que ser conocido acerca de un mdulo es benfico en varias formas: En un equipo de desarrollo, la gente desarrollando cdigo que usa un mdulo, solo deber entender la interfase del mdulo, no cmo trabaja, entonces seran ms productivos. Debido a que los desarrolladores pueden ignorar en forma segura algunos aspectos del sistema, tendrn un mejor entendimiento de los aspectos que s necesitan conocer, entonces se introducirn menos errores. Los errores debern ser ms fciles de encontrar (en desarrollo y mantenimiento), porque se evitar el examinar mdulos irrelevantes. Una vez que existe un mdulo, con documentacin de lo que provee y lo que requiere, es posible considerar reusarlo. El reto real, es definir buenos mdulos con las cosas correctas en sus interfases. Solo entonces se pueden lograr los beneficios completos.
Analisis.ppt
Pag. 12
Un mdulo puede tener varias interfases A veces es necesario documentar los servicios que un mdulo provee con
varias y diferentes interfases, de un modo que podamos ser ms 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 Cmo son los sistemas considerados buenos?
Un buen sistema consiste de mdulos encapsulados
Analisis.ppt
Pag. 13
Abstraccin: Alta Cohesin.
Los buenos mdulos tienen la propiedad de que sus interfases proveen una abstraccin de alguna cosa que se entiende intuitivamente la cual sin embargo puede ser compleja de implantar. Tales mdulos se dice que tienen una alta cohesin. La interfase realiza una abstraccin de las cosas que el desarrollador no tiene que entender para usar el mdulo, dejando una figura coherente de lo que el usuario de un mdulo quiere conocer. El desarrollador est protegido de informacin irrelevante acerca de cmo el mdulo hace lo que hace. Esta preocupacin de permitir al desarrollador concentrarse en lo esencial es ligeramente diferente a la preocupacin de encapsulacin para lograr un acoplamiento bajo, lo cual va dirigido a la prevencin de que el desarrollador use informacin escondida.
Abstraccin es cuando un cliente de un mdulo no necesita saber ms de lo que est en la interfase. Encapsulacin es cuando un cliente de un mdulo no es capaz de conocer ms de lo que est en la interfase.
Si un mdulo, de cualquier tamao y complejidad, es una buena abstraccin (tiene una alta cohesin y un acoplamiento bajo) puede ser factible de reusarlo en posteriores sistemas, o de reemplazo en sistemas ya existentes. Estaramos hablando de un componente insertable o conectable (pluggable component)
Analisis.ppt
Pag. 14
Arquitectura y componentes
La arquitectura donde se desarrolla y aquella dnde se va a usar. En los 80s y principios de los 90s, la tecnologa orientada a objetos iba a ser la solucin 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 mdulo con propiedades que lo hacen reusable y reemplazable. Qu determina cuando un mdulo es reusable?
Tiene una cohesin alta Acoplamiento bajo con el resto del sistema Interfase bien definida Abstraccin encapsulada de una cosa bien entendida
Si un mdulo es reusable depende del contexto en que se desarroll y en

el cual va a ser reusado. Ejemplo de un factor no tcnico de reuso: Recompensar al programador por el nmero de lneas que escriben. Los factores tcnicos involucran decisiones de arquitectura y ms alto nivel.
Analisis.ppt
Pag. 15
Diseo 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 ms pronto en el proyecto. Son afectadas por la naturaleza de los componentes en la arquitectura Pueden ser influenciadas por el medio ambiente del proyecto
Analisis.ppt
Pag. 16
Cmo 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 verificacin y validacin, tan esenciales como construir el producto en s mismo. Usar un almacn de CONOCIMIENTOS, ARQUITECTURAS y COMPONENTES relevantes. Hacer un uso sensible de herramientas.
Analisis.ppt
Pag. 17
Proceso de desarrollo
Mtodo tradicional para el desarrollo de Sistemas Anlisis Diseo Implementacin Pruebas Mantenimiento
Cada fase se realiza hasta que se complet la anterior. Supone que no se vuelve a
entrar en las fases terminadas. Administracin de riesgos implica: 1.- Cada vez que se toma una decisin se tiene el riesgo de que sea incorrecta. Mientras ms se tarde en detectar un error ms difcil es corregirlo. Evaluaciones frecuentes ayudan a corregir. 2.- Un riesgo mayor es que los desarrolladores malinterpreten los requerimientos. La elaboracin deTransicin prototipos permite reafirmarlos. Construccin Espiral de desarrollo:
Diseo Anlisis
Pag. Analisis.pptBooch, James Rumbaugh, Ivar Jacobson se unieron para formar el Lenguaje de 18
Metodologa Unificada. Gran cantidad de metodologas orientadas a objetos han salido a la luz y las de Grady
Proceso de desarrollo (cont.)
Procesos donde utilizar UML. Los procesos iterativos debern tener un plan de que sern las
iteraciones y que ser cubierto por cada una de ellas. En la fase de construccin: El comienzo proporciona el compromiso del patrocinador del proyecto de seguir adelante se conoce el caso de negocios y su factibilidad y alcance bsicos. La elaboracin da la arquitectura bsica de el sistema, un plan para el acuerdo de construccin, identifica todos los riesgos significantes, entendimiento cabal de los mayores riesgos para no estar preocupados. La construccin termina con una versin beta del sistema. Transicin es el proceso de introducir el sistema a sus usuarios. Otros procesos han adoptado UML como su lenguaje de modelacin: Catalysis, Rational Unified Process, etc.
Analisis.ppt
Pag. 19
Diagramas Estticos
Casos de Uso
Es una coleccin 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 transaccin. Cada caso de uso necesita representar una tarea, o una unidad coherente de funcionalidad, la cul 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 lneas de comunicacin entre un actor particular y el caso de uso.
Sist. de Informacin de Biblioteca
Recursos para Prestamo Agregar recursos Regresar Recursos
Bibliotecario
Usuario
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 diseo. Cuando se tienen varios subsistemas es comn dibujar la frontera del Pag. 20 Analisis.ppt
Diagramas Estticos
Casos de Uso (cont.)
Interacciones con sistemas externos: Las opiniones de incluir a los sistemas externos como casos de uso o no,
varan:
Analisis.ppt
1.- Algunos sienten que todas las interacciones con sistemas remotos deben aparecer en el diagrama. Si requiere acceso a Reuters se debera indicar. 2.- Algunas personas consideran que slo se deben mostrar los casos de uso con una interaccin externa, cuando quien inicia el contacto es otro sistema. Contabilidad solo se mostrara si dicho sistema invocara algn 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 despus es recogido por el sistema de contabilidad, entonces ste es el actor que corresponde, por necesitar de dicho archivo. 4.- Otros ms sienten que constituye un enfoque Pag. 21
Diagramas Estticos
Un actor en un caso de uso representa un rol que alguien debe jugar, en vez de representar a alguien en individual. Una relacin de comunicacin 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 algn valor. Se puede diferenciar entre quienes necesitan el caso de uso y quienes estn involucrados con l sin obtener ningn beneficio. Actores no humanos, como otros a sistemas o en algunos casos se pueden identificar diferentes dispositivos externos al sistema.
Analisis.ppt
Pag. 22
Diagramas Estticos
Utilizacin 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 interaccin que esperen tener con el sistema.
Casos de uso a travs del desarrollo. Planeacin. Antes de que se haga un proceso de estimacin y planeacin 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 quin quiere cada uno y qu tanto lo desea. Conocer cul caso de uso acarrea ms riesgo Un plan de que tanto tomar implementar cada caso de uso. Aspectos polticos. Recuerde que el 25% de los sistemas nunca se terminan. Debemos poder demostrar que el sistema hace algo til primeramente para la gente ms influyente. Aspectos tcnicos. Debemos sacar adelante primero los casos de uso con mayor riesgo, para eliminar el riesgo ms grande an cuando tengamos contingencias para poderlas eliminar y no que quedemos atorados en un diseo que no nos permita manejar los casos de uso ms riesgoso. Validacin del Sistema. Tomar cada caso de uso y verificar que el diseo permitir completarlo, igualmente se deben disear pruebas para cada caso de uso.
Analisis.ppt
Pag. 23
Diagramas Estticos
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 estticos, podemos terminar desarrollando sistemas top-down orientados a funciones, difciles de mantener e inflexibles. Para evitarlo debemos administrar correctamente el inicio de cada etapa, si la etapa previa dej alguna situacin insatisfactoria deber volverse a producir. Peligro de equivocar el diseo 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 diseo 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 anlisis de casos de uso y el modelado conceptual de clases.
Analisis.ppt
Pag. 24
Diagramas Estticos
Relaciones entre casos de uso. La inclusin 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. Al hacer en forma externa partes del caso de uso puede hacerlo ms corto y fcil de entender Al identificar funcionalidad en comn 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 elaboracin de un sistema basado en funciones, top-down con sistemas inflexibles. Es difcil para alguien no adiestrado en UML entender la notacin de incluir
Analisis.ppt
Pag. 25
Buena forma de registrar la conveniencia de se usara un componente
Diagramas Estticos
Relaciones entre casos de uso.(cont.) La extensin, permite crear un caso mediante la adicin 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.
Reabastecer Punto de extensin llenar los compartimientos incluir Exhibir el interior
incluir
extender (llenar los Compartimientos) Reabastecer de Acuerdo a las ventas
Cubrir el interior
Generalizacin. Un caso de uso secundario hereda las acciones y

significado del primario y adems agrega sus propias acciones.
Comprar gaseosa Comprar un vaso de gaseosa
Analisis.ppt
Pag. 26
Diagramas Estticos
Relaciones entre casos de uso.(cont.) Las reglas para aplicar incluir o extender son:
Utilice extender cuando describa una variacin 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 sinnimo de casos de uso, pero en el contexto de UML, la palabra escenario se refiere a una sola ruta a travs de un caso de uso, una ruta que muestra una particular combinacin 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 mayora se generan durante la captura de requerimientos, pero se irn 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-ao se esperaran 20 casos de uso 100 casos dependiendo del nivel de detalle.
Analisis.ppt
Pag. 27
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 dems 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 mtodos, los cules se invocan envindoles mensajes. Representacin UML de un objeto (Diagrama de Clase):
Empleado
- Nombre:String - Sexo:Boolean - Direccion:String - RFC:String + TomarNombre:String + TomarRFC:String + TomarDireccion:String
Analisis.ppt
Pag. 28
Problemas con la definicin de objetos
Se pueden crear objetos degenerados como: Un objeto sin datos. Que sera lo mismo que una biblioteca de funciones. Un objeto sin mtodos, con solo operaciones del tipo crear, recuperar,
actualizar y borrar (Que se correspondera con las estructuras de datos tradicionales).
Un sistema construido con objetos degenerados no es un sistema verdaderamente orientado a objetos. Las aplicaciones de gestin estn constituidas mayoritariamente por objetos degenerados
Analisis.ppt
Pag. 29
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. Son los datos que estn encapsulados dentro del objeto y determinan su estado. Algunos pueden cambiar (p.ej: un empleado puede cambiar de direccin), otros son inmutables y deben conservar el mismo valor durante la vida del objeto (p.ej: el RFC de un empleado) Son una implementacin del comportamiento requerido por una clase, cada instancia de objeto proveniente de la clase tendr stos mtodos. Podrn ser llamados por otros objetos o internamente. Los objetos responden o actan en funcin 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 mtodo y generalmente se desconoce el cdigo que ejecutar porque est encapsulado. Es el medio fundamental de comunicacin entre los objetos. La interfase describe completamente cmo van a interactuar con la clase los usuarios de la clase. La interfase pblica de un objeto define cules mensajes aceptar sin importar de donde provengan.
Atributos
Mtodos
Mensajes
Interfases
Analisis.ppt
Pag. 30
Herencia
Permite a una clase heredar los atributos y mtodos de otra clase, facilitando de esta forma la reutilizacin del cdigo y permitiendo crear nuevas clases mediante la abstraccin de los atributos y mtodos comunes.
Mamferos
- colorOjos: int + TomarColorOjos: int
Superclase
Perro
-frecuenciaLadrido: int + Ladrar: int
gato
-frecuenciaMaullido:int + Maullar: int
Subclases
Analisis.ppt
Las clases Perro y Gato heredan de la clase Mamferos, esto significa que la clase Perro tiene los siguientes atributos: colorOjos Heredada de la clase Mamferos frecuenciaLadrido Definida solo para la clase Perro y los siguientes mtodos:
Pag. 31
Abstraccin
Quitar las propiedades y acciones de un objeto para dejar slo aquellas que sean necesarias. Significa tener muchas formas. En lenguajes de programacin significa que una entidad puede tener uno de muchos tipos. En orientacin a objetos una variable polimrfica puede referirse a diferentes objetos en diferentes tiempos. Las subclases pueden hacer caso omiso de los mtodos o atributos de las superclases y definir los suyos propios. La asignacin dinmica permitir que al mandar un mensaje a un objeto se asignar dinmicamente dependiendo del cdigo del mtodo que haya definido la instancia de dicho objeto que puede ser uno propio o heredado. Se oculta la funcionalidad de los objetos, evitando que otros objetos o el mundo exterior puedan ver sus operaciones internas. Un objeto puede estar relacionado con uno o ms objetos La agregacin de objetos permite definir composiciones, en las que cada componente se considera como tal slo como parte del objeto compuesto.
Polimorfismo
Encapsulamiento
Asociaciones Composiciones
Analisis.ppt
Pag. 32
Diagramas
Para describir el diseo 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 diseo, sino una representacin de un modelo de el diseo, que captura un aspecto de el diseo 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 esttico que describe los elementos de el sistema y sus relaciones. El modelo dinmico que describe el comportamiento del sistema a travs del tiempo.
podremos tomar una: Vista lgica nos permitir alcanzar los requerimientos funcionales. Cules partes van
juntas? Cules son las clases y sus relaciones? Vista de proceso ayuda a lograr los requerimientos no-funcionales, como el desempeo y la disponibilidad. Cules necesidades de control hay? Qu actividades pueden ser concurrentes? Qu sincronizacin debe haber? Vista de desarrollo ayuda a administrar el proyecto. Cul parte har cada elemento del equipo de gente? Que partes pueden reusarse? Vista fsica ayuda a alcanzar los requerimientos no-funcionales, haciendo una vista ms concreta que la de proceso.Cuales partes corrern en la misma computadora?
Analisis.ppt
Pag. 33
Diagramas UML
La relacin existente entre los diversos diagramas de UML se muestra a continuacin:
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 Distribucin Distribucin CODIGO CODIGO

Pag. 34
Diagrama de Diagrama de Colaboracin Colaboracin
Diagrama de Diagrama de Componentes Componentes
Diagrama de Diagrama de Actividad Actividad
Analisis.ppt
Diagramas Estticos
Objetos y Clases
Identificar las clases que deben existir en nuestro sistema, es la parte mas grande del trabajo de disear sistemas orientados a objetos. Construir rpidamente y lo ms barato posible el sistema que alcance
nuestros requerimientos. Construir un sistema que sea fcil 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 tcnica es la identificacin de sustantivos. Descarte los candidatos que sean inapropiados por alguna razn, renombrando las clases restantes si es necesario Pueden descartar candidatos por: redundancia, vaguedad, son un evento o una operacin, son meta-lenguaje, estn fuera del alcance del sistema, son un atributo.
Analisis.ppt
Pag. 35
Diagramas Estticos
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 (reunin, interseccin)
Categora del concepto Ejemplos TDPV, Dado EspecicacindeProducto, ReglasdeJuego Tienda, MesadeJuego Venta, Pago, Reservacion, Apuesta VentasLineadeProducto Cajero, Gerente, Jugador Tienda, Cesto, Biblioteca Producto, Libro SistemaAutorizacionTarjetasdeCredito Hambre, Suerte DepartamentodeVentas, LineaAerea Venta, Robo, Junta, Vuelo, Accidente, RodarDados
Objetos fsicos o tangibles Especificaciones, diseo o descripciones de cosas Lugares Transacciones Lnea o rengln de un elemento de transacciones Rol de las personas Contenedores de otras cosas Cosas dentro de un contenedor Otros sistemas de cmputo o electromecnicos externos al sistema Conceptos de nombres abstractos Organizaciones Eventos
Procesos VentaUnProducto, ReservacionAsiento A menudo no estn representados como conceptos, pero pueden estarlo) Reglas y polticas Catlogos Registros de finanzas, de trabajo, de contratos, de asuntos legales Instrumentos y servicios financieros Manuales y libros PoliticadeReembolso, PoliticadeCancelaciones CatalogodeProductos, CatalogodeLibros Recibo, Mayor, ContratodeEmpleo LineadeCredito, Existencia ManualdePersonal, ManualdeReparaciones
Analisis.ppt
Pag. 36
Diagramas Estticos
Diagramas de clases Describe la vista esttica de un sistema en trminos de clases y relaciones entre las
clases, la representacin de una clase es con:
Nombre
Atributos ...
ejemplo:
Operaciones ...
Automvil
+ Placa:String -Datos:DatosAutomvil + Velocidad:Integer + Direccin: Direccin +Manejar(vel:Integer, dir:Direccin) + tomarDatos(): DatosAutomvil
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 operacin
ser referenciado desde otras clases diferentes a donde esta definido, se definen como pblicos(+) ,privados(-) protegidos (#) Una restriccin 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. Pag. Analisis.pptLas propiedades se indican mediante llaves, dando propiedades a los elementos 37
Los atributos y las operaciones pueden tener diferente visibilidad. Es visible si puede
Diagramas Estticos
Diagramas de clases (cont.) Los atributos no deberan usarse para relacionar conceptos en el modelo conceptual,
solamente para describir estos conceptos. Una de las violaciones ms comunes a esta regla consiste en agregar atributos como llaves forneas. Las operaciones son utilizadas para manipular los atributos o realizar otras acciones. Normalmente son llamadas funciones, pero estn dentro de una clase y pueden aplicarse solo a objetos de esa clase. Se conoce como la firma de la operacin a el nombre de la operacin su tipo de valor que regresa y los parmetros que utiliza. Un objeto se especifica con una firma o con precondicin, post-condicin algoritmo y el efecto que tiene sobre un objeto.

La precondicin debe ser cierta antes de que la operacin pueda ejecutarse. La post-condicin debe ser cierta despus de que la operacin sea ejecutada. Estas especificaciones son como propiedades para una operacin. Las propiedades usualmente no se muestran directamente en los diagramas de clases.
Una clase persistente es aquella cuyos objetos existen an despus 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 operacin 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.
Analisis.ppt
Pag. 38
Diagramas Estticos
Relaciones entre clases.

Asociacin, es una conexin entre clases, lo que significa que tambin es
una conexin entre los objetos de esas clases. En UML, una asociacin es una relacin que describe un conjunto de ligas, que estn definidas como una conexin semntica entre un conjunto de objetos. Corresponden a los verbos. Existen instancias de asociacin. Normalmente una asociacin es bidireccional, lo que significa que si un objeto est asociado con otro objeto, ambos objetos se conocen uno al otro. Asociacin normal: Usa Autor Computadora
Un autor usa una computadora Las restricciones en las asociaciones, permiten que se siga cierta regla: Cajero Atiende
{Ordenado}
Cliente
Un cajero atiende a un cliente, pero cada cliente es atendido en el orden en que se encuentre en la formacin
Analisis.ppt
Pag. 39
Diagramas Estticos
Relaciones entre clases (cont.)

Hay asociaciones que establecen una relacin en ambas direcciones La multiplicidad es la cantidad de objetos de una clase que se relacionan
con un objeto de la clase asociada:
1..*
Persona
Posee Posedo por
0..*
Carro
Un carro puede tener uno o mas dueos, una persona puede tener cero o ms carros
La asociacin recursiva es una asociacin de una clase a s misma, una

conexin 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. (en una red de cmputo
Analisis.ppt
Pag. 40
Diagramas Estticos

Los roles en una asociacin especifican el papel que juega un objeto en
una relacin, se indica con un string colocado cerca de la terminal de la asociacin siguiente a la clase a la cual se aplica. Pliza de Seguros
0..1
Refiere a
1
Est expresado en un
Compaa Aseguradora
1 Asegurador
tiene Refiere a
0..*
Contrato de Seguros
0..*
tiene
1..* esposa Asegurado
Persona
esposo
casado con
Analisis.ppt
Pag. 41
Diagramas Estticos

Categora de la asociacin A es una parte fsica de B A es una parte lgica de B A est fsicamente contenido en B A est contenido lgicamente en B A es una descripcin de B A es un elemento de lnea (o rengln) en una transaccin 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 transaccin B A es una transaccin relacionada con otra transaccin B A es propiedad de B
Analisis.ppt
Ejemplos Caja-TPDV VentasLneadeProducto -Venta TPDV-Tienda, Producto-Estante DescripcindeProducto -Catlogo DescripcindeProducto -Producto VentasLneadeProducto -Venta Venta-TPDV Cajero-Tienda Departamento-Tienda Cajero-TPDV Cliente-Cajero Pago-Venta Pago-Venta TPDV-Tienda
Pag. 42
Diagramas Estticos
Tipos de asociaciones
Asociacin calificada (Qualified association). Representa la informacin
de identidad y reduce la multiplicidad de uno a muchos por una de uno a uno.
rengln:{1,2,3} columna:{1,2,3}
1 1
Tablero
Cuadro
Asociacin Or {or}. En algunos modelos no todas las combinaciones de

asociacin son vlidas Elige Estudiante de Educacin Media Superior
{Or}
Acadmico
Elige Comercial
Asociacin Ordenada {ordered}. Cuando los enlaces entre objetos pueden

tener un orden implcito {ordered} {ordenadas por incremento de tiempo}.
Analisis.ppt
Pag. 43
Diagramas Estticos
Tipos de asociaciones
Clase de Asociacin. Una clase puede estar unida a una asociacin. Se
usa para agregar informacin 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 asociacin. Jugador Participa en Equipo Negociado por
Contrato
Director General
Asociacin ternaria (Ternary association). Ms de dos clases pueden

asociarse con otra, la asociacin ternaria asocia tres clases. Compaa Aseguradora
1 Asegurador 0..*
Contrato de Seguros
0..* 0..1 1..* Asegurado
Pliza de Seguros
Persona
Analisis.ppt
Pag. 44
Diagramas Estticos
Tipos de asociaciones (cont.)

Una agregacin, es un caso especial de asociacin, indica que la relacin
entre las clases es de alguna forma parte de un todo. Se describen diferentes niveles de abstraccin. Se indica con rombo en blanco en el lado de la clase que agrupa a las dems. Se puede tener una restriccin en una agregacin, como en la relacin {O} que se indica con lnea punteada Comida
1
{O}
Comida
Ensalada
PlatoFuerte
Postre
Una composicin es una agregacin donde cada componente puede

pertenecer tan solo a un todo. Se representa con diamante slido. Tablero
1 9
Cuadros
En un juego del gato, los cuadros solo tienen sentido si estn
formando parte del tablero
Analisis.ppt
Pag. 45
Diagramas Estticos
Tipos de asociaciones (cont.)

La generalizacin es una relacin entre un elemento ms general y uno
ms especfico. El elemento ms especfico puede tener solo informacin adicional. Se utiliza sobre tipos, nunca sobre instancias (una clase puede heredar otra clase, pero un objeto no puede heredar otro objeto). La clase especfica 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 jerarqua de clases. En grficas de jerarqua, las clases estn conectadas unas con otras, va relaciones de generalizacin.
Vehculo
Carro
Bote
Camin
Analisis.ppt
Pag. 46
Diagramas Estticos
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 smbolo 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 lnea a la clase
Teclado
Analisis.ppt
Pag. 47
Diagramas Estticos
Diagrama de objetos
Un diagrama de objetos en UML usa la misma notacin 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
Diagramas Estticos
Diagrama de Clases
Modelo Conceptual de Punto de Venta
Registra-venta-de Descritas-por
1
Catalogo deProducto
* 1 * 1
Contiene
1..*
Especificacion deProducto Descripcion Precio

Codigode barras
1 *
0..1
VentasLinea deProducto cantidad

1..*
Usado-por Almacena
1 *
Tienda Direccin Nombre

1 1..*
Describe
Producto
Contenidas-en
1 * 1
Capturas terminadas
1
Contiene
1
TPDV
Venta Fecha Hora

Pagado-por
1 1 1
Iniciado-por
1
Capturadas-en
Gerente
Registra-ventas-en
1
Iniciado-por
1
Pago Monto
Analisis.ppt
Cliente
Cajero
Pag. 49
Diagramas Dinmicos
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 smbolos UML en un diagrama de estados son:
Estado Nombre Inicio Transicin Evento que dispara Variables de estado Actividades Fin Transicin
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.ppt
Pag. 50
Diagramas Dinmicos
Diagramas de estados (cont.)

Se puede agregar ciertos detalles a las lneas de transicin, para indicar
un suceso que provoca una transicin (la que desencadena un suceso) y la actividad de cmputo que se ejecute y haga que suceda la modificacin de estado.
Encender la PC
Inicializacin
Operacin
Apagado
Apagar
Hacer/Arrancar
Las condiciones de seguridad permiten establecer una relacin entre

Encender la PC
estados que dependen de que se cumpla dicha condicin. Operacin Apagado Apagar Inicializacin Hacer/Arrancar
[lapso transcurrido] Teclazo o movimiento del ratn
Protector De pantalla
Analisis.ppt
Pag. 51
Diagramas Dinmicos
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. Tambin has subestados concurrentes cuando pueden ocurrir al mismo tiempo. Se representan dentro del estado original, separados por lnea punteada. Operacin A la espera de accin del usuario Registro de una accin del usuario
Representacin de la accin del usuario
Verificar el conmetro del sistema
[lapso transcurrido]
Actualizar despliegue
Analisis.ppt
Pag. 52
Diagramas Dinmicos
Estados histricos.
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 histrico profundo cuando alcanza a recordar varios niveles (H*) en caso contrario se dice que es superficial
H A la espera de accin del usuario
Operacin Registro de una accin del usuario

Representacin de la accin del usuario
Verificar el conmetro del sistema
Actualizar despliegue
Teclazo o movimiento del ratn

Pag. 53
Analisis.ppt
Diagramas Dinmicos
Cuando utilizar los diagramas de estados: Se tendra que hacer uno por cada clase del sistema, pero se sugiere
hacerlos solo para aquellos que presenten un estado interesante y cuando la construccin 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.
Analisis.ppt
Pag. 54
Diagramas Dinmicos
Diagramas de actividades
Describen como se coordinan las actividades, muestran como puede ser implementada una operacin 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 Actividad
La transicin se muestra como una flecha, normalmente no se les pone

etiqueta, a menos que se tenga una condicin.
Actividad 1
Actividad 2
Analisis.ppt
Pag. 55
Diagramas Dinmicos
Diagramas de actividades (cont.)

Barras de sincronizacin, indica coordinacin 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 ejecucin de actividades en paralelo.
Fin de la jornada
Bao
Descanso
Analisis.ppt
Pag. 56
Diagramas Dinmicos
Las indicaciones, permiten que se ejecuten otras actividades, usando un pentgono convexo para el envo del un evento y uno cncavo para la recepcin del evento.
Televisin
Remoto.Tecleo (canal) Oprimir numero de canal
Fin de la jornada
Cambiar(canal)
Cambiar(canal)
Oprimir numero de canal
Analisis.ppt
Pag. 57
Diagramas Dinmicos

Diamantes de decisin 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 lneas de responsabilidad, Al poner muchas actividades relacionadas entre s, se pueden colocar de acuerdo al objeto o al actor que las ejecuta, o a cul 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 inters es la terminacin de las actividades. Las actividades se pretende que se continen a lo largo del diagrama sin quedarse estancadas.
Analisis.ppt
Pag. 58
Diagramas Dinmicos
Ejemplo de un diagrama de actividades en una biblioteca.

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 prstamo
Preparar para el siguiente miembro
Analisis.ppt
Pag. 59
Diagramas Dinmicos
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 programacin multihilos. Se recomienda usarlos para: El anlisis de un caso de uso. Para comprender qu acciones deben ocurrir y cules son las dependencias de comportamiento. Asignando posteriormente los mtodos a los objetos y mostrando tales asignaciones mediante diagramas de secuencia o colaboracin. La comprensin del flujo de trabajo, a travs 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 colaboracin. Para tratar de ver como se comporta un objeto durante su perodo de vida. Es mejor usar un diagrama de estados.
Analisis.ppt
Pag. 60
Diagramas Dinmicos
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 lnea vertical el tiempo, se indican las operaciones que ejecuta el objeto o activacin se representan mediante un rectngulo cuya altura va en relacin a la duracin de la operacin. Los mensajes van de un objeto a otro se representan con lneas. Pueden ser simples (transfieren control), sincrnicos (esperan respuesta) o asincrnicos (no espera respuesta)
:Objeto 1 :Objeto 2
Analisis.ppt
Pag. 61
Diagramas Dinmicos
Diagrama de secuencias. (cont.)

Para ilustrar los diagramas de secuencia se usar el siguiente caso de
uso:
La ventana Entrada de pedido enva un mensaje prepara a Pedido. El Pedido enva entonces un mensaje prepara a cada lnea de
pedido dentro del Pedido. Cada Lnea de pedido revisa el Artculo de inventario correspondiente. - Si esta revisin devuelve verdadero, la Lnea de pedido descuenta la cantidad apropiada de Artculo de inventario del almacn. Si no sucede as, quiere decir que la cantidad del Artculo de inventario ha cado ms abajo del nivel de reorden y entonces dicho Artculo de inventario solicita una nueva entrega.
En el diagrama siguiente se muestra el diagrama de secuencia
omitiendo las activaciones, que segn Fowler, no aportan mucho a la ejecucin de procedimientos y solamente sugiere usarlas en situaciones concurrentes.
Analisis.ppt
Pag. 62
Diagramas Dinmicos
El siguiente ejemplo muestra

unPedido Una Lnea de Pedido Un artculo de inventario
Ventana de Entrada de Pedidos prepara()
Objeto Iteracin
*[para cada lnea de pedido] prepara()
Mensaje Condicin
hayExistencia:= revisa() [hayExistencia] descuenta() necesitaReorden:= necesitareordenar()
Autodelegacin
[necesitaReorden] nuevo Un Artculo de reorden
Regreso
Creacin
[hayExistencia] nuevo() Un Artculo para entrega
Analisis.ppt
Pag. 63
Diagramas Dinmicos
De el objeto se desprende una lnea vertical conocida como lnea de vida del objeto y representa el tiempo de duracin del objeto durante la interaccin. Los mensajes representados por lneas estn en orden de arriba hacia abajo. La autodelegacin es un mensaje que un objeto se manda a s mismo. Una condicin indica cundo se enva un mensaje, el cual se enviar solo si la condicin es verdadera. Una iteracin muestra cuando un mensaje se enva varias veces a varios objetos receptores, como sucedera cuando se itera sobre una coleccin. 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.
Analisis.ppt
Pag. 64
Diagramas Dinmicos
Otra ilustracin adicional nos permitir visualizar las activaciones y la creacin de objetos. Ejemplo de una transaccin bancaria: Cuando se crea una Transaccin, sta crea un Coordinador de
transaccin que coordina el trmite de la transaccin. Este coordinador crea una cantidad (en el ejemplo, dos) de objetos Revisor de Transaccin, cada uno de los cuales es responsable de una revisin particular. Este proceso permitir aadir con facilidad otros proceso de revisin, porque cada registro es llamado asincrnicamente y opera en paralelo. Cuando termina un revisor de transaccin, se le notifica al coordinador de transaccin. 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 Transaccin que todo est bien.
Analisis.ppt
Pag. 65
Diagramas Dinmicos

nuevo Una Transaccin nuevo unCoordinador de transacciones nuevo Activacin un primer Revisor de transaccin nuevo un segundo Revisor de transaccin
Mensaje asncrono
bien se suprimen las dems transacciones
todo terminado?
bien el objeto se borra a s mismo
es Vlido
todo terminado? Autodelegacin
Analisis.ppt
Pag. 66
Diagramas Dinmicos
Diagramas de secuencias. (cont.)
Cuando utilizar los diagramas de secuencias, se sugieren para: Son tiles para ver la interaccin entre los objetos, debido a que pone
nfasis en la secuencia y es fcil 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 travs de muchos casos de uso (usar mejor un diagrama de estados) Si quiere ver el comportamiento a travs de muchos casos de uso o muchos proceso mejor utilice un diagrama de actividad.
Analisis.ppt
Pag. 67
Diagramas Dinmicos
Diagramas de colaboraciones.
Muestra los objetos,las relaciones entre ellos, los mensajes que se envan los objetos entre s. El mensaje se representa como una flecha cerca de la lnea de asociacin
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
1:Agregar()
3:Actualizar() :Nombre2 :Nombre3

Analisis.ppt
2:Modificar()
Pag. 68
Diagramas Dinmicos
Diagramas de colaboraciones. (cont.)
Ejemplo de un diagrama de colaboraciones: El actor es el usuario quien inicia la interaccin 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 enva un mensaje al monitor El monitor presenta el carcter alfanumrico en la pantalla, con lo que se har evidente al usuario.
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. 69
Diagramas Dinmicos
Diagramas de colaboraciones. (cont.)
Cuando utilizar los diagramas de colaboracin, se sugieren para: Es la mejor forma si se quiere mostrar los objetos y mostrar como se
reconectan estticamente unos con otros. Cuando se desee ver el comportamiento de varios objetos en un caso de uso. Sirven para mostrar la colaboracin entre los objetos, sin embargo, no sirven tan bien para la definicin 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 travs de muchos casos de uso (usar mejor un diagrama de estados) Si quiere ver el comportamiento a travs de muchos casos de uso o muchos proceso mejor utilice un diagrama de actividad.
Analisis.ppt
Pag. 70
Diagramas de Implementacin
Diagramas de componentes
Un componente es la implementacin de un subsistema, la cual da las especificaciones (en trminos de casos de uso) y una estructura de clases que lleva a cabo la especificacin. Su representacin es:
calculadora.java
Hay diferentes tipos de componentes y cada uno con diferentes tipos de dependencia , Clasificndolos en relacin con el proceso de compilacin un componente podra ser: Cdigo fuente, el cual depende de que otros componentes estn disponibles al
momento de compilacin. Cdigo objeto binario, (biblioteca de clases) que depende de cualquier cdigo objeto al cul se ligara desde un programa ejecutable. Una aplicacin ejecutable, la cul puede depender de otros programas ejecutables al tiempo de ejecucin.
Los detalles dependen del lenguaje de programacin 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
Pag. 71
Analisis.ppt
Diagramas de componentes (cont.)
Cada clase del modelo lgico se realiza en dos componentes: la especificacin y el cuerpo. La especificacin contiene la interfaz de la clase mientras que el cuerpo contiene la realizacin de la clase. En el caso de clases parametrizables se puede dar una especificacin genrica. 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 segn un criterio lgico y con vistas a simplificar la implementacin. Son paquetes estereotipados en subsistemas para incorporar la nocin de biblioteca de compilacin y de gestin de configuracin.
Analisis.ppt
Pag. 72
Un diagrama de componentes mostrando las dependencias de tiempo de compilacin:

ligar streams.o biblioteca MiEntradaSalida
compilar
MiAplicacin ejecutable
La interfaz se puede representar por una lnea con un crculo

Programa de bsqueda Resultado de la bsqueda
Analisis.ppt
Pag. 73
Si un componente implementa clases se puede establecer la relacin entre el componente y las clases como sigue:
ProcesadorTextos.exe Clases: ProcesadorTextos VerificadorOrtografico ContadorPalabras
ProcesadorTextos.exe
ProcesadorTextos
VerificadorOrtografico
ContadorPalabras
Analisis.ppt
Pag. 74
Solo se podrn ejecutar las operaciones dentro de un componente a travs de su interfase. La relacin entre un componente y su interfase se conoce como realizacin. 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 exportacin, al que accede a un servicio se dice que utiliza una interfaz de importacin.
Interfaz ElementoDeEscucha
cambioAlEstadoDelElemento()
AWTEventMulticaster
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.
Pag. 75
Analisis.ppt
Pgina Web con controles ActiveX.

Animacion.htm
VBScript
ActiveX DisposicionAnimacion.alx ActiveX BotonEjecutar ActiveX ImagenEsfera
ActiveX BotonDetener ActiveX CronometroEsfera
ActiveX BotonReinicar
Esfera.gif ActiveX CuadroCombCronometro ActiveX CuadroCombDistancia
Analisis.ppt
Pag. 76
Diagramas de distribucin.
Los diagramas de distribucin muestran la disposicin fsica 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 cmputo y se representa por un cubo:
Nodo
Los estereotipos permiten precisar la naturaleza del equipo: Dispositivos Procesadores Memoria Etc.
Analisis.ppt
Pag. 77
Diagramas de distribucin.
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 telefnico corporativo
Programa de bsqueda
Resultado de la bsqueda
Analisis.ppt
Pag. 78
Diagramas de distribucin. (cont.)
Las conexiones entre nodos se puede poner mediante una relacin

Servidor
Directorio telefnico corporativo
Programa de bsqueda
Resultado de la bsqueda
Comunicacin
Cliente
Programa de Presentacin
Analisis.ppt
Pag. 79
Diagramas de distribucin. (cont.)
Aplicacin de los diagramas de distribucin. Un equipo de cmputo casero podra 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.ppt
Procesador ISP Infosel.net
Dispositivo Terminador
Dispositivo Terminador
Pag. 80
Caso de Estudio (CS4)
Presentacin del caso.
Administracin CS4
Un estudiante CS4 (eCS4), es cualquier estudiante que esta tomando cualquier mdulo de cuarto ao en el departamento de ciencias computacionales, ya sea que este o no inscrito para un grado en ciencias computacionales. Al final de cada ao acadmico, el Comit Acadmico de el Departamento de Ciencias Computacionales determina qu mdulos estarn disponibles para los eCS4 en el siguiente ao. Al final de cada ao el Jefe del Departamento fija actividades para los miembros del cuerpo de maestros y otros, en particular a una persona es asignada para ensear cada uno de los mdulos que se supone van a estar disponibles para el prximo ao (adjunto) Cada profesor adjunto actualiza los apuntes en el manual del curso de su mdulo. El coordinador CS4 (CCS4) actualiza otras partes de cada manual y checa los apuntes producidos por los profesores adjuntos. Los apuntes de los mdulos estn escritos en el lenguaje de formato LATEX. Alguien en la Oficina de Enseanza Profesional (OEP) produce la versin en papel de cada manual de curso; el CCS4 produce la versin HTML ejecutando la aplicacin 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 direccin de correo cs4class. Cada estudiante es avisado por un miembro del cuerpo de maestros que acta como Director de Estudios (DdE). Un DdE se asigna a un estudiante en su primer ao de estudios y permanece con sa funcin hasta que termina. Los estudiantes se inscriben en forma provisional en los mdulos llenando una forma y entregndola en la Oficina de Enseanza 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 mdulos. En caso de duda, se consulta al DdE del estudiante y se puede tener una pltica con el estudiante. El OEP produce luego las listas para los adjuntos de los estudiantes que tomarn sus mdulos. Estas listas no pueden llegarles a los adjuntos antes de la semana 3. Esto es, muy tarde para que los adjuntos puedan saber cuntas copias deben preparar de su material.
Pag. 81
Analisis.ppt
Administracin 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 Ingeniera Electrnica, etc. Los detalles de la asesora y las reglas acerca de cules combinaciones de mdulos son aceptables, son diferentes para cada grado, igualmente hay manuales separados para cada uno de ellos. Sin embargo, muchos mdulos se aceptan en varios diferentes cursos de grado, y en cada caso la descripcin 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 mdulos en lnea. Que el OEP pueda obtener fcilmente informacin actualizada y confiable. Mejorar el seguimiento de dicha informacin. Hacer que la informacin tal como los manuales de cursos y las listas de los estudiantes que toman los cursos estn disponibles cuanto antes, automatizando su produccin. El sistema de administracin CS4 deber poder producir un informe sobre cada eCS4 indicando si es de 4to ao o an no se grada, qu mdulos est tomando el estudiante, cuales cursos de grado esta llevando un eCS4, o cul miembro del staff es el DdE de un eCS4. Deber poder dar informacin sobre los mdulos, quines los imparten, de que curso forman parte y que estudiantes los estn tomando.
Analisis.ppt
Pag. 82
Diagrama de casos de uso (CS4) Las consultas pueden ser realizadas mediante una base de datos y usando
tcnicas estndar 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 mdulos.
Producir la lista CS4

Organizador Cursos CS3 CCS4
Producir el manual del curso

OEP Adjunto CS4
Inscribir en los Mdulos

eCS4 Director de estudios CS4
Analisis.ppt
Pag. 83
Diagrama de casos de uso (CS4)
Descripcin de caso de uso: Producir el manual del curso Este caso de uso se puede usarse solamente cuando el comit acadmico
ha determinado el conjunto de mdulos que estarn 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, modificndolo y regresndolo modificado al sistema. El adjunto de cada mdulo, actualiza la descripcin del mdulo tomndolo del sistema, actualizndolo y regresndolo al sistema. Estas actualizaciones pueden suceder en cualquier orden. El sistema conserva el registro de cules cambios se han hecho. Una vez que se hicieron todas las actualizaciones, el sistema enva el texto completo del manual por correo electrnico 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 mdulos.
Analisis.ppt
Pag. 84
Diagrama de clases (CS4)
Un diagrama de clases a nivel conceptual, sin incluir actividades y operaciones:

Adjunto
1 Imparte 0..*
Mdulo
6 toma 6..*
Director de Estudios
1
dirige
1..*
1..*
0..*
Estudiante
Cursos Grado
esta en 1
Estudiante otros aos
Estudiante 4to ao
0..*
Analisis.ppt
Pag. 85
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:
Jefe de Departamento Adjunto OEP CCS4
Actualizar secciones principales
Comit Acadmico Determinar los mdulos
Asignar Adjuntos Actualizar registro de mdulo
Imprimir manual
Generar versin HTML
Analisis.ppt
Pag. 86
Caso de Estudio (Restaurante)
Presentacin 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 Anlisis
Qu sucede cuando un cliente entra al restaurante? R: Si el cliente tiene un abrigo,le ayudamos a quitrselo, lo almacenamos en el guardarropa y le damos un boleto para solicitarlo posteriormente. Lo mismo hacemos con el sombrero. Y si hay lnea de espera, se forma? R: Se le pregunta si hizo reservacin, en cuyo caso lo pasamos lo ms pronto posible. Si no hay reservacin deja su nombre y puede ir al bar a tomar algo antes de comer o esperar sentado en rea de espera.
Entra el cliente [Tiene abrigo y/o sombrero] Ayudar a quitrselo [Prefiere el bar] Espera en el bar Guardarlo
[Lista de espera] [No hizo reservacin] Dejar su nombre
[Prefiere el rea de espera]
Aguarda en el rea de espera
Analisis.ppt
Pag. 87
Presentacin del caso. (cont.)
Entrevista de Anlisis (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 capitn 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 quin coloca una charola con pan y mantequilla. Si alguien ha pedido una bebida el mesero la traer. Cmo deciden los clientes qu van a consumir? R: El mesero propone siempre a los clientes la sugerencia del da y les da de 5 a 10 minutos para que decidan. Cuando el cliente llama la atencin del mesero, ste regresa a tomarle su orden. Y luego lo notifica al chef. Mediante la transcripcin de la eleccin en un formulario, llamado comanda. Qu contiene la comanda? R: La mesa, la eleccin 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 mayora de las comidas incluyen un entrems antes del plato fuerte. A la mayora de la gente le gusta comer el plato fuerte caliente, el chef prepara el entrems 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.
Analisis.ppt
Pag. 88
Diagrama: Servir a un cliente

Entra el cliente
[Tiene abrigo y/o sombrero]
Ayudar a quitrselo
Guardarlo
[Lista de espera]
[No hizo reservacin]
[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
Entrevista de Anlisis (cont.)

Cmo 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 entrems; despus el mesero lleva el plato fuerte a la mesa. Los comensales ingerirn 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 crdito. Luego traer el cambio o los vouchers, los clientes dejarn una propina, recogern sus abrigos y se irn. 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.
Analisis.ppt
Pag. 90
Diagrama de Servir a un cliente (cont.)

Traer entrems Ingerir entrems 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.ppt
Pag. 91
Preparacin de platillos
Cmo 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 entrems, el mesero va a la cocina, los toma y los lleva a la mesa. Cmo se entera el mesero que ya estn listos los entremeses? R: El mesero va a la cocina de vez en cuando. El chef luego de dar el entrems al mesero, espera que este le avise cuando la mayora 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 estn listos para el plato fuerte, el chef termina su preparacin. El mesero los toma y los lleva a la mesa
Analisis.ppt
Pag. 92
Preparacin de platillos
Recibir comanda
Preparar entremeses
Iniciar la preparacin Del plato fuerte Coordinar la preparacin de otros pedidos Recibir la notificacin de que los Entremeses casi se han consumido
Llevar entremeses
Ingerir entremeses
Finaliza la preparacin de plato fuete Tomar el plato fuerte
Llevar Plato fuerte
Analisis.ppt
Pag. 93
Clases y asociaciones
El cliente se asocia con una gran cantidad de clases, como muestran las
asociaciones a continuacin:
Postre
1
Cuenta Liquida
1 1 1 1..* 1 1 1 1 1 1 1
Propina
1
Reservacin
1
Ingiere
1
Deja Hace
Cliente
Es atendido por Da a guardar
Mesero Sombrero
0..* 1
Da a guardar
Encargado del Guardarropa
Elige del Ingiere Hace

1 1 1
0..*
Abrigo
Elige del
Men
Alimento
Men del postre
Orden
Analisis.ppt
Pag. 94
Detalle de las clases
Cliente, sus atributos seran:

Cliente nombre horallegada orden horaservicio ingerir() beber() ordenar() pagar()
Analisis.ppt
Pag. 95
Detalle de las clases Empleado es una clase abstracta que puede contener la informacin de los
empleados y como clases secundarias, se pueden tener Mesero, Chef, Gerente, Asistente.
Empleado nombre domicilio RFC aosExperiencia fechaContratacin 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
Diagrama de distribucin, Restaurante
Los meseros contarn con una computadora palmtop y la utilizarn para comunicarse con la cocina y con los mozos de piso. Estos ltimos tambin tendrn 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 Inalmbrico
Dispositivo Red
Dispositivo
PC de la cocina
Dispositivo
PC del gerente
Analisis.ppt
Pag. 97
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 Transmitir la orden a la cocina Cambiar una orden Incluir
Incluir
Recibir una notificacin de la cocina Llamar a un mozo de piso Recibir una notificacin del bar Imprimir una cuenta
Llamar a un Asistente
Analisis.ppt
Pag. 98

Analisis 101018120712 Phpapp02

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Analisis 101018120712 Phpapp02

Enviado por

Direitos autorais:

Formatos disponíveis

Anlisis y Diseo de Sistemas de Informacin

Anlisis y Diseo de Sistemas de Informacin

Anlisis y Diseo de Sistemas de Informacin

Tenemos buenos sistemas?

Anlisis y Diseo de Sistemas de Informacin

Anlisis y Diseo de Sistemas de Informacin

Anlisis y Diseo de Sistemas de Informacin

Anlisis y Diseo de Sistemas de Informacin

Cmo son los sistemas considerados buenos?

Anlisis y Diseo de Sistemas de Informacin

Cmo son los sistemas considerados buenos? (cont.)

Anlisis y Diseo de Sistemas de Informacin

Encapsulamiento: Acoplamiento bajo

Anlisis y Diseo de Sistemas de Informacin

Encapsulamiento: Acoplamiento bajo (Cont.)

Interfases Una interfase a un mdulo define algunas caractersticas del mdulo

Anlisis y Diseo de Sistemas de Informacin

Encapsulamiento: Acoplamiento bajo (Cont.)

Anlisis y Diseo de Sistemas de Informacin

Encapsulamiento: Acoplamiento bajo (Cont.)

Anlisis y Diseo de Sistemas de Informacin

Encapsulamiento: Acoplamiento bajo (Cont.)

Un buen sistema consiste de mdulos encapsulados

Anlisis y Diseo de Sistemas de Informacin

Abstraccin: Alta Cohesin.

Anlisis y Diseo de Sistemas de Informacin

Si un mdulo es reusable depende del contexto en que se desarroll y en

Anlisis y Diseo de Sistemas de Informacin

Diseo basado en componentes: Insertabilidad, conectabilidad (pluggability)

Anlisis y Diseo de Sistemas de Informacin

Cmo se construyen los buenos sistemas?

Anlisis y Diseo de Sistemas de Informacin

Anlisis y Diseo de Sistemas de Informacin

Proceso de desarrollo (cont.)

Anlisis y Diseo de Sistemas de Informacin

Recursos para Prestamo Agregar recursos Regresar Recursos

Anlisis y Diseo de Sistemas de Informacin

Casos de Uso (cont.)

Anlisis y Diseo de Sistemas de Informacin

Casos de Uso (cont.)

Anlisis y Diseo de Sistemas de Informacin

Casos de Uso (cont.)

Anlisis y Diseo de Sistemas de Informacin

Casos de Uso (cont.)

Anlisis y Diseo de Sistemas de Informacin

Casos de Uso (cont.)

Al reusar los casos de uso se tienen las siguientes ventajas:

Buena forma de registrar la conveniencia de se usara un componente

Anlisis y Diseo de Sistemas de Informacin

Casos de Uso (cont.)

extender (llenar los Compartimientos) Reabastecer de Acuerdo a las ventas

Generalizacin. Un caso de uso secundario hereda las acciones y

Anlisis y Diseo de Sistemas de Informacin

Casos de Uso (cont.)

Anlisis y Diseo de Sistemas de Informacin

Anlisis y Diseo de Sistemas de Informacin

Problemas con la definicin de objetos

Anlisis y Diseo de Sistemas de Informacin

Anlisis y Diseo de Sistemas de Informacin

Anlisis y Diseo de Sistemas de Informacin

Anlisis y Diseo de Sistemas de Informacin

Anlisis y Diseo de Sistemas de Informacin

La relacin existente entre los diversos diagramas de UML se muestra a continuacin: