Anlisis de Sistemas

SEMANA 1 AGOSTO 2011 CONCEPTO DE ANLISIS DE SISTEMAS

DOCENTE: DR. LUIS ROMERO ECHEVARRIA

En clase
Cual es el ciclo de vida de un ingenierio de sistema:? Anlisis Diseo Desarrollo

Agenda
Introduccin

Problemtica
Etapas Trabajo de Investigacin

Anlisis de Sistemas
Trata bsicamente de determinar los objetivos y lmites

del sistema objeto de anlisis, caracterizar su estructura y funcionamiento, marcar las directrices que permitan alcanzar los objetivos propuestos y evaluar sus consecuencias.
Dependiendo de los

objetivos del anlisis

Problemticas distintas

Anlisis de un sistema ya existente para comprender, mejorar, ajustar y/o predecir su comportamiento Anlisis como paso previo al diseo de un nuevo sistema-producto

Etapas
Conceptualizacin Anlisis funcional
Anlisis de condiciones (o constricciones) Construccin de modelos Validacin del anlisis

Conceptualizacin
Consiste en obtener una visin de muy alto nivel

del sistema, identificando sus elementos bsicos y las relaciones de stos entre s y con el entorno.

Anlisis funcional
Describe las acciones o transformaciones que tienen lugar en el sistema. Dichas acciones o transformaciones se especifican en forma de procesos que reciben unas entradas y producen unas salidas.

Anlisis de condiciones (o constricciones)

Debe reflejar todas aquellas limitaciones impuestas

al sistema que restringen el margen de las soluciones posibles. Estas se derivan a veces de los propios objetivos del sistema:

Operativas, como son las restricciones fsicas, ambientales, de mantenimiento, de personal, de seguridad, etc. De calidad, como fiabilidad, mantenibilidad, seguridad, convivencia, generalidad, etc.

Anlisis de condiciones (o constricciones)

Humanos Temporales, que suponen unos plazos a cumplir Metodolgicos, que conllevan la utilizacin de tcnicas determinadas

Econmicos, reflejados en un presupuesto

Limitaciones en los diferentes recursos utilizables:

Materiales, como espacio, herramientas disponibles

Construccin de modelos
Una de las formas ms habituales y convenientes

de analizar un sistema consiste en construir un prototipo (un modelo en definitiva) del mismo.

Validacin del anlisis

A fin de comprobar que el anlisis efectuado es correcto y evitar, en su caso, la posible propagacin de errores a la fase de diseo, es imprescindible proceder a la validacin del mismo. Para ello hay que comprobar los extremos siguientes:
El anlisis debe ser consistente y completo Si el anlisis se plantea como un paso previo para realizar un diseo, habr que comprobar adems que los objetivos propuestos son correctos y realizables

Una ventaja fundamental que presenta la construccin de prototipos desde el punto de vista de la validacin radica en que estos modelos, una vez construidos, pueden ser evaluados directamente por los usuarios o expertos en el dominio del sistema para validar sobre ellos el anlisis.

Trabajo de investigacin
Sustente :
Cul

es la funcin de Analista de Sistemas en la EOFAP? p1 Cul es la funcin de Analista de Sistemas en el Grupo Areo 8? p2

Preguntas . . . . .

Adaptado de:

DAEDALUS . Empresa con especialistas en la investigacin, el desarrollo, la innovacin y la transferencia de tecnologa en el sector de las Tecnologas de la Informacin y de las Comunicaciones (TIC). 2009.
http://www.daedalus.es/inteligencia-de-negocio/sistemas-complejos/ingenieria-desistemas/analisis-de-sistemas/

Temario
Temario Ingeniera de Software Estructuras de Objetos Diagramas Estticos

Diagramas de Clases Diagramas de Casos de Uso Diagramas de Estado Diagramas de Actividades Diagramas de Secuencias Diagramas de Colaboracin Diagramas de Componentes Diagramas de Distribucin

Diagramas Dinmicos

Diagramas de Implementacin

Casos de estudio Patrones de Diseo Metodologas

Instructor Ing. y M.A. Francisco Javier Mariscal Flores fmarisc@uach.mx

