Anlisis y diseo de Sistemas

Rational Unified Process (RUP)

RUP consiste en un conjunto de actividades necesarias para transformar los requerimientos de

usuario en el sistema de software.
Este proceso de trabajo genrico puede ser especializado para diversos tipos de software de
sistemas, diversas reas de aplicacin, diferentes tipos de organizaciones, diferentes niveles de
competencia y diferentes tamaos de proyectos. Existen tres elementos centrales que definen a RUP
y estos son:
a) El conjunto de filosofas y prcticas que son la base para un desarrollo de software exitoso.
Procesos Esenciales
Topics
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

VisionDevelop a Vision
PlanManage to the Plan
RisksMitigate Risks and Track Related Issues
Business CaseExamine the Business Case
ArchitectureDesign a Component Architecture
PrototypeIncrementally Build and Test the Product
EvaluationRegularly Assess Results
Change RequestsManage and Control Changes
User SupportDeploy a Usable Product
ProcessAdopt a Process that Fits Your Project

b) Un modelo de proceso y una librera de contenidos asociados.

Ambos definen el proceso de ingeniera de software base de RUP. Adems, permiten al equipo
responsable de desarrollo crear sus propias configuraciones y convertirlo en una metodologa gil si
lo desea.
c) Un meta-modelo de proceso bsico
Posee elementos de definicin de proceso para describir un proceso de ingeniera de software. Est
basado en el Proceso Unificado.

Prof. Giancarlo Escobedo Valdivia

Anlisis y diseo de Sistemas

RUP y su estructura
El proceso se describe en dos dimensiones o dos ejes: El eje horizontal representa tiempo y muestra el aspecto
dinmico del proceso, expresado en trminos de ciclos, fases, iteraciones, y metas. El eje vertical representa el
aspecto esttico del proceso como est descrito en trminos de actividades, artefactos, trabajadores y flujos de
trabajo.

Prof. Giancarlo Escobedo Valdivia

Anlisis y diseo de Sistemas

Fases del RUP
Inicio: Define el alcance del proyecto.
Elaboracin: Se desarrolla el Plan del proyecto, la especificacin de caractersticas y la
arquitectura base.
Construccin: Construye el producto.
Transicin: Traslada el producto a la comunidad del usuario.
Workflows de RUP
Tambin, conocidos como disciplinas o flujos de trabajo del proceso. Un workflow de RUP es una secuencia de
actividades que producen un resultado de valor observable.
Existen dos grupos que son workflows tcnicos y workflows de apoyo.
Organizacin por Componentes
Flujos de trabajo del proceso

Modelo del Negocio: cul es el problema?

Captura de requisitos: Qu hace el sistema?
Anlisis: Cmo funciona?
Diseo: cmo se construye?
implementacin: Archivos
Pruebas
Prueba en Servicio

Iteraciones
Cada fase en RUP puede descomponerse en iteraciones. Una iteracin es un ciclo de desarrollo completo que
produce como resultado una entrega de producto ejecutable.

Prof. Giancarlo Escobedo Valdivia

Anlisis y diseo de Sistemas

EL LENGUAJE DE MODELAMIENTO UNIFICADO - UML

El Lenguaje de Modelamiento Unificado (UML) es un lenguaje estndar que permite visualizar,
especificar, construir y documentar los artefactos del sistema de software. Este lenguaje puso fin a la
guerra de metodologas dentro de la comunidad orientada a objetos. Esta orientacin a objetos fue
inicialmente concebida por el lenguaje de programacin Simula, pero no fue popular hasta finales de
los 80s con el advenimiento de los lenguajes de programacin como C++ y Smalltalk. Cuando la
programacin orientada a objetos se convirti en un xito, la necesidad de metodologas para
soportar el desarrollo de software continu.
Algunas de las metodologas orientadas a objetos que llegaron a ser populares a comienzos de los 90s
son:
- Booch: La metodologa de Grady Booch para el desarrollo orientado a objetos est disponible en un
sin nmero de versiones. Booch defini la nocin de que un sistema es analizado como un conjunto
de vistas, en el que cada una es descrita por un determinado nmero de diagramas de modelo.

