2014

Algoritmos UML
Silvia Margarita Martnez Velzquez
ING. Jos ngel Flores Velazco
Universidad Politcnica de Gmez Palacio
Indice
Universidad Politcnica de Gmez Palacio ............................................................. 0
El UML es un Lenguaje ........................................................................................... 3
El UML es un lenguaje para visualizacin ............................................................... 3
El UML es un lenguaje para especificacin ............................................................. 5
El UML es un lenguaje para construccin. .............................................................. 5
El UML es un lenguaje para documentacin ........................................................... 6
Dnde puede el UML ser usado? .......................................................................... 7
Un modelo conceptual del UML .............................................................................. 8
Bloques de construccin de UML ............................................................................ 8
Elementos en UML: Hay cuatro tipos de Elementos en UML: ................................. 8
Estructurales ........................................................................................................... 9
Los tres Elementos restantes ................................................................................ 12
Elementos de comportamiento (behavioral): ......................................................... 14
Elementos de agrupamiento.................................................................................. 15
Elementos anotacionales ...................................................................................... 16
Diagramas en UML: .............................................................................................. 19
Reglas de UML ...................................................................................................... 21
UML tiene reglas de semntica para: .................................................................... 22
Omitidos(Elided): ................................................................................................... 22
Incompletos: .......................................................................................................... 22
Inconsistentes ....................................................................................................... 22
Mecanismos comunes de UML ............................................................................. 23
Especificaciones .................................................................................................... 23
Adornos ................................................................................................................. 23
Divisiones comunes .............................................................................................. 24
Mecanismos de extensibilidad ............................................................................... 25
Arquitectura ........................................................................................................... 26
Ciclo de vida del desarrollo del software ............................................................... 29





















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

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


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

El UML es un lenguaje para construccin.

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

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.


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

El 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?

El 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
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 del 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:
Estructurales
De comportamiento(behavioral)
De Agrupamiento
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.





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.




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



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:
Dependencias
Asociacin
Generalizacin
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 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.



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:
Diagramas de clases
Diagramas de objetos
Diagramas de casos de uso
Diagramas de secuencia
Diagramas de colaboracin
Diagramas de estado
Diagramas de actividad
Diagramas de componente
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.


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.

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.
Especificaciones
Adornos(Adornments)
Divisiones comunes
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 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
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.
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.

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

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