Extractado de: UML User Guide - Booch, Rumbaugh, Jacobson

INTRODUCCION A UML
Resumen de UML
Tres pasos para el entendimiento de UML
Arquitectura de software.
El proceso de desarrollo de software

El Lenguaje de Modelado Unificado (UML) es un lenguaje estndar para la escritura de

proyectos de software. UML puede ser usado para visualizar, especificar, construir y
documentar los componentes de un sistema de software extenso.

UML es apropiado para una gran variedad de sistemas de modelado de sistemas de

informacin de empresas para aplicaciones distribuidas basadas en Web an ms para
sistemas empotrados de tiempo real. Este es un lenguaje muy expresivo, que abarca todos los
panoramas necesarios para desarrollar y estructurar tales sistemas. Para aprender a usar UML
adecuadamente se requiere aprender tres elementos principalmente: los bloques de
construccin bsicos, las reglas que dictan como esos bloques deben ser relacionados y
algunos mecanismos que aplica todo el tiempo el lenguaje.

UML es un proceso independiente que ptimamente debe ser usado en un proceso que es un
manejador de caso de uso, con arquitectura central, iterativa e incremental.

Un resumen de UML
UML es un lenguaje para

Visualizacin
Especificacin
Construccin
Documentacin

CAPITULO 2

los componentes de un sistema de software extenso.

UML es un Lenguaje

Un lenguaje proporciona un vocabulario y las reglas para combinar las palabras de ese
vocabulario para la comunicacin. Un lenguaje de modelado es un lenguaje cuyo vocabulario y
reglas se enfocan en la representacin conceptual y fsica de un sistema. Un lenguaje de
modelado tal como UML es as un lenguaje estndar para proyectos de software.

El modelado permite entender un sistema. Ninguno es suficiente. Mejor dicho, frecuentemente

necesitas mltiples modelos que son conectados a algn otro en orden para entender hasta lo
ms trivial del sistema.

El vocabulario y las reglas de un lenguaje tal como UML nos dicen como crear y leer modelos
bien formados, pero no nos dicen que modelos debes crear y cuando debes crearlos. Un
proceso bien definido te gua en decidir que componentes producir, que actividades y que
trabajadores usar para crearlos y manejarlos y como usar esos componentes para validar y
controlar el proyecto como tal.
UML es un lenguaje para visualizacin

Para muchos programadores la distancia entre el pensamiento de una implementacin y

convertirlo en cdigo es casi nulo. T lo piensas, t lo codificas. De hecho, algunos objetos son
mejor descritos directamente en cdigo. El texto es una forma maravillosamente mnima y
directa para escribir expresiones y algoritmos.

En tal caso el programador se detiene a hacer un modelado aunque totalmente mental. El

debe esbozar sus ideas en un pizarrn o en una servilleta si es posible. No obstante hay
muchos problemas con esto. Primero, comunicando esos modelos conceptuales a otros es
probable un error al menos que cada uno implique expresar el mismo lenguaje. Tpicamente
los proyectos y organizaciones desarrollan sus propios lenguajes y este es difcil de entender
por una persona ajena o nueva en el grupo. Segundo, hay algunas cosas acerca de un
sistema de software que no puedes entender al menos que construyas modelos que
trasciendan el lenguaje de programacin textual. Por ejemplo, el significado de una jerarqua
de clase puede ser deducida pero no totalmente comprendido fijando la atencin en el cdigo
para todas las clases en la jerarqua. Tercero, si el desarrollador, quien deja de hacer el
cdigo, nunca escribi los modelos que estaban dentro de su cabeza, esta informacin podra

CAPITULO 2

ser perdida para siempre.

Los modelos escritos en UML enfocan el tercer problema: Un modelo explcito facilita la
comunicacin.
Algunas cosas son mejor modelados textualmente, otros son mejor modelados grficamente.
En todos los sistemas interesantes hay estructuras que trascienden que pueden ser
representadas en un lenguaje de programacin El UML como tal, es un lenguaje grfico. Este
enfoca el segundo problema descrito fcilmente.
El UML es ms que un gran nmero de smbolos grficos. Mejor dicho, detrs de cada smbolo
de la notacin de UML hay una semntica bien definida. De esta forma, un desarrollador
puede escribir un modelo en el UML y otro desarrollador aun con otra herramienta puede
interpretar ese modelo no ambiguamente. Este direcciona el primer problema descrito
fcilmente.