La metodologa de Booch, en flotacin grfica, es muy extensa. La metodologa tambin contiene un

proceso mediante el cual un sistema es analizado tanto por un punto de vista de mayor escala como
de menor escala, y est basado en un proceso altamente iterativo e incrementa.
- OMT: La Tcnica de Modelamiento de Objetos (OMT) es una metodologa desarrollada en General
Electric donde James Rumbaugh trabaj. El sistema es descrito por un determinado nmero de
modelos; el modelo de objetos, el modelo dinmico, el modelo funcional y el modelo de casos de uso,
los cuales se complementan entre ellos para dar la descripcin completa del sistema. La metodologa
OMT tambin contena varias descripciones prcticas de cmo hacer un diseo de sistemas, tomando
en cuenta las concurrencias y relaciones con las bases de datos relacionales.

Prof. Giancarlo Escobedo Valdivia

Anlisis y diseo de Sistemas

- OOSE/Objectory: Las metodologas Object Oriented Software Engineering-OOSE y Objectory, ambas
fueron construidas con el mismo punto de vista bsico postulado por Ivar Jacobson. La metodologa
COSE (1. Jacobson, 1994) es la visin de Jacobson de una metodologa orientada a objetos. La
metodologa Objectory se utiliza para construir un sinnmero de sistemas, tan diversos como los
sistemas de telecomunicaciones para Ericsson y sistemas financieros para las compaas WalI Street.
Ambas metodologas estn basadas en casos de uso, las cuales definen los requerimientos iniciales
del sistema vistos por un actor externo. Los casos de uso son luego implementados en todas las fases
de desarrollo hasta probar el sistema en el que son empleados para verificar el sistema. Objectory
tambin ha sido adaptado por la ingeniera de negocios, en la cual las ideas son empleadas para
modelar y mejorar los procesos de negocios.

- Fusion: Esta metodologa proviene de HewlettPackard (D. Coleman, 1994). Se conoce con el
nombre de metodologa de segunda generacin, ya que esta basada en las experiencias de muchas de
las metodologas iniciales. Fusion ha mejorado muchas de las ideas previas e incluye las tcnicas para
la especificacin de operaciones y la interaccin entre objetos. La metodologa tiene un gran nmero
de diagramas de modelos.
- CoadlYourdon: La metodologa Coad/Yourdon, tambin conocida como OOAJOOD, fue uno de los
primeros mtodos utilizados para el diseo y anlisis orientado a objetos. La metodologa era bastante
simple y fcil de aprender y, como tal, funcionaba bien para iniciar a los novatos en las ideas y
terminologas de la tecnologa orientada a objetos. Sin embargo, la flotacin y metodologa no podan
aumentarse a una escala mayor, sino que funcionaban tan slo con sistemas muy limitados. En
consecuencia, esta metodologa es raramente utilizada hoy en da.
Cada una de estas metodologas tenan sus propias notaciones (los smbolos usados para dibujar los
modelos orientado a objetos), procesos (qu actividades realizar en las distintas etapas de desarrollo),
y herramientas (las herramientas CASE que soporten la flotacin y proceso). Esto hace que la eleccin
de una metodologa sea una decisin bastante importante, y frecuentemente lleva a discusiones
acaloradas y debates sobre qu metodologa es la mejor, ms avanzada, y la correcta para
utilizarse en un proyecto especfico. Y, con estetipo de discusiones, raramente haba una buena
respuesta, ya que todas las metodologas tenan sus propias fortalezas y debilidades. Los
desarrolladores con experiencia frecuentemente tomaban una metodologa como base, y luego

Prof. Giancarlo Escobedo Valdivia

Anlisis y diseo de Sistemas

