Anlisis y diseo de Sistemas

Prof. Giancarlo Escobedo Valdivia

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. VisionDevelop a Vision

2. PlanManage to the Plan

3. RisksMitigate Risks and Track Related Issues

4. Business CaseExamine the Business Case

5. ArchitectureDesign a Component Architecture

6. PrototypeIncrementally Build and Test the Product

7. EvaluationRegularly Assess Results

8. Change RequestsManage and Control Changes

9. User SupportDeploy a Usable Product

10. 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.

Anlisis y diseo de Sistemas

Prof. Giancarlo Escobedo Valdivia

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.

Anlisis y diseo de Sistemas

Prof. Giancarlo Escobedo Valdivia

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.

Anlisis y diseo de Sistemas

Prof. Giancarlo Escobedo Valdivia

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.

Anlisis y diseo de Sistemas

Prof. Giancarlo Escobedo Valdivia

- 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

Anlisis y diseo de Sistemas

Prof. Giancarlo Escobedo Valdivia

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

Anlisis y diseo de Sistemas

Prof. Giancarlo Escobedo Valdivia

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:

Anlisis y diseo de Sistemas

Prof. Giancarlo Escobedo Valdivia

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.

Anlisis y diseo de Sistemas

Prof. Giancarlo Escobedo Valdivia

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.

Anlisis y diseo de Sistemas

Prof. Giancarlo Escobedo Valdivia

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).

Anlisis y diseo de Sistemas

Prof. Giancarlo Escobedo Valdivia

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.

Anlisis y diseo de Sistemas

Prof. Giancarlo Escobedo Valdivia

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.

Anlisis y diseo de Sistemas

Prof. Giancarlo Escobedo Valdivia

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.

Anlisis y diseo de Sistemas

Prof. Giancarlo Escobedo Valdivia

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.

Anlisis y diseo de Sistemas

Prof. Giancarlo Escobedo Valdivia

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.

Anlisis y diseo de Sistemas

Prof. Giancarlo Escobedo Valdivia

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.

Anlisis y diseo de Sistemas

Prof. Giancarlo Escobedo Valdivia

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.