UML es un lenguaje para especificacin

En este contexto, especificacin significa modelos de construccin que son precisos, no

ambiguos y completos. En particular, el UML direcciona la especificacin de todas las
decisiones importantes de anlisis, diseo e implementacin que deben ser hechas para el
desarrollo y estructuracin de un sistema de software extenso.
UML es un lenguaje para construccin.

UML no es lenguaje de programacin visual, pero su modelo puede ser directamente

conectado a una variedad de lenguajes de programacin. Esto significa que es posible mapear
de un modelo de UML a un lenguaje de programacin tal como Java, C++, Visual Basic, o an
ms, a tablas en una base de datos relacional el almacenamiento persistente de una base de
datos orientada a objetos. Las cosas que son mejor expresados grficamente son hechas en
UML, mientras que los que son mejor expresados textualmente en el lenguaje de
programacin.
Este mapeo permite avances de ingeniera: La generacin de un cdigo dentro de un lenguaje
de programacin. La inversa tambin es posible. La ingeniera inversa requiere de
herramientas de soporte con intervencin humana.

CAPITULO 2

En resumen, UML es suficientemente expresivo y no ambiguo para permitir la ejecucin directa

de los modelos la simulacin de sistemas y la instrumentacin de sistemas de ejecucin.

UML es un lenguaje para documentacin

Una buena organizacin de software produce todos los tipos de componentes para el cdigo
ejecutable. Estos componentes incluyen (pero no estn limitados):
Requerimientos
Arquitectura
Diseo
Cdigo fuente
Planes del proyecto
Pruebas
Prototipos
Revisiones (Releases)
Dependiendo de la cultura de desarrollo, alguno de estos componentes son ms o menos
formal que otros. Tales componentes no son solo la deliberacin de un proyecto, son tambin
indispensables para controlar, validar y comunicar un sistema antes de su desarrollo y
despus de su estructuracin.

UML proporciona direcciona la documentacin de una arquitectura de un sistema y todos

sus detalles. Tambin proporciona un lenguaje para requerimientos y preguntas. Finalmente,
UML proporciona un lenguaje para modelar las actividades de planeacin del proyecto y
manejo de revisiones.

Dnde puede el UML ser usado?

UML es contemplado primeramente para sistemas de software intensivos. Este ha sido

usado efectivamente campos como:
Sistemas de informacin de empresas
Servicios de banco y financieros.
Telecomunicaciones

CAPITULO 2

Transportacin
Defensa/aeroespacio
Ventas
Electrnica mdico
Cientficos
Servicios basados en Web

UML no est limitado a modelado de software. De hecho este es suficiente expresivo para
modelar sistemas de no software, tal como el diseo de hardware y sistemas para determinar
la salud de un paciente.

Un modelo conceptual de UML

Para entender UML necesitas formar un modelo conceptual del lenguaje y este requiere
aprender tres elementos principalmente. Los bloques de construccin bsicos, las reglas que
dictan como esos bloques pueden ser combinados y algunos mecanismos que se aplican todo
el tiempo en UML.
Bloques de construccin de UML

El vocabulario de UML que comprende tres tipos de bloques de construccin:

1.Elementos (Cosas)
2.Relaciones
3.Diagramas.

Los Elementos son las abstracciones que son ciudadanas de primera clase en un modelo, las
relaciones ligan estos elementos entre s; el grupo de diagramas comparte colecciones de
estos elementos.
Elementos en UML: Hay cuatro tipos de Elementos en UML:
1. Estructurales

CAPITULO 2

2. De comportamiento(behavioral)
3. De Agrupamiento
4. Anotacionales.

Son los bloques de construccin bsicos orientados a objetos de los modelos de UML.
Estructurales: Los Elementos estructurales, son los sustantivos de los modelos de UML.
Estos son en la mayora partes estticas de un modelo, representando elementos que o bien
conceptuales o fsicos. Hay siete tipos de elementos estructurales.

Una clase es una descripcin de un conjunto de objetos que comparten los mismos atributos,
operaciones, relaciones y semnticas. Una clase lleva a cabo una o ms interfaces.
Grficamente, una clase es representada con un rectngulo, usualmente incluyendo su
nombre, atributos y operaciones, como en la figura 2.1.