tomaban prestado algunas ideas y soluciones de otras. En la prctica, la diferencia entre las
metodologas no era tan significativa, y a medida que el tiempo transcurra y las metodologas se
desarrollaban, crecan hasta parecerse entre ellas. Esto fue observado por mucho de los gurus en
metodologas, quienes empezaron a buscar formas de cooperar.
HISTORIA DE UML
Grady Booch y James Rumbaugh, en Rational Rose Corporation, comenzaron su trabajo en 1994. Su
meta fue crear una nueva metodologa, Metodologa Unificada, la cual une las metodologas Booch
y OMT-2 del cual Rumbaugh fue el desarrollador principal. En 1995, lvar Jacobson, el hombre detrs
de las metodologas OOSE y Objectory, se les uni. Rational Software tambin compr Objetive
Systems, la compaa sueca que desarroll y distribuy
Objectory. En este punto, los futuros desarrolladores
de UML tambin se dieron cuenta de que su trabajo
tena como objetivo crear un lenguaje de
modelamiento estndar, y renombraron su trabajo
como El Lenguaje Unificado de Modelamiento. Tener
xito en establecer un lenguaje de modelamiento
estndar es una tarea ms simple que hacer las mismas
cosas para un proceso, a partir de que un proceso
difiere substancialmente entre distintas compaas y
culturas. Es incierto si es del todo posible crear un
proceso estndar que pueda ser utilizado por todos.
Booch, Rumbaugh, y Jacobson lanzaron un nmero de
versiones preliminares de UML a la comunidad orientada a objetos. Esto les permiti retroalimentarse
y les dio muchas ideas y sugerencias para incorporarlas y as mejorar el lenguaje. La versin 1.0 del
Lenguaje de Modelamiento Unificado fue lanzada en enero de 1997 y actualmente se encuentra en la
versin 2.0 Aunque las principales partes del UML estn basadas en las metodologas de Booch, OMT,
y OOSE, estos diseadores de metodologas tambin incluyeron conceptos de otras metodologas. Por
ejemplo, el trabajo de David Harel sobre los diagramas de estado ha sido adoptado en los diagramas
de estado de UML; partes de la notacin de la metodologa Fusion para numerar operaciones han sido
incluidas en los diagramas de colaboracin; el trabajo de Gamma-Helm-Johnson-Vlissides en patrones
y cmo documentarlos ha inspirado la elaboracin de detalles en los diagramas de clases.

ESTANDARIZACIN OMG
Cuando comenz el trabajo con UML, ste pretenda establecerse por s mismo como el estndar de
facto, lo cual significa que a travs del uso prctico por parte de los desarrolladores podra ser
reconocido como el principal lenguaje de modelamiento. Sin embargo, cuando OMG requiri un
lenguaje de modelamiento UML se dieron cuenta de que podan hacer de l un una mayor demanda
de una definicin ms formal y estndar, los desarrolladores de estndar formal. Ello dio lugar a
precisa del UML y mejora de la calidad del lenguaje. Una estandarizacin formal es importante para
muchas de las industrias antes de aventurarse a usar una nueva tecnologa. OMG decidi usar UML
como su estndar y est trabajando en los detalles finales de la especificacin. URL: www.omg.org

Prof. Giancarlo Escobedo Valdivia

Anlisis y diseo de Sistemas

LENGUAJE DE MODELAMIENTO Y METODOLOGIA

