You are on page 1of 22

CAPITULO 2

INTRODUCIENDO A EL UML

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

El Lenguaje de Modelado Unificado (UML) es un lenguaje estndar para la escritura de proectos
de software. El UML puede ser usado para !isuali"ar# especificar# construir documentar los
componentes de un sistema de software e$tenso.

El UML es apropiado para una gran !ariedad de sistemas de modelado de sistemas de
informaci%n de empresas para aplicaciones distri&uidas &asadas en 'e& a(n ms para
sistemas empotrados de tiempo real. Este es un lenguaje mu e$presi!o# que a&arca todos los
panoramas necesarios para desarrollar estructurar tales sistemas. )ara aprender a usar UML
adecuadamente se requiere aprender tres elementos principalmente* los &loques de construcci%n
&sicos# las reglas que dictan como esos &loques de&en ser relacionados algunos mecanismos
que aplica todo el tiempo el lenguaje.

UML es un proceso independiente que %ptimamente de&e ser usado en un proceso que es un
manejador de caso de uso# con arquitectura central# iterati!a e incremental.

Un resumen del UML

El UML es un lenguaje para

+isuali"aci%n
Especificaci%n
,onstrucci%n
-ocumentaci%n

los componentes de un sistema de software e$tenso.

El UML es un Lenguaje

Un lenguaje proporciona un !oca&ulario las reglas para com&inar las pala&ras de ese
!oca&ulario para la comunicaci%n. Un lenguaje de modelado es un lenguaje cuo !oca&ulario
reglas se enfocan en la representaci%n conceptual f.sica de un sistema. Un lenguaje de
modelado tal como UML es as. un lenguaje estndar para proectos de software.

El modelado permite entender un sistema. /inguno es suficiente. Mejor dic0o# frecuentemente
necesitas m(ltiples modelos que son conectados a alg(n otro en orden para entender 0asta lo
ms tri!ial del sistema.

El !oca&ulario las reglas de un lenguaje tal como UML nos dicen como crear leer modelos &ien
formados# pero no nos dicen que modelos de&es crear cuando de&es crearlos. Un proceso &ien
definido te gu.a en decidir que componentes producir# que acti!idades que tra&ajadores usar
para crearlos manejarlos como usar esos componentes para !alidar controlar el proecto
como tal.

El UML es un lenguaje para visualizacin

)ara muc0os programadores la distancia entre el pensamiento de una implementaci%n
con!ertirlo en c%digo es casi nulo. T( lo piensas# t( lo codificas. -e 0ec0o# algunos o&jetos son
mejor descritos directamente en c%digo. El te$to es una forma mara!illosamente m.nima directa
para escri&ir e$presiones algoritmos.

En tal caso el programador se detiene a 0acer un modelado aunque totalmente mental. El de&e
es&o"ar sus ideas en un pi"arr%n o en una ser!illeta si es posi&le. /o o&stante 0a muc0os
pro&lemas con esto. )rimero# comunicando esos modelos conceptuales a otros es pro&a&le un
error al menos que cada uno implique e$presar el mismo lenguaje. T.picamente los proectos
organi"aciones desarrollan sus propios lenguajes este es dif.cil de entender por una persona
ajena o nue!a en el grupo. 1egundo# 0a algunas cosas acerca de un sistema de software que no
puedes entender al menos que construas modelos que trasciendan el lenguaje de programaci%n
te$tual. )or ejemplo# el significado de una jerarqu.a de clase puede ser deducida pero no
totalmente comprendido fijando la atenci%n en el c%digo para todas las clases en la jerarqu.a.
Tercero# si el desarrollador# quien deja de 0acer el c%digo# nunca escri&i% los modelos que
esta&an dentro de su ca&e"a# esta informaci%n podr.a ser perdida para siempre.

