UNIDAD II.

- LENGUAJE
MODULADO UNIFICADO

2.1.- INTRODUCCIN.
El

UML

(Unifed

Modelig

Languaje

Lenguaje

de

Modelamiento Unificado) es un lenguaje grfico para la

especificacin,

visualizacin,

construccin

documentacin de piezas de informacin usadas o

producidas durante el proceso de desarrollo de software.
A estas piezas de construccin se les conoce como
Artefactos. UML provee un marco arquitectnico de
diagramas para trabajar sobre anlisis y diseo orientado
a objetos, as como tambin el modelamiento de negocios
y otros sistemas que no son software. UML es un lenguaje
simblico para expresar modelos orientados objetos y no
una metodologa para desarrollarlos.
Este lenguaje es el resultado de la convergencia de las
mejores prcticas en la industria e tecnologa de software
orientado a objetos, en especial de la simbologa utilizada
por tres los principales mtodos de anlisis y diseo
orientado a objetos como son Booch (Booch), OMT

(Rumbaugh),

OOSE

(Jacobson)

cuyos

autores

se

agruparon en Rational Software para desarrollarlo.

UML es un lenguaje estndar para escribir planos de
software.

UML

puede

utilizarse

para

visualizar,

especificar, construir y documentar los artefactos de

un sistema que involucra una gran cantidad de
software.
UML es apropiado para modelar desde sistemas de
informacin

en

empresas

hasta

aplicaciones

distribuidas basadas en la Web, e incluso para

sistemas empotrados de tiempo real muy exigentes.
Es un lenguaje muy expresivo, que cubre todas las
vistas necesarias para desarrollar y luego desplegar
tales sistemas.
UML es slo un lenguaje y por tanto es tan slo una
parte de un mtodo de desarrollo de software.
Un lenguaje proporciona un vocabulario y las reglas para
combinar palabras de ese vocabulario con el objetivo de
posibilitar la comunicacin. Un lenguaje de modelado es
un lenguaje cuyo vocabulario y reglas se centran en la
representacin conceptual y fsica de un sistema. Un
lenguaje de modelado como UML es por tanto un lenguaje
estndar para los planos del software. El vocabulario y las
reglas de un lenguaje como UML indican cmo crear y
leer modelos bien formados, pero no dicen que modelos

se deben crear ni cundo se deberan crear. Esta es la

tarea del proceso de desarrollo de software.
UML es algo ms que un simple montn de smbolos
grficos. Detrs de cada smbolo en la notacin UML
hay una semntica bien definida. De esta manera,
un desarrollador puede escribir un modelo en UML, y
otro desarrollador, o incluso otra herramienta, puede
interpretar ese modelo sin ambigedad.
UML no es un lenguaje de programacin visual, pero
sus modelos pueden conectarse de forma directa a
una gran variedad de lenguajes de programacin.
Esta

correspondencia

permite

ingeniera

directa:

la

generacin de cdigo a partir de un modelo UML en un

lenguaje de programacin. Lo contrario tambin es
posible: se puede reconstruir un modelo en UML a partir
de una implementacin.
UML es lo suficientemente expresivo y no ambiguo
como para permitir la ejecucin directa de modelos,
la simulacin de sistemas y la instrumentacin de
sistemas en ejecucin.
UML cubre la documentacin de la arquitectura de
un sistema y todos sus detalles. UML tambin
proporciona un lenguaje para expresar requisitos y
pruebas. Finalmente; UML proporciona un lenguaje

para modelar las actividades de planificacin de

proyectos y gestin de versiones.

2.2.- TIPOS DE DIAGRAMAS.

Un diagrama es una representacin grfica de un
conjunto

de

elementos,

la

mayora

de

las

veces

mostrados como grafo conexo de vrtices (cosas) y arcos

(relaciones). Los buenos diagramas hacen el sistema que
se est desarrollando, ms comprensible y cercano a los
objetivos.
El lenguaje unificado de diagrama o notacin (UML) sirve
para especificar, visualizar y documentar esquemas de
sistemas de software orientado a objetos. UML no es un
mtodo de desarrollo, lo que significa que no sirve para
determinar qu hacer en primer lugar o cmo disear el
sistema, sino que simplemente le ayuda a visualizar el
diseo y a hacerlo ms accesible para otros. UML est
controlado por el grupo de administracin de objetos
(OMG) y es el estndar de descripcin de esquemas de
software.
UML est diseado para su uso con software orientado a
objetos, y tiene un uso limitado en otro tipo de cuestiones
de programacin.

UML

se

compone

de

muchos