Existen diferencias importantes entre una metodologa y un lenguaje de modelamiento. Una
metodologa es una forma explcita de estructurar nuestras acciones y pensamientos. Una
metodologa le dice al usuario qu hacer, cmo hacerlo, cundo hacerlo, y por qu hacerlo (el
propsito de una actividad especfica). Las metodologas contienen modelos, y estos modelos se usan
para describir algo y para comunicar los resultados de la utilizacin de una metodologa. La principal
diferencia entre una metodologa y un lenguaje de modelamiento es que el lenguaje de modelamiento
carece de los procesos o instrucciones para saber qu hacer, cmo hacerlo, cundo hacerlo, y por qu
hacerlo.
Cuando construimos modelos, tambin estructuramos nuestros pensamientos. Un modelo es siempre
un modelo de algo y ste tiene un propsito. Si el modelo no tiene un propsito explcito, causar
problemas, ya que nadie sabr cmo o porqu usarlo. Un modelo se expresa en un lenguaje de
modelamiento. Un lenguaje de modelamiento contiene notaciones, los smbolos usados en los
modelos, y un conjunto de reglas que indican cmo hacerlo. Las reglas son de sintaxis, semnticas, y
pragmticas.
La sintaxis nos dice cmo deberan lucir los smbolos y cmo se combinan los smbolos en lenguaje de
modelamiento. La sintaxis se compara con las palabras en lenguaje natural; es importante saber cmo
deletrearlas correctamente y cmo juntar distintas palabras para formar una oracin. Las reglas
semnticas nos dice qu significa cada smbolo y cmo debera ser interpretado por s mismo y, en el
contexto de otros smbolos, son comparados con los significados de las palabras en un lenguaje
natural.
Las reglas pragmticas definen las intenciones de los smbolos a travs del cual el propsito de un
modelo es alcanzado y se vuelven entendibles para otros. Esto corresponde en el lenguaje natural con
las reglas de construccin de oraciones las cuales son claras y entendibles. Por ejemplo, los libros sobre
el estilo de escritura se conocen como pragmticos en dicho sentido.
Para usar bien un lenguaje de modelamiento, es necesario aprender todas estas reglas. La buena
noticia es que UML es mucho ms fcil de comprender que un lenguaje natural. La mayora de los
lenguajes de modelamiento cubre slo sintaxis y semntica. El pragmatismo es un poco difcil cuando
se trata de describir, ya que no se puede formalizar, tan slo puede actuar como gua.
Naturalmente, incluso cuando se domina el lenguaje, no hay garanta de que los modelos producidos
sean buenos. As como escribir una historia en un lenguaje natural, e lenguaje es tan solo una
herramienta que el autor debe dominar. Ms aun depende del autor escribir una buena historia.

REVISIN DE UML
El Lenguaje de Modelamiento Unificado tiene un gran campo de accin. Puede ser usado para el
modelamiento de negocios, modelamiento de software en todas las fases de desarrollo y para todo
tipo de sistemas, y modelamiento general de cualquier tipo de construccin que tenga tanto una
estructura esttica como un comportamiento dinmico. Para poder alcanzar estas capacidades, el
lenguaje se define para que sea lo suficientemente extenso y genrico para permitir el modelamiento
de tanta diversidad de sistemas, evitando la extrema especializacin y complejidad.
La revisin describe las diferentes partes del UML:

Prof. Giancarlo Escobedo Valdivia

Anlisis y diseo de Sistemas

Vistas: Las vistas muestran los distintos aspectos de los sistemas a modelar. Una vista no es un grfico,
sino una abstraccin, la cual consiste en un nmero de diagramas. Slo al definir un determinado
nmero de vistas, que muestran un aspecto en particular del sistema, puede construirse una figura
completa del sistema. Las vistas tambin vinculan el lenguaje de modelamiento con el proceso /
metodologa elegida para el desarrollo.
Diagramas: Los diagramas son los grficos que describen los contenidos en una vista. UML tiene nueve
tipos de diagramas distintos que se usan en combinacin para proveer todas las vistas del sistema.
Elementos de modelo: Los conceptos usados en los diagramas son elementos de modelo que
representan conceptos orientado a objetos comunes tales como clases, objetos, y mensajes, y las
relaciones entre estos conceptos los cuales incluyen los trminos de asociacin, dependencia, y
generalizacin. Un elemento del modelo se usa en varios diagramas diferentes, pero siempre tiene el
mismo significado y smbolo.
Mecanismos generales: Los mecanismos generales proveen comentarios adicionales, informacin, o
semnticas acerca de un elemento de modelo. Tambin, proveen mecanismos de extensin para
adaptar y extender el UML a un proceso / metodologa especfica, organizacin, o usuario.