Los modelos escritos en UML enfocan el tercer pro&lema* Un modelo e$pl.cito facilita la
comunicaci%n.
Algunas cosas son mejor modelados te$tualmente# otros son mejor modelados grficamente. En
todos los sistemas interesantes 0a estructuras que trascienden que pueden ser representadas
en un lenguaje de programaci%n El UML como tal# es un lenguaje grfico. Este enfoca el segundo
pro&lema descrito fcilmente.
El UML es ms que un gran n(mero de s.m&olos grficos. Mejor dic0o# detrs de cada s.m&olo de
la notaci%n de UML 0a una semntica &ien definida. -e esta forma# un desarrollador puede
escri&ir un modelo en el UML otro desarrollador aun con otra 0erramienta puede interpretar ese
modelo no am&iguamente. Este direcciona el primer pro&lema descrito fcilmente.


El UML es un lenguaje para especi!icacin

En este conte$to# especificacin significa modelos de construcci%n que son precisos# no
am&iguos completos. En particular# el UML direcciona la especificaci%n de todas las decisiones
importantes de anlisis# dise2o e implementaci%n que de&en ser 0ec0as para el desarrollo
estructuraci%n de un sistema de software e$tenso.

El UML es un lenguaje para c"ns#ruccin$

El UML no es lenguaje de programaci%n !isual# pero su modelo puede ser directamente
conectado a una !ariedad de lenguajes de programaci%n. Esto significa que es posi&le mapear
de un modelo de UML a un lenguaje de programaci%n tal como 3a!a# ,44# +isual 5asic# o a(n
ms# a ta&las en una &ase de datos relacional el almacenamiento persistente de una &ase de
datos orientada a o&jetos. Las cosas que son mejor e$presados grficamente son 0ec0as en
UML# mientras que los que son mejor e$presados te$tualmente en el lenguaje de programaci%n.
Este mapeo permite a!ances de ingenier.a* La generaci%n de un c%digo dentro de un lenguaje de
programaci%n. La in!ersa tam&i6n es posi&le. La ingenier.a in!ersa requiere de 0erramientas de
soporte con inter!enci%n 0umana.

En resumen# UML es suficientemente e$presi!o no am&iguo para permitir la ejecuci%n directa
de los modelos la simulaci%n de sistemas la instrumentaci%n de sistemas de ejecuci%n.


El UML es un lenguaje para d"cumen#acin

Una &uena organi"aci%n de software produce todos los tipos de componentes para el c%digo
ejecuta&le. Estos componentes incluen (pero no estn limitados)*
Requerimientos
Arquitectura
-ise2o
,%digo fuente
)lanes del proecto
)rue&as
)rototipos
Re!isiones (Releases)
-ependiendo de la cultura de desarrollo# alguno de estos componentes son ms o menos formal
que otros. Tales componentes no son solo la deli&eraci%n de un proecto# son tam&i6n
indispensa&les para controlar# !alidar comunicar un sistema antes de su desarrollo despu6s
de su estructuraci%n.

El UML proporciona direcciona la documentaci%n de una arquitectura de un sistema todos sus
detalles. Tam&i6n proporciona un lenguaje para requerimientos preguntas. 7inalmente# UML
proporciona un lenguaje para modelar las acti!idades de planeaci%n del proecto manejo de
re!isiones.


%Dnde puede el UML ser usad"&

El UML es contemplado primeramente para sistemas de software intensi!os. Este 0a sido usado
efecti!amente campos como*
1istemas de informaci%n de empresas
1er!icios de &anco financieros.
Telecomunicaciones
Transportaci%n
-efensa8aeroespacio
+entas
Electr%nica m6dico
,ient.ficos
1er!icios &asados en 'e&

UML no est limitado a modelado de software. -e 0ec0o este es suficiente e$presi!o para
modelar sistemas de no software# tal como el dise2o de 0ardware sistemas para determinar la
salud de un paciente.


Un m"del" c"ncep#ual del UML

)ara entender UML necesitas formar un modelo conceptual del lenguaje este requiere aprender
tres elementos principalmente. Los &loques de construcci%n &sicos# las reglas que dictan como
esos &loques pueden ser com&inados algunos mecanismos que se aplican todo el tiempo en
UML.

'l"(ues de c"ns#ruccin de UML

El !oca&ulario de UML que comprende tres tipos de &loques de construcci%n*
9.Elementos (,osas)
:.Relaciones
;.-iagramas.

Los Elementos son las a&stracciones 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.

Elemen#"s en UML* =a cuatro tipos de Elementos en UML*
9. Estructurales
:. -e comportamiento(&e0a!ioral)
;. -e Agrupamiento
>. Anotacionales.