Una interfaz es una coleccin de operaciones que especifican un servicio de una clase o
componente. As, una interfaz describe el desempeo externamente visible de ese objeto. Una
interfaz puede representar el funcionamiento completo de una clase o componente o solo una
parte de ese desempeo. Una interfaz define un conjunto de especificaciones de
operacin(que es su signatura) pero nunca un conjunto de implementaciones de operacin.

CAPITULO 2

Fig. 2.1: Clases

Grficamente una interfaz se representa con un crculo junto con su nombre. Una interfaz
raramente es nica. Mejor dicho, esta es tpicamente agregada a las clases o componentes
que realizan la interfaz como en la figura 2.2

Spelling

Figura 2.2: Interfaz

Una colaboracin define una iteraccin y es una sociedad de roles y otros elementos que
trabajan a la vez para proporcionar algunas funciones cooperativas que son mayores que la
suma de todos los elementos. Una clase dada puede participar en diversas colaboraciones.
Estas colaboraciones representan la implementacin de patrones que integran un sistema.
Grficamente, una colaboracin se representa con una elipse lneas punteadas, usualmente
incluyendo slo su nombre, como en la figura 2.3.

Fig. 2.3: Colaboraciones

Un caso de uso es una descripcin de un conjunto de secuencias de acciones que un sistema

desempea para permitir un resultado de valor observable para un actor particular. Un caso de
uso es usado para estructurar los elementos de comportamiento(behavioral) de un modelo.
Grficamente, un caso de uso se representa con una elipse de lneas slidas, usualmente
incluyendo slo su nombre como en la fig. 2.4.

CAPITULO 2

Fig. 2.4: Casos de uso

Los tres Elementos restantes - clases activas, componentes y nodos- son todas clases
semejantes en significado, ellos describen tambin un conjunto de objetos que comparten los
mismos atributos, operaciones, relaciones y semnticas. Sin embargo estas tres son lo
suficientemente diferentes y son necesarios para ciertos aspectos de modelado de un sistema
orientado a objetos.

Una clase activa es una clase cuyos objetos reconocen uno o ms procesos o hilos y por lo
tanto pueden iniciar una actividad de control. Una clase activa es semejante a una clase
excepto que sus objetos representan elementos cuya funcin es concurrente con otros
elementos. Grficamente una clase activa se representa semejante a una clase pero con
lneas ms anchas, usualmente incluyendo su nombre, atributos y operaciones, como en la
figura 2.5.

Figura. 2.5: Clases activas

Los dos elementos restantes- componente y nodos- son tambin diferentes. Representan
Elementos fsicos, tal como los cinco Elementos anteriores representan Elementos lgicos o
conceptuales.

Un componente es un una parte fsica y reemplazable de un sistema que conforma y

proporciona la realizacin de un conjunto de interfaces. En un sistema encontrars diferentes
tipos de componentes de estructuracin, tal como componentes COM+ o Java Beans, adems
de componentes que son artefactos de procesos de desarrollo, tal como los archivos de cdigo
fuente. Un componente tpicamente representa el empaquetado fsico de diferentes elementos
lgicos tal como clases, interfaces, y colaboraciones. Grficamente, un componente es

CAPITULO 2

representado por un rectngulo con pestaas (tabuladores), usualmente incluyendo slo su

nombre como en la figura 2.6

Fig. 2.6: Componentes

Un nodo es un elemento fsico que existe al tiempo de ejecucin y representa un recurso

computacional, generalmente tiene al menos una memoria y frecuentemente capacidad de
procesamiento. Un conjunto de componentes puede residir en un nodo y puede tambin
emigrar de un nodo a otro. Grficamente un nodo es representado por un cubo incluyendo
usualmente slo su nombre como en la figura 2.7.

Fig. 2.7: Nodos

Estos siete elementos - clases, interfaces, colaboraciones, casos de uso, clases activas,
componentes y nodos - son los Elementos estructurales bsicos que puedes incluir en un
modelo de UML. Hay tambin variaciones de estos siete, tal como actores, seales, y
utilidades (tipos de clase), procesos e hilos (Threads, tipos de clases activas), y aplicaciones,
documentos, archivos, libreras, pginas y tablas(tipos de componentes).
Elementos de comportamiento (behavioral): Son las partes dinmicas de los modelos UML.
Estos son los verbos de un modelo que rerpesentan la funcin sobre tiempo y espacio. De
hecho, hay dos tipos principales de Elementos de comportamiento.
Una iteraccin es una funcin que comprende un conjunto de intercambio de mensajes entre
un conjunto de objetos con un contexto particular para lograr un propsito especfico. La
funcin de una asociacin de objetos o de una operacin individual puede ser especificada con
una interaccin. Una interaccin involucra un nmero de otros elementos incluyendo