Analisis.ppt

Bibliografa

Bibliografa

Using UML. Software Engineering with objects and Components The Object-Oriented Thought Process Aprendiendo UML en 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

Perdita Stevens, Rob Pooley Matt Weisfeld Joseph Schmuller James J. Odell Craig Larman

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

Kendall & Kendall Martin Fowler con Kendal Scott

Prentice Hall. Pearson Educacin. Tercera Edicin. 1995 Addison Wesley. Pearson. 1999

Analisis.ppt

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

Ingeniera de Software

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

Ingeniera de Software

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

Ingeniera de Software
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, Addison-Wesley 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

Ingeniera de Software

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

Ingeniera de Software

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

Ingeniera de Software

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

Ingeniera de Software

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.
Analisis.ppt

Ingeniera de Software

Encapsulamiento: Acoplamiento bajo (Cont.) 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

Ingeniera de Software
Encapsulamiento: Acoplamiento bajo (Cont.) 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 Analisis.ppt y mantenimiento), porque se evitar el examinar mdulos

Ingeniera de Software
Encapsulamiento: Acoplamiento bajo (Cont.) 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

Ingeniera de Software
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 Analisis.ppt

Ingeniera de Software
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 Analisis.ppt Acoplamiento bajo con el resto del sistema

Ingeniera de Software
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

Analisis.ppt

Ingeniera de Software
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

Ingeniera de Software
Anlisis
Proceso de desarrollo Implementacin Mtodo tradicional para el desarrollo de Sistemas

Diseo

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 Transicin corregirlo. Evaluaciones frecuentes ayudan a Construccin corregir. 2.- Un riesgo mayor es que los desarrolladores malinterpreten los requerimientos. La Diseo Anlisis elaboracin de prototipos permite reafirmarlos. Espiral de desarrollo:

Metodologa Unificada.

Analisis.ppt

Ingeniera de Software
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. Analisis.ppt Otros procesos han adoptado UML como su lenguaje de

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. 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: 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 equivocado considerar que un sistema es un actor.

Analisis.ppt

Diagramas Estticos
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 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

Diagramas Estticos
Casos de Uso (cont.) 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.
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

Casos de uso a travs del desarrollo.

Diagramas Estticos
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 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

Diagramas Estticos
Casos de Uso (cont.) Relaciones entre casos de uso.

La inclusin permite volver a utilizar los pasos de un caso de uso dentro de otro Exhibir
incluir Recolectar dinero incluir el interior

Cubrir el interior

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 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. Analisis.ppt Sin embargo se tienen las siguientes desventajas:

Casos de Uso (cont.)

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.
incluir Reabastecer Punto de extensin llenar los compartimientos incluir extender (llenar los Compartimientos) Reabastecer de Acuerdo a las ventas Comprar gaseosa Exhibir el interior Cubrir el interior

Comprar un vaso de gaseosa

Generalizacin. Un caso de uso secundario hereda las acciones y significado del primario y adems agrega sus propias acciones.
Analisis.ppt

Casos de Uso (cont.)

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. Analisis.ppt Se puede tener diferente grado de granularidad, por ejemplo para un

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

Estructuras de Objetos
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

Estructuras de Objetos
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 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) Mtodos 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. Mensajes 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. Interfases Es el medio fundamental de comunicacin entre los objetos. La interfase describe Analisis.ppt completamente cmo van a interactuar con la clase los usuarios de la clase. La

Estructuras de Objetos
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 Superclase
- colorOjos: int + TomarColorOjos: int

Perro
-frecuenciaLadrido: int

gato
-frecuenciaMaullido:int

Subclases

+ Ladrar: int

+ Maullar: int

Las clases Perro y Gato heredan de la clase Mamferos, esto significa que la clase Perro tiene los siguientes atributos:

colorOjos frecuenciaLadrido tomarColorOjos Ladrar

Heredada de la clase Mamferos Definida solo para la clase Perro Heredada de la clase Mamferos Definida solo para la clase Perro

y los siguientes mtodos:

Analisis.ppt

Estructuras de Objetos
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
Analisis.ppt