1on los &loques de construcci%n &sicos orientados a o&jetos de los modelos de UML.

Es#ruc#urales* Los Elementos estructurales# son los sustanti!os de los modelos de UML. Estos
son en la maor.a partes estticas de un modelo# representando elementos que o &ien
conceptuales o f.sicos. =a siete tipos de elementos estructurales.

Una clase es una descripci%n de un conjunto de o&jetos que comparten los mismos atri&utos#
operaciones# relaciones semnticas. Una clase lle!a a ca&o una o ms interfaces.
?rficamente# una clase es representada con un rectngulo# usualmente incluendo su nom&re#
atri&utos operaciones# como en la figura :.9.

Una interfa" es una colecci%n de operaciones que especifican un ser!icio de una clase o
componente. As.# una interfa" descri&e el desempe2o e$ternamente !isi&le de ese o&jeto. Una
interfa" puede representar el funcionamiento completo de una clase o componente o solo una
parte de ese desempe2o. Una interfa" define un conjunto de especificaciones de operaci%n(que
es su signatura) pero nunca un conjunto de implementaciones de operaci%n.




Fig. 2.1: Clases

?rficamente una interfa" se representa con un c.rculo junto con su nom&re. Una interfa"
raramente es (nica. Mejor dic0o# esta es t.picamente agregada a las clases o componentes que
reali"an la interfa" como en la figura :.:
1pelling

Figura 2.2: Interfaz

Una colaboracin define una iteracci%n es una sociedad de roles otros elementos que
tra&ajan a la !e" para proporcionar algunas funciones cooperati!as que son maores que la suma
de todos los elementos. Una clase dada puede participar en di!ersas cola&oraciones. Estas
cola&oraciones representan la implementaci%n de patrones que integran un sistema.
?rficamente# una cola&oraci%n se representa con una elipse l.neas punteadas# usualmente
incluendo s%lo su nom&re# como en la figura :.;.


Fig. 2.3: Colaboraciones

Un caso de uso es una descripci%n de un conjunto de secuencias de acciones que un sistema
desempe2a para permitir un resultado de !alor o&ser!a&le para un actor particular. Un caso de
uso es usado para estructurar los elementos de comportamiento(&e0a!ioral) de un modelo.
?rficamente# un caso de uso se representa con una elipse de l.neas s%lidas# usualmente
incluendo s%lo su nom&re como en la fig. :.>.



Fig. 2.4: Casos de uso


Los tres Elementos restantes @ clases acti!as# componentes nodos@ son todas clases
semejantes en significado# ellos descri&en tam&i6n un conjunto de o&jetos que comparten los
mismos atri&utos# operaciones# relaciones semnticas. 1in em&argo estas tres son lo
suficientemente diferentes son necesarios para ciertos aspectos de modelado de un sistema
orientado a o&jetos.

Una clase acti!a es una clase cuos o&jetos reconocen uno o ms procesos o 0ilos por lo tanto
pueden iniciar una acti!idad de control. Una clase acti!a es semejante a una clase e$cepto que
sus o&jetos representan elementos cua funci%n es concurrente con otros elementos.
?rficamente una clase acti!a se representa semejante a una clase pero con l.neas ms anc0as#
usualmente incluendo su nom&re# atri&utos operaciones# como en la figura :.A.
Figura. 2.5: Clases activas

Los dos elementos restantes@ componente nodos@ son tam&i6n diferentes. Representan
Elementos f.sicos# tal como los cinco Elementos anteriores representan Elementos l%gicos o
conceptuales.

Un componente es un una parte f.sica reempla"a&le de un sistema que conforma proporciona
la reali"aci%n de un conjunto de interfaces. En un sistema encontrars diferentes tipos de
componentes de estructuraci%n# tal como componentes ,BM4 o 3a!a 5eans# adems de
componentes que son artefactos de procesos de desarrollo# tal como los arc0i!os de c%digo
fuente. Un componente t.picamente representa el empaquetado f.sico de diferentes elementos
l%gicos tal como clases# interfaces# cola&oraciones. ?rficamente# un componente es
representado por un rectngulo con pesta2as (ta&uladores)# usualmente incluendo s%lo su
nom&re como en la figura :.C

Fig. 2.6: Componentes


Un nodo es un elemento f.sico que e$iste al tiempo de ejecuci%n representa un recurso
computacional# generalmente tiene al menos una memoria frecuentemente capacidad de
procesamiento. Un conjunto de componentes puede residir en un nodo puede tam&i6n emigrar
de un nodo a otro. ?rficamente un nodo es representado por un cu&o incluendo usualmente
s%lo su nom&re como en la figura :.D.


Fig. 2.7: Nodos

Estos siete elementos @ clases# interfaces# cola&oraciones# casos de uso# clases acti!as#
componentes nodos @ son los Elementos estructurales &sicos que puedes incluir en un modelo
de UML. =a tam&i6n !ariaciones de estos siete# tal como actores# se2ales# utilidades (tipos de
clase)# procesos e 0ilos (T0reads# tipos de clases acti!as)# aplicaciones# documentos# arc0i!os#
li&rer.as# pginas ta&las(tipos de componentes).

