Вы находитесь на странице: 1из 98

Anlisis y Diseo de Sistemas de Informacin

Temario

Temario

Ingeniera de Software
Estructuras de Objetos
Diagramas Estticos
Diagramas de Clases
Diagramas de Casos de Uso
Diagramas Dinmicos
Diagramas de Estado
Diagramas de Actividades
Diagramas de Secuencias
Diagramas de Colaboracin
Diagramas de Implementacin
Diagramas de Componentes
Diagramas de Distribucin
Casos de estudio
Patrones de Diseo
Metodologas

Analisis.ppt

Pag. 1

Anlisis y Diseo de Sistemas de Informacin

Bibliografa

Bibliografa

Analisis.ppt

Pag. 2

Anlisis y Diseo de Sistemas de Informacin

Ingeniera de Software

Qu es un BUEN SISTEMA?

Un buen sistema (o uno de alta calidad) es aqul que cumple con las
necesidades del cliente. El sistema debe ser:
UTIL y UTILIZABLE: Un buen software hace ms fcil o mejor la vida a las personas.
CONFIABLE: Un buen software tiene pocos errores.
FLEXIBLE: Las necesidades cambian con el tiempo, an cuando el software se est

desarrollando, entonces es importante poder hacer cambios posteriores al software.


Debe podrsele dar mantenimiento despus de liberado.
ACCESIBLE: tanto para comprar como para mantener. Debe ser razonablemente
fcil y rpido poderlo desarrollar o darle mantenimiento.
DISPONIBLE: De otra forma no importa que tan bueno es. Debe ser capaz de
ejecutarse el el hardware disponible y con el sistema operativo disponible, etc. Debe
existir y entregarse el software prometido.

Tenemos buenos sistemas?

Existen avances satisfactorios en sistemas de software modernos:


contabilidad, bancos, bsqueda de informacin, etc. Lo que indica que
estamos haciendo las cosas correctamente.

Analisis.ppt

Pag. 3

Anlisis y Diseo de Sistemas de Informacin

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

Pag. 4

Anlisis y Diseo de Sistemas de Informacin

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

Pag. 5

Anlisis y Diseo de Sistemas de Informacin

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, AddisonWesley 1975/1995), mientras ms grande sea el proyecto, mayor ser
la proporcin del costo y tiempo del proyecto gastado en la
comunicacin entre la gente del proyecto, porque cada persona tiene
ms gente con quin comunicarse. Cuando un proyecto empieza a
quedarse atrs en el tiempo, el poner ms gente por lo general falla.
El Departamento de Defensa de EU, intent resolver la crisis del
software y comision el diseo del lenguaje de programacin ADA, el
cual se estandariz en 1983, el cual soportaba lo mejor de los
conceptos de anlisis, diseo y programacin estructurados, la
modularidad y la encapsulacin fueron conceptos clave en el diseo
del lenguaje, pero an esta enorme inversin ha fracasado.

Analisis.ppt

Pag. 6

Anlisis y Diseo de Sistemas de Informacin

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

Pag. 7

Anlisis y Diseo de Sistemas de Informacin

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

Pag. 8

Anlisis y Diseo de Sistemas de Informacin

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

Pag. 9

Anlisis y Diseo de Sistemas de Informacin

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

Pag. 10

Anlisis y Diseo de Sistemas de Informacin

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

Pag. 11

Anlisis y Diseo de Sistemas de Informacin

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 y
mantenimiento), porque se evitar el examinar mdulos irrelevantes.
Una vez que existe un mdulo, con documentacin de lo que provee y
lo que requiere, es posible considerar reusarlo.
El reto real, es definir buenos mdulos con las cosas correctas en sus
interfases. Solo entonces se pueden lograr los beneficios completos.

Analisis.ppt

Pag. 12

Anlisis y Diseo de Sistemas de Informacin

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

Pag. 13

Anlisis y Diseo de Sistemas de Informacin

Abstraccin: Alta Cohesin.

Ingeniera de Software

Los buenos mdulos tienen la propiedad de que sus interfases proveen una
abstraccin de alguna cosa que se entiende intuitivamente la cual sin
embargo puede ser compleja de implantar. Tales mdulos se dice que tienen
una alta cohesin.
La interfase realiza una abstraccin de las cosas que el desarrollador no tiene
que entender para usar el mdulo, dejando una figura coherente de lo que el
usuario de un mdulo quiere conocer.
El desarrollador est protegido de informacin irrelevante acerca de cmo el
mdulo hace lo que hace. Esta preocupacin de permitir al desarrollador
concentrarse en lo esencial es ligeramente diferente a la preocupacin de
encapsulacin para lograr un acoplamiento bajo, lo cual va dirigido a la
prevencin de que el desarrollador use informacin escondida.

Abstraccin es cuando un cliente de un mdulo no necesita saber ms


de lo que est en la interfase.
Encapsulacin es cuando un cliente de un mdulo no es capaz de
conocer ms de lo que est en la interfase.

Si un mdulo, de cualquier tamao y complejidad, es una buena abstraccin


(tiene una alta cohesin y un acoplamiento bajo) puede ser factible de reusarlo
en posteriores sistemas, o de reemplazo en sistemas ya existentes.
Estaramos hablando de un componente insertable o conectable (pluggable
component)

Analisis.ppt

Pag. 14

Anlisis y Diseo de Sistemas de Informacin

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
Acoplamiento bajo con el resto del sistema
Interfase bien definida
Abstraccin encapsulada de una cosa bien entendida

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


el cual va a ser reusado.
Ejemplo de un factor no tcnico de reuso: Recompensar al programador
por el nmero de lneas que escriben.
Los factores tcnicos involucran decisiones de arquitectura y ms alto
nivel.
Analisis.ppt

Pag. 15

Anlisis y Diseo de Sistemas de Informacin

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
Pueden ser influenciadas por el medio ambiente del proyecto

Analisis.ppt

Pag. 16

Anlisis y Diseo de Sistemas de Informacin

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

Pag. 17

Ingeniera de Software

Anlisis y Diseo de Sistemas de Informacin

Proceso de desarrollo

Mtodo tradicional para el desarrollo de Sistemas

Anlisis
Diseo
Implementacin
Pruebas
Mantenimiento
Cada fase se realiza hasta que se complet la anterior. Supone que no se vuelve a entrar en las

fases terminadas.
Administracin de riesgos implica:
1.- Cada vez que se toma una decisin se tiene el riesgo de que sea incorrecta. Mientras
ms se tarde en detectar un error ms difcil es corregirlo. Evaluaciones frecuentes ayudan
a corregir.
2.- Un riesgo mayor es que los desarrolladores malinterpreten los requerimientos. La
elaboracin de prototipos permite reafirmarlos.
Espiral de desarrollo:
Construccin
Diseo