Polimorfismo

Encapsulamiento

Asociaciones

Composiciones

Estructuras de Objetos
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. 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 Analisis.ppt concreta que la de proceso.Cuales partes corrern en la misma computadora?

podremos tomar una:

Diagramas UML

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

Diagrama de Clases

Casos de Uso

Diagrama de Secuencias Diagrama de Estados

Diagrama de Distribucin

Diagrama de Colaboracin

Diagrama de Componentes
CODIGO
Analisis.ppt

Diagrama de Actividad

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

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)

Analisis.ppt

Diagramas Estticos
Categora del concepto 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 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 Ejemplos

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

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

Nombre

Describe la vista esttica de un sistema en trminosAtributos ... relaciones entre las clases, la de clases y representacin de una clase es con: Operaciones ...

Automvil

Nombre de la clase Atributos de la clase: son los datos contenidos en un objeto de la clase

+ Placa:String ejemplo: -Datos:DatosAutomvil + Velocidad:Integer + Direccin: Direccin +Manejar(vel:Integer, dir:Direccin) + tomarDatos(): DatosAutomvil

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

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 pblicos(+) ,privados(-) protegidos (#) Analisis.ppt Una restriccin es un texto que especifica una o varias reglas que sigue la clase, se indica

Diagramas Estticos
Objetos y Clases (cont.)

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 Analisis.ppt para las clases en caso de que no se proporcione.

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. Usa Corresponden a los verbos. Existen instancias de asociacin. Autor Computadora Normalmente una asociacin es bidireccional, lo que significa que si un objeto est asociado con otro objeto, ambos objetos se Un autor usa una computadora conocen uno al otro. Asociacin normal: {Ordenado}

Cajero

Atiende

Cliente

Un cajero atiende a un cliente, pero cada cliente es atendido en el orden en que se encuentre en la formacin Analisis.ppt

Diagramas Estticos
Relaciones entre clases (cont.)
Hay asociaciones que establecen una relacin en ambas Persona Carro Posedo por direcciones Un carro puede tener uno o mas dueos, La multiplicidad es la cantidad de objetos de una clase que se una persona puede tener cero o ms carros relacionan con un objeto de la clase asociada:

1..*

Posee

0..*

*
conecta

Nodo *

La asociacin recursiva es una asociacin de una clase a s misma, una conexin entre objetos de la misma clase
Analisis.ppt

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

Diagramas Estticos
Relaciones entre clases (cont.)

Pliza de Los roles en una asociacin especifican el papel que juega un Seguros objeto en una relacin, se indica con un string colocado cerca de la 0..1 terminal de la asociacin siguiente a la clase a la cualexpresado Est se aplica. Refiere a
0..* 1 en un 1

Compaa Aseguradora

tiene Refiere a

Asegurador

Contrato de Seguros
0..*

tiene
1..* esposa Asegurado

Persona
esposo

casado con Analisis.ppt

Diagramas Estticos
Categora de la asociacin A es una parte fsica de B Caja-TPDV Ejemplos

Relaciones entre de B A es una parte lgica clases (cont.)VentasLneadeProducto-Venta

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 TPDV-Tienda, Producto-Estante DescripcindeProducto-Catlogo DescripcindeProducto-Producto VentasLneadeProducto-Venta

A se conoce/ introduce/ registra/ presenta/ Venta-TPDV 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 Cajero-Tienda Departamento-Tienda Cajero-TPDV Cliente-Cajero Pago-Venta

A es una transaccin relacionada con otra Pago-Venta transaccin B A es propiedad de B TPDV-Tienda

Analisis.ppt

Diagramas Estticos
Tipos de asociaciones

1 rengln:{1,2,3} Asociacin calificada (Qualified association). Representa la Cuadro Tablero columna:{1,2,3} informacin de identidad y reduce la multiplicidad de uno a muchos por una de uno a uno.

Elige Estudiante de Educacin Media Superior Acadmico

{Or}

Elige Comercial

Asociacin Or {or}. En algunos modelos no todas las combinaciones de asociacin son vlidas

Analisis.ppt

Diagramas Estticos
Tipos de asociaciones

Participa en Clase deJugador Asociacin. Una clase puede estar unida a una asociacin. Equipo Se usa para agregar informacin extra sobre un enlace; por ejemplo, el tiempo en que el link fue creado. Cada enlace est Negociado por Director Contrato asociacin. asociado a un objeto de la clase de General

Compaa Aseguradora

1 Asegurador

0..*

Contrato de Seguros
0..* 0..1

1..* Ms de Asociacin ternaria (Ternary association). Asegurado dos clases pueden asociarse con otra, la asociacin ternaria asocia tres clases. Persona

Pliza de Seguros

Analisis.ppt

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 Comida describen diferentes niveles de abstraccin. Se indica con rombo 1 en blanco en el lado de la clase que agrupa a las dems. Se puede 1 tener una {O} restriccin 1 una agregacin, como1 en la en 1 relacin {O} que se indica con lnea punteada Comida Ensalada PlatoFuerte Postre

Tablero

Cuadros

Una composicin es una agregacin donde cada componente Analisis.ppt puede pertenecer tan solo a un todo. Se representa con diamante

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, Vehculo 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.

Carro

Bote

Camin

Analisis.ppt

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

MaquinaDeEscribir
Teclado
Analisis.ppt

Diagramas Estticos
Diagrama de objetos
Un diagrama de objetos en UML usa la misma notacin que los Autor Computadora Usa diagramas de clases, ya que los objetos solo son instancias de la Clases: nombre: String nombre: String misma clase. 1..* 0..*

edad: Integer

memoria: Integer

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

Bob1:Computadora nombre=IBM 128 Memoria=128

Analisis.ppt

Diagramas Estticos
Registra-venta-de

Diagrama de Clases

Descritas-por
1

Modelo Conceptual de
*

Catalogo Punto de Venta deProducto

1 *

Contiene
1..*

Especificacion deProducto Descripcion Precio

Codigode barras
1 *

0..1

VentasLinea deProducto cantidad

1..* 1

Usado-por

Tienda Direccin Nombre

1 1..*

Describe

Almacena
1 *

Producto

Contenidas-en
1

Capturas terminadas
* 1 1 1

Contiene
1

TPDV

Iniciado-por

Venta Fecha Hora

1

Capturadas-en

Gerente

Registra-ventas-en

Pagado-por
1

Iniciado-por
1 1

Pago Monto

Cliente Cajero Analisis.ppt

Diagramas Dinmicos
Diagramas de estados Estado Presenta los estados en los que puede encontrarse un objeto junto con las transiciones entre los estados, y muestra los Nombre Fin puntosInicio y final de una secuencia de cambios de estado. inicial Variables de Los smbolos UML en un diagrama de estados son: estado Transicin Transicin
Evento que dispara Actividades

Las actividades cuentan con sucesos y acciones de entrada (qu sucede cuando el sistema entra al estado), salida (Qu Analisis.ppt

Diagramas Dinmicos
Diagramas de estados (cont.)
Encender Inicializacin PC puede agregar ciertos la Se

Operaci Apagado Apagar detalles a las lneas de transicin, para n indicar un suceso que provoca una transicin (la que desencadena un suceso) y la actividad de cmputo que se ejecute y haga que suceda Hacer/Arranca de estado. la modificacin
r

Encender la PC

Inicializacin

Operaci n

Apagado Apagar

Hacer/Arranca Las condiciones de seguridad permiten establecer una relacin r Teclazo o movimiento [lapso transcurrido]

entre estados que dependen de que sedel ratn dicha condicin. cumpla
Protector De pantalla

Analisis.ppt

Diagramas Dinmicos
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 Operacin original,la esperasecuencialmente. ligados A Registro de Representacin Tambin accin concurrentes cuando pueden ocurrir al de la accin de has subestados una accin del usuario del usuario del usuario mismo tiempo. Se representan dentro del estado original, separados por lnea punteada.

Verificar el conmetro del sistema

[lapso transcurrido]

Actualizar despliegue

Analisis.ppt

Diagramas Dinmicos
Diagramas de estados (cont.) Estados histricos.

Operacin Se dice de los estados compuestos que pueden recordar su subestado activo cuando el objeto H trasciende fuera de tal estado compuesto. A la espera Registro de Se representa con una H y en caso de subestados anidados Representacin se dice que es histrico profundo de la accin de accinrecordar varios niveles (H*) en caso contrario se dice que es superficial una accin cuando alcanza a del usuario del usuario del usuario

Verificar el conmetro del sistema

[lapso transcurrido]

Actualizar despliegue

[lapso transcurrido]

Teclazo o movimiento del ratn Analisis.ppt

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

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. Actividad 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 1 Actividad 2

La transicin se muestra como una flecha, normalmente no se les pone etiqueta, a menos que se tenga una condicin.

Analisis.ppt

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 Fin de la la barra han sido terminadas. Se utilizan para la ejecucin de jornada actividades en paralelo.

Bao

Descanso

Analisis.ppt

Diagramas Dinmicos
Diagramas de actividades (cont.) Televisin Las indicaciones, permiten que se ejecuten otras actividades, Remoto.Tecleo (canal) usando un pentgono convexo para el envo del un evento y uno cncavo para la recepcin del Oprimir numero evento.
Fin de la jornada de canal

Cambiar(canal)

Cambiar(canal)

Oprimir numero de canal

Analisis.ppt

Diagramas Dinmicos
Diagramas de actividades (cont.)
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 Analisis.ppt

Diagramas Dinmicos
[prestatario] Encontrar libro Diagramas de actividades (cont.) en gaveta [regresador] de un diagrama de actividades en una biblioteca. Ejemplo

miembro

bibliotecario

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

Diagramas Dinmicos
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 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. Analisis.ppt

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 :Objeto 2 rectngulo:Objetoaltura va en relacin a la duracin de la cuya 1 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)

Analisis.ppt

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. Analisis.ppt

Diagramas Dinmicos
Diagrama de secuencias. (cont.) prepara() *[para cada El siguiente ejemplo muestra lnea de
pedido] prepara() Ventana de Entrada de Pedidos unPedido Una Lnea de Pedido Un artculo de inventario

Objeto Iteracin 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

Diagramas Dinmicos
Diagrama de secuencias. (cont.) 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 Analisis.ppt

Diagramas Dinmicos
Diagrama de secuencias. (cont.) 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 Analisis.ppt ejemplo, entonces el coordinador notifica a la Transaccin que

Diagramas Dinmicos
nuevo Una Transaccin nuevo unCoordinador de transacciones

Diagrama de secuencias. (cont.) un primer

nuevo Activacin Mensaje asncrono Revisor de transaccin nuevo

un segundo Revisor de transaccin

bien se suprimen las dems transacciones

todo terminado?

bien el objeto se borra a s mismo

es Vlido

todo terminado? Autodelegacin

Analisis.ppt

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) Analisis.ppt Si quiere ver el comportamiento a travs de muchos casos de uso o

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. :Nombre1 Un diagrama de secuencias1:Agregar() convertido en uno de puede ser colaboraciones y viceversa. 3:Actualizar() una cifra al mensaje para indicar la secuencia propia Se agregar :Nombre2 del mensaje.