Elemen#"s de c"mp"r#amien#" (&e0a!ioral)* 1on las partes dinmicas de los modelos UML.
Estos son los !er&os de un modelo que rerpesentan la funci%n so&re tiempo espacio. -e 0ec0o#
0a dos tipos principales de Elementos de comportamiento.
Una iteraccin es una funci%n que comprende un conjunto de intercam&io de mensajes entre un
conjunto de o&jetos con un conte$to particular para lograr un prop%sito espec.fico. La funci%n de
una asociaci%n de o&jetos o de una operaci%n indi!idual puede ser especificada con una
interacci%n. Una interacci%n in!olucra un n(mero de otros elementos incluendo mensajes#
secuencias de acci%n (la funci%n in!ocada por un mensaje)# ligas (la cone$i%n entre o&jetos).
?rficamente un mensaje se representa con una l.nea dirigida incluendo s%lo el nom&re de su
operaci%n. tal como en la figura :.E.

Fig. 2.: !ensa"es

Una mquina de estado es una funci%n que especifica la secuencia de estados de un o&jeto o
una interacci%n dada durante su tiempo de !ida en respuesta a e!entos# junto con las respuestas
de esos e!entos. La funci%n de una clase indi!idual o una cola&oraci%n de clases puede ser
especificada con una mquina de estados. Una mquina de estados in!olucra otros elementos
incluendo estados# transiciones(el flujo de un estado a otro)# e!entos acti!idades. ?rficamente
se representa con un rectngulo redondeado# incluendo usualmente su nom&re sus su&estados
si 0a alguno# como en la figura :.F.

Fig. 2.#: $stados.

Las mquinas de estado las interacciones son los o&jetos funcionales &sicos que puedes
incluir en UML. 1emnticamente# estos elementos estn usualmente conectados a !arios
elementos estructurales# principalmente clases# cola&oraciones o&jetos.

Elemen#"s de agrupamien#"* 1on las partes de organi"aci%n de los modelos UML. Estos son
cajas dentro de las cuales un modelo puede ser descompuesto. =a un tipo principal de
Elementos de agrupamiento nom&rados paquetes.
Un paquete es un mecanismo de prop%sito general para la organi"aci%n de elementos en grupos.
Los Elementos estructurales# funcionales aun los de agrupaci%n pueden estar situados dentro
de un paquete. A diferencia de los componentes (los cuales e$isten al tiempo de ejecuci%n) un
paquete es puramente conceptual (significa que e$iste durante el tiempo de desarrollo).
?rficamente un paquete se representa con un folder ta&ulado incluendo usualmente su nom&re
en ocasiones su contenido# como en la figura :@9G.


Fig. 2.1%: &a'uetes.
Los paquetes son los Elementos de agrupamiento &sicos con los cuales se puede organi"ar un
modelo de UML. =a !ariaciones# tal como 7rameworHs# modelos su&sistemas(tipos de
paquetes).