CAPITULO 2

mensajes, secuencias de accin (la funcin invocada por un mensaje), ligas (la conexin entre
objetos). Grficamente un mensaje se representa con una lnea dirigida incluyendo slo el
nombre de su operacin. tal como en la figura 2.8.

Fig. 2.8: Mensajes

Una mquina de estado es una funcin que especifica la secuencia de estados de un objeto o
una interaccin dada durante su tiempo de vida en respuesta a eventos, junto con las
respuestas de esos eventos. La funcin de una clase individual o una colaboracin de clases
puede ser especificada con una mquina de estados. Una mquina de estados involucra otros
elementos incluyendo estados, transiciones(el flujo de un estado a otro), eventos y actividades.
Grficamente se representa con un rectngulo redondeado, incluyendo usualmente su nombre
y sus subestados si hay alguno, como en la figura 2.9.

Fig. 2.9: Estados.

Las mquinas de estado y las interacciones son los objetos funcionales bsicos que puedes
incluir en UML. Semnticamente, estos elementos estn usualmente conectados a varios
elementos estructurales, principalmente clases, colaboraciones y objetos.
Elementos de agrupamiento: Son las partes de organizacin de los modelos UML. Estos son
cajas dentro de las cuales un modelo puede ser descompuesto. Hay un tipo principal de
Elementos de agrupamiento nombrados paquetes.
Un paquete es un mecanismo de propsito general para la organizacin de elementos en
grupos. Los Elementos estructurales, funcionales y aun los de agrupacin pueden estar
situados dentro de un paquete. A diferencia de los componentes (los cuales existen al tiempo
de ejecucin) un paquete es puramente conceptual (significa que existe durante el tiempo de
desarrollo). Grficamente un paquete se representa con un folder tabulado incluyendo
usualmente su nombre y en ocasiones su contenido, como en la figura 2-10.

CAPITULO 2

Fig. 2.10: Paquetes.

Los paquetes son los Elementos de agrupamiento bsicos con los cuales se puede organizar
un modelo de UML. Hay variaciones, tal como Frameworks, modelos y subsistemas(tipos de
paquetes).
Elementos anotacionales: Son las partes explicativas de los modelos de UML. Son los
comentarios que se pueden aplicar para describir, iluminar y remarcar algunos elementos de
un modelo. Hay un tipo principal de Elementos anotacionales llamado nota. Una nota es
simplemente un smbolo para representar las limitaciones y comentarios asociados a un
elemento o una coleccin de elementos. Grficamente una nota se representa con un
rectngulo con una esquina doblada, junto con un comentario textual o grfico, como la figura
2.11.

Fig. 2.11: Notas.

Relaciones en UML: hay cuatro tipos de relaciones en UML:

1. Dependencias
2. Asociacin
3. Generalizacin
4. Realizacin

Estas relaciones se usan para escribir modelos bien formados.

Una dependencia es una relacin semntica entre dos Elementos tal que un cambio en un
thing (el independiente) puede afectar al otro(el dependiente). Grficamente una dependencia

CAPITULO 2

se representa con una lnea punteada posiblemente dirigida y ocasionalmente incluye una
etiqueta tal como en la figura 2-12.

Fig. 2.12: Dependencias

Una asociacin es una relacin estructural que describe un conjunto de ligas. Una liga es una
conexin entre objetos.

Una agregacin es un tipo especial de asociacin que representa una relacin estructural entre
un todo y sus partes. Grficamente una asociacin es representada con una lnea slida
posiblemente dirigida, ocasionalmente incluye una etiqueta y frecuentemente contiene otros
adornos tal como multiplicidad y nombres de roles como en la figura 2-13

Employer employee

Fig. 2.13: Asociaciones

Una generalizacin es una relacin especializacin/generalizacin en la cual los objetos del

elemento especializado(el hijo) son sustituidos por elementos del elemento generalizado(el
padre). De esta forma, el hijo comparte la estructura y funcin del padre. Grficamente una
relacin de generalizacin es representada con una lnea slida con una flecha vaca hacia el
padre como en la figura2-14.

CAPITULO 2

Fig. 2.14: Generalizaciones

