Anal Is Is

Análisis y Diseño de Sistemas de Información Temario
• Temario
• Ingeniería de Software
• Estructuras de Objetos
• Diagramas Estáticos
• Diagramas de Clases
• Diagramas de Casos de Uso
• Diagramas Dinámicos
• Diagramas de Estado
• Diagramas de Actividades
• Diagramas de Secuencias
• Diagramas de Colaboración
• Diagramas de Implementación
• Diagramas de Componentes
• Diagramas de Distribución
• Casos de estudio
• Patrones de Diseño
• Metodologías
• Instructor
• Ing. y M.A. Francisco Javier Mariscal Flores fmarisc@uach.mx
Analisis.ppt Pag. 1
Análisis y Diseño de Sistemas de Información Bibliografía
• Bibliografía
Using UM
with obje
Analisis.ppt Pag. 2
Análisis y Diseño de Sistemas de Información Ingeniería de Software
• ¿Qué es un BUEN SISTEMA?

• Un buen sistema (o uno de alta calidad) es aquél que cumple con las
necesidades del cliente. El sistema debe ser:
• UTIL y UTILIZABLE: Un buen software hace más fácil o mejor la vida a las personas.
• CONFIABLE: Un buen software tiene pocos errores.
• FLEXIBLE: Las necesidades cambian con el tiempo, aún cuando el software se está
desarrollando, entonces es importante poder hacer cambios posteriores al software.
Debe podérsele dar mantenimiento después de liberado.
• ACCESIBLE: tanto para comprar como para mantener. Debe ser razonablemente
fácil y rápido poderlo desarrollar o darle mantenimiento.
• DISPONIBLE: De otra forma no importa que tan bueno es. Debe ser capaz de
ejecutarse el el hardware disponible y con el sistema operativo disponible, etc. Debe
existir y entregarse el software prometido.
• ¿Tenemos buenos sistemas?

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

• A veces las fallas en algunos de los atributos deseables de los
sistemas han provocado catástrofes como las siguientes:
• Ariane 5: Fallas de software hacen explotar la nave (1996)
• Taurus: Mercado accionario londinense no pudieron terminar proyecto de
software y tuvieron grandes pérdidas (1993)
• Manejo de maletas de Denver: Fallas del sistema y el alto costo de
corregirlo, no permitía al aeropuerto abrir a tiempo.
• Sistema de Ambulancias de Londres: Fallas de diseño y de ejecución
provocaron la muerte de gente por falta de ambulancias (1992)
• Therac-25: Sobredosis radioactivas por fallas en el software de la máquina
a varias personas (1987)
• Según W. Wayt Gibbs en Software’s chronic crisis. Scientific
American (International Ed.) pp 72-81, Sep. 1994. dice:
• En promedio, los proyectos grandes toman 50% más de tiempo de lo
planeado;
• 75% de los proyectos grandes tienen fallas operacionales;
• 25% de los proyectos grandes son cancelados
Analisis.ppt Pag. 5
• Promesas, promesas
• Cada nueva tecnología promete reducir los tiempos de desarrollo e
incrementar los promedios de éxito de los proyectos.
• Todos lo dudamos.
• Según Frederick P. Brooks (The mythical man-month, Addison-
Wesley 1975/1995), mientras más grande sea el proyecto, mayor será
la proporción del costo y tiempo del proyecto gastado en la
comunicación entre la gente del proyecto, porque cada persona tiene
más gente con quién comunicarse. Cuando un proyecto empieza a
quedarse atrás en el tiempo, el poner más gente por lo general falla.
• El Departamento de Defensa de EU, intentó resolver la crisis del
software y comisionó el diseño del lenguaje de programación ADA, el
cual se estandarizó en 1983, el cual soportaba lo mejor de los
conceptos de análisis, diseño y programación estructurados, la
modularidad y la encapsulación fueron conceptos clave en el diseño
del lenguaje, pero aún esta enorme inversión ha fracasado.
Analisis.ppt Pag. 6
• ¿Cómo son los sistemas considerados buenos?

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

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

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

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

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

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

• Un módulo puede tener varias interfases
• A veces es necesario documentar los servicios que un módulo provee con
varias y diferentes interfases, de un modo que podamos ser más precisos
acerca de que servicios un cliente dado necesita. Esto es a la vez útil para
el mantenimiento y para el reuso.
• Ya tenemos una respuesta parcial a la pregunta de ¿Cómo son los
sistemas considerados buenos?
• Un buen sistema consiste de módulos encapsulados
• Abstracción: Alta Cohesión.

• Los buenos módulos tienen la propiedad de que sus interfases proveen una
abstracción de alguna cosa que se entiende intuitivamente la cual sin
embargo puede ser compleja de implantar. Tales módulos se dice que tienen
una alta cohesión.
• La interfase realiza una abstracción de las cosas que el desarrollador no tiene
que entender para usar el módulo, dejando una figura coherente de lo que el
usuario de un módulo quiere conocer.
• El desarrollador está protegido de información irrelevante acerca de cómo el
módulo hace lo que hace. Esta preocupación de permitir al desarrollador
concentrarse en lo esencial es ligeramente diferente a la preocupación de
encapsulación para lograr un acoplamiento bajo, lo cual va dirigido a la
prevención de que el desarrollador use información escondida.
• Abstracción es cuando un cliente de un módulo no necesita saber más
de lo que está en la interfase.
• Encapsulación es cuando un cliente de un módulo no es capaz de
conocer más de lo que está en la interfase.
• Si un módulo, de cualquier tamaño y complejidad, es una buena abstracción
(tiene una alta cohesión y un acoplamiento bajo) puede ser factible de reusarlo
en posteriores sistemas, o de reemplazo en sistemas ya existentes.
• Estaríamos hablando de un componente insertable o conectable (“pluggable
component”)
• Arquitectura y componentes
• La arquitectura donde se desarrolla y aquella dónde se va a usar.
• En los 80s y principios de los 90s, la tecnología orientada a objetos
iba a ser la solución a la crisis en desarrollo de software.
• Componente
• Es una cosa que se puede reusar o reemplazar
• Desarrollo Basado en Componentes (CBD, Component Based
Development)
• Un módulo con propiedades que lo hacen reusable y reemplazable.
• ¿Qué determina cuando un módulo es reusable?
• Tiene una cohesión alta
• Acoplamiento bajo con el resto del sistema
• Interfase bien definida
• Abstracción encapsulada de una cosa bien entendida
• Si un módulo es reusable depende del contexto en que se desarrolló y en
el cual va a ser reusado.
• Ejemplo de un factor no técnico de reuso: Recompensar al programador
por el número de líneas que escriben.
• Los factores técnicos involucran decisiones de arquitectura y más alto
nivel.
• Diseño basado en componentes: Insertabilidad, conectabilidad