:Nombre3

2:Modificar()
Analisis.ppt

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 Tecleo El sistema operativo le notifica a la CPU El sistema operativo actualiza la GUI :GUI 1:notificar(tecleo) La CPU notifica a la tarjeta de video La 6:respuesta() tarjeta de video enva un mensaje al monitor El monitor presenta el carcter alfanumrico en la pantalla, con lo que se har evidente al 3:actualizar(tecleo) :Sistema operativo usuario. :Monitor
2:actualizar(tecleo) 5:mostrar(tecleo)

:CPU
4:notificar(tecleo)

:Tarjeta de video

Analisis.ppt

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 Analisis.ppt de las condiciones

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) calculadora.java clases que lleva a cabo la y una estructura de especificacin. Su representacin es:

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 Analisis.ppt diferenciar los diferentes tipos de componentes, por ejemplo: archivo , biblioteca

Diagramas de Implementacin
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 Analisis.ppt

Diagramas de Implementacin
Diagramas de componentes (cont.) streams.o MiEntradaSalida biblioteca Un diagrama de componentes mostrando las dependencias de tiempo de compilacin:
compilar ligar

MiAplicacin ejecutable

Programa de bsqueda

Resultado de la bsqueda

Analisis.ppt La interfaz se puede representar por una lnea con un crculo