Una realizacin es una relacin semntica entre clasificadores(classifiers) donde un

clasificador especifica un contrato que otro clasificador garantiza llevar a cabo. Las relaciones
de realizacin se encuentran en dos partes: entre interfaces y las clases componentes que las
realizan y entre casos de uso y las colaboraciones que las realizan. Grficamente una relacin
de realizacin se representa por un hbrido entre una relacin de generalizacin y una de
dependencia como en la figura 2-15.

Fig. 2.15: realizacin

Diagramas en UML: Un diagrama es la representacin grfica de un conjunto de elementos,

ms frecuentemente representados como una grfica conectada de vrtices(objetos) y
arcos(relaciones). Los diagramas se utilizan para visualizar un sistema desde diferentes
perspectivas. As, un diagrama es una proyeccin de un sistema. Un diagrama representa un
panorama de los elementos que integran un sistema. Los mismos elementos pueden aparecer
en todos los diagramas, slo en una parte de los diagramas o en ninguno(raramente sucede).
En teora un diagrama puede contener alguna combinacin de objetos y relaciones. UML
incluye nueve tipos de diagramas:
1. Diagramas de clases
2. Diagramas de objetos
3. Diagramas de casos de uso
4. Diagramas de secuencia
5. Diagramas de colaboracin
6. Diagramas de estado
7. Diagramas de actividad
8. Diagramas de componente
9. Diagrama de estructuracin(deployment)
Un diagrama de clase muestra un conjunto de clases, interfaces y colaboraciones y sus
relaciones. Estos diagramas son los ms comunes del modelado de sistemas orientados a
objetos. Direccionan Vista de diseo esttico del sistema.

CAPITULO 2

Un diagrama de objeto muestra un conjunto de objetos y relaciones. Representan instancias

de los objetos encontrados dentro de diagramas de clase. Estos diagramas direccionan Vista
de diseo esttico o Vista de proceso esttico de un sistema tal como los diagramas de clase
pero desde la perspectiva de casos reales o prototpica.

Un diagrama de caso de uso muestra un conjunto de casos de uso y actores (un tipo especial
de clases) y sus relaciones. Un diagrama de caso direcciona Vista de caso de uso esttica de
un sistema.

Tanto los diagramas de secuencia y colaboracin son tipos de diagramas de iteraccin. Un

diagrama de iteraccin muestra una iteraccin consistiendo de un conjunto de objetos y sus
relaciones, incluyendo los mensajes que pueden ser enviados entre ellos. Los diagramas de
iteraccin direccionan Vista dinmico de un sistema. Un diagrama de secuencia es un
diagrama de iteraccin que enfatiza el ordenamiento del tiempo de mensajes; un diagrama de
coleccin es un diagrama de iteraccin que enfatiza la organizacin estructural de los objetos
que envan y reciben mensajes. Los diagramas de secuencia y colaboracin son isomrficos,
lo que significa que t puedes tomar uno y transformarlo en el otro.

Un diagrama de estado muestra una mquina de estados que consiste de estados,

transiciones, eventos y actividades. Direccionan Vista dinmico del sistema. Son importantes
para modelar el desempeo de una interfaz, clase o colaboracin reactivos de modelado y
enfatiza el desempeo ordenado de eventos de un objeto el cual es especialmente usado en
modelado de sistemas reactivos.

Un diagrama de actividad es un tipo especial de un diagrama de estado que muestra el flujo de

actividad de un sistema. Direcciona Vista dinmico de un sistema. Son importantes para
modelar la funcin de un sistema y enfatiza el flujo de control de los objetos.

Un diagrama de componente muestra las organizaciones y dependencias de un conjunto de

componentes. Estos diagramas direccionan Vista de implementacin esttico. Estn
relacionados a diagramas de clases en donde un componente normalmente mapea uno o ms
clases, interfaces y colaboraciones.

Un diagrama de instalacin (deployment) muestra la configuracin de los nodos procesndose

al tiempo de ejecucin y los componentes que ellos tienen. Direccionan Vista de estructuracin
esttico de una arquitectura. Estn relacionados a diagramas de componentes, en donde un
nodo normalmente contiene a uno o ms componentes.

CAPITULO 2

Reglas de UML
Los bloques de construccin no pueden ser modelados a la vez en forma aleatoria. UML tiene
un conjunto de reglas que un modelo bien formado debe contemplar. Un modelo bien formado
es aquel que es semnticamente consistente en s mismo y en armona con sus modelos
relacionados.