(pluggability)
• La forma ideal de construir un nuevo sistema es tomar algunos
componentes existentes y juntarlos.
• Pluggability es la propiedad que tienen los componentes de poder
ser juntados.
• Los componentes tienen que ser partes que llenan o cumplen
necesidades en un sistema completo.
• Las partes tienen que ser compatibles unas con otras y eso depende
de la presencia de una arquitectura adecuada.
• Las decisiones importantes acerca de la arquitectura:
• Deben ser tomadas lo más pronto en el proyecto.
• Son afectadas por la naturaleza de los componentes en la arquitectura
• Pueden ser influenciadas por el medio ambiente del proyecto
• ¿Cómo se construyen los buenos sistemas?

• Usar un PROCESO definido con FASES claras, cada una de las
cuales tiene un PRODUCTO FINAL (puede ser un documento o tal vez
un prototipo)
• Preocuparse por cumplir con un conjunto claro de requerimientos,
que se definen tan pronto como sea posible
• Preocuparse por formas de verificación y validación, tan esenciales
como construir el producto en sí mismo.
• Usar un almacén de CONOCIMIENTOS, ARQUITECTURAS y
COMPONENTES relevantes.
• Hacer un uso sensible de herramientas.
• Proceso de desarrollo
• Método tradicional para el desarrollo de Sistemas
Análisis
Diseño
Implementación
Pruebas
Mantenimiento
• Cada fase se realiza hasta que se completó la anterior. Supone que no se vuelve a entrar en las fases
terminadas.
• Administración de riesgos implica:
• 1.- Cada vez que se toma una decisión se tiene el riesgo de que sea incorrecta. Mientras más se
tarde en detectar un error más difícil es corregirlo. Evaluaciones frecuentes ayudan a corregir.
• 2.- Un riesgo mayor es que los desarrolladores malinterpreten los requerimientos. La
elaboración de prototipos permite reafirmarlos.
• Espiral de desarrollo:
Construcción Transición
Diseño Análisis
• Metodología Unificada.
• Gran cantidad de metodologías orientadas a objetos han salido a la luz y las de Grady Booch, James
Rumbaugh, Ivar Jacobson se unieron para formar el Lenguaje de Modelación Unificado (UML) y fue
adoptado por el Object Management Group (OMG) como el estándar para cuestiones orientadas a
objetos.
• Proceso de desarrollo (cont.)

• Procesos donde utilizar UML.
• Los procesos iterativos deberán tener un plan de que serán las
iteraciones y que será cubierto por cada una de ellas.
• En la fase de construcción:
• El comienzo proporciona el compromiso del patrocinador del
proyecto de seguir adelante se conoce el caso de negocios y su
factibilidad y alcance básicos.
• La elaboración da la arquitectura básica de el sistema, un plan para el
acuerdo de construcción, identifica todos los riesgos significantes,
entendimiento cabal de los mayores riesgos para no estar
preocupados.
• La construcción termina con una versión beta del sistema.
• Transición es el proceso de introducir el sistema a sus usuarios.
• Otros procesos han adoptado UML como su lenguaje de modelación:
Catalysis, Rational Unified Process, etc.
Análisis y Diseño de Sistemas de Información Diagramas Estáticos
• Casos de Uso
• Es una colección de situaciones que ocurren cuando un actor usa un sistema para
completar un proceso. Normalmente un caso de uso es un proceso relativamente largo,
no un paso individual o transacción. Cada caso de uso necesita representar una tarea, o
una unidad coherente de funcionalidad, la cuál necesita ser soportada por el sistema.
• Una vez identificado los casos de uso se pueden crear diagramas de casos de uso para
colocar el caso de uso en contexto. Involucrando las fronteras del sistema para un
conjunto de casos de uso y definiendo las líneas de comunicación entre un actor
particular y el caso de uso.
Sist. de Información
de Biblioteca
Recursos para
Prestamo
Agregar
recursos
Bibliotecario Usuario
Regresar
Recursos
• En las etapas iniciales de desarrollo del proyecto, los diagramas de casos de uso
describen las actividades del mundo real y las motivaciones. Se puede afinar los
diagramas en etapas posteriores para reflejar las interfases de usuario y los detalles de
diseño.
• Cuando se tienen varios subsistemas es común dibujar la frontera del sistema, pero
generalmente se omite.
• Casos de Uso (cont.)

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

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

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

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

• Relaciones entre casos de uso.
• La inclusión permite volver a utilizar los pasos de un caso de uso dentro
de otro
Exhibir
«incluir» el interior
Recolectar
dinero
«incluir» 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 más
corto y fácil de entender
• Al identificar funcionalidad en común entre los casos de uso al
principio puede ser una forma de descubrir la posibilidad de reusar
un componente que implemente la funcionalidad compartida.
• Sin embargo se tienen las siguientes desventajas:
• Peligro de buscar funcionalidad y al hallarla fomentar la elaboración
de un sistema basado en funciones, top-down con sistemas
inflexibles.
• Es difícil para alguien no adiestrado en UML entender la notación de
«incluir»

• Relaciones entre casos de uso.(cont.)
• La extensión, permite crear un caso mediante la adición de pasos a uno
existente, Se dice que el nuevo caso de uso extiende al original dado que
agrega otros pasos a la secuencia del caso de uso original, que se
conoce como el caso de uso base.
Exhibir
«incluir» el interior
Reabastecer
Punto de extensión llenar
los compartimientos
«incluir» Cubrir
«extender» el interior
(llenar los
Compartimientos)
Reabastecer de
Acuerdo a las ventas
• Generalización. Un caso de uso secundario hereda las acciones y

significado del primario y además agrega sus propias acciones.
Comprar Comprar un vaso

gaseosa de gaseosa