Diagramas de Implementacin
ProcesadorTextos.exe Diagramas de componentes (cont.) Clases: ProcesadorTextos Si un componente implementa clases se puede establecer la VerificadorOrtografico ContadorPalabras relacin entre el componente y las clases como sigue:

ProcesadorTextos.exe

ProcesadorTextos

VerificadorOrtografico

ContadorPalabras

Analisis.ppt

Diagramas de Implementacin
Diagramas de componentes (cont.) 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 Interfaz AWTEventMulticaster ElementoDeEscucha se dice que provee una interfaz de exportacin, al que accede a un servicio se dice que utiliza una interfaz de importacin.
cambioAlEstadoDelElemento()

Analisis.ppt

Diagramas de Implementacin
Diagramas de componentes (cont.) Pgina Web con controles ActiveX.
VBScript ActiveX DisposicionAnimacion.alx

Animacion.htm

ActiveX BotonEjecutar ActiveX ImagenEsfera

ActiveX BotonDetener ActiveX CronometroEsfera

ActiveX BotonReinicar

Esfera.gif ActiveX CuadroCombCronometro ActiveX CuadroCombDistancia

Analisis.ppt

Diagramas de Implementacin
Diagramas de distribucin. Los diagramas de distribucin muestran la disposicin fsica de los distintos nodos que componen un sistema y el reparto Nodo de los componentes sobre dichos nodos. Un nodo representa todo tipo de equipo de cmputo y se representa por un cubo:

Los estereotipos permiten precisar la naturaleza del equipo:

Dispositivos

Analisis.ppt

Diagramas de Implementacin
Diagramas de distribucin. Los nodos se interconectan mediante soportes bidireccionales (en principio) que puede a su vez estereotiparse. Servidor Se pueden mostrar los componentes en relaciones de dependencia con un nodo: telefnico Directorio
corporativo

Programa de bsqueda

Resultado de la bsqueda

Analisis.ppt

Diagramas de Implementacin
Diagramas de distribucin. (cont.) Las conexiones entre nodos se puede poner mediante una Directorio telefnico corporativo relacin
Servidor

Programa de bsqueda

Resultado de la bsqueda

Comunicacin

Cliente
Programa de Presentacin

Analisis.ppt

Diagramas de Implementacin
Dispositivo Dispositivo Dispositivo Dispositivo Diagramas de distribucin. (cont.) Monitor Daewoo Impresora Impresora Scanner Microtek CMC-1505 HP Deskjet 610L HP Lasejet 5L SlimScanC3 Aplicacin de los diagramas de distribucin. Dispositivo Camara Digital Polaroid Flash640

Un equipo de cmputo casero podra ser como sigue:

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

Procesador ISP Infosel.net

Dispositivo Terminador

Dispositivo Terminador

Analisis.ppt

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. Analisis.ppt Estas listas no pueden llegarles a los adjuntos antes de la semana 3. Esto es, muy tarde para que los

Caso de Estudio (CS4)

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

Caso de Estudio (CS4)

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 Producir la lista CS4 Organizador Cursos CS3 Inscribir en los mdulos.

Producir el manual del curso

OEP

CCS4

Adjunto CS4

Inscribir en los Mdulos

eCS4 Director de estudios CS4

Analisis.ppt

Caso de Estudio (CS4)

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 Analisis.ppt imprime y actualiza la pagina Web del mismo.

Caso de Estudio (CS4)

Diagrama de clases (CS4) 0..* Mdulo Un diagrama de clases a nivel conceptual, sin incluir 6 6..* actividades y operaciones:
Adjunto
toma 1 Imparte

Director de Estudios
1

dirige

1..*

1..*

0..*

Estudiante

Cursos Grado
esta en 1

Estudiante otros aos