elementos

de

esquematizacin que representan las diferentes partes de

un sistema de software. Los elementos UML se utilizan
para crear diagramas, que representa alguna parte o
punto de vista del sistema.
Umbrello UML Modeller soporta los siguientes tipos de
diagramas:
Diagrama de casos de uso que muestra a los actores
(otros usuarios del sistema), los casos de uso (las
situaciones que se producen cuando utilizan el
sistema) y sus relaciones.
Diagrama de clases que muestra las clases y la
relaciones entre ellas.
Diagrama de secuencia muestra los objetos y sus
mltiples relaciones entre ellos.
Diagrama de colaboracin que muestra objetos y sus
relaciones, destacando los objetos que participan en
el intercambio de mensajes.
Diagrama de estado muestra estados, cambios de
estado y eventos en un objeto o en parte del
sistema.
Diagrama de actividad que muestra actividades, as
como los cambios de una a otra actividad junto con
los eventos que ocurren en ciertas partes del
sistema.

 Diagrama

de

componentes

que

muestra

los

componentes de mayor nivel de la programacin

(cosas como Kparts o Java Beans).
Diagrama

de

implementacin

que

muestra

las

instancias de los componentes y sus relaciones.

Diagrama de relaciones de entidad que muestra los
datos y las relaciones y restricciones entre ellos.

2.3.-

DIAGRAMAS

ESTRUCTURALES.
Diagramas Estructurales
Los

diagramas

visualizar,

estructurales

especificar,

en

construir

UML
y

existen

para

documentar

los

aspectos estticos del sistema.

Los diagramas estructurales estn organizados sobre
grupos de cosas (u objetos) que se encontrarn cuando
se est modelando un sistema.
1. Diagramas de clases, interfaces y colaboraciones
2. Diagramas de objetos
3. Diagramas de componentes
4. Diagramas de implantacin nodos

Diagramas de clases.- un diagrama de ste tipo muestra

un conjunto de clases, interfaces, colaboraciones y sus
relaciones.
Diagramas de objetos.- Muestra un conjunto de objetos y
sus relaciones. A diferencia de los diagramas anteriores,
estos diagramas se enfocan en la perspectiva de casos
reales o prototipos.
Diagramas de componentes.- Muestra el conjunto de
componentes y sus relaciones y se utilizan para ilustrar la
vista de la implementacin esttica de un sistema.
Diagramas de implantacin.- Muestra un conjunto de
nodos y sus relaciones; se usan para ilustrar la vista de
implantacin esttica de un sistema.

2.3.1.- DIAGRAMA DE CLASES.

En UML el diagrama de clases es uno de los tipos de
diagramas o smbolo esttico y tiene como fin describir la
estructura de un sistema mostrando sus clases, atributos
y

relaciones

entre

ellos.

Estos diagramas son utilizados durante el proceso de

anlisis y diseo de los sistemas informticos, en donde
se intentan conformar el diagrama conceptual de la
informacin que se manejar en el sistema.

Como ya sabemos UML es un modelado de sistema

Orientados a Objetos, por ende los conceptos de este
paradigma se incorporan a este lenguaje de modelado.

Los

diagramas

de

clases

tiene

las

siguientes

caractersticas:
Las clases define el mbito de definicin de un
conjunto de objetos.
Cada objeto pertenece a una clase.

 Los objetos se crean por instanciacin de las clases.

2.3.2.- DIAGRAMA DE COMPONENTES.

Un diagrama de componentes es un diagrama tipo del
Lenguaje Unificado de Modelado.
Los diagramas de componentes describen los elementos
fsicos

del sistema

y sus

relaciones. Muestran las

opciones de realizacin incluyendo

Un

diagrama

de

componentes

representa

las

dependencias entre componentes software, incluyendo

componentes de cdigo fuente, componentes del cdigo
binario, y componentes ejecutables. Un mdulo de
software

se

puede

representar

como

componente.

Algunos componentes existen en tiempo de compilacin,

algunos en tiempo de enlace y algunos en tiempo de
ejecucin,

otros

en

varias

de

stas.

Un componente de slo compilacin es aquel que es

significativo nicamente en tiempo de compilacin. Un
componente ejecutable es

un programa

ejecutable.

Un diagrama de componentes tiene slo una versin con

descriptores,

no

tiene

versin

con

instancias.

Para

mostrar las instancias de los componentes se debe usar

un diagrama de despliegue.

Un diagrama de componentes muestra clasificadores de

componentes,

las

clases

definidas

en

ellos,

las

relaciones entre ellas. Los clasificadores de componentes