UML tiene reglas de semntica para:

Nombres :Cmo llamar a los Elementos, relaciones y diagramas.
Alcance : El contexto que da un significado especfico a un nombre.
Visibilidad. Cmo esos nombres pueden ser vistos y usados por otros.
Integridad: Cmo los Elementos se relacionan adecuadamente y consistentemente con
otros
Ejecucin: Qu significa correr y simular un modelo dinmico.

Es comn que un desarrollador construya no slo modelos que son bien formados, sino
tambin modelos que sean:

Omitidos(Elided): ciertos elementos son ocultos para simplificar Vista.

Incompletos: Ciertos elementos pueden ser olvidados.
Inconsistentes: La integridad de un modelo no es garantizada.

Las reglas de UML te alientan, pero no forzan a direccionar los aspectos ms

importantes de anlisis, diseo e implementacin para que los modelos lleguen a ser
bien formados con respecto al tiempo.

Mecanismos comunes de UML

UML cuenta con cuatro mecanismos comunes que se aplican consistentemente todo el tiempo
en el lenguaje.
1. Especificaciones
2. Adornos(Adornments)
3. Divisiones comunes

CAPITULO 2

4. Mecanismos de extensibilidad.
Especificaciones: UML es ms que un lenguaje grfico. Mejor dicho, detrs de cada parte de
su notacin grfica hay una especificacin que proporciona una declaracin textual de la
sintaxis y semntica de los bloques de construccin. Por ejemplo, detrs de un icono de clase
esta una especificacin que proporciona el conjunto de operaciones, atributos y funcin que
contempla la clase.

Las especificaciones de UML proporcionan una semntica regresiva que contiene todas las
partes de todos los modelos de un sistema, cada parte relacionada a otra en forma
consistente.
Adornos: La mayora de los elementos de UML tienen una notacin grfica dirigida y nica
que proporciona una representacin visual de los aspectos ms importantes de los elementos.
Por ejemplo la figura 2.16 muestra una clase adornada para indicar que es una clase abstracta
con dos operaciones pblicas, una protegida y una privada.

Fig. 2.16: Adornos.

Divisiones comunes: En el modelado de sistemas orientados a objetos al menos se tienen

dos formas de divisin.

Primeramente, la divisin de clases y objetos. Una clase es una abstraccin; un objeto es una
manifestacin concreta de una abstraccin. En UML puedes modelar clases tan bien como
objetos. Cada bloque de construccin en UML tiene el mismo tipo de dicotoma clase/objeto.
Por ejemplo, se pueden tener casos de usos y sus instancias de casos de uso, componentes e

CAPITULO 2

instancias de componentes, nodos e instancias de nodo y as. Grficamente, el UML distingue

un objeto usando el mismo smbolo que su clase y subrayando el nombre del objeto como en
la figura 2.17.

Fig. 2.17:Clases y objetos

Segundo, existe la separacin de interface e implementacin. Una interface declara un

contrato(de agregacin) y una implementacin representa una realizacin concreta de ese
contrato, responsable de llevar a cabo fcilmente la semntica completa de la interfaz. En UML
se puede modelar tanto las interfaces como sus implementaciones como en la figura 2.18.

en esta figura hay dos componentes llamadas spellingwizard.dd que implementan dos
interfaces, Iunknown y Ispelling.

Fig. 2.18: Interfaces e implementaciones

Mecanismos de extensibilidad: UML proporciona un lenguaje estndar para la escritura de

proyectos de software. UML es un lenguaje abierto que hace posible que uno pueda extender
en forma controlada. Los mecanismos de extensin incluyen:
Estereotipos

CAPITULO 2

Valores de etiquetado(tagged)
Restricciones(constraints)

Un estereotipo extiende el vocabulario de UML permitiendo crear nuevos bloques de

construccin que son derivados de unos existentes pero que son especficos para el problema.
Por ejemplo si ests trabajando en un lenguaje de programacin como Java frecuentemente
querrs modelar excepciones. En este lenguaje las excepciones son clases y son tratadas en
forma muy especial en tus modelos son tratados como bloques de construccin bsicos y se
pueden hacer con un apropiado estereotipo.

Un valor de etiquetado extiende las propiedades de un bloque de construccin de UML,

permitiendo crear nueva informacin de la especificacin de ese elemento.

Una restriccin extiende la semntica de un bloque de construccin de UML, permitiendo