Elemen#"s an"#aci"nales* 1on las partes e$plicati!as de los modelos de UML. 1on los
comentarios que se pueden aplicar para descri&ir# iluminar remarcar algunos elementos de un
modelo. =a un tipo principal de Elementos anotacionales llamado nota. Una nota es
simplemente un s.m&olo para representar las limitaciones comentarios asociados a un elemento
o una colecci%n de elementos. ?rficamente una nota se representa con un rectngulo con una
esquina do&lada# junto con un comentario te$tual o grfico# como la figura :.99.
Fig. 2.11: Notas.


Relaci"nes en UML* 0a cuatro tipos de relaciones en UML*
9. -ependencias
:. Asociaci%n
;. ?enerali"aci%n
>. Reali"aci%n

Estas relaciones se usan para escri&ir modelos &ien formados.

Una dependencia es una relaci%n semntica entre dos Elementos tal que un cam&io en un t0ing
(el independiente) puede afectar al otro(el dependiente). ?rficamente una dependencia se
representa con una l.nea punteada posi&lemente dirigida ocasionalmente inclue una etiqueta
tal como en la figura :@9:.



Fig. 2.12: (ependencias


Una asociacin es una relaci%n estructural que descri&e un conjunto de ligas. Una liga es una
cone$i%n entre o&jetos.

Una agregacin es un tipo especial de asociaci%n que representa una relaci%n estructural entre
un todo sus partes. ?rficamente una asociaci%n es representada con una l.nea s%lida
posi&lemente dirigida# ocasionalmente inclue una etiqueta frecuentemente contiene otros
adornos tal como multiplicidad nom&res de roles como en la figura :@9;




$mplo)er emplo)ee

Fig. 2.13: *sociaciones


Una generalizacin es una relaci%n especiali"aci%n8generali"aci%n en la cual los o&jetos del
elemento especiali"ado(el 0ijo) son sustituidos por elementos del elemento generali"ado(el
padre). -e esta forma# el 0ijo comparte la estructura funci%n del padre. ?rficamente una
relaci%n de generali"aci%n es representada con una l.nea s%lida con una flec0a !ac.a 0acia el
padre como en la figura:@9>.


Fig. 2.14: +eneralizaciones

Una realizacin es una relaci%n semntica entre clasificadores(classifiers) donde un clasificador
especifica un contrato que otro clasificador garanti"a lle!ar a ca&o. Las relaciones de reali"aci%n
se encuentran en dos partes* entre interfaces las clases componentes que las reali"an entre
casos de uso las cola&oraciones que las reali"an. ?rficamente una relaci%n de reali"aci%n se
representa por un 0.&rido entre una relaci%n de generali"aci%n una de dependencia como en la
figura :@9A.
Fig. 2.1,: realizaci-n

-iagramas en UML* Un diagrama es la representaci%n grfica de un conjunto de elementos# ms
frecuentemente representados como una grfica conectada de !6rtices(o&jetos)
arcos(relaciones). Los diagramas se utili"an para !isuali"ar un sistema desde diferentes
perspecti!as. As.# un diagrama es una proecci%n de un sistema. Un diagrama representa un
panorama de los elementos que integran un sistema. Los mismos elementos pueden aparecer en
todos los diagramas# s%lo en una parte de los diagramas o en ninguno(raramente sucede). En
teor.a un diagrama puede contener alguna com&inaci%n de o&jetos relaciones. UML inclue
nue!e tipos de diagramas*
9. -iagramas de clases
:. -iagramas de o&jetos
;. -iagramas de casos de uso
>. -iagramas de secuencia
A. -iagramas de cola&oraci%n
C. -iagramas de estado
D. -iagramas de acti!idad
E. -iagramas de componente
F. -iagrama de estructuraci%n(deploment)
Un diagrama de clase muestra un conjunto de clases# interfaces cola&oraciones sus
relaciones. Estos diagramas son los ms comunes del modelado de sistemas orientados a
o&jetos. -ireccionan +ista de dise2o esttico del sistema.

Un diagrama de objeto muestra un conjunto de o&jetos relaciones. Representan instancias de
los o&jetos encontrados dentro de diagramas de clase. Estos diagramas direccionan +ista de
dise2o esttico o +ista de proceso esttico de un sistema tal como los diagramas de clase pero
desde la perspecti!a de casos reales o protot.pica.

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