tambin se pueden anidar dentro de otros clasificadores
de componentes para mostrar relaciones de definicin.
Un diagrama que contiene clasificadores de componentes
y

de

nodo

se

puede

utilizar

para

mostrar

las

dependencias del compilador, que se representa como

flechas con lneas discontinuas (dependencias) de un
componente cliente a un componente proveedor del que
depende. Los tipos de dependencias son especficos del
lenguaje y se pueden representar como estereotipos de
las
El

dependencias.
diagrama

interfaces

tambin
las

puede

usarse

dependencias

de

para

mostrar

llamada

entre

componentes, usando flechas con lneas discontinuas

desde

los

componentes

las

interfaces

de

otros

componentes.
ELEMENTOS Y CONECTORES DEL DIAGRAMA DE
COMPONENTES

2.3.3.- DIAGRAMA DE OBJETOS.

Forma parte de la vista esttica del sistema. En este
diagrama se modelan las instancias de las clases del
Diagrama de Clases. Este diagrama cabe aclarar que
cuenta con objetos y enlaces. En estos diagramas
tambin es posible encontrar las clases para tomar como
referencia su instanciacin.
En otras palabras el Diagrama de Objetos muestra un
conjunto de objetos y sus relaciones en un momento
concreto. Los Diagramas de Objetos son realmente tiles
para modelar estructuras de datos complejas

2.3.4.- DIAGRAMA DE PAQUETES.

Un diagrama de paquetes muestra como un sistema est
dividido

en

agrupaciones

dependencias

entre

normalmente

un

esas

paquete

lgicas

mostrando

agrupaciones.
est

pensado

Dado
como

las
que
un

directorio, los diagramas de paquetes suministran una

descomposicin de la jerarqua lgica de un sistema.
Los

Paquetes

estn

normalmente

organizados

para

maximizar la coherencia interna dentro de cada paquete

y minimizar el acoplamiento externo entre los paquetes.
Con estas lneas maestras sobre la mesa, los paquetes
son buenos elementos de gestin. Cada paquete puede
asignarse

un

individuo

un

equipo,

las

dependencias entre ellos pueden indicar el orden de

desarrollo requerido.

 Partes del diagrama de paquetes

Paquetes: Agrupacin de elementos que pueden ser
casos de usos clases o componentes es posible anidar
paquetes entre si se representan mediante un smbolo en
forma de carpeta el nombre se coloca en la pestaa y el
contenido dentro de la carpeta la visibilidad de los
elementos devn indicarse con los smbolos + -#+
Dependencias: indica que un elemento de un paquete
requiere a otro de un paquete distinto. Se representa
mediante una flecha discontinua con inicio en el paquete
que depende del otro

2.3.5.- DIAGRAMA DE ACTIVIDADES.

Un Diagrama de Actividades representa un flujo de

trabajo paso a paso de negocio y operacionales de los
componentes en un sistema.
En UML 1, un diagrama de actividades es una variacin
del

Diagrama

de

Estados

UML

donde

los

estados

representan operaciones y las transiciones representan

las actividades que ocurren cuando la operacin es
completa.
En la actualidad, el diagrama de actividades en UML 2.0
es similar al aspecto del diagrama en UML 1, solo que
ahora la semntica esta basada en lo que se conoce
como Redes de Petri. En UML 2.0, el diagrama general de
interaccin est basado en el diagrama de Actividad.
Componentes:
Inicio: el inicio de un diagrama de actividades es
representado por un crculo de color negro slido.
Actividad: Una actividad representa la accin que
ser realizada por el sistema la cual representa
dentro de un valo.
Transicin: Una transicin ocurre cuando se lleva
acabo el cambio de una actividad a otra, la
transicin es representada simplemente por una

lnea con una flecha en su terminacin para indicar

su direccin.

2.4.-

DIAGRAMA

DE

COMPORTAMIENTO.
Los diagramas de comportamiento se emplean para
visualizar,
aspectos

especificar,
dinmicos

construir
de

documentar
un

los

sistema.

Los aspectos dinmicos de un sistema de software

involucran cosas tales como el flujo de mensajes a lo
largo del tiempo y el movimiento fsico de componentes
en una red.

2.4.1. DIAGRAMAS DE CASOS DE USO.

Los Casos de Uso no forma parte de la llamada Fase de
Diseo, sino parte de la fase de Anlisis, respondiendo el

interrogante Qu?. De forma que al ser parte del anlisis