Transicin

Anlisis

Metodologa Unificada.
Gran cantidad de metodologas orientadas a objetos han salido a la luz y las de Grady Booch,

James Rumbaugh, Ivar Jacobson se unieron para formar el Lenguaje de Modelacin Unificado
(UML) y fue adoptado por el Object Management Group (OMG) como el estndar para
cuestiones orientadas a objetos.

Analisis.ppt

Pag. 18

Anlisis y Diseo de Sistemas de Informacin

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.
Otros procesos han adoptado UML como su lenguaje de modelacin:
Catalysis, Rational Unified Process, etc.

Analisis.ppt

Pag. 19

Diagramas Estticos

Anlisis y Diseo de Sistemas de Informacin

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

Bibliotecario

Agregar
recursos
Regresar
Recursos

Usuario

En las etapas iniciales de desarrollo del proyecto, los diagramas de casos de uso
describen las actividades del mundo real y las motivaciones. Se puede afinar los
diagramas en etapas posteriores para reflejar las interfases de usuario y los detalles
de diseo.
Cuando se tienen varios subsistemas es comn dibujar la frontera del sistema, pero
generalmente se omite.

Analisis.ppt

Pag. 20

Anlisis y Diseo de Sistemas de Informacin

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

Pag. 21

Anlisis y Diseo de Sistemas de Informacin

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

Pag. 22

Anlisis y Diseo de Sistemas de Informacin

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.

Casos de uso a travs del desarrollo.


Planeacin. Antes de que se haga un proceso de estimacin y planeacin para el

proyecto completo, es necesario hacer una lista de los casos de uso del sistema,
junto con:
Una buena idea de lo que significa cada uno
Entender quin quiere cada uno y qu tanto lo desea.
Conocer cul caso de uso acarrea ms riesgo
Un plan de que tanto tomar implementar cada caso de uso.
Aspectos polticos. Recuerde que el 25% de los sistemas nunca se terminan.
Debemos poder demostrar que el sistema hace algo til primeramente para la gente
ms influyente.
Aspectos tcnicos. Debemos sacar adelante primero los casos de uso con mayor
riesgo, para eliminar el riesgo ms grande an cuando tengamos contingencias para
poderlas eliminar y no que quedemos atorados en un diseo que no nos permita
manejar los casos de uso ms riesgoso.
Validacin del Sistema. Tomar cada caso de uso y verificar que el diseo permitir
completarlo, igualmente se deben disear pruebas para cada caso de uso.

Analisis.ppt

Pag. 23

Anlisis y Diseo de Sistemas de Informacin

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

Pag. 24

Anlisis y Diseo de Sistemas de Informacin

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

Recolectar
dinero

incluir

incluir

Exhibir
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.
Sin embargo se tienen las siguientes desventajas:
Peligro de buscar funcionalidad y al hallarla fomentar la elaboracin
de un sistema basado en funciones, top-down con sistemas
inflexibles.
Es difcil para alguien no adiestrado en UML entender la notacin de
incluir
Analisis.ppt

Pag. 25

Diagramas Estticos

Anlisis y Diseo de Sistemas de Informacin

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.
Reabastecer
Punto de extensin llenar
los compartimientos

incluir

incluir

extender
(llenar los
Compartimientos)

Exhibir
el interior

Cubrir
el interior

Reabastecer de
Acuerdo a las ventas

Generalizacin. Un caso de uso secundario hereda las acciones y


significado del primario y adems agrega sus propias acciones.
Comprar
gaseosa

Analisis.ppt

Comprar un vaso
de gaseosa

Pag. 26

Anlisis y Diseo de Sistemas de Informacin

Diagramas Estticos

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.
Se puede tener diferente grado de granularidad, por ejemplo para un
proyecto de 10 personas-ao se esperaran 20 casos de uso 100
casos dependiendo del nivel de detalle.
Analisis.ppt

Pag. 27

Anlisis y Diseo de Sistemas de Informacin

Estructuras de Objetos

Qu es un objeto?

Conceptualmente, un objeto es una cosa con la que se puede


interactuar: Se le pueden mandar varios mensajes y reaccionar. El
como se comporte depender del estado interno actual del objeto. Un
objeto tiene una identidad la cual lo distingue de todos los dems
objetos.
El estado de un objeto se representa mediante los datos
almacenados en el mismo, los cuales son llamados atributos.
El comportamiento de un objeto es lo que ste puede hacer y se
encuentra contenido en mtodos, los cules se invocan envindoles
mensajes.
Representacin UML de un objeto (Diagrama de Clase):
Empleado
- Nombre:String
- Sexo:Boolean
- Direccion:String
- RFC:String
+ TomarNombre:String
+ TomarRFC:String
+ TomarDireccion:String

Analisis.ppt

Pag. 28

Anlisis y Diseo de Sistemas de Informacin

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

Pag. 29

Anlisis y Diseo de Sistemas de Informacin

Clases

Atributos

Mtodos

Mensajes

Interfases

Estructuras de Objetos

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


tienen un rol equivalente en un sistema. Para crear una instancia de un objeto
se usa la clase como la base para determinar como formar el objeto.
Son los datos que estn encapsulados dentro del objeto y determinan su
estado. Algunos pueden cambiar (p.ej: un empleado puede cambiar de
direccin), otros son inmutables y deben conservar el mismo valor durante la
vida del objeto (p.ej: el RFC de un empleado)
Son una implementacin del comportamiento requerido por una clase, cada
instancia de objeto proveniente de la clase tendr stos mtodos. Podrn ser
llamados por otros objetos o internamente.
Los objetos responden o actan en funcin a los mensajes que reciben y el
estado actual de sus atributos. Cuando se manda un mensaje a un objeto se le
esta ordenando que ejecute un mtodo y generalmente se desconoce el
cdigo que ejecutar porque est encapsulado.
Es el medio fundamental de comunicacin entre los objetos. La interfase
describe completamente cmo van a interactuar con la clase los usuarios de
la clase. La interfase pblica de un objeto define cules mensajes aceptar sin
importar de donde provengan.

Analisis.ppt

Pag. 30

Estructuras de Objetos

Anlisis y Diseo de Sistemas de Informacin

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

gato

-frecuenciaLadrido: int

-frecuenciaMaullido:int

+ Ladrar: int

+ Maullar: int

Subclases

Las clases Perro y Gato heredan de la clase Mamferos, esto significa que la
clase Perro tiene los siguientes atributos:
colorOjos
Heredada de la clase Mamferos
frecuenciaLadrido
Definida solo para la clase Perro
y los siguientes mtodos:
tomarColorOjos
Heredada de la clase Mamferos
Ladrar
Definida solo para la clase Perro