Prof. Giancarlo Escobedo Valdivia

Anlisis y diseo de Sistemas

VISTAS
Modelar un sistema complejo es una tarea extensa. Un grfico simple no puede capturar toda la
informacin necesaria para definir un sistema. Un sistema se describe con un nmero de aspectos
diferentes: funcional (su estructura esttica e interacciones dinmicas), no funcional (requerimientos
oportunos, confiabilidad, implementacin, etc.), y aspectos organizacionales (organizacin del
trabajo, elaboracin de mdulos de cdigo, etc.).
Por lo tanto, un sistema se describe en una serie de vistas, en las que cada una representa una
proyeccin de la descripcin del sistema completo y muestra un aspecto en particular del sistema.
Cada vista se describe con una serie de diagramas que contienen informacin que enfatizan un
aspecto en particular del sistema. En parte hay cierta concurrencia, de tal forma que un diagrama
puede realmente ser parte de ms de una vista. Observando el sistema desde diferentes vistas, es
posible concentrarse en un aspecto del sistema a la vez. Un diagrama en una vista en particular debera
ser lo suficientemente simple para ser fcilmente comunicado, ms an que sea coherente con los
otros diagramas y vistas, de tal forma que la figura completa del sistema sea descrita por todas las
vistas juntas (a travs de sus respectivos diagramas).

Estas vistas son:

Vista de Casos de Uso: Una vista que muestra la funcionalidad del sistema percibida por actores
externos.
Vista Lgica: Una vista que muestra cmo la funcionalidad es diseada dentro del sistema en trminos
de la estructura esttica del sistema y comportamiento dinmico.
Vista de Componentes o Implementacin: Una vista que muestra la organizacin de los componentes
de cdigo.

Prof. Giancarlo Escobedo Valdivia

Anlisis y diseo de Sistemas

Vista de Concurrencia o Procesos: Una vista que muestra las concurrencias en el sistema y encamina
los problemas de comunicacin y sincronizacin que estn presentes en un sistema con concurrencias.
Vista de Despliegue o Implantacin: Una vista que muestra la implementacin del sistema como una
estructura fsica con computadoras y dispositivos llamados nodos. Cuando se escoge una herramienta
para dibujar los diagramas, hay que asegurarse de que sea fcil la navegacin entre una vista y otra.
Adems, para poder ver como una funcin es diseada para funcionar dentro de un diagrama, la
herramienta debera hacer fcil el cambiar ya sea a la vista de casos de uso, para ver como la funcin
es descrita por un usuario externo o a la vista de despliegue para ver como la funcin es distribuida
en la estructura fsica.

Vista de Casos de Uso

La vista de Casos de Uso describe la funcionalidad que el sistema debera cumplir tal y como es
percibida por actores externos. Un actor interacta con el sistema: puede ser un usuario o algn otro
sistema. La vista de casos de uso es para los clientes, diseadores, desarrolladores, y evaluadores. Est
descrito en los diagramas de casos de uso y ocasionalmente en diagramas de actividades. El uso que
se desee del sistema se describe como una serie de casos de uso en la vista de casos de uso, en el que
un caso de uso es una descripcin genrica de un uso del sistema (una funcin requerida). La vista de
casos de uso es cntrica. Esto quiere decir que sus contenidos encaminan el desarrollo de las otras
vistas. El objetivo final del sistema es proveer la funcionalidad descrita en esta vista (junto con algunas
propiedades no funcionales); ms an, esta vista afecta a las otras. Esta vista es, tambin, empleada
para validar y finalmente verificar el sistema mediante la comprobacin de la vista de casos de uso
con los clientes (se pregunta Es esto lo que desea) y se contrasta con el sistema no terminado (se
pregunta El sistema trabaja tal y como fue especificado).