Tanto los diagramas de secuencia colaboracin son tipos de diagramas de iteracci%n. Un
diagrama de iteraccin muestra una iteracci%n consistiendo de un conjunto de o&jetos sus
relaciones# incluendo los mensajes que pueden ser en!iados entre ellos. Los diagramas de
iteracci%n direccionan +ista dinmico de un sistema. Un diagrama de secuencia es un diagrama
de iteracci%n que enfati"a el ordenamiento del tiempo de mensajes< un diagrama de coleccin es
un diagrama de iteracci%n que enfati"a la organi"aci%n estructural de los o&jetos que en!.an
reci&en mensajes. Los diagramas de secuencia cola&oraci%n son isom%rficos# lo que significa
que t( puedes tomar uno transformarlo en el otro.

Un diagrama de estado muestra una mquina de estados que consiste de estados# transiciones#
e!entos acti!idades. -ireccionan +ista dinmico del sistema. 1on importantes para modelar el
desempe2o de una interfa"# clase o cola&oraci%n reacti!os de modelado enfati"a el desempe2o
ordenado de e!entos de un o&jeto el cual es especialmente usado en modelado de sistemas
reacti!os.

Un diagrama de actividad es un tipo especial de un diagrama de estado que muestra el flujo de
acti!idad de un sistema. -irecciona +ista dinmico de un sistema. 1on importantes para modelar
la funci%n de un sistema enfati"a el flujo de control de los o&jetos.

Un diagrama de componente muestra las organi"aciones dependencias de un conjunto de
componentes. Estos diagramas direccionan +ista de implementaci%n esttico. Estn
relacionados a diagramas de clases en donde un componente normalmente mapea uno o ms
clases# interfaces cola&oraciones.

Un diagrama de instalacin (deployment) muestra la configuraci%n de los nodos procesndose
al tiempo de ejecuci%n los componentes que ellos tienen. -ireccionan +ista de estructuraci%n
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 &loques de construcci%n no pueden ser modelados a la !e" en forma aleatoria. UML tiene un
conjunto de reglas que un modelo &ien formado de&e contemplar. Un modelo &ien formado es
aquel que es semnticamente consistente en s. mismo en armon.a con sus modelos
relacionados.

UML tiene reglas de semntica para*
/om&res *,%mo llamar a los Elementos# relaciones diagramas.
Alcance * El conte$to que da un significado espec.fico a un nom&re.
+isi&ilidad. ,%mo esos nom&res pueden ser !istos usados por otros.
Integridad* ,%mo los Elementos se relacionan adecuadamente consistentemente con
otros
Ejecuci%n* Ju6 significa correr simular un modelo dinmico.

Es com(n que un desarrollador construa no s%lo modelos que son &ien formados# sino
tam&i6n modelos que sean*

Bmitidos(Elided)* ciertos elementos son ocultos para simplificar +ista.
Incompletos* ,iertos elementos pueden ser ol!idados.
Inconsistentes* La integridad de un modelo no es garanti"ada.

Las reglas de UML te alientan# pero no for"an a direccionar los aspectos ms importantes
de anlisis# dise2o e implementaci%n para que los modelos lleguen a ser &ien 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.
9. Especificaciones
:. Adornos(Adornments)
;. -i!isiones comunes
>. Mecanismos de e$tensi&ilidad.

Especi!icaci"nes* UML es ms que un lenguaje grfico. Mejor dic0o# detrs de cada parte de su
notaci%n grfica 0a una especificaci%n que proporciona una declaraci%n te$tual de la sinta$is
semntica de los &loques de construcci%n. )or ejemplo# detrs de un icono de clase esta una
especificaci%n que proporciona el conjunto de operaciones# atri&utos funci%n que contempla la
clase.

Las especificaciones de UML proporcionan una semntica regresi!a que contiene todas las
partes de todos los modelos de un sistema# cada parte relacionada a otra en forma consistente.

Ad"rn"s* La maor.a de los elementos de UML tienen una notaci%n grfica dirigida (nica que
proporciona una representaci%n !isual de los aspectos ms importantes de los elementos. )or
ejemplo la figura :.9C muestra una clase adornada para indicar que es una clase a&stracta con
dos operaciones p(&licas# una protegida una pri!ada.



Fig. 2.16: *dornos.

Divisi"nes c"munes) En el modelado de sistemas orientados a o&jetos al menos se tienen dos
formas de di!isi%n.

)rimeramente# la di!isi%n de clases o&jetos. Una clase es una a&stracci%n< un o&jeto es una
manifestaci%n concreta de una a&stracci%n. En UML puedes modelar clases tan &ien como
o&jetos. ,ada &loque de construcci%n en UML tiene el mismo tipo de dicotom.a clase8o&jeto. )or
ejemplo# se pueden tener casos de usos sus instancias de casos de uso# componentes e
instancias de componentes# nodos e instancias de nodo as.. ?rficamente# el UML distingue un
o&jeto usando el mismo s.m&olo que su clase su&raando el nom&re del o&jeto como en la
figura :.9D.