• Relaciones entre casos de uso.(cont.)
• Las reglas para aplicar «incluir» o «extender» son:
• Utilice extender cuando describa una variación de conducta normal.
• Emplee incluir para repetir cuando se trate de uno o varios casos de
uso y desee evitar repeticiones
• Algunas veces el termino escenario es usado como sinónimo de casos de
uso, pero en el contexto de UML, la palabra escenario se refiere a una sola
ruta a través de un caso de uso, una ruta que muestra una particular
combinación de condiciones dentro de dicho caso de uso.
• Cuando emplear los casos de uso
• Todo caso de uso es un requerimiento potencial y hasta que no haya
sido capturado, no se podrá planear como manejarlo en el proyecto.
La mayoría se generan durante la captura de requerimientos, pero se
irán descubriendo otros conforme se avance en el proyecto, es
necesario estar siempre pendiente de ellos.
• El modelado conceptual junto con los usuarios ayuda a descubrir los
casos de uso.
• Se puede tener diferente grado de granularidad, por ejemplo para un
proyecto de 10 personas-año se esperarían 20 casos de uso ó 100
casos dependiendo del nivel de detalle.
Análisis y Diseño de Sistemas de Información Estructuras de Objetos
• ¿Qué es un objeto?
• Conceptualmente, un objeto es una cosa con la que se puede
interactuar: Se le pueden mandar varios mensajes y reaccionará. El
como se comporte dependerá del estado interno actual del objeto. Un
objeto tiene una identidad la cual lo distingue de todos los demás
objetos.
• El estado de un objeto se representa mediante los datos
almacenados en el mismo, los cuales son llamados atributos.
• El comportamiento de un objeto es lo que éste puede hacer y se
encuentra contenido en métodos, los cuáles se invocan enviándoles
mensajes.
• Representación UML de un objeto (Diagrama de Clase):
Empleado
- Nombre:String
- Sexo:Boolean
- Direccion:String
- RFC:String
+ TomarNombre:String
+ TomarRFC:String
+ TomarDireccion:String
• Problemas con la definición de objetos

• Se pueden crear objetos degenerados como:
• Un objeto sin datos. Que sería lo mismo que una biblioteca de funciones.
• Un objeto sin métodos, con solo operaciones del tipo crear, recuperar,
actualizar y borrar (Que se correspondería con las estructuras de datos
tradicionales).
• Un sistema construido con objetos degenerados no es un sistema
verdaderamente orientado a objetos.
• “Las aplicaciones de gestión están constituidas mayoritariamente
por objetos degenerados”
• Clases
• Es un tipo (o plantilla) de objeto, el cual describe un conjunto de objetos que
tienen un rol equivalente en un sistema. Para crear una instancia de un objeto
se usa la clase como la base para determinar como formar el objeto.
• Atributos
• Son los datos que están encapsulados dentro del objeto y determinan su
estado. Algunos pueden cambiar (p.ej: un empleado puede cambiar de
dirección), otros son inmutables y deben conservar el mismo valor durante la
vida del objeto (p.ej: el RFC de un empleado)
• Métodos
• Son una implementación del comportamiento requerido por una clase, cada
instancia de objeto proveniente de la clase tendrá éstos métodos. Podrán ser
llamados por otros objetos o internamente.
• Mensajes
• Los objetos responden o actúan en función a los mensajes que reciben y el
estado actual de sus atributos. Cuando se manda un mensaje a un objeto se le
esta ordenando que ejecute un método y generalmente se desconoce el
código que ejecutará porque está encapsulado.
• Interfases
• Es el medio fundamental de comunicación entre los objetos. La interfase
describe completamente cómo van a interactuar con la clase los usuarios de
la clase. La interfase pública de un objeto define cuáles mensajes aceptará sin
importar de donde provengan.
• Herencia
• Permite a una clase heredar los atributos y métodos de otra clase, facilitando de
esta forma la reutilización del código y permitiendo crear nuevas clases mediante
la abstracción de los atributos y métodos comunes.
Mamíferos
Superclase
- colorOjos: int
+ TomarColorOjos: int
Perro gato
-frecuenciaLadrido: int -frecuenciaMaullido:int Subclases
+ Ladrar: int + Maullar: int
• Las clases Perro y Gato heredan de la clase Mamíferos, esto significa que la clase
Perro tiene los siguientes atributos:
• colorOjos Heredada de la clase Mamíferos
• frecuenciaLadrido Definida solo para la clase Perro
• y los siguientes métodos:
• tomarColorOjos Heredada de la clase Mamíferos
• Ladrar Definida solo para la clase Perro
• Abstracción
• Quitar las propiedades y acciones de un objeto para dejar sólo aquellas que
sean necesarias.
• Polimorfismo
• Significa tener muchas formas. En lenguajes de programación significa que
una entidad puede tener uno de muchos tipos. En orientación a objetos una
variable polimórfica puede referirse a diferentes objetos en diferentes tiempos.
Las subclases pueden hacer caso omiso de los métodos o atributos de las
superclases y definir los suyos propios.
• La asignación dinámica permitirá que al mandar un mensaje a un objeto se
asignará dinámicamente dependiendo del código del método que haya
definido la instancia de dicho objeto que puede ser uno propio o heredado.
• Encapsulamiento
• Se oculta la funcionalidad de los objetos, evitando que otros objetos o el
mundo exterior puedan ver sus operaciones internas.
• Asociaciones
• Un objeto puede estar relacionado con uno o más objetos
• Composiciones
• La agregación de objetos permite definir composiciones, en las que cada
componente se considera como tal sólo como parte del objeto compuesto.
• Diagramas
• Para describir el diseño de un sistema, el lenguaje que usemos debe estar
basado en diagramas, porque la experiencia nos ha mostrado que es así como
pensamos en los sistemas.
• No es el diseño, sino una representación de un modelo de el diseño, que
captura un aspecto de el diseño de una forma que puede ser discutida.
• Los modelos de diagramas a considerar son:
• El modelo de casos de uso que describe el sistema requerido desde el punto de
vista de los usuarios.
• El modelo estático que describe los elementos de el sistema y sus relaciones.
• El modelo dinámico que describe el comportamiento del sistema a través del
tiempo.
• podremos tomar una:
• Vista lógica nos permitirá alcanzar los requerimientos funcionales. Cuáles partes
van juntas? Cuáles son las clases y sus relaciones?
• Vista de proceso ayuda a lograr los requerimientos no-funcionales, como el
desempeño y la disponibilidad. Cuáles necesidades de control hay? Qué
actividades pueden ser concurrentes? Qué sincronización debe haber?
• Vista de desarrollo ayuda a administrar el proyecto. Cuál parte hará cada elemento
del equipo de gente? Que partes pueden reusarse?
• Vista física ayuda a alcanzar los requerimientos no-funcionales, haciendo una vista
más concreta que la de proceso.Cuales partes correrán en la misma computadora?
• Diagramas UML
• La relación existente entre los diversos diagramas de UML se
muestra a continuación:
Diagrama
Diagramadede
Clases
Clases
Diagrama
Diagramadede
Casos
Casosde
de Diagrama
Diagramade
de Distribución
Distribución
Uso
Uso Secuencias
Secuencias
CODIGO
CODIGO
Diagrama
Diagramade
de
Estados Diagrama
Diagramade
de
Diagrama Estados
Diagramadede Componentes
Componentes
Colaboración
Colaboración
Diagrama
Diagramadede
Actividad
Actividad
• Objetos y Clases
• Identificar las clases que deben existir en nuestro sistema, es la parte
mas grande del trabajo de diseñar sistemas orientados a objetos.
• Construir rápidamente y lo más barato posible el sistema que alcance
nuestros requerimientos.
• Construir un sistema que sea fácil de mantener y adaptar para los
requerimientos futuros.
• Cada pieza de comportamiento requerida por el sistema deberá ser
proporcionada de una manera sensible, por los objetos de las clases
que elijamos.
• Un buen modelo de clases consiste de clases de los objetos
principales, los cuales no dependen de la funcionalidad particular
requerida actualmente
• Una técnica es la identificación de sustantivos. Descarte los
candidatos que sean inapropiados por alguna razón, renombrando
las clases restantes si es necesario
• Pueden descartar candidatos por: redundancia, vaguedad, son un
evento o una operación, son meta-lenguaje, están fuera del alcance
del sistema, son un atributo.
• Objetos y Clases (cont.)

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