Estudiante 4to ao

0..*

Analisis.ppt

Caso de Estudio (CS4)

Jefe de Adjunto Comit Diagrama de actividad (CS4) OEP CCS4 Departamento Acadmico El siguiente diagrama muestra el flujo de trabajo requerido Actualizar secciones Determinar principales para los mdulos determinar qu cursos hay, quien los imparte, generar los manuales de los cursos: Asignar Adjuntos Actualizar registro de mdulo

Imprimir manual

Generar versin HTML Analisis.ppt

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.

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 Entracomer o esperar sentado en rea de espera. el cliente
[Tiene abrigo y/o sombrero] Ayudar a quitrselo [Prefiere el bar] Guardarlo

Entrevista de Anlisis

[Lista de espera]
[No hizo reservacin] Dejar su nombre

Espera en el bar

[Prefiere el rea de espera]

Aguarda en el rea de espera

Analisis.ppt

Caso de Estudio (Restaurante)

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

Caso de Estudio (Restaurante)

Entra el cliente
[Tiene abrigo y/o sombrero]

Diagrama: Servir a un cliente

[Prefiere el bar]

Ayudar a quitrselo

Guardarlo

[Lista de espera]

[No hizo reservacin]

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

Tomar un pedido de bebidas

Llamar al asistente Servir Pan y agua Traer bebida Ir por las bebidas

Sugerir platillo

Leer Men

Elegir

Notificar al chef

Traer entremes

Preparar platillo

Analisis.ppt

Modelado en un diagrama Por separado

Caso de Estudio (Restaurante)

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

Caso de Estudio (Restaurante)

Traer entrems Ingerir entrems Traer el plato fuerte Preparar platillo

Modelado en un diagrama Por separado

Diagrama de Servir a un cliente (cont.)

[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

Caso de Estudio (Restaurante)

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

Caso de Estudio (Restaurante)

Recibir comanda

Preparacin de platillos
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

Caso de Estudio (Restaurante)

Clases y asociaciones 1 1 1

Ingiere Liquida Deja Postre Cuenta Propina Reservacin

1

El cliente se asocia con una gran cantidad de clases, como 1 1 1 Hace muestran las asociaciones a continuacin: 1
Cliente
1 1 1..* 1 1 1 1

Es atendido por Da a guardar

Mesero Sombrero
0..* 1

Da a guardar

Encargado del Guardarropa

Elige del Abrigo Hace

1 1 1

0..*

Ingiere

Elige del
1

Men

Alimento

Men del postre

Orden

Analisis.ppt

Caso de Estudio (Restaurante)

Cliente

Detalle de las clases Cliente, sus

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

nombre horallegada orden atributos seran: horaservicio

Analisis.ppt

Caso de Estudio (Restaurante)

Empleado Detalle de las clases

Empleado es una clase abstracta que puede contener la informacin de los empleados domicilio y como clases secundarias, se pueden tener Mesero, Chef, Gerente, Asistente. RFC
aosExperiencia fechaContratacin salario

nombre

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

Caso de Estudio (Restaurante)

Diagrama de distribucin, Restaurante

Los meseros contarn con una computadora palmtop y la utilizarn para comunicarse con la cocina Dispositivo y con los mozos de piso. Estos ltimos tambin tendrn palmtops para comunicarse. La cocina Computadora tendr una terminal de escritorio y una o varias pantallas. El gerente tendr una en su oficina. palmtop Inalmbrico

Dispositivo Red

Dispositivo
PC de la cocina

Dispositivo
PC del gerente

Analisis.ppt

Caso de Estudio (Restaurante)

Casos de uso

Mesero

Totalizar Una cuenta Transmitir una Orden al bar Notificar al chef del progreso de los clientes En sus alimentos

El paquete mesero

Sondear el progreso De la orden Tomar una orden Incluir Transmitir la orden a la cocina Incluir Llamar a un mozo de piso Tomar una orden De bebida

Obtener un acuse De recibo

Recibir una notificacin de la cocina Imprimir una cuenta Recibir una notificacin del bar

Cambiar una orden

Llamar a un Asistente

Analisis.ppt