Prof. Giancarlo Escobedo Valdivia

Anlisis y diseo de Sistemas

Vista Lgica
La vista lgica describe como la funcionalidad se provee. Es principalmente para diseadores y
desarrolladores. En contraste con la vista de casos de uso, la vista lgica se enfoca en el interior del
sistema. Describe tanto la estructura esttica (clases, objetos, y relaciones) como las colaboraciones
dinmicas que ocurren cuando, entre los objetos, se envan mensajes para proveer una determinada
funcin. Las propiedades tales como persistencia y concurrencias tambin son definidas, as mismo
las interfaces y la estructura interna de clases. La estructura esttica se describe en diagramas de
objetos y clases. El modelamiento dinmico se describe en diagramas de actividades, colaboracin,
secuencia y estado.

Vista de Componentes
La vista de componentes es una descripcin de los mdulos de implementacin y sus dependencias.
Es principalmente para los desarrolladores. Los componentes son diferentes tipos de mdulos de
cdigo fuente, binario o ejecutable. Estos se muestran con sus respectivas estructuras y dependencias.
Informacin adicional acerca de los componentes, tales como asignacin de recursos (responsabilidad
para un componente), u otra informacin administrativa, como un reporte de progreso para el trabajo
de desarrollo, tambin pueden ser incluidos.

Prof. Giancarlo Escobedo Valdivia

Anlisis y diseo de Sistemas

Vista de Proceso
La vista de proceso tiene que ver con la divisin del sistema en procesos y procesadores. Este aspecto,
el cual es una propiedad no funcional del sistema, permite un uso de recursos eficiente, la ejecucin
en paralelo y la manipulacin de eventos asncronos desde el entorno. Detrs de la divisin del
sistema, en hilos concurrentes de control ejecutables, la vista debe tambin resolver la comunicacin
y sincronizacin de estos hilos. La vista de proceso es para los desarrolladores e integradores del
sistema y consiste de diagramas dinmicos (estado, secuencia, colaboracin, y diagramas de
actividades).

Vista de Despliegue
Muestra el despliegue fsico del sistema, tales como computadoras y dispositivos (nodos) y como se
conectan entre ellos. La vista de despliegue es para los desarrolladores, integradores, y evaluadores.
Se representa con el diagrama de despliegue. Esta vista tambin incluye una relacin que muestra
cmo los componentes son implementados en la arquitectura fsica; por ejemplo, qu objetos se
ejecutan en sus respectivas computadoras.

Prof. Giancarlo Escobedo Valdivia

Anlisis y diseo de Sistemas

DIAGRAMAS
Los diagramas son los grficos que realmente muestran los smbolos del modelo para ilustrar aspectos
o particularidades del sistema. Un modelo de sistema tpicamente tiene varios diagramas de cada tipo.
Un diagrama es parte de una vista especfica; y cuando es dibujado, es usualmente asignado a una
vista. Algunos tipos de diagrama pueden ser parte de varias vistas, dependiendo de los contenidos del
diagrama.
A continuacin, se describirn los conceptos bsicos detrs de cada diagrama. Todos los detalles
referentes a los diagramas, su sintaxis, su significado exacto y cmo interactan se describirn a lo
largo de los captulos del curso.

Diagrama de Casos de Uso

Un diagrama de casos de uso muestra un nmero de actores externos y su conexin a los casos de uso
que el sistema provee. Un caso de uso es la descripcin de una funcionalidad (un uso especfico del
sistema) que el sistema provee. La descripcin del caso de uso real, es normalmente, hecho en un
archivo de texto plano como una propiedad de documentacin del smbolo de caso de uso, pero
tambin puede ser descrita usando un diagrama de actividades. Los casos de uso se describen slo
como son vistos externamente por el actor (el comportamiento del sistema como el usuario lo percibe)
y no describe como la funcionalidad es provista dentro del sistema. Los casos de uso definen los
requerimientos funcionales del sistema.