Fig. 2.17:Clases ) ob"etos


1egundo# e$iste la separaci%n de interface e implementaci%n. Una interface declara un
contrato(de agregaci%n) una implementaci%n representa una reali"aci%n concreta de ese
contrato# responsa&le de lle!ar a ca&o fcilmente la semntica completa de la interfa". En UML se
puede modelar tanto las interfaces como sus implementaciones como en la figura :.9E.

en esta figura 0a dos componentes llamadas spellingwi"ard.dd que implementan dos interfaces#
IunHnown Ispelling.


Fig. 2.1: Interfaces e implementaciones

Mecanismos de e$tensi&ilidad* UML proporciona un lenguaje estndar para la escritura de
proectos de software. UML es un lenguaje a&ierto que 0ace posi&le que uno pueda e$tender en
forma controlada. Los mecanismos de e$tensi%n incluen*
Estereotipos
+alores de etiquetado(tagged)
Restricciones(constraints)

Un estereotipo e$tiende el !oca&ulario de UML permitiendo crear nue!os &loques de construcci%n
que son deri!ados de unos e$istentes pero que son espec.ficos para el pro&lema. )or ejemplo si
ests tra&ajando en un lenguaje de programaci%n como 3a!a frecuentemente querrs modelar
e$cepciones. En este lenguaje las e$cepciones son clases son tratadas en forma mu especial
en tus modelos son tratados como &loques de construcci%n &sicos se pueden 0acer con un
apropiado estereotipo.

Un valor de etiquetado e$tiende las propiedades de un &loque de construcci%n de UML#
permitiendo crear nue!a informaci%n de la especificaci%n de ese elemento.

Una restricci%n e$tiende la semntica de un &loque de construcci%n de UML# permitiendo
adicionar nue!as reglas o modificar algunas e$istentes.