• Diagramas de clases
• Describe la vista estática de un sistema en términos de clases y relaciones entre las clases, la
representación de una clase es con:
Nombre
• ejemplo: Atributos ...
Operaciones ...
Automóvil Nombre de la clase

+ Placa:String
-Datos:DatosAutomóvil Atributos de la clase: son los datos
+ Velocidad:Integer contenidos en un objeto de la clase
+ Dirección: Dirección
+Manejar(vel:Integer, Operaciones de la clase: definen la forma en
dir:Dirección) La cual los objetos pueden interactuar,
+ tomarDatos():
DatosAutomóvil
Cuando un objeto manda un mensaje a otro,
Le esta pidiendo que ejecute una operación
• Los atributos y las operaciones pueden tener diferente visibilidad. Es visible si puede ser referenciado
desde otras clases diferentes a donde esta definido, se definen como públicos(+) ,privados(-) ó
protegidos (#)
• Una restricción es un texto que especifica una o varias reglas que sigue la clase, se indica mediante
un texto libre encerrado entre llaves {}. Existe el OCL que define de manera formal las restricciones en
UML.
• Las propiedades se indican mediante llaves, dando propiedades a los elementos donde se haya n
incluido estas.

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

• Asociación, es una conexión entre clases, lo que significa que también es
una conexión entre los objetos de esas clases. En UML, una asociación es
una relación que describe un conjunto de ligas, que están definidas como
una conexión semántica entre un conjunto de objetos.
• Corresponden a los verbos. Existen instancias de asociación.
• Normalmente una asociación es bidireccional, lo que significa que si un
objeto está asociado con otro objeto, ambos objetos se conocen uno al
otro.
• Asociación normal:
Usa
Autor Computadora
Un autor usa una computadora

• Las restricciones en las asociaciones, permiten que se siga cierta regla:
{Ordenado}
Atiende
Cajero Cliente
Un cajero atiende a un cliente, pero cada cliente es

atendido en el orden en que se encuentre en la formación
• Relaciones entre clases (cont.)

• Hay asociaciones que establecen una relación en ambas direcciones
• La multiplicidad es la cantidad de objetos de una clase que se relacionan
con un objeto de la clase asociada:
1..* Posee 0..*

Persona Carro
Poseído por
Un carro puede tener uno o mas dueños,
una persona puede tener cero o más carros
• La asociación recursiva es una asociación de una clase a sí misma, una

conexión entre objetos de la misma clase
*
Nodo
conecta
*
Un nodo se conecta a muchos nodos y estos a su vez se conectan
con varios mas. (en una red de cómputo

• Los roles en una asociación especifican el papel que juega un objeto en
una relación, se indica con un string colocado cerca de la terminal de la
asociación siguiente a la clase a la cual se aplica.
Póliza de
Seguros
0..1
Refiere a Está expresado
1 en un
Compañía 1 tiene 0..* Contrato de

Aseguradora Asegurador
Refiere a Seguros
0..*
tiene
1..* Asegurado
esposa
Persona
esposo
casado con
Categoría de la asociación Ejemplos

A es una parte física de B Caja-TPDV
A es una parte lógica de B VentasLíneadeProducto -Venta
A está físicamente contenido en B TPDV-Tienda, Producto-Estante
A está contenido lógicamente en B DescripcióndeProducto -Catálogo
A es una descripción de B DescripcióndeProducto -Producto
A es un elemento de línea (o renglón) en
VentasLíneadeProducto -Venta
una transacción o reporte B
A se conoce/ introduce/ registra/ presenta/
Venta-TPDV
captura en B
A es miembro de B Cajero-Tienda
A es una unidad organizacional de B Departamento-Tienda
A usa o dirige a B Cajero-TPDV
A se comunica con B Cliente-Cajero
A se relaciona con una transacción B Pago-Venta
A es una transacción relacionada con otra
Pago-Venta
transacción B
A es propiedad de B TPDV-Tienda
• Tipos de asociaciones
• Asociación calificada (Qualified association). Representa la información
de identidad y reduce la multiplicidad de uno a muchos por una de uno a
uno.
renglón:{1,2,3} 1 1
Tablero Cuadro
columna:{1,2,3}
• Asociación Or {or}. En algunos modelos no todas las combinaciones de

asociación son válidas
Elige
Académico
Estudiante de {Or}
Educación Elige
Media Superior Comercial
• Asociación Ordenada {ordered}. Cuando los enlaces entre objetos pueden

tener un orden implícito {ordered} {ordenadas por incremento de tiempo}.
• Tipos de asociaciones
• Clase de Asociación. Una clase puede estar unida a una asociación. Se
usa para agregar información extra sobre un enlace; por ejemplo, el
tiempo en que el link fue creado. Cada enlace está asociado a un objeto de
la clase de asociación.
Participa en
Jugador Equipo
Negociado por Director

Contrato
General
• Asociación ternaria (Ternary association). Más de dos clases pueden

asociarse con otra, la asociación ternaria asocia tres clases.
Compañía 1 0..* Contrato de

Aseguradora Asegurador Seguros
0..*
0..1 Póliza de
Seguros
1..* Asegurado
Persona
• Tipos de asociaciones (cont.)

• Una agregación, es un caso especial de asociación, indica que la relación
entre las clases es de alguna forma parte de un “todo”. Se describen
diferentes niveles de abstracción. Se indica con rombo en blanco en el
lado de la clase que agrupa a las demás.
• Se puede tener una restricción en una agregación, como en la relación {O}
que se indica con línea punteada
Comida
1
{O}
1 1 1 1
Comida Ensalada PlatoFuerte Postre
• Una composición es una agregación donde cada componente puede

pertenecer tan solo a un todo. Se representa con diamante sólido.
1 9
Tablero Cuadros
• En un juego del gato, los cuadros solo tienen sentido si están

formando parte del tablero
• Tipos de asociaciones (cont.)

• La generalización es una relación entre un elemento más general y uno
más específico. El elemento más específico puede tener solo información
adicional. Se utiliza sobre tipos, nunca sobre instancias (una clase puede
heredar otra clase, pero un objeto no puede heredar otro objeto).
• La clase específica o subclase, hereda todo de la clase general, llamada
superclase. Los atributos, operaciones y todas las asociaciones son
heredadas. Una clase puede ser superclase y subclase si esta en una
jerarquía de clases. En gráficas de jerarquía, las clases están conectadas
unas con otras, vía relaciones de generalización.
Vehículo
Carro Bote Camión
• Interfaces y realizaciones
• Una interfaz es un conjunto de operaciones que especifica cierto
aspecto de la funcionalidad de una clase, y es un conjunto de
operaciones que una clase presenta a otras. Se usa el símbolo de
clase pero sin atributos, solamente con las operaciones:
Teclado
marca
cantidadDeteclas
«interfaz»
Ctrl() MaquinaDeEscribir
Alt()
RePag() Teclazo()
AvPag()
...
• Adicionalmente la interfaz puede ser representada como un circulo

MaquinaDeEscribir
conectado con una línea a la clase
Teclado
• Diagrama de objetos
• Un diagrama de objetos en UML usa la misma notación que los diagramas
de clases, ya que los objetos solo son instancias de la misma clase.
Autor Computadora
Usa
Clases:
nombre: String nombre: String
0..* 1..*
edad: Integer memoria: Integer
Juan: Autor Bob1:Computadora

Objetos:
nombre= “Juan P.” nombre=“IBM 128”
edad = 33 Memoria=128
• Diagrama de Clases
• Modelo Conceptual de Punto de Venta
Registra-venta-de
Descritas-por
1
Catalogo Contiene Especificacion

deProducto 1..* deProducto
Descripcion
*
1 Precio
VentasLinea * Usado-por Codigode barras
0..1 1
deProducto Tienda *
Describe
cantidad 1 Dirección Almacena

Nombre 1 Producto
1..* * 1
Capturas 1
Contiene
Contenidas-en terminadas 1..*
TPDV 1
1 1 Iniciado-por
*
Venta
Fecha 1 Gerente
1 Capturadas-en 1
Hora Registra-ventas-en
1 1
Pagado-por Iniciado-por
1 1 1
Pago Cliente
Cajero
Monto
Análisis y Diseño de Sistemas de Información Diagramas Dinámicos
• Diagramas de estados
• Presenta los estados en los que puede encontrarse un objeto junto
con las transiciones entre los estados, y muestra los puntos inicial y
final de una secuencia de cambios de estado.
• Los símbolos UML en un diagrama de estados son:
Estado
Nombre
Inicio Fin
Variables de
estado Transición
Transición
Evento que Actividades
dispara
• 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)
• Diagramas de estados (cont.)

• Se puede agregar ciertos detalles a las líneas de transición, para indicar
un suceso que provoca una transición (la que desencadena un suceso) y
la actividad de cómputo que se ejecute y haga que suceda la modificación
de estado.
Encender Inicialización Operación Apagado Apagar
la PC
Hacer/Arrancar
• Las condiciones de seguridad permiten establecer una relación entre

estados que dependen de que se cumpla dicha condición.
Encender
la PC Inicialización Operación Apagado Apagar
Hacer/Arrancar
[lapso transcurrido] Teclazo o movimiento
del ratón
Protector
De
pantalla

• Subestados. Cuando un estado se encuentra dentro de otro estado,
se conocen como subestados.
• Se dice que pueden suceder en forma secuencial cuando suceden uno
tras de otro y se representan dentro del cuadro de estado original, ligados
secuencialmente.
• También has subestados concurrentes cuando pueden ocurrir al mismo
tiempo. Se representan dentro del estado original, separados por línea
punteada.
Operación
A la espera Registro de Representación
de acción una acción de la acción
del usuario del usuario del usuario
[lapso transcurrido]
Verificar el
Actualizar
conómetro
despliegue
del sistema

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

• Cuando utilizar los diagramas de estados:
• Se tendría que hacer uno por cada clase del sistema, pero se sugiere
hacerlos solo para aquellos que presenten un estado interesante y cuando
la construcción de tales diagramas ayude a aclarar lo que sucede.
• Algunos sugieren usarlos en los objetos de interfaz de usuario y de
control, debido a que tienen el tipo de comportamiento que es útil
describir mediante diagramas de estado.
• En caso de que se desee representar las secuencias general de acciones
de vario objetos y casos de uso, es mejor utilizar el diagrama de
actividades.
• Diagramas de actividades
• Describen como se coordinan las actividades, muestran como puede
ser implementada una operación que debe realizar muchas tareas
diferentes y se desea mostrar cuales son las dependencias
esenciales entre ellas.
• Elementos de un diagrama de actividades:
• La actividad se muestra como una caja con nombre con las esquinas muy
redondeadas, representa cuando la actividad ha terminado
Actividad
• La transición se muestra como una flecha, normalmente no se les pone

etiqueta, a menos que se tenga una condición.
Actividad 1 Actividad 2
• Diagramas de actividades (cont.)

• Barras de sincronización, indica coordinación de actividades y no se
puede pasar de la barra hasta que todas las actividades previas a la barra
han sido terminadas. Se utilizan para la ejecución de actividades en
paralelo.
Fin de la
jornada
Baño Descanso

• Las indicaciones, permiten que se ejecuten otras actividades, usando
un pentágono convexo para el envío del un evento y uno cóncavo
para la recepción del evento.
Televisión Remoto.Tecleo (canal)
Oprimir numero
Fin de la de canal
jornada
Cambiar(canal) Cambiar(canal)
Oprimir numero
de canal

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

• Ejemplo de un diagrama de actividades en una biblioteca.
miembro bibliotecario
[prestatario]
Encontrar libro
en gaveta
[regresador]
Esperar en [regresando]
la fila
[obteniendo
prestado]
Registrar el Poner el libro de
regreso Regreso en gaveta
Registrar el
préstamo
Preparar para
el siguiente miembro

• Cuando utilizar diagramas de actividades:
• Debido a que manejan y promueven el comportamiento en paralelo, son
una herramienta muy útil para el modelado de flujo de trabajo y para la
programación multihilos.
• Se recomienda usarlos para:
• El análisis de un caso de uso. Para comprender qué acciones deben
ocurrir y cuáles son las dependencias de comportamiento.
Asignando posteriormente los métodos a los objetos y mostrando
tales asignaciones mediante diagramas de secuencia o colaboración.
• La comprensión del flujo de trabajo, a través de numerosos casos de
uso. Para representar y entender el comportamiento de las
interacciones entre los casos de uso. Ayuda a aclarar situaciones
dominadas por flujo de trabajo.
• Cuando se trata de aplicaciones multihilos. Son adecuados en éste
uso
• No sirven para:
• Tratar de ver como colaboran los objetos. Usar mejor diagramas de
secuencia o colaboración.
• Para tratar de ver como se comporta un objeto durante su período de
vida. Es mejor usar un diagrama de estados.
• Diagrama de secuencias.
• Muestra la forma en que los objetos se comunican entre sí al
transcurrir el tiempo. Constan de objetos y representando en una
línea vertical el tiempo, se indican las operaciones que ejecuta el
objeto o activación se representan mediante un rectángulo cuya
altura va en relación a la duración de la operación.
• Los mensajes van de un objeto a otro se representan con líneas.
Pueden ser simples (transfieren control), sincrónicos (esperan
respuesta) o asincrónicos (no espera respuesta)
:Objeto 1 :Objeto 2
• Diagrama de secuencias. (cont.)

• Para ilustrar los diagramas de secuencia se usará el siguiente caso de
uso:
• La ventana Entrada de pedido envía un mensaje “prepara” a Pedido.
• El Pedido envía entonces un mensaje “prepara” a cada línea de
pedido dentro del Pedido.
• Cada Línea de pedido revisa el Artículo de inventario
correspondiente.
• - Si esta revisión devuelve “verdadero”, la Línea de pedido
descuenta la cantidad apropiada de Artículo de inventario del
almacén.
• Si no sucede así, quiere decir que la cantidad del Artículo de
inventario ha caído más abajo del nivel de reorden y entonces
dicho Artículo de inventario solicita una nueva entrega.
• En el diagrama siguiente se muestra el diagrama de secuencia

omitiendo las activaciones, que según Fowler, no aportan mucho a la
ejecución de procedimientos y solamente sugiere usarlas en
situaciones concurrentes.

• El siguiente ejemplo muestra
Ventana de Entrada Una Línea Un artículo Objeto
unPedido de inventario
de Pedidos de Pedido
Iteración
prepara() *[para cada Mensaje
línea de
pedido] Condición
prepara()
hayExistencia:=
revisa() necesitaReorden:=
necesitareordenar()
[hayExistencia]
descuenta() Autodelegación
[necesitaReorden]
Regreso nuevo
Un Artículo
de reorden
Creación
[hayExistencia]
nuevo()
Un Artículo
para entrega

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

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

nuevo Una
Transacción
nuevo unCoordinador
de transacciones
un primer
nuevo
Revisor
Activación
de transacción
Mensaje asíncrono un segundo
nuevo
Revisor
de transacción
bien
se suprimen
las demás
¿todo transacciones
terminado?
bien
el objeto
se borra
¿todo a sí mismo
es Válido terminado?
Autodelegación
• Diagramas de secuencias. (cont.)

• Cuando utilizar los diagramas de secuencias, se sugieren para:
• Son útiles para ver la interacción entre los objetos, debido a que pone
énfasis en la secuencia y es fácil apreciar el orden en el que ocurren las
cosas.
• Cuando se desee ver el comportamiento de varios objetos en un caso de
uso y la secuencia de los mensajes.
• No se sugieren para:
• No son convenientes para representar el comportamiento condicional,
debido a que son para mostrar un comportamiento simple, se sugiere usar
mejor diagramas separados para cada una de las condiciones
• No sirve para ver el comportamiento de un solo objeto a través de muchos
casos de uso (usar mejor un diagrama de estados)
• Si quiere ver el comportamiento a través de muchos casos de uso o
muchos proceso mejor utilice un diagrama de actividad.
• Diagramas de colaboraciones.
• Muestra los objetos,las relaciones entre ellos, los mensajes que se
envían los objetos entre sí.
• El mensaje se representa como una flecha cerca de la línea de asociación
entre dos objetos. Esta flecha apunta al objeto receptor. El tipo de
mensaje se mostrará en una etiqueta cerca de la flecha.
• El mensaje le indicará al objeto receptor que ejecute una de sus
operaciones.
• Un diagrama de secuencias puede ser convertido en uno de
colaboraciones y viceversa.
• Se agregará una cifra al mensaje para indicar la secuencia propia del
mensaje.
:Nombre1
1:Agregar()
3:Actualizar()
:Nombre2
:Nombre3 2:Modificar()
• Diagramas de colaboraciones. (cont.)

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

• Cuando utilizar los diagramas de colaboración, se sugieren para:
• Es la mejor forma si se quiere mostrar los objetos y mostrar como se
reconectan estáticamente unos con otros.
• Cuando se desee ver el comportamiento de varios objetos en un caso de
uso.
• Sirven para mostrar la colaboración entre los objetos, sin embargo, no
sirven tan bien para la definición precisa del comportamiento
• No se sugieren para:
• No son convenientes para representar el comportamiento condicional,
debido a que son para mostrar un comportamiento simple, se sugiere usar
mejor diagramas separados para cada una de las condiciones
• No sirve para ver el comportamiento de un solo objeto a través de muchos
casos de uso (usar mejor un diagrama de estados)
• Si quiere ver el comportamiento a través de muchos casos de uso o
muchos proceso mejor utilice un diagrama de actividad.
Análisis y Diseño de Sistemas de Información Diagramas de Implementación
• Diagramas de componentes
• Un componente es la implementación de un subsistema, la cual da las
especificaciones (en términos de casos de uso) y una estructura de clases que lleva a
cabo la especificación. Su representación es:
calculadora.java
• Hay diferentes tipos de componentes y cada uno con diferentes tipos de dependencia
, Clasificándolos en relación con el proceso de compilación un componente podría
ser:
• Código fuente, el cual depende de que otros componentes estén disponibles al momento de
compilación.
• Código objeto binario, (biblioteca de clases) que depende de cualquier código objeto al cuál
se ligara desde un programa ejecutable.
• Una aplicación ejecutable, la cuál puede depender de otros programas ejecutables al tiempo
de ejecución.
• Los detalles dependen del lenguaje de programación usado, se pueden usar
estereotipos como «compilar» ó «ligar», igualmente se pueden usar estereotipos para
diferenciar los diferentes tipos de componentes, por ejemplo: «archivo» , «biblioteca»
, «ejecutable» , «tabla», «documento»
• Diagramas de componentes (cont.)

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

• Un diagrama de componentes mostrando las dependencias de
tiempo de compilación:
«ligar»
streams.o
«biblioteca» MiEntradaSalida
«compilar»
MiAplicación
«ejecutable»
• La interfaz se puede representar por una línea con un círculo

Programa Resultado de
de búsqueda la búsqueda

• Si un componente implementa clases se puede establecer la relación
entre el componente y las clases como sigue:
ProcesadorTextos.exe
Clases:
ProcesadorTextos
VerificadorOrtografico
ContadorPalabras
ProcesadorTextos.exe
ProcesadorTextos VerificadorOrtografico ContadorPalabras

• Solo se podrán ejecutar las operaciones dentro de un componente a
través de su interfase. La relación entre un componente y su interfase se
conoce como realización. Un componente puede acceder a los servicios
de otro componente mediante el uso de su interfase, al que proporciona
el servicio se dice que provee una interfaz de exportación, al que accede
a un servicio se dice que utiliza una interfaz de importación.
«Interfaz»
ElementoDeEscucha AWTEventMulticaster
cambioAlEstadoDelElemento()
• 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.

• Página Web con controles ActiveX.
Animacion.htm
«ActiveX»
VBScript
DisposicionAnimacion.alx
«ActiveX»
BotonEjecutar
«ActiveX»
ImagenEsfera «ActiveX»
BotonDetener
«ActiveX»
CronometroEsfera «ActiveX»
BotonReinicar
Esfera.gif
«ActiveX» «ActiveX»
CuadroCombCronometro CuadroCombDistancia
• Diagramas de distribución.
• Los diagramas de distribución muestran la disposición física de los
distintos nodos que componen un sistema y el reparto de los
componentes sobre dichos nodos.
• Un nodo representa todo tipo de equipo de cómputo y se representa
por un cubo:
Nodo
• Los estereotipos permiten precisar la naturaleza del equipo:

• Dispositivos
• Procesadores
• Memoria
• Etc.
• Diagramas de distribución.
• Los nodos se interconectan mediante soportes bidireccionales (en
principio) que puede a su vez estereotiparse.
• Se pueden mostrar los componentes en relaciones de dependencia
con un nodo:
Servidor
Directorio telefónico
corporativo
Programa de Resultado de
búsqueda la búsqueda
• Diagramas de distribución. (cont.)

• Las conexiones entre nodos se puede poner mediante una relación
Servidor
Directorio telefónico
corporativo
Programa de Resultado de
búsqueda la búsqueda
«Comunicación»
Cliente
Programa de
Presentación
• Diagramas de distribución. (cont.)

• Aplicación de los diagramas de distribución.
• Un equipo de cómputo casero podría ser como sigue:
«Dispositivo» «Dispositivo» «Dispositivo» «Dispositivo» «Dispositivo»

Scanner Microtek Monitor Daewoo Impresora Impresora Camara Digital
SlimScanC3 CMC-1505 HP Deskjet 610L HP Lasejet 5L Polaroid Flash640
PC PC
Pentium 300Mhz Pentium 300Mhz
Windows 95 Windows 95
Office 2000 Internet Explorer Office 2000 Visio 5Enterprise
«Dispositivo» «Dispositivo»
Modem ESS 336V Monitor
Conector T Conector T
PackardBell
Internet «Procesador» «Dispositivo»

«Dispositivo»
ISP Infosel.net Terminador Terminador
Análisis y Diseño de Sistemas de Información Caso de Estudio (CS4)
• Presentación del caso.

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

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

• Las consultas pueden ser realizadas mediante una base de datos y usando
técnicas estándar para hacer objetos persistentes. Y se dejará fuera de la
respuesta, quedando pues los siguientes casos de uso:
• Producir el manual del curso
• Producir la lista CS4
• Inscribir en los módulos.
Producir la lista CS4

Organizador Cursos CS3 CCS4
Producir el
manual del curso
OEP Adjunto CS4
Inscribir en los
Módulos
eCS4 Director de estudios CS4
• Diagrama de casos de uso (CS4)

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

• Un diagrama de clases a nivel conceptual, sin incluir actividades y
operaciones:
1
Imparte
Adjunto
0..*
Módulo
6 6..*
toma
Director de
Estudios dirige
1..*
1 1..*
0..* Estudiante
Cursos Grado
1
esta en
0..*
Estudiante Estudiante
otros años 4to año
• 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:
Comité Jefe de Adjunto OEP CCS4
Académico Departamento
Actualizar secciones
Determinar
principales
los módulos
Asignar
Adjuntos
Actualizar registro
de módulo
Imprimir Generar versión

manual HTML
Análisis y Diseño de Sistemas de Información Caso de Estudio (Restaurante)
• Presentación del caso.

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

Aguarda en el
Dejar su nombre Área de espera
[Prefiere el área de espera]
• Presentación del caso. (cont.)

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

Entra el cliente
[Tiene abrigo y/o

sombrero] Ayudar a quitárselo Guardarlo
[Lista de [No hizo [Prefiere el bar]

espera] reservación] Espera en el bar
Dejar su nombre [Prefiere el área
de espera] Aguarda en el
Área de espera
Sentar al cliente Alistar la mesa

[Desea bebida] Tomar un pedido
de bebidas
Llamar al mesero Mostrar el menú
Llamar al asistente
Ir por las bebidas
Servir Pan y agua
Traer bebida
Sugerir platillo Leer Menú Elegir Notificar al chef
Modelado en
un diagrama
Traer entremes Preparar platillo Por separado
• Entrevista de Análisis (cont.)

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

Modelado en
Traer entremés Preparar platillo un diagrama
Por separado
Ingerir entremés
Traer el plato fuerte
[Desea café] Servir café
Ingerir plato fuerte

Beber café
[Desea postre]
Traer el menú
de postres
Traer postres Trae la cuenta
Ingerir postres
[Guardar abrigo/sombrero] Liquidar cuenta
Recoger abrigo Dejar propina
Salir
o sombrero
• Preparación de platillos
• ¿Cómo se coordina el chef para tener los platillos a tiempo? R: La gente en una mesa
casi siempre termina sus entremeses, en momentos distintos. Entre el mesero y el chef
se coordinan para traerles a todos los platos fuertes al mismo tiempo. El chef recibe la
comanda y empieza a preparar los entremeses y el plato fuerte, cuando esta terminado el
entremés, el mesero va a la cocina, los toma y los lleva a la mesa.
• ¿Cómo se entera el mesero que ya están listos los entremeses? R: El mesero va a la
cocina de vez en cuando. El chef luego de dar el entremés al mesero, espera que este le
avise cuando la mayoría de los comensales ya casi ha terminado con sus entremeses
para poderle dar el toque final a cada plato fuerte. El mesero va a la cocina, y le avisa al
chef que ya casi están listos para el plato fuerte, el chef termina su preparación. El
mesero los toma y los lleva a la mesa
• Preparación de platillos
Recibir comanda
Iniciar la preparación
Preparar entremeses
Del plato fuerte
Coordinar la preparación
Llevar entremeses
de otros pedidos
Recibir la notificación de que los

Ingerir entremeses
Entremeses casi se han consumido
Finaliza la preparación
de plato fuete
Tomar el plato
fuerte
Llevar Plato fuerte
• Clases y asociaciones
• El cliente se asocia con una gran cantidad de clases, como muestran las
asociaciones a continuación:
Postre Cuenta Propina Reservación
1 1 1
Ingiere Liquida 1
Deja
1 1 1
1
Hace
1..*
Es atendido por 1
1
Cliente Mesero
Da a guardar Sombrero
1
0..*
1 1 1 1 1
Da a guardar 1 Encargado del
Guardarropa
Elige del 0..*
Abrigo
Ingiere
Hace
1
1 1 Elige del
1
Orden
Menú Alimento Menú del
postre
• Detalle de las clases

• Cliente, sus atributos serían:
Cliente
nombre
horallegada
orden
horaservicio
ingerir()
beber()
ordenar()
pagar()
• Detalle de las clases

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

trabajaCon
llevar()
preparar() preparar() monitor()
servir()
cocinar() cocinar() operaRestaurante()
recoger(
servirPan() darPrioridad() asignar()
llamar()
servirAgua() crearReceta() rotar()
verificarEstado()
DeLaOrden()
• Diagrama de distribución, Restaurante

• Los meseros contarán con una computadora palmtop y la utilizarán para comunicarse
con la cocina y con los mozos de piso. Estos últimos también tendrán palmtops para
comunicarse. La cocina tendrá una terminal de escritorio y una o varias pantallas. El
gerente tendrá una en su oficina.
«Dispositivo»
Computadora
palmtop
Inalámbrico
«Dispositivo»
Red
PC de la PC del
cocina gerente
• Casos de uso
• El paquete mesero
Mesero
Totalizar
Una cuenta
Transmitir una
Orden al bar
Notificar al chef del

Sondear el progreso progreso de los clientes
De la orden En sus alimentos
Tomar
Tomar una orden Obtener un acuse
una orden
Incluir De bebida De recibo
Transmitir la orden Recibir una notificación

a la cocina de la cocina
Incluir Llamar a un mozo

Cambiar Imprimir
de piso una cuenta
una orden
Llamar a un Recibir una notificación

Asistente del bar

Anal Is Is

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Anal Is Is

Hochgeladen von

Copyright:

Verfügbare Formate

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

• ¿Qué es un BUEN SISTEMA?

• ¿Tenemos buenos sistemas?

• Problemas aún más drásticos.

• ¿Cómo son los sistemas considerados buenos?

• ¿Cómo son los sistemas considerados buenos? (cont.)

• Encapsulamiento: Acoplamiento bajo

• Encapsulamiento: Acoplamiento bajo (Cont.)

• Encapsulamiento: Acoplamiento bajo (Cont.)

• Encapsulamiento: Acoplamiento bajo (Cont.)

• Encapsulamiento: Acoplamiento bajo (Cont.)

• Un buen sistema consiste de módulos encapsulados

• Abstracción: Alta Cohesión.

• Diseño basado en componentes: Insertabilidad, conectabilidad

• ¿Cómo se construyen los buenos sistemas?

• Proceso de desarrollo (cont.)

• Casos de Uso (cont.)

• Casos de Uso (cont.)

• Casos de Uso (cont.)

• Casos de Uso (cont.)

• Casos de Uso (cont.)

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

• Casos de Uso (cont.)

• Generalización. Un caso de uso secundario hereda las acciones y

Comprar Comprar un vaso

• Casos de Uso (cont.)

• Problemas con la definición de objetos

• Objetos y Clases (cont.)

• Objetos y Clases (cont.)

Automóvil Nombre de la clase

• Objetos y Clases (cont.)

• Relaciones entre clases.

Un autor usa una computadora

Un cajero atiende a un cliente, pero cada cliente es

• Relaciones entre clases (cont.)

1..* Posee 0..*

• La asociación recursiva es una asociación de una clase a sí misma, una

• Relaciones entre clases (cont.)

Compañía 1 tiene 0..* Contrato de

• Relaciones entre clases (cont.)

Categoría de la asociación Ejemplos

• Asociación Or {or}. En algunos modelos no todas las combinaciones de

• Asociación Ordenada {ordered}. Cuando los enlaces entre objetos pueden

Negociado por Director

• Asociación ternaria (Ternary association). Más de dos clases pueden

Compañía 1 0..* Contrato de

• Tipos de asociaciones (cont.)

• Una composición es una agregación donde cada componente puede

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

• Tipos de asociaciones (cont.)

Carro Bote Camión

• Adicionalmente la interfaz puede ser representada como un circulo

Juan: Autor Bob1:Computadora

Catalogo Contiene Especificacion

cantidad 1 Dirección Almacena

• Las actividades cuentan con sucesos y acciones de entrada (qué

• Diagramas de estados (cont.)

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

• Diagramas de estados (cont.)

• Diagramas de estados (cont.)

• Diagramas de estados (cont.)

• La transición se muestra como una flecha, normalmente no se les pone

• Diagramas de actividades (cont.)