Diagrama de Clases
Un diagrama de clases muestra la estructura esttica de las clases en el sistema. Las clases representan
las cosas que son manipuladas en el sistema. Las clases pueden estar relacionadas entre ellas en
distintas formas: asociada (conectada entre ellas), dependiente (una clase depende / usa otra clase),
especializada (una clase es una especializacin de otra clase) o empaquetada (agrupada como una
unidad). Todas estas relaciones se muestran en un diagrama de clases junto con la estructura interna
de las clases en trminos de atributos y operaciones. El diagrama es considerado esttico cuando la
estructura descrita es siempre vlida en cualquier punto del ciclo de vida del sistema. Un sistema
tpicamente tiene un determinado nmero de diagramas de clases, no todas las clases se insertan en
un nico diagrama de clases, y una clase puede participar en varios diagramas de clases.

Prof. Giancarlo Escobedo Valdivia

Anlisis y diseo de Sistemas

Diagrama de Objetos
Un diagrama de objetos es una variante de un diagrama de clases y usa casi una flotacin idntica. La
diferencia entre ambos es que un diagrama de objetos muestra un nmero de instancias de objetos
de clases en vez de las clases reales. Por lo tanto, un diagrama de objetos es un ejemplo de un
diagrama de clases que muestra una posible imagen del sistema en ejecucin: cmo el sistema se
vera en algn punto en el tiempo. Se usa la misma notacin de un diagrama de clases, con dos
excepciones: los nombres de los objetos se subrayan y todas las instancias en una relacin se
muestran.
Los diagramas de objetos no son tan importantes como los diagramas de clases, pero pueden ser
utilizados para ejemplificar un diagrama de clases complejo mostrando como las instancias reales y
las relaciones se veran. Los diagramas de objetos tambin se usan como parte de los diagramas de
colaboracin, en la que la colaboracin dinmica entre un conjunto de objetos se muestra.

Diagrama de Estados
Un diagrama de estados es tpicamente un complemento de la descripcin de una clase. Muestra
todos los posibles estados que los objetos de una clase pueden tener, y qu eventos provocan el
cambio de estado. Un evento puede ser otro objeto que le enva un mensaje, por ejemplo, que un
determinado tiempo ha transcurrido, o que alguna condicin se ha cumplido. Un cambio de estado se
llama transicin. Una transicin tambin puede tener una accin asociada a ella que especfica qu se
debera hacer con relacin a la transicin de estado. Los diagramas de estado no se hacen para todas
las clases, es slo para aquellas que tengan un nmero de estados bien definidos y en donde el
comportamiento de la clase es afectado y cambiado por los distintos estados. Los diagramas de estado
tambin pueden ser hechos para todo el sistema en su totalidad.

Prof. Giancarlo Escobedo Valdivia

Anlisis y diseo de Sistemas

Diagrama de Secuencias
Un diagrama de secuencias muestra una colaboracin dinmica entre un nmero determinado de
objetos, como se muestra en la figura. El aspecto importante de este diagrama es que muestra una
secuencia de mensajes enviados entre objetos. Tambin muestra una interaccin entre objetos, algo
que pasar en algn punto especfico en la ejecucin del sistema. El diagrama consiste en un
determinado nmero de objetos mostrados con lneas verticales. El tiempo transcurre en forma
descendente en el diagrama el cual muestra el intercambio de mensajes entre los objetos a medida
que el tiempo transcurre en la secuencia o funcin. Los mensajes se muestran como lneas con flechas
que indican mensajes entre las lneas verticales de los objetos. Las especificaciones del tiempo y otros
comentarios se agregan en un script a un costado del diagrama.