Ar(ui#ec#ura

La !isuali"aci%n# especificaci%n construcci%n documentaci%n de un sistema de software
requiere que el sistema sea enfocado desde diferentes perspecti!as. -iferentes personas @
usuarios finales# analistas# desarrolladores# integradores del sistema# escritores t6cnicos
manejadores de proectos@ cada uno aporta diferentes agendas a un proecto cada uno !e el
sistema de diferentes formas# a diferente tiempo durante el ciclo de !ida del proecto. Una
arquitectura del sistema es qui"s el artefacto que puede ser usado para manejar los diferentes
puntos as. controlar el desarrollo iterati!o e incremental de un sistema durante su ciclo de !ida.

La arquitectura es el conjunto de decisiones significati!as acerca de*
La organi"aci%n de un sistema de software
La selecci%n de los elementos estructurales sus interfaces mediante las cuales se
compone el sistema.
1us funciones# especificada en la s cola&oraciones entre estos elementos.
La composici%n de estos elementos estructural funcionalmente para su&sistemas
progresi!amente ms largos.
El estilo de arquitectura que gu.a esta organi"aci%n* los elementos estticos dinmicos
sus interfaces# cola&oraciones composiciones.

La arquitectura de software no s%lo contempla la estructura desempe2o# sino tam&i6n usos#
funcionalidad# desempe2o# elasticidad# reuso# compresi&ilidad# contratos econ%micos
tecnol%gicos todo lo que concierne a est6tica.

En la figura :.9F se ilustra como la arquitectura de un sistema de software puede ser descrito
desde cuatro puntos de !ista. cada !ista es una proecci%n dentro de la organi"aci%n estructura
del sistema# enfocndose en general a aspectos de ese sistema.
Fig. 2.1#: !odelando la ar'uitectura del sistema

+ista de caso de uso de un sistema enfoca los casos de uso que descri&e el desempe2o del
sistema tal como lo !en los usuarios finales# analistas ensaistas. E$iste para especificar las
fuer"as que comparte la arquitectura de un sistema. En UML los aspectos estticos dentro de
este panorama son capturados en diagramas de caso de uso los dinmicos en este panorama
son capturados en diagramas de iteracci%n# de estado de acti!idad.
+ista de diseo de un sistema a&arca las clases# interfaces# cola&oraciones que forman el
!oca&ulario del pro&lema su soluci%n. Este panorama principalmente soporta los requerimientos
funcionales del sistema# es decir# los ser!icios que el sistema de&e proporcionar a sus usuarios.
En UML el aspecto esttico de este panorama es capturado en los diagramas de clases los de
o&jeto# el aspecto dinmico de este punto de !ista son capturados en los diagramas de
iteracci%n# diagramas de estado de acti!idad.

+ista de proceso de un sistema enfoca los 0ilos de control procesos que conforman los
mecanismos de concurrencia sincroni"aci%n. )rincipalmente# direcciona el desempe2o#
escala&ilidad duraci%n del sistema.

+ista de implementacin de un sistema comprende los componentes arc0i!os que son usados
para ensam&lar li&erar el sistema f.sico. Este panorama direcciona principalmente el manejo de
configuraci%n de la li&eraci%n del sistema. con UML el aspecto esttico de este panorama es
capturado en diagramas de componentes< el aspecto dinmico es capturado en los diagramas
de iteracci%n de estado acti!idad.

+ista de instalacin(deploment) de un sistema comprende los nodos forman la topolog.a de
0ardware del sistema dentro de las cuales el sistema se ejecuta. -irecciona principalmente la
distri&uci%n# entrega e instalaci%n de las partes que lle!a a ca&o el sistema f.sico. En UML el
aspecto esttico es capturado en los diagramas de estructura el dinmico en los diagramas de
iteracci%n# estado acti!idad.

Cicl" de vida del desarr"ll" del s"!#*are

El UML es un proceso independiente# lo que significa que no requiere un ciclo de !ida de
desarrollo de software particular. )ara o&tener los mejores &eneficios de UML se de&en
considerar un proceso que es*

Un manejado por casos de uso
,entrado en la arquitectura (enfocada a)
Iterati!o e incremental

Manejado por caso de uso significa que los casos de uso son usados principalmente como una
0erramienta para esta&lecer el funcionamiento deseado del sistema# para !erificaci%n
!alidaci%n de la arquitectura del sistema# prue&a comunicaci%n entre las personas del proecto.

Un proceso iterativo es aquel que in!olucra el manejo de un flujo de li&eraciones ejecuta&les. Un
proceso incremental es aquel que in!olucra la integraci%n continua de la arquitectura del sistema
para producir esos releases. ,on cada nue!o release se incluen mejoras incrementales so&re el
otro.

Este manejo de caso de uso# centrado en arquitectura los procesos iterati!os incrementales
pueden di!idirse en fases. Una fase es la duraci%n de tiempo dos clculos del proceso# cuando
un conjunto de o&jeti!os es conocido# los artefactos son completados las decisiones reali"adas
para lle!ar a ca&o la pr%$ima fase. =a cuatro fases en el ciclo de !ida del desarrollo del software*
,onceptuali"aci%n (inception)# ela&oraci%n# construcci%n transici%n.

La conceptualizacin es la primera fase del proceso# cuando se tiene la idea para el desarrollo
lle!a al punto lo suficientemente &ien fundamentado para garanti"ar por completo la fase de
ela&oraci%n.

La ela&oraci%n es cuando la !isi%n del producto su arquitectura son definidos. En este punto los
requerimientos del sistema son articulados# prioriti"ados referenciados.

La construccin es la fase cuando el proceso de software que lle!a a ca&o la arquitectura
ejecuta&le para que este lista para ser transportada al am&iente del usuario. Aqu. tam&i6n los
requerimientos del sistema su e!aluaci%n son constantemente ree$aminados.

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

You might also like