Analisis.ppt

Pag. 31

Anlisis y Diseo de Sistemas de Informacin

Abstraccin

Quitar las propiedades y acciones de un objeto para dejar slo aquellas que
sean necesarias.

Polimorfismo

Estructuras de Objetos

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.

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 ms objetos

Composiciones

La agregacin de objetos permite definir composiciones, en las que cada


componente se considera como tal slo como parte del objeto compuesto.

Analisis.ppt

Pag. 32

Anlisis y Diseo de Sistemas de Informacin

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.

podremos tomar una:


Vista lgica nos permitir alcanzar los requerimientos funcionales. Cules partes
van juntas? Cules son las clases y sus relaciones?
Vista de proceso ayuda a lograr los requerimientos no-funcionales, como el
desempeo y la disponibilidad. Cules necesidades de control hay? Qu
actividades pueden ser concurrentes? Qu sincronizacin debe haber?
Vista de desarrollo ayuda a administrar el proyecto. Cul parte har cada elemento
del equipo de gente? Que partes pueden reusarse?
Vista fsica ayuda a alcanzar los requerimientos no-funcionales, haciendo una vista
ms concreta que la de proceso.Cuales partes corrern en la misma computadora?

Analisis.ppt

Pag. 33

Estructuras de Objetos

Anlisis y Diseo de Sistemas de Informacin

Diagramas UML

La relacin existente entre los diversos diagramas de UML se


muestra a continuacin:

Diagrama
Diagramade
de
Clases
Clases
Casos
Casosde
de
Uso
Uso

Diagrama
Diagramade
de
Secuencias
Secuencias

Diagrama
Diagramade
de
Colaboracin
Colaboracin

Diagrama
Diagramade
de
Estados
Estados

Diagrama
Diagramade
de
Distribucin
Distribucin

Diagrama
Diagramade
de
Componentes
Componentes

CODIGO
CODIGO

Diagrama
Diagramade
de
Actividad
Actividad

Analisis.ppt

Pag. 34

Anlisis y Diseo de Sistemas de Informacin

Diagramas Estticos

Objetos y Clases

Identificar las clases que deben existir en nuestro sistema, es la parte


mas grande del trabajo de disear sistemas orientados a objetos.
Construir rpidamente y lo ms barato posible el sistema que alcance
nuestros requerimientos.
Construir un sistema que sea fcil de mantener y adaptar para los
requerimientos futuros.

Cada pieza de comportamiento requerida por el sistema deber ser


proporcionada de una manera sensible, por los objetos de las clases
que elijamos.
Un buen modelo de clases consiste de clases de los objetos
principales, los cuales no dependen de la funcionalidad particular
requerida actualmente
Una tcnica es la identificacin de sustantivos. Descarte los
candidatos que sean inapropiados por alguna razn, renombrando
las clases restantes si es necesario
Pueden descartar candidatos por: redundancia, vaguedad, son un
evento o una operacin, son meta-lenguaje, estn fuera del alcance
del sistema, son un atributo.

Analisis.ppt

Pag. 35

Anlisis y Diseo de Sistemas de Informacin

Diagramas Estticos

Objetos y Clases (cont.)

Las cosas que pueden ser clases se refieren a: cosas tangibles (libro,
copia, curso), roles (estudiante, maestro, bibliotecario), eventos
(llegada, partida, solicitud), Interacciones (reunin, interseccin)
Categora del concepto

Ejemplos

Objetos fsicos o tangibles

TDPV, Dado

Especificaciones, diseo o descripciones de cosas

EspecicacindeProducto, ReglasdeJuego

Lugares

Tienda, MesadeJuego

Transacciones

Venta, Pago, Reservacion, Apuesta

Lnea o rengln 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 cmputo o electromecnicos 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 estn representados como conceptos, pero pueden estarlo)
Reglas y polticas

PoliticadeReembolso, PoliticadeCancelaciones

Catlogos

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

Analisis.ppt

Pag. 36

Anlisis y Diseo de Sistemas de Informacin

Diagramas Estticos

Objetos y Clases (cont.)

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

Nombre
ejemplo:

Atributos ...
Operaciones ...

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