Diagramas de Colaboracin
Un diagrama de colaboracin muestra una colaboracin dinmica, as como lo hace un diagrama de
secuencia. Frecuentemente queda a criterio del usuario mostrar la colaboracin ya sea en un diagrama
de secuencias o como un diagrama de colaboracin. Adems de mostrar el intercambio de mensajes
(interaccin), el diagrama de colaboracin muestra a los objetos y sus relaciones (algunas veces
referidas como el contexto). Ya sea que use un diagrama de secuencias o un diagrama de colaboracin,
frecuentemente, se puede decidir por lo siguiente: Si el aspecto ms importante de enfatizar es el
tiempo o secuencia, escoja el diagrama de secuencias; en cambio, si importa enfatizar el contexto,
escoja el diagrama de colaboracin. La interaccin entre los objetos se muestra en ambos diagramas.
Los diagramas de colaboracin se muestran como diagramas de objetos, donde un nmero
determinado de objetos se muestran junto con sus relaciones (al usar la notacin del diagrama de
clases / objetos). Las flechas que representan mensajes se dibujan entre los objetos para mostrar el
flujo de mensajes entre los objetos. Los mensajes son rotulados, los cuales entre otras cosas, muestran
el orden en el cual los mensajes son enviados. Esto tambin puede mostrar condiciones, iteraciones,
valores de retorno, etc. Una vez que un desarrollador est familiarizado con la sintaxis de rotular
mensajes, puede leer la colaboracin, y seguir el flujo de ejecucin y el intercambio de mensajes. Un
diagrama de colaboracin tambin puede contener objetos activos, aquellos que se ejecutan en forma
concurrente con otros objetos.

Prof. Giancarlo Escobedo Valdivia

Anlisis y diseo de Sistemas

Diagrama de Actividades
Un diagrama de actividades muestra un flujo de secuencias de actividades. El diagrama de actividades
es tpicamente utilizado para describir las actividades ejecutadas en una operacin, aunque tambin
puede ser empleado para describir otros flujos de actividades, como un caso de uso o una interaccin.
El diagrama de actividades consiste en estados de acciones, el cual contiene. una especificacin de
una actividad a ser ejecutada (una accin). Un estado de accin dejar el estado cuando la accin ha
sido realizada (un estado en un diagrama de estados necesita de un evento explcito antes de dejar el
estado). Por lo tanto, el control fluye entre los estados de accin, los cuales estn conectados unos
con otros. Las decisiones y condiciones, as como tambin la ejecucin paralela de estados de accin,
tambin pueden ser mostradas en el diagrama. El diagrama tambin puede contener especificaciones
de mensajes que son enviados o recibidos como parte de las acciones realizadas.

Prof. Giancarlo Escobedo Valdivia

Anlisis y diseo de Sistemas

Diagrama de Componentes
Un diagrama de componentes muestra la estructura fsica del cdigo en trminos de componentes de
cdigo. Un componente puede ser un componente de cdigo fuente, binario, o ejecutable. Un
componente contiene informacin sobre las clases lgicas o clases que implementa: por lo tanto. crea
una relacin entre la vista lgica y la vista de componentes. La dependencia entre los componentes
se muestra y se hace ms fcil analizar cmo otros componentes se ven afectados por cambios en un
componente. Los componentes tambin se pueden mostrar con cualquiera de las interfaces que
exponen, corno as interfaces OLE/COM; adems, pueden ser agrupadas en paquetes.

Diagrama de Despliegue
El diagrama de despliegue muestra la arquitectura fsica de hardware y software en el sistema. Puede
mostrar las computadoras y dispositivos reales (nodos) junto con las conexiones que presentan entre
ellos; tambin, puede mostrar el tipo de conexiones. Dentro de los nodos, los componentes
ejecutables y objetos son ubicados con el fin de mostrar qu unidades de software se ejecutan en
determinados nodos. Tambin puede mostrar las dependencias entre los componentes. Como hemos
dicho anteriormente, el diagrama de despliegue, mostrado en la vista de despliegue, describe la
arquitectura fsica actual del sistema. Esto es ms que la descripcin funcional en la vista de casos de
usos.

Prof. Giancarlo Escobedo Valdivia