adicionar nuevas reglas o modificar algunas existentes.

Arquitectura
La visualizacin, especificacin construccin y documentacin de un sistema de software
requiere que el sistema sea enfocado desde diferentes perspectivas. Diferentes personas usuarios finales, analistas, desarrolladores, integradores del sistema, escritores tcnicos y
manejadores de proyectos- cada uno aporta diferentes agendas a un proyecto y cada uno ve
el sistema de diferentes formas, a diferente tiempo durante el ciclo de vida del proyecto. Una
arquitectura del sistema es quizs el artefacto que puede ser usado para manejar los
diferentes puntos y as controlar el desarrollo iterativo e incremental de un sistema durante su
ciclo de vida.

La arquitectura es el conjunto de decisiones significativas acerca de:

La organizacin de un sistema de software
La seleccin de los elementos estructurales y sus interfaces mediante las cuales se
compone el sistema.
Sus funciones, especificada en la s colaboraciones entre estos elementos.
La composicin de estos elementos estructural y funcionalmente para subsistemas
progresivamente ms largos.

CAPITULO 2

El estilo de arquitectura que gua esta organizacin: los elementos estticos y dinmicos
sus interfaces, colaboraciones y composiciones.

La arquitectura de software no slo contempla la estructura y desempeo, sino tambin usos,

funcionalidad, desempeo, elasticidad, reuso, compresibilidad, contratos econmicos y
tecnolgicos y todo lo que concierne a esttica.

En la figura 2.19 se ilustra como la arquitectura de un sistema de software puede ser descrito
desde cuatro puntos de vista. cada vista es una proyeccin dentro de la organizacin y
estructura del sistema, enfocndose en general a aspectos de ese sistema.

Fig. 2.19: Modelando la arquitectura del sistema

Vista de caso de uso de un sistema enfoca los casos de uso que describe el desempeo del
sistema tal como lo ven los usuarios finales, analistas y ensayistas. Existe para especificar las
fuerzas que comparte la arquitectura de un sistema. En UML los aspectos estticos dentro de
este panorama son capturados en diagramas de caso de uso y los dinmicos en este
panorama son capturados en diagramas de iteraccin, de estado y de actividad.
Vista de diseo de un sistema abarca las clases, interfaces, y colaboraciones que forman el
vocabulario del problema y su solucin. Este panorama principalmente soporta los
requerimientos funcionales del sistema, es decir, los servicios que el sistema debe
proporcionar a sus usuarios. En UML el aspecto esttico de este panorama es capturado en
los diagramas de clases y los de objeto, el aspecto dinmico de este punto de vista son
capturados en los diagramas de iteraccin, diagramas de estado y de actividad.

CAPITULO 2

Vista de proceso de un sistema enfoca los hilos de control y procesos que conforman los
mecanismos de concurrencia y sincronizacin. Principalmente, direcciona el desempeo,
escalabilidad y duracin del sistema.

Vista de implementacin de un sistema comprende los componentes y archivos que son

usados para ensamblar y liberar el sistema fsico. Este panorama direcciona principalmente el
manejo de configuracin de la liberacin del sistema. con UML el aspecto esttico de este
panorama es capturado en diagramas de componentes; y el aspecto dinmico es capturado en
los diagramas de iteraccin de estado y actividad.

Vista de instalacin(deployment) de un sistema comprende los nodos forman la topologa de

hardware del sistema dentro de las cuales el sistema se ejecuta. Direcciona principalmente la
distribucin, entrega e instalacin de las partes que lleva a cabo el sistema fsico. En UML el
aspecto esttico es capturado en los diagramas de estructura y el dinmico en los diagramas
de iteraccin, estado y actividad.

Ciclo de vida del desarrollo del software

UML es un proceso independiente, lo que significa que no requiere un ciclo de vida de
desarrollo de software particular. Para obtener los mejores beneficios de UML se deben
considerar un proceso que es:

Un manejado por casos de uso

Centrado en la arquitectura (enfocada a)
Iterativo e incremental

Manejado por caso de uso significa que los casos de uso son usados principalmente como una
herramienta para establecer el funcionamiento deseado del sistema, para verificacin y
validacin de la arquitectura del sistema, prueba y comunicacin entre las personas del
proyecto.

Un proceso iterativo es aquel que involucra el manejo de un flujo de liberaciones ejecutables.