Nombre de la clase
Atributos de la clase: son los datos
contenidos en un objeto de la clase
Operaciones de la clase: definen la forma en
La cual los objetos pueden interactuar,
Cuando un objeto manda un mensaje a otro,
Le esta pidiendo que ejecute una operacin

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 (#)
Una restriccin es un texto que especifica una o varias reglas que sigue la clase, se indica
mediante un texto libre encerrado entre llaves {}. Existe el OCL que define de manera formal
las restricciones en UML.
Las propiedades se indican mediante llaves, dando propiedades a los elementos donde se
haya n incluido estas.
Analisis.ppt

Pag. 37

Anlisis y Diseo de Sistemas de Informacin

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

Analisis.ppt

Pag. 38

Diagramas Estticos

Anlisis y Diseo de Sistemas de Informacin

Relaciones entre clases.


Asociacin, es una conexin entre clases, lo que significa que tambin es
una conexin entre los objetos de esas clases. En UML, una asociacin es
una relacin que describe un conjunto de ligas, que estn definidas como
una conexin semntica entre un conjunto de objetos.
Corresponden a los verbos. Existen instancias de asociacin.
Normalmente una asociacin es bidireccional, lo que significa que si un
objeto est asociado con otro objeto, ambos objetos se conocen uno al
otro.
Asociacin normal:
Usa
Autor

Computadora

Un autor usa una computadora


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

Atiende

{Ordenado}

Cliente

Un cajero atiende a un cliente, pero cada cliente es


atendido en el orden en que se encuentre en la formacin
Analisis.ppt

Pag. 39

Diagramas Estticos

Anlisis y Diseo de Sistemas de Informacin

Relaciones entre clases (cont.)


Hay asociaciones que establecen una relacin en ambas direcciones
La multiplicidad es la cantidad de objetos de una clase que se relacionan
con un objeto de la clase asociada:
1..*

Persona

Posee

0..*

Posedo por

Carro

Un carro puede tener uno o mas dueos,


una persona puede tener cero o ms carros

La asociacin recursiva es una asociacin de una clase a s misma, una


conexin entre objetos de la misma clase

Nodo

conecta

Un nodo se conecta a muchos nodos y estos a su vez se conectan


con varios mas. (en una red de cmputo

Analisis.ppt

Pag. 40

Diagramas Estticos

Anlisis y Diseo de Sistemas de Informacin

Relaciones entre clases (cont.)


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

Est expresado
1 en un

Refiere a
Compaa
Aseguradora

1
Asegurador

tiene

0..*

Refiere a

Contrato de
Seguros
0..*

tiene
1..*
esposa

Asegurado

Persona
esposo

casado con

Analisis.ppt

Pag. 41

Anlisis y Diseo de Sistemas de Informacin

Diagramas Estticos

Relaciones entre clases (cont.)


Categora de la asociacin

Ejemplos

A es una parte fsica de B

Caja-TPDV

A es una parte lgica de B

VentasLneadeProducto-Venta

A est fsicamente contenido en B

TPDV-Tienda, Producto-Estante

A est contenido lgicamente en B

DescripcindeProducto-Catlogo

A es una descripcin de B

DescripcindeProducto-Producto

A es un elemento de lnea (o rengln) en


una transaccin o reporte B

VentasLneadeProducto-Venta

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 transaccin B

Pago-Venta

A es una transaccin relacionada con otra


transaccin B

Pago-Venta

A es propiedad de B

TPDV-Tienda

Analisis.ppt

Pag. 42

Diagramas Estticos

Anlisis y Diseo de Sistemas de Informacin

Tipos de asociaciones
Asociacin calificada (Qualified association). Representa la informacin
de identidad y reduce la multiplicidad de uno a muchos por una de uno a
uno.

Tablero

rengln:{1,2,3}
columna:{1,2,3}

Cuadro

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


asociacin son vlidas
Elige
Estudiante de {Or}
Educacin
Media Superior

Acadmico

Elige
Comercial

Asociacin Ordenada {ordered}. Cuando los enlaces entre objetos pueden


tener un orden implcito {ordered} {ordenadas por incremento de tiempo}.
Analisis.ppt

Pag. 43

Diagramas Estticos

Anlisis y Diseo de Sistemas de Informacin

Tipos de asociaciones
Clase de Asociacin. Una clase puede estar unida a una asociacin. Se
usa para agregar informacin extra sobre un enlace; por ejemplo, el
tiempo en que el link fue creado. Cada enlace est asociado a un objeto de
la clase de asociacin.
Jugador

Participa en

Contrato

Equipo
Negociado por

Director
General

Asociacin ternaria (Ternary association). Ms de dos clases pueden


asociarse con otra, la asociacin ternaria asocia tres clases.
Compaa
Aseguradora

1
Asegurador

0..*

Contrato de
Seguros
0..*
0..1
1..*

Pliza de
Seguros

Asegurado

Persona

Analisis.ppt

Pag. 44

Diagramas Estticos

Anlisis y Diseo de Sistemas de Informacin

Tipos de asociaciones (cont.)


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

{O}

Comida

Ensalada

PlatoFuerte

Postre

Una composicin es una agregacin donde cada componente puede


pertenecer tan solo a un todo. Se representa con diamante slido.
Tablero

Cuadros

En un juego del gato, los cuadros solo tienen sentido si estn

formando parte del tablero

Analisis.ppt

Pag. 45

Diagramas Estticos

Anlisis y Diseo de Sistemas de Informacin

Tipos de asociaciones (cont.)


La generalizacin es una relacin entre un elemento ms general y uno
ms especfico. El elemento ms especfico puede tener solo informacin
adicional. Se utiliza sobre tipos, nunca sobre instancias (una clase puede
heredar otra clase, pero un objeto no puede heredar otro objeto).
La clase especfica o subclase, hereda todo de la clase general, llamada
superclase. Los atributos, operaciones y todas las asociaciones son
heredadas. Una clase puede ser superclase y subclase si esta en una
jerarqua de clases. En grficas de jerarqua, las clases estn conectadas
unas con otras, va relaciones de generalizacin.

Vehculo

Carro

Analisis.ppt

Bote

Camin

Pag. 46

Diagramas Estticos

Anlisis y Diseo de Sistemas de Informacin

Interfaces y realizaciones

Una interfaz es un conjunto de operaciones que especifica cierto


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

interfaz
MaquinaDeEscribir
Teclazo()

Adicionalmente la interfaz puede ser representada como un circulo


MaquinaDeEscribir
conectado con una lnea a la clase
Teclado

Analisis.ppt

Pag. 47

Diagramas Estticos

Anlisis y Diseo de Sistemas de Informacin

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

Autor
Clases:

Objetos:

Analisis.ppt

nombre: String
edad: Integer

Computadora

Usa
0..*

1..*

nombre: String
memoria: Integer

Juan: Autor

Bob1:Computadora

nombre= Juan P.
edad = 33

nombre=IBM 128
Memoria=128

Pag. 48

Diagramas Estticos

Anlisis y Diseo de Sistemas de Informacin

Diagrama de Clases
Modelo Conceptual de Punto de Venta
Registra-venta-de
Descritas-por
1

Contiene

Catalogo
deProducto
*

1
*

VentasLinea
deProducto

0..1

cantidad
1..*

Pagado-por

*
1

Capturadas-en

Pago
Monto

Codigode barras
1
*

Describe

Almacena
1

Producto

Contiene
1

Iniciado-por

Registra-ventas-en

Gerente

Iniciado-por
1

Analisis.ppt

1..*

TPDV

Venta
Fecha
Hora

Descripcion
Precio

Usado-por

Tienda
Direccin
Nombre

Capturas
terminadas

Contenidas-en

1..*

Especificacion
deProducto

Cliente

Cajero

Pag. 49

Diagramas Dinmicos

Anlisis y Diseo de Sistemas de Informacin

Diagramas de estados

Presenta los estados en los que puede encontrarse un objeto junto


con las transiciones entre los estados, y muestra los puntos inicial y
final de una secuencia de cambios de estado.
Los smbolos UML en un diagrama de estados son:
Estado
Nombre
Inicio
Transicin
Evento que
dispara

Variables de
estado

Fin
Transicin

Actividades

Las actividades cuentan con sucesos y acciones de entrada (qu


sucede cuando el sistema entra al estado), salida (Qu pasa cuando
el sistema sale del estado) y de hacer (que sucede cuando el sistema
est en el estado)

Analisis.ppt

Pag. 50

Diagramas Dinmicos

Anlisis y Diseo de Sistemas de Informacin

Diagramas de estados (cont.)


Se puede agregar ciertos detalles a las lneas de transicin, para indicar
un suceso que provoca una transicin (la que desencadena un suceso) y
la actividad de cmputo que se ejecute y haga que suceda la modificacin
de estado.
Encender
la PC

Inicializacin

Operacin

Apagado

Apagar

Hacer/Arrancar

Las condiciones de seguridad permiten establecer una relacin entre


estados que dependen de que se cumpla dicha condicin.
Encender
la PC
Operacin Apagado
Apagar
Inicializacin
Hacer/Arrancar
[lapso transcurrido]

Teclazo o movimiento
del ratn

Protector
De
pantalla
Analisis.ppt

Pag. 51

Diagramas Dinmicos

Anlisis y Diseo de Sistemas de Informacin

Diagramas de estados (cont.)

Subestados. Cuando un estado se encuentra dentro de otro estado,


se conocen como subestados.
Se dice que pueden suceder en forma secuencial cuando suceden uno
tras de otro y se representan dentro del cuadro de estado original, ligados
secuencialmente.
Tambin has subestados concurrentes cuando pueden ocurrir al mismo
tiempo. Se representan dentro del estado original, separados por lnea
punteada.
Operacin
A la espera
de accin
del usuario

Verificar el
conmetro
del sistema

Analisis.ppt

Registro de
una accin
del usuario

[lapso transcurrido]

Representacin
de la accin
del usuario

Actualizar
despliegue

Pag. 52

Diagramas Dinmicos

Anlisis y Diseo de Sistemas de Informacin

Diagramas de estados (cont.)

Estados histricos.
Se dice de los estados compuestos que pueden recordar su subestado activo
cuando el objeto trasciende fuera de tal estado compuesto.
Se representa con una H y en caso de subestados anidados se dice que es
histrico profundo cuando alcanza a recordar varios niveles (H*) en caso
contrario se dice que es superficial

H
A la espera
de accin
del usuario

Verificar el
conmetro
del sistema

[lapso transcurrido]

Analisis.ppt

Operacin
Registro de
una accin
del usuario

Representacin
de la accin
del usuario

[lapso transcurrido]

Actualizar
despliegue

Teclazo
o movimiento
del ratn
Pag. 53

Anlisis y Diseo de Sistemas de Informacin

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

Pag. 54

Anlisis y Diseo de Sistemas de Informacin

Diagramas Dinmicos

Diagramas de actividades

Describen como se coordinan las actividades, muestran como puede


ser implementada una operacin que debe realizar muchas tareas
diferentes y se desea mostrar cuales son las dependencias
esenciales entre ellas.
Elementos de un diagrama de actividades:
La actividad se muestra como una caja con nombre con las esquinas muy
redondeadas, representa cuando la actividad ha terminado
Actividad

La transicin se muestra como una flecha, normalmente no se les pone


etiqueta, a menos que se tenga una condicin.
Actividad 1

Analisis.ppt

Actividad 2

Pag. 55

Diagramas Dinmicos

Anlisis y Diseo de Sistemas de Informacin

Diagramas de actividades (cont.)


Barras de sincronizacin, indica coordinacin de actividades y no se
puede pasar de la barra hasta que todas las actividades previas a la barra
han sido terminadas. Se utilizan para la ejecucin de actividades en
paralelo.

Fin de la
jornada

Bao

Analisis.ppt

Descanso

Pag. 56

Anlisis y Diseo de Sistemas de Informacin

Diagramas Dinmicos

Diagramas de actividades (cont.)

Las indicaciones, permiten que se ejecuten otras actividades, usando


un pentgono convexo para el envo del un evento y uno cncavo
para la recepcin del evento.
Televisin

Fin de la
jornada

Cambiar(canal)

Remoto.Tecleo (canal)
Oprimir numero
de canal

Cambiar(canal)

Oprimir numero
de canal

Analisis.ppt

Pag. 57

Anlisis y Diseo de Sistemas de Informacin

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 diagrama sin
quedarse estancadas.

Analisis.ppt

Pag. 58

Diagramas Dinmicos

Anlisis y Diseo de Sistemas de Informacin

Diagramas de actividades (cont.)

Ejemplo de un diagrama de actividades en una biblioteca.


miembro
[prestatario]
[regresador]

bibliotecario

Encontrar libro
en gaveta
[regresando]

Esperar en
la fila
[obteniendo
prestado]

Registrar el
regreso

Poner el libro de
Regreso en gaveta

Registrar el
prstamo
Preparar para
el siguiente miembro

Analisis.ppt

Pag. 59

Anlisis y Diseo de Sistemas de Informacin

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.
Cuando se trata de aplicaciones multihilos. Son adecuados en ste
uso
No sirven para:
Tratar de ver como colaboran los objetos. Usar mejor diagramas de
secuencia o colaboracin.
Para tratar de ver como se comporta un objeto durante su perodo de
vida. Es mejor usar un diagrama de estados.

Analisis.ppt

Pag. 60

Diagramas Dinmicos

Anlisis y Diseo de Sistemas de Informacin

Diagrama de secuencias.

Muestra la forma en que los objetos se comunican entre s al


transcurrir el tiempo. Constan de objetos y representando en una
lnea vertical el tiempo, se indican las operaciones que ejecuta el
objeto o activacin se representan mediante un rectngulo cuya
altura va en relacin a la duracin de la operacin.
Los mensajes van de un objeto a otro se representan con lneas.
Pueden ser simples (transfieren control), sincrnicos (esperan
respuesta) o asincrnicos (no espera respuesta)
:Objeto 1

Analisis.ppt

:Objeto 2

Pag. 61

Anlisis y Diseo de Sistemas de Informacin

Diagramas Dinmicos

Diagrama de secuencias. (cont.)


Para ilustrar los diagramas de secuencia se usar el siguiente caso de
uso:
La ventana Entrada de pedido enva un mensaje prepara a Pedido.
El Pedido enva entonces un mensaje prepara a cada lnea de

pedido dentro del Pedido.


Cada Lnea de pedido revisa el Artculo de inventario
correspondiente.
- Si esta revisin devuelve verdadero, la Lnea de pedido
descuenta la cantidad apropiada de Artculo de inventario del
almacn.
Si no sucede as, quiere decir que la cantidad del Artculo de
inventario ha cado ms abajo del nivel de reorden y entonces
dicho Artculo de inventario solicita una nueva entrega.
En el diagrama siguiente se muestra el diagrama de secuencia

omitiendo las activaciones, que segn Fowler, no aportan mucho a la


ejecucin de procedimientos y solamente sugiere usarlas en
situaciones concurrentes.

Analisis.ppt

Pag. 62

Diagramas Dinmicos

Anlisis y Diseo de Sistemas de Informacin

Diagrama de secuencias. (cont.)

El siguiente ejemplo muestra

Ventana de Entrada
de Pedidos

unPedido

Una Lnea
de Pedido

Un artculo
de inventario

Objeto
Iteracin

prepara()

*[para cada
lnea de
pedido]
prepara()

Mensaje
Condicin
hayExistencia:=
revisa()
[hayExistencia]
descuenta()

necesitaReorden:=
necesitareordenar()

Autodelegacin
[necesitaReorden]
nuevo
Un Artculo
de reorden

Regreso

Creacin
[hayExistencia]
nuevo()

Analisis.ppt

Un Artculo
para entrega

Pag. 63

Anlisis y Diseo de Sistemas de Informacin

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 oscurecer el flujo,
Fowler recomienda usarlo solamente cuando ayuden a aumentar la
claridad.
El borrado de un objeto se muestra con una X grande. Los objetos
pueden autodestruirse o pueden ser destruidos mediante otro
mensaje.

Analisis.ppt

Pag. 64

Anlisis y Diseo de Sistemas de Informacin

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 ejemplo, entonces el
coordinador notifica a la Transaccin que todo est bien.

Analisis.ppt

Pag. 65

Diagramas Dinmicos

Anlisis y Diseo de Sistemas de Informacin

Diagrama de secuencias. (cont.)


nuevo

Una
Transaccin
nuevo

unCoordinador
de transacciones
nuevo

Activacin

un primer
Revisor
de transaccin

Mensaje asncrono

nuevo

un segundo
Revisor
de transaccin

bien
se suprimen
las dems
transacciones

todo
terminado?

bien

es Vlido

el objeto
se borra
a s mismo

todo
terminado?
Autodelegacin

Analisis.ppt

Pag. 66

Anlisis y Diseo de Sistemas de Informacin

Diagramas Dinmicos

Diagramas de secuencias. (cont.)

Cuando utilizar los diagramas de secuencias, se sugieren para:


Son tiles para ver la interaccin entre los objetos, debido a que pone
nfasis en la secuencia y es fcil apreciar el orden en el que ocurren las
cosas.
Cuando se desee ver el comportamiento de varios objetos en un caso de
uso y la secuencia de los mensajes.

No se sugieren para:
No son convenientes para representar el comportamiento condicional,
debido a que son para mostrar un comportamiento simple, se sugiere usar
mejor diagramas separados para cada una de las condiciones
No sirve para ver el comportamiento de un solo objeto a travs de muchos
casos de uso (usar mejor un diagrama de estados)
Si quiere ver el comportamiento a travs de muchos casos de uso o
muchos proceso mejor utilice un diagrama de actividad.

Analisis.ppt

Pag. 67

Diagramas Dinmicos

Anlisis y Diseo de Sistemas de Informacin

Diagramas de colaboraciones.

Muestra los objetos,las relaciones entre ellos, los mensajes que se


envan los objetos entre s.
El mensaje se representa como una flecha cerca de la lnea de asociacin
entre dos objetos. Esta flecha apunta al objeto receptor. El tipo de
mensaje se mostrar en una etiqueta cerca de la flecha.
El mensaje le indicar al objeto receptor que ejecute una de sus
operaciones.
Un diagrama de secuencias puede ser convertido en uno de
colaboraciones y viceversa.
Se agregar una cifra al mensaje para indicar la secuencia propia del
mensaje.
:Nombre1

1:Agregar()

3:Actualizar()
:Nombre2
:Nombre3
Analisis.ppt

2:Modificar()

Pag. 68

Diagramas Dinmicos

Anlisis y Diseo de Sistemas de Informacin

Diagramas de colaboraciones. (cont.)

Ejemplo de un diagrama de colaboraciones:


El actor es el usuario quien inicia la interaccin al oprimir una tecla, se
inicia la siguiente secuencia:

La GUI notifica al sistema operativo que se oprimi la tecla


El sistema operativo le notifica a la CPU
El sistema operativo actualiza la GUI
La CPU notifica a la tarjeta de video
La tarjeta de video enva un mensaje al monitor
El monitor presenta el carcter alfanumrico en la pantalla, con lo que se har
evidente al usuario.
Tecleo

:GUI

1:notificar(tecleo)

6:respuesta()
3:actualizar(tecleo)

:Sistema operativo

:Monitor

2:actualizar(tecleo)
5:mostrar(tecleo)

:Tarjeta de video

Analisis.ppt

:CPU
4:notificar(tecleo)

Pag. 69

Anlisis y Diseo de Sistemas de Informacin

Diagramas Dinmicos

Diagramas de colaboraciones. (cont.)

Cuando utilizar los diagramas de colaboracin, se sugieren para:


Es la mejor forma si se quiere mostrar los objetos y mostrar como se
reconectan estticamente unos con otros.
Cuando se desee ver el comportamiento de varios objetos en un caso de
uso.
Sirven para mostrar la colaboracin entre los objetos, sin embargo, no
sirven tan bien para la definicin precisa del comportamiento

No se sugieren para:
No son convenientes para representar el comportamiento condicional,
debido a que son para mostrar un comportamiento simple, se sugiere usar
mejor diagramas separados para cada una de las condiciones
No sirve para ver el comportamiento de un solo objeto a travs de muchos
casos de uso (usar mejor un diagrama de estados)
Si quiere ver el comportamiento a travs de muchos casos de uso o
muchos proceso mejor utilice un diagrama de actividad.

Analisis.ppt

Pag. 70

Anlisis y Diseo de Sistemas de Informacin

Diagramas de Implementacin

Diagramas de componentes

Un componente es la implementacin de un subsistema, la cual da las


especificaciones (en trminos de casos de uso) y una estructura de clases que
lleva a cabo la especificacin. Su representacin es:

calculadora.java

Hay diferentes tipos de componentes y cada uno con diferentes tipos de


dependencia , Clasificndolos en relacin con el proceso de compilacin un
componente podra ser:
Cdigo fuente, el cual depende de que otros componentes estn disponibles al
momento de compilacin.
Cdigo objeto binario, (biblioteca de clases) que depende de cualquier cdigo objeto
al cul se ligara desde un programa ejecutable.
Una aplicacin ejecutable, la cul puede depender de otros programas ejecutables al
tiempo de ejecucin.

Los detalles dependen del lenguaje de programacin usado, se pueden usar


estereotipos como compilar ligar, igualmente se pueden usar
estereotipos para diferenciar los diferentes tipos de componentes, por
ejemplo: archivo , biblioteca , ejecutable , tabla, documento

Analisis.ppt

Pag. 71

Anlisis y Diseo de Sistemas de Informacin

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 compilacin y de gestin de configuracin.

Analisis.ppt

Pag. 72

Diagramas de Implementacin

Anlisis y Diseo de Sistemas de Informacin

Diagramas de componentes (cont.)

Un diagrama de componentes mostrando las dependencias de


tiempo de compilacin:
ligar
streams.o
biblioteca

MiEntradaSalida

compilar

MiAplicacin
ejecutable

La interfaz se puede representar por una lnea con un crculo


Programa
de bsqueda

Analisis.ppt

Resultado de
la bsqueda

Pag. 73

Diagramas de Implementacin

Anlisis y Diseo de Sistemas de Informacin

Diagramas de componentes (cont.)

Si un componente implementa clases se puede establecer la relacin


entre el componente y las clases como sigue:
ProcesadorTextos.exe
Clases:
ProcesadorTextos
VerificadorOrtografico
ContadorPalabras

ProcesadorTextos.exe

ProcesadorTextos

Analisis.ppt

VerificadorOrtografico

ContadorPalabras

Pag. 74

Anlisis y Diseo de Sistemas de Informacin

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 se dice que provee una interfaz de exportacin,
al que accede a un servicio se dice que utiliza una interfaz de
importacin.

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.

Analisis.ppt

Pag. 75

Diagramas de Implementacin

Anlisis y Diseo de Sistemas de Informacin

Diagramas de componentes (cont.)

Pgina Web con controles ActiveX.


Animacion.htm

ActiveX
DisposicionAnimacion.alx

VBScript

ActiveX
BotonEjecutar
ActiveX
ImagenEsfera

ActiveX
BotonDetener
ActiveX
CronometroEsfera

ActiveX
BotonReinicar

Esfera.gif
ActiveX
CuadroCombCronometro

Analisis.ppt

ActiveX
CuadroCombDistancia

Pag. 76

Anlisis y Diseo de Sistemas de Informacin

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 de los
componentes sobre dichos nodos.
Un nodo representa todo tipo de equipo de cmputo y se representa
por un cubo:
Nodo

Los estereotipos permiten precisar la naturaleza del equipo:


Dispositivos
Procesadores
Memoria
Etc.

Analisis.ppt

Pag. 77

Diagramas de Implementacin

Anlisis y Diseo de Sistemas de Informacin

Diagramas de distribucin.

Los nodos se interconectan mediante soportes bidireccionales (en


principio) que puede a su vez estereotiparse.
Se pueden mostrar los componentes en relaciones de dependencia
con un nodo:
Servidor

Directorio telefnico
corporativo

Programa de
bsqueda

Analisis.ppt

Resultado de
la bsqueda

Pag. 78

Diagramas de Implementacin

Anlisis y Diseo de Sistemas de Informacin

Diagramas de distribucin. (cont.)

Las conexiones entre nodos se puede poner mediante una relacin


Servidor

Directorio telefnico
corporativo

Programa de
bsqueda

Resultado de
la bsqueda

Comunicacin

Cliente
Programa de
Presentacin

Analisis.ppt

Pag. 79

Anlisis y Diseo de Sistemas de Informacin

Diagramas de Implementacin

Diagramas de distribucin. (cont.)

Aplicacin de los diagramas de distribucin.


Un equipo de cmputo casero podra ser como sigue:

Dispositivo
Scanner Microtek
SlimScanC3

Dispositivo
Monitor Daewoo
CMC-1505

Dispositivo
Camara Digital
Polaroid Flash640

PC
Pentium 300Mhz

Windows 95

Windows 95

Internet Explorer

Dispositivo
Modem ESS 336V

Analisis.ppt

Dispositivo
Impresora
HP Lasejet 5L

PC
Pentium 300Mhz

Office 2000

Internet

Dispositivo
Impresora
HP Deskjet 610L

Procesador
ISP Infosel.net

Office 2000

Dispositivo
Conector T

Dispositivo
Conector T

Dispositivo
Terminador

Dispositivo
Terminador

Visio 5Enterprise

Dispositivo
Monitor
PackardBell

Pag. 80

Anlisis y Diseo de Sistemas de Informacin

Caso de Estudio (CS4)

Presentacin del caso.

Administracin CS4

Un estudiante CS4 (eCS4), es cualquier estudiante que esta tomando cualquier mdulo
de cuarto ao en el departamento de ciencias computacionales, ya sea que este o no
inscrito para un grado en ciencias computacionales.
Al final de cada ao acadmico, el Comit Acadmico de el Departamento de Ciencias
Computacionales determina qu mdulos estarn disponibles para los eCS4 en el
siguiente ao.
Al final de cada ao el Jefe del Departamento fija actividades para los miembros del
cuerpo de maestros y otros, en particular a una persona es asignada para ensear cada
uno de los mdulos que se supone van a estar disponibles para el prximo ao (adjunto)
Cada profesor adjunto actualiza los apuntes en el manual del curso de su mdulo. El
coordinador CS4 (CCS4) actualiza otras partes de cada manual y checa los apuntes
producidos por los profesores adjuntos. Los apuntes de los mdulos estn escritos en el
lenguaje de formato LATEX.
Alguien en la Oficina de Enseanza Profesional (OEP) produce la versin en papel de
cada manual de curso; el CCS4 produce la versin HTML ejecutando la aplicacin
latex2html sobre la fuente LATEX.
El CCS3 proporciona una lista de los estudiantes entrando a CS4 provenientes de CS3 al
CCS4 y al OEP. El CCS4 le dice al OEP acerca de cualquier otro estudiante que provenga
de de otros cursos que no sean CS3. El OEP mantiene la lista maestra de todos los eCS4
y actualiza las listas de correo de los estudiantes tomando cursos CS4, la cual se conoce
por la direccin de correo cs4class.
Cada estudiante es avisado por un miembro del cuerpo de maestros que acta como
Director de Estudios (DdE). Un DdE se asigna a un estudiante en su primer ao de
estudios y permanece con sa funcin hasta que termina.
Los estudiantes se inscriben en forma provisional en los mdulos llenando una forma y
entregndola en la Oficina de Enseanza Profesional . El OEP verifica que cada
estudiante que se inscriba, est listado como un eCS4, y cada eCS4 es inscrito en un
numero razonable de mdulos. En caso de duda, se consulta al DdE del estudiante y se
puede tener una pltica con el estudiante.
El OEP produce luego las listas para los adjuntos de los estudiantes que tomarn sus
mdulos. Estas listas no pueden llegarles a los adjuntos antes de la semana 3. Esto es,
muy tarde para que los adjuntos puedan saber cuntas copias deben preparar de su
material.

Analisis.ppt

Pag. 81

Anlisis y Diseo de Sistemas de Informacin

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

Pag. 82

Anlisis y Diseo de Sistemas de Informacin

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
Inscribir en los mdulos.

Producir la lista CS4


CCS4

Organizador Cursos CS3

Producir el
manual del curso
Adjunto CS4

OEP

Inscribir en los
Mdulos
eCS4

Analisis.ppt

Director de estudios CS4

Pag. 83

Anlisis y Diseo de Sistemas de Informacin

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

Desarrolle las descripciones de los casos de uso para:


Producir la lista CS4
Inscribir en los mdulos.

Analisis.ppt

Pag. 84

Caso de Estudio (CS4)

Anlisis y Diseo de Sistemas de Informacin

Diagrama de clases (CS4)

Un diagrama de clases a nivel conceptual, sin incluir actividades y


operaciones:
Adjunto

Imparte
0..*

Mdulo
6

6..*

toma

Director de
Estudios

dirige

1..*

1
0..*

Estudiante
otros aos

Analisis.ppt

1..*

Estudiante

Estudiante
4to ao

Cursos Grado

0..*

esta en

Pag. 85

Caso de Estudio (CS4)

Anlisis y Diseo de Sistemas de Informacin

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
Acadmico

Jefe de
Departamento

Adjunto

OEP

CCS4
Actualizar secciones
principales

Determinar
los mdulos
Asignar
Adjuntos
Actualizar registro
de mdulo

Imprimir
manual

Analisis.ppt

Generar versin
HTML

Pag. 86

Caso de Estudio (Restaurante)

Anlisis y Diseo de Sistemas de Informacin

Presentacin del caso.

Las empresa Restaurantes,S.A. ha hecho una encuesta sobre el mundo de los


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

Entrevista de Anlisis

Qu sucede cuando un cliente entra al restaurante? R: Si el cliente tiene un abrigo,le


ayudamos a quitrselo, lo almacenamos en el guardarropa y le damos un boleto para
solicitarlo posteriormente. Lo mismo hacemos con el sombrero.
Y si hay lnea de espera, se forma? R: Se le pregunta si hizo reservacin, en cuyo caso
lo pasamos lo ms pronto posible. Si no hay reservacin deja su nombre y puede ir al bar
a tomar algo antes de comer o esperar sentado en rea de espera.

Entra el cliente
[Tiene abrigo y/o sombrero]
Guardarlo

Ayudar a quitrselo

[Lista de espera]

[Prefiere el bar]
Espera en el bar

[No hizo reservacin]


Dejar su nombre

Analisis.ppt

[Prefiere el rea de espera]

Aguarda en el
rea de espera

Pag. 87

Anlisis y Diseo de Sistemas de Informacin

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

Pag. 88

Anlisis y Diseo de Sistemas de Informacin

Caso de Estudio (Restaurante)

Diagrama: Servir a un cliente


Entra el cliente
[Tiene abrigo y/o
sombrero]

Ayudar a quitrselo

[Lista de [No hizo


espera]
reservacin]

[Prefiere el bar]

Dejar su nombre

Sentar al cliente

Guardarlo

[Prefiere el rea
de espera]

Aguarda en el
rea de espera

Alistar la mesa
[Desea bebida]

Llamar al mesero

Espera en el bar

Mostrar el men
Llamar al asistente

Servir Pan y agua

Tomar un pedido
de bebidas

Ir por las bebidas

Traer bebida

Sugerir platillo

Leer Men

Elegir

Traer entremes
Analisis.ppt

Notificar al chef

Preparar platillo

Modelado en
un diagrama
Por separado
Pag. 89

Anlisis y Diseo de Sistemas de Informacin

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

Pag. 90

Caso de Estudio (Restaurante)

Anlisis y Diseo de Sistemas de Informacin

Diagrama de Servir a un cliente (cont.)


Traer entrems
Ingerir entrems

Preparar platillo

Modelado en
un diagrama
Por separado

Traer el plato fuerte

[Desea caf]

Ingerir plato fuerte

Servir caf

Beber caf

[Desea postre]

Traer el men
de postres
Traer postres

Trae la cuenta

Ingerir postres
[Guardar abrigo/sombrero]

Salir

Analisis.ppt

Recoger abrigo
o sombrero

Liquidar cuenta
Dejar propina

Pag. 91

Anlisis y Diseo de Sistemas de Informacin

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

Pag. 92

Caso de Estudio (Restaurante)

Anlisis y Diseo de Sistemas de Informacin

Preparacin de platillos
Recibir comanda

Preparar entremeses

Iniciar la preparacin
Del plato fuerte

Llevar entremeses

Coordinar la preparacin
de otros pedidos

Ingerir entremeses

Recibir la notificacin de que los


Entremeses casi se han consumido

Finaliza la preparacin
de plato fuete
Tomar el plato
fuerte

Llevar Plato fuerte

Analisis.ppt

Pag. 93

Caso de Estudio (Restaurante)

Anlisis y Diseo de Sistemas de Informacin

Clases y asociaciones
El cliente se asocia con una gran cantidad de clases, como muestran las
asociaciones a continuacin:
Cuenta

Postre
1

Propina

Reservacin

Ingiere Liquida

Deja

1 1

Hace

1
1..*
1

Cliente

Es atendido por

Mesero

Da a guardar

Sombrero
0..*

Da a guardar

Elige del

Encargado del
Guardarropa

0..*

Abrigo

Ingiere
Hace
1
1

Men

Alimento

Analisis.ppt

Elige del

Men del
postre

Orden

Pag. 94

Anlisis y Diseo de Sistemas de Informacin

Caso de Estudio (Restaurante)

Detalle de las clases

Cliente, sus atributos seran:


Cliente
nombre
horallegada
orden
horaservicio
ingerir()
beber()
ordenar()
pagar()

Analisis.ppt

Pag. 95

Caso de Estudio (Restaurante)

Anlisis y Diseo de Sistemas de Informacin

Detalle de las clases


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

Asistente

Mesero

Chef

Gerente

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

Analisis.ppt

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

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

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

Pag. 96

Anlisis y Diseo de Sistemas de Informacin

Caso de Estudio (Restaurante)

Diagrama de distribucin, Restaurante

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

Dispositivo
Computadora
palmtop
Inalmbrico

Dispositivo
Red

Dispositivo
PC de la
cocina

Analisis.ppt

Dispositivo
PC del
gerente

Pag. 97

Anlisis y Diseo de Sistemas de Informacin

Caso de Estudio (Restaurante)

Casos de uso
El paquete mesero
Mesero
Totalizar
Una cuenta
Transmitir una
Orden al bar
Notificar al chef del
progreso de los clientes
En sus alimentos

Sondear el progreso
De la orden
Tomar
una orden

Incluir
Transmitir la orden
a la cocina

Cambiar
una orden

Incluir

Llamar a un
Asistente

Analisis.ppt

Tomar una orden


De bebida

Obtener un acuse
De recibo

Recibir una notificacin


de la cocina
Llamar a un mozo
de piso

Imprimir
una cuenta

Recibir una notificacin


del bar

Pag. 98