ayuda a describir que es lo que el sistema debe hacer.
Estos diagramas muestran operaciones que se esperan
de una aplicacin o sistema y como se relaciona con su
entorno, es por ello que se ve desde el punto de vista del
usuario. Describen un uso del sistema y como ste
interacta con el usuario.
Los casos de usos se representan en el diagrama por una
elipses la cual denota un requerimiento solucionado por
el

sistema.

El conjunto de casos de usos representa la totalidad de

operaciones que va a desarrollar el sistema. Por ltimo a
estos elipses lo acompaa un nombre significativo de
manera de rtulo.

Otro elemento fundamental de estos diagramas son los

actores la cual representa a un usuario del sistema, que

necesita o interacta con algn caso de uso, la que

tambin es acompaado por un nombre. Por ltimo
tenemos los flujos de eventos que corresponde a la
ejecucin normal y exitosa del caso de uso.

2.4.2.- DIAGRAMA DE ESTADO.

Un estado es una condicin durante la vida de un objeto,
de forma que cuando dicha condicin se satisface se lleva
a cabo alguna accin o se espera por un evento.
El estado de un objeto se puede caracterizar por el valor
de uno o varios de los atributos de su clase, adems,
el estado de un objeto tambin se puede caracterizar por
la existencia de un enlace con otro objeto.
El diagrama de estados engloba todos los mensajes que
un objeto puede enviar o recibir, en otras palabras es un
escenario que representa un camino dentro de un
diagrama.
Como caracterstica de estos diagramas siempre cuentan
con dos estados especiales, el inicial y el final, con la
particularidad que este diagrama puede tener solo un
estado inicial pero varios estados finales.

Una transicin entre estados representa un cambio de un

estado origen a un estado sucesor destino que podra ser
el mismo que el estado origen, dicho cambio de estado
puede estar aparejado con alguna accin. Adems las
acciones se asocian a las transiciones y se consideran
que ocurre de forma rpida e interrumpible.

Los elementos que componen estos diagramas son:

Crculo lleno, apuntando el estado inicial.
Crculo hueco que contiene un crculo lleno ms
pequeo en el interior, indicando el estado final.
Rectngulo

redondeado

dividido

por

una

lnea

horizontal, indicado los estados, en la parte de arriba

se encuentra el nombre del estado y abajo se indica
la actividad que realiza.

 Flecha, la cual denota la transicin, el nombre del

evento que causa esta transicin etiqueta el cuerpo
de la flecha.

2.4.3.- DIAGRAMA DE SECUENCIA.

Un Diagrama de Secuencias muestra una interaccin
ordenada segn la secuencia temporal de eventos y el
intercambio de mensajes. Los diagramas diagramas de
secuencia ponen especial nfasis en el orden y el
momento en el que se envan los mensajes a los objetos.
En los diagramas de Secuencias los elementos estn
representados por lneas intermitentes verticales, con el
nombre del objeto en la parte ms alta.

Los mensajes pueden ser o bien sncronos, el tipo normal

de llamada del mensaje donde se pasa el control a objeto

llamado hasta que el mtodo finalice, o asncronos donde

se devuelve el control directamente al objeto que realiza
la llamada.
Los mensajes sncronos tienen una caja vertical en un
lateral del objeto invocarte que muestra el flujo del
control del programa.

2.4.4.- DIAGRAMA DE COLABORACIN.

Un diagrama de colaboracin, se puede decir que es una
forma alternativa al diagrama de secuencias a la hora de
mostrar

un

escenario.

Este tipo de diagrama muestra las interacciones que

ocurren entre los objetos que participan en una situacin
determinada.
A diferencia del diagrama de secuencia, el diagrama de
colaboracin se enfoca en la relacin entre los objetos y
su topologa de comunicacin.
En estos diagramas los mensajes enviados de un objeto a
otro se representa mediante flechas, acompaado del
nombre del mensaje, los parmetros y la secuencia del
mensaje.
Estos diagramas estn indicados para mostrar una
situacin

flujo

de

programa

especfico

son

considerados uno de los mejores diagramas para mostrar

o explicar rpidamente un proceso dentro de la lgica del

programa

2.4.5.- DIAGRAMA DE DISTRIBUCIN.

Los diagramas de distribucin permiten comprender
cmo estaran conectadas las unidades entre s y dnde
se

ejecutaran

los

programas.

Cada

objeto

en

el

diagrama es por ejemplo:

1-El

servidor

dnde

esta

instalada

la

aplicacin

2-La mquina del gerente a donde pones los dashboards

3-Las mquinas de los vendedores que acceden al CRM
(quiero esperar que tu sistema de ventas sea la definicin
moderna

de

un

CRM)