Un proceso incremental es aquel que involucra la integracin continua de la arquitectura del

CAPITULO 2

sistema para producir esos releases. Con cada nuevo release se incluyen mejoras
incrementales sobre el otro.

Este manejo de caso de uso, centrado en arquitectura y los procesos iterativos incrementales
pueden dividirse en fases. Una fase es la duracin de tiempo dos clculos del proceso, cuando
un conjunto de objetivos es conocido, los artefactos son completados y las decisiones
realizadas para llevar a cabo la prxima fase. Hay cuatro fases en el ciclo de vida del
desarrollo del software: Conceptualizacin (inception), elaboracin, construccin y transicin.

La conceptualizacin es la primera fase del proceso, cuando se tiene la idea para el desarrollo
lleva al punto lo suficientemente bien fundamentado para garantizar por completo la fase de
elaboracin.

La elaboracin es cuando la visin del producto y su arquitectura son definidos. En este punto
los requerimientos del sistema son articulados, prioritizados y referenciados.

La construccin es la fase cuando el proceso de software que lleva a cabo la arquitectura

ejecutable para que este lista para ser transportada al ambiente del usuario. Aqu tambin los
requerimientos del sistema y su evaluacin son constantemente reexaminados.

La transicin es la fase donde el software es turnado a las manos del usuario. Durante esta
fase el sistema es continuamente mejorado.

MODELO CONCEPTUAL DE UML

ESTRUCTURALES

CLASE
INTERFAZ
COLABORACION
CASO DE USO
CLASE ACTIVA
COMPONENTE
NODO

DE COMPORTAMIENTO

INTERACCION
MAQUINA DE ESTADOS

DE AGRUPACION

PAQUETE

DE ANOTACION

NOTAS

ELEMENTOS

DEPENDENCIA
ASOCIACION
GENERALIZACION
REALIZACION

BLOQUES DE CONSTRUCCION
C
O
M
P
O
N
E
N
T
E
S

RELACIONES

DE CLASES
DE OBJETOS
DE CASOS DE USO

DE ESTADO (STATECHART)
DE ACTIVIDADES
DE COMPONENTES
DE DESPLIEGUE

REGLAS

MECANISMOS COMUNES

NOMBRES
ALCANCE
VISIBILIDAD
INTEGRIDAD
EJECUCION
ESPECIFICACIONES
ADORNOS
DIVISIONES COMUNES
MECANISMOS DE
EXTENSIBILIDAD

VISTA DE CASOS DE USO

DE CASOS DE USO

DINAMICA

DE INTERACCION
DE ESTADO (STATECHART)
DE ACTIVIDADES

VISTA DE DISEO
DINAMICA
ESTATICA
VISTA DE PROCESOS
DINAMICA
ESTATICA
VISTA DE IMPLEMENTACION

DINAMICA
ESTATICA

VISTA DE DESPLIEGUE
C
I
C.
V
I
D
A
D
E
S.
S
O
F
T.

ESTEREOTIPOS
VALORES ETIQUETADOS
RESTRICCIONES

ESTATICA

ESTATICA
A
R
Q
U
I
T
E
C
T
U
R
A

DE SECUENCIA
DE COLABORACION

DE INTERACCION

DIAGRAMAS

DINAMICA

DE CLASES
DE OBJETOS
DE INTERACCION
DE ESTADO (STATECHART)
DE ACTIVIDADES
DE CLASES
DE OBJETOS
DE INTERACCION
DE ESTADO (STATECHART)
DE ACTIVIDADES
DE COMPONENTES
DE INTERACCION
DE ESTADO (STATECHART)
DE ACTIVIDADES
DE DESPLIEGUE
DE INTERACCION
DE ESTADO (STATECHART)
DE ACTIVIDADES

DIRIGIDO POR LOS CASOS DE USO

CENTRADO EN LA ARQUITECTURA
ITERATIVO E INCREMENTAL

FASES

INICIACION
ELABORACION
CONSTRUCCION
TRANSICION

FLUJOS DE TRABAJO DEL PROCESO

MODELADO DEL NEGOCIO

REQUISITOS
ANALISIS Y DISEO
IMPLEMENTACION
PRUEBAS
DESPLIEGUE

FLUJOS DE TRABAJO DE SOPORTE

GESTION DEL CAMBIO Y CONFIGURAC IONES

GESTION DEL PROYECTO
ENTORNO

ENFASIS EN CLASES ACTIVAS