4-Las mquinas de las personas de inventarios

De

ese

modo

dibujas

las

entidades

como

se

interconectan entre s para dar una idea grfica de las

capacidades de cmputo distribuido de tu aplicacin.

Por eso se llaman 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 es un elemento fsico que existe en tiempo de
ejecucin y representa un recurso computacional, que
generalmente tiene algo de memoria y, a menudo,
capacidad de procesamiento. Los nodos se utilizan para
modelar la topologa del hardware sobre el que se ejecuta
el sistema. Representa tpicamente un procesador o un
dispositivo sobre el que se pueden

desplegar los

componentes.
La relacin entre nodos puede representarse como se
muestra a continuacin:

2.5.- ADAPTACIN DE UML AL

PROCESO DE DESARROLLO.
Existen dos tipos de metodologas: antiguas y recientes.
Se entiende por metodologa a la estructura y naturaleza
de los pasos en un esfuerzo de desarrollo. Pero antes de
iniciar a programar los desarrolladores deben tener
claridad sobre el problema.
Mtodo antiguo
Las etapas deben suceder en lapsos definidos, una
despus de otra. Obsrvese el mtodo en cascada:
Este mtodo reduce el impacto de la comprensin
obtenida

en el proyecto. Si el proceso no puede

retroceder y volver a ver los primeros estados, es posible

que las ideas desarrolladas no sean utilizadas.

Mtodo reciente
Tiende a la colaboracin entre las fases de desarrollo esta
moderna

ingeniera

de

programas,

los

analistas

diseadores hacen revisiones para desarrollar un slido

fundamento para los desarrolladores. Existe interaccin
entre todo el equipo de trabajo.
La ventaja es que conforme crece la comprensin, el
equipo incorpora nuevas ideas y genera un sistema ms
confiable.

Lo que debe hacer un proceso de desarrollo

El

equipo

tiene

que

formarse

de

analistas

para

comunicarse con el cliente y comprender el problema,

diseadores para generar una solucin, programadores
para

codificarla

ingenieros

de

sistemas

para

que sus fases no

sean

distribuirlas.
A su vez debe asegurar
discontinuas.
GRAPPLE
Significa Guas para la Ingeniera de Aplicaciones Rpidas,
tiene dentro de s una condensacin de ideas de varias
otras personas.
Consta de cinco segmentos en lugar de fases, cada
segmento consta de diversas acciones cada accin es
responsabilidad de un jugador.
Los

segmentos

son:

recopilacin,

anlisis,

diseo,

desarrollo y distribucin. Lo que otorga un acrnimo

RADDD.
Recopilacin de necesidades
La funcin es comprender lo que desea el cliente.
Realice un anlisis del dominio

El objetivo es comprender de la mejor manera posible el

dominio del cliente. El analista debe acomodarse al
cliente.
Descubra las necesidades del sistema
El equipo realiza su primera sesin de JAD(Desarrollo de
conjunto de aplicaciones).En dnde se rene a quienes
toman las decisiones en la empresa del cliente, a los
usuarios potenciales y a los miembros de los equipos de
desarrollo.
Presentar los resultados al cliente
Cuando finaliza todas las acciones de Necesidades, el
administrador de proyectos presentar los resultados al
cliente.
Anlisis
En este segmento aumenta la comprensin por parte
del equipo.Se necesita trabajar sobre: la comprensin del
uso del sistema, hacer realidad de los casos de uso,
depurar los diagramas de clases, analizar cambios de
estado en los objetos, definir la comunicacin entre
objetos,

analizar

colaboraciones.

la

integracin

con

diagramas

de

Diseo
El equipo trabajar con los resultados del segmento de
Anlisis para disear la solucin, en este punto se harn
revisiones pertinentes hasta que el diseo se haya
completado. Contiene las siguientes fases: desarrollo y
depuracin de diagramas de componentes, desarrollo de
diagramas

de

componentes,

planeacin

para

la

distribucin, diseo y prototipos de la interfaz del usuario,

pruebas de diseo, iniciar la documentacin.
Desarrollo
De este segmento se encargan los programadores, debe
realizarse con rapidez y sin problemas.
Fases: generacin del cdigo, verificacin del cdigo,
generacin de interfaces del usuario y conexin con el
cdigo, prueba, consumacin de la documentacin.
Distribucin
En este segmento se distribuye en el hardware adecuado
y se integra con los sistemas cooperativos.
Fases: planeacin

para

copias

de

seguridad

recuperacin, instalacin del sistema terminado en el

hardware adecuado, verificacin del sistema instalado,

celebracin.