Diagramacin UML Lenguaje de Modelado UML Esta tesis introduce el Lenguaje Unificado de Modelado (UML), versin 1.1.

Analiza los diagramas ue com!onen UML " ofrece acercamientos a casos de uso guiados so#re cmo estos diagramas se usan !ara modelar sistemas. La tesis tam#i$n trata los mecanismos de e%tensi#ilidad de UML, los cuales !ermiten am!liar su notacin " su sem&ntica. 'am#i$n sugiere la e%tensin de UML mediante dos t$cnicas no incor!oradas( tarjetas )*) !ara an&lisis guiados !or la res!onsa#ilidad, " diagramas de Entidad de *elacin (E*) !ara modelar #ases de datos relacionales. A continuacin se descri#e de manera general el lenguaje de modelamiento UML " los mecanismos ue !resenta !ara su e%tensin. +ara a!render a usar UML adecuadamente se re uiere a!render tres elementos !rinci!ales( 1) los #lo ues de construccin #&sicos, ,) las reglas ue dicen como esos #lo ues de#en ser relacionados " -) algunos mecanismos ue se a!lican todo el tiem!o so#re el lenguaje. UML es un !roceso inde!endiente ue !timamente de#e ser usado en un !roceso ue es un manejador de caso de uso, con ar uitectura central, iterativa e incremental. UML !ermite ue se re!resente de manera semiformal la estructura general del sistema, con la ventaja de ue este mismo lenguaje !uede ser usado en todas las eta!as de desarrollo del sistema " su re!resentacin gr&fica !uede ser usada !ara comunicarse con los usuarios. La seccin tres !resenta una !ro!uesta !ara re!resentar las estructuras de ar uitectura utilizando UML, " en la seccin cuatro se muestran tra#ajos relacionados. +or .ltimo se !lantear&n las conclusiones de esta !ro!uesta de investigacin " las !osi#ilidades de tra#ajos futuros a !artir de ella. +or .ltimo se !lantear&n las conclusiones de esta !ro!uesta de investigacin " las !osi#ilidades de tra#ajos futuros a !artir de ella. UML es un lenguaje !ara /isualizar Es!ecificar )onstruir Documentar Los com!onentes de un sistema de soft0are e%tenso. UML se !uede usar !ara modelar distintos ti!os de sistemas( sistemas de soft0are, sistemas de 1ard0are, " organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas. 2 Diagramas de )asos de Uso !ara modelar los !rocesos. 2 Diagramas de 3ecuencia !ara modelar el !aso de mensajes entre o#jetos. 2 Diagramas de )ola#oracin !ara modelar interacciones entre o#jetos. 2 Diagramas de Estado !ara modelar el com!ortamiento de los o#jetos en el sistema. 2 Diagramas de Actividad !ara modelar el com!ortamiento de los )asos de Uso, o#jetos u o!eraciones. 2 Diagramas de )lases !ara modelar la estructura est&tica de las clases en el sistema. 2 Diagramas de 4#jetos !ara modelar la estructura est&tica de los o#jetos en el sistema. 2 Diagramas de )om!onentes !ara modelar com!onentes. 2 Diagramas de 5m!lementacin !ara modelar la distri#ucin del sistema. UML es una consolidacin de muc1as de las notaciones " conce!tos m&s utilizados en el dise6o de sistemas orientados a o#jetos.

Em!ez como una consolidacin del tra#ajo de 7rade 8ooc1, 9ames *um#aug1, e 5var 9aco#son, creadores de tres de las metodolog:as orientadas a o#jetos m&s !o!ulares. En 1;;<, el 4#ject Management 7rou! (4M7), un !ilar est&ndar !ara la comunidad del dise6o orientado a o#jetos, !u#lic una !eticin con !ro!sito de un metamodelo orientado a o#jetos de sem&ntica " notacin est&ndares. UML, en su versin 1.=, fue !ro!uesto como una res!uesta a esta !eticin en enero de 1;;>. ?u#o otras cinco !ro!uestas rivales. Durante el transcurso de 1;;>, los seis !romotores de las !ro!uestas, unieron su tra#ajo " !resentaron al 4M7 un documento revisado de UML, llamado UML versin 1.1. Este documento fue a!ro#ado !or el 4M7 en @oviem#re de 1;;>. El 4M7 llama a este documento 4M7 UML versin 1.1. El 4M7 est& actualmente en !roceso de mejorar una edicin t$cnica de esta es!ecificacin, !revista su finalizacin !ara el 1 de a#ril de 1;;;. UML Generalidades UML es un lenguaje gr&fico de modelamiento ue usa conce!tos de orientacin !or o#jetos. Este lenguaje tiene una sinta%is " una sem&ntica #ien definidas, sirviendo adem&s !ara todas las eta!as de desarrollo. En UML se utilizan !ara el modelamiento de un sistema diferentes elementos " relaciones, ue tienen una sem&ntica " sinta%is definidas. Estos elementos se agru!an en diagramas !reesta#lecidos ue corres!onden a diferentes !ro"ecciones del sistema. Los elementos #&sicos de UML, a uellos ue re!resentan !rinci!almente las !artes est&ticas del sistema, son( )lases )asos de uso )om!onentes @odos +a uetes Las relaciones ue se utilizan !ara esta#lecer cone%iones entre los elementos son( De!endencia Asociacin 7eneralizacin *ealizacin )ada uno de estos elementos " relaciones tiene una re!resentacin gr&fica " !uede com!lementarse su informacin utilizando lo ue se conoce como es!ecificacin. La es!ecificacin de un elemento o relacin generalmente no es visi#le en la re!resentacin gr&fica, o slo lo es !arcialmente, " corres!onde a los datos o !ro!iedades adicionales ue com!letan o detallan la sem&ntica del elemento o relacin, " !or lo tanto del sistema en general. Los elementos " relaciones se agru!an en diagramas ue re!resentan diferentes as!ectos del sistema. Los diagramas de UML son( Diagrama de clases: +resenta las clases, junto con sus atri#utos, o!eraciones, interfaces " relaciones. 'am#i$n !resenta el agru!amiento de clases en !a uetes " las relaciones entre ellos. Diagrama de objetos: Muestra instancias de clases (o#jetos) con valores en sus atri#utos " relaciones. Diagrama de casos de uso: Los escenarios de uso del sistema, inclu"endo los roles de los usuarios.

 Diagramas de interaccin: )om!rende los diagramas de secuencia " de cola#oracin. +resenta o#jetos " relaciones entre ellos desde el !unto de vista din&mico. Diagrama de estado: *e!resenta los !osi#les estados, eventos " transiciones entre las clases u o#jetos. Diagrama de componentes: 4rganizacin " de!endencia entre com!onentes f:sicos. Diagrama fsico (deployment): La distri#ucin " comunicacin de los com!onentes en los dis!ositivos de 1ard0are. La gran ventaja de UML es el 1ec1o de ue !oco a !oco se 1a venido ado!tando en diferentes medios em!resariales " acad$micos como el lenguaje Aest&ndarB !ara el an&lisis " dise6o de los sistemas de soft0are. 7racias a la !osi#ilidad de e%tender el UML " a la construccin de 1erramientas " metodolog:as ue a!o"an este lenguaje se 1a convertido en el est&ndar de facto en la actualidad !ara el modelamiento de los sistemas. Mecanismos de extensin UML tiene !rinci!almente tres mecanismos de e%tensin ue !ermiten construir nuevos elementos o modificar la sem&ntica de los "a e%istentes, !ara 1acer m&s !recisa la re!resentacin del sistema. Estos mecanismos son( 1. Valores Adicionados (tagged values)( Mediante estos valores es !osi#le adicionarle nuevas !ro!iedades o atri#utos a los elementos del modelo de UML. 2. Restricciones (constraints)( Las restricciones !ermiten adicionar nueva sem&ntica o modificar la e%istente. 3. Estereotipos( Los estereoti!os !ermiten crear nuevos elementos en el modelo #asados en otros "a e%istentes. )ada nuevo estereoti!o !uede reunir !ro!iedades (tagged values) " restricciones !articulares. A trav$s de estas e%tensiones es !osi#le enri uecer el modelo de UML !ara re!resentar adecuadamente los diferentes as!ectos del sistema. COMPONENTES 1. Casos de uso (componentes conceptuales) Un caso de uso re!resenta un re uerimiento funcional del sistema o un !roceso del negocio ue se im!lementa en el sistema de soft0are. *e!resentacin( 3e usa el mismo elemento Caso de Uso de UML 2. Actores Un actor es una !ersona, sistema o dis!ositivo ue interact.a con el sistema, iniciando, reci#iendo los resultados o !artici!ando en alguna de las acciones de un caso de uso. +or lo general re!resenta un rol, !or ejem!lo( jefe de conta#ilidad, !rofesor, etc. *e!resentacin( 3e usa el elemento Actor de UML. 3. Mdulos Un mdulo es una divisin conce!tual del sistema ue !uede ser visto como una agru!acin de funciones ue tengan alguna relacin entre ellas ", !or lo tanto, !uede !resentar un servicio com!leto al e%terior una vez se 1a desarrollado. *e!resentacin( Un modulo se re!resenta con el elemento Paquete de UML. . Clases Una clase es la re!resentacin a#stracta de un conjunto de o#jetos o artefactos ue de#e modelar el sistema.

)ada clase inclu"e las caracter:sticas " el com!ortamiento de los o#jetos ue re!resenta. Una clase !uede ser de ti!o interfaz (interact.a con el e%terior), control (realiza o!eraciones " controla otras clases) u entidad (1ace !ersistentes los datos). !. Unidades de "o#t$are )onjunto de funciones (en !rogramas o !rocedimientos) ue realizan las acciones del sistema " ue se im!lementan en arc1ivos f:sicos. Las unidades de soft0are tienen asociado un ti!o (valor adicionado), ue !uede ser( filtro, !rocedimental, o#jetos, re!ositorio de datos activo u otro. *e!resentacin( 3e usa el elemento Componente de %. "istemas e&ternos Un sistema e%terno re!resenta un sistema de la organizacin ue interact.a con el sistema ue se est& desarrollando. +or ejem!lo, el sistema de conta#ilidad (si se est& desarrollando el de recursos 1umanos). *e!resentacin( 3e crear& un estereoti!o !ara re!resentar a este com!onente. El estereoti!o, llamado !terno, est& #asado en el elemento com!onente de UML. '. (erramientas de so#t$are 3istemas o !rogramas ue contri#u"en al adecuado funcionamiento del sistema. +or ejem!lo, el sistema o!erativo, un !rograma navegador de 5nternet, la m& uina virtual de java, etc. *e!resentacin( 3e crea el estereoti!o "erram, #asado en el elemento com!onente de UML ). *rocesador Este com!onente re!resenta un com!utador (!rocesador " memoria) donde se localizan !rogramas o datos " donde, !or lo general, se corren dic1os !rogramas. Este !rocesador !uede tener roles como servidor, cliente, terminal, etc. Adem&s, !uede esta#lecerse su u#icacin f:sica (ciudad o &rea de la organizacin) !ara com!lementar la informacin de este com!onente. *e!resentacin( 3e usa el elemento #odo de UML. +. ,ispositi-o El dis!ositivo es un com!onente o elemento de 1ard0are ue !resenta una interaccin con el sistema. +or ejem!lo, un medidor de !resin, un terminal de com!utadores o un mdem. *e!resentacin( 3e crea un estereoti!o Dispos #asado en elemento nodo de UML. Len.ua/e de Modelado Uni#icado cap0tulo 1 C+or u$ Modelamos1 En este cap0tulo La im!ortancia del modelado. )uatro !rinci!ios del modelado. Lo fundamental de los ante!ro"ectos de un sistema de soft0are. Modelado orientado a o#jetos. La importancia del Modelado Modelar es !ro#ar, es una t$cnica #ien a!ro#ada en la ingenier:a. 3e constru"e el modelo de una casa !ara tener una vista !revia del !roducto final. 3e constru"en modelos matem&ticos !ara analizar los efectos de los vientos o terremotos en las construcciones. "i construimos... Una casa !ara el !erro. 3lo necesitaremos unos cuantos materiales " !ocas 1erramientas. +ro#a#lemente no necesitemos modelar.

Un edificio de 1== !isos. @ecesitaremos muc1os materiales, muc1as 1erramientas " a"uda de muc1as !ersonas. 3i necesitamos modelar. 23ue es entonces un modelo1 Un modelo es una sim!lificacin de la realidad. Un modelo !ro!orciona un ante!ro"ecto del sistema. Es una a#straccin de la realidad. Es una !ro"eccin a micro escala. De!ende del conte%to. 2*or 4u5 de6emos modelar1 !ara entender mejor el !ro#lema ue estamos desarrollando. A trav$s del modelado nosotros alcanzamos cuatro !untos( 1. A"uda a visualizar como es el sistema. ,. @os a"uda a es!ecificar la conducta de la estructura del sistema. -. Da una gu:a #ase !ara la construccin del sistema. D. Documenta las decisiones ue de#emos tomar. *rincipios del modelado +rimero Escoger el modelo ue tenga una !rofunda influencia en cmo enfocar el !ro#lema " la forma de solucin. Ejem!lificacin 3i se nos !ide utilizar un lenguaje como 9ava un modelo recomendado !or omisin es el 44. 3egundo 'odos los modelos de#en !oder ser e%!resados en diferentes niveles de !recisin. Ejem!lo( 3i se est& constru"endo un edificio, necesitamos una distancia de muc1os metros !ara visualizar el o#jeto. +ero si deseamos ver slo un de!artamento del edificio la distancia visual se acorta. De igual manera sucede con el soft0are. 'ercero El mejor modelo est& conectado a la realidad. Ejem!lificacin Un modelo f:sico ue no corres!onde de igual manera a la realidad tiene valor limitado. Un modelo de un avin ue asume slo condiciones ideales " !erfecta manufactura, !uede tener fatales errores en el avin real. En el soft0are esto !or ejem!lo, se re!resenta cuando 1a" una descone%in entre el an&lisis " el dise6o. )uarto Un modelo sim!le no es suficiente. Es mejor modelar, sistemas no triviales !or un conjunto !e ue6o de modelos casi inde!endientes. Ejem!lificacin 3i construimos un edificio, los !lanos, es!ecificaciones " ma uetas no son un conjunto de modelos aislados. +or ejem!lo los !lanos el$ctricos, 1idr&ulicos, etc., en un !ro"ecto de ingenier:a civil, no son inde!endientes sino ue tienen ue estar :ntegramente relacionados unos con otros. Modelado en in.enier0a ci-il

La ingenier:a civil constru"e muc1os ti!os de modelos. Estos modelos civiles !or lo general son est&ticos " sirven a la gente !ara visualizar !artes del sistema. De!endiendo del &rea de la ingenier:a, estos !ueden ser tam#i$n modelos din&micos. )ada ti!o de modelo est& organizado de manera diferente " tiene un enfo ue !ro!io. Modelado de so#t$are En el soft0are, se tienen varios caminos !ara acercase al modelo. Los dos caminos m&s comunes, son la !ers!ectiva de los algoritmos " la !ers!ectiva de la orientacin a o#jetos. Modelado con al.oritmos En la tradicional vista del modelado de soft0are, se toma la !ers!ectiva de los algoritmos. La construccin !rinci!al de todo el soft0are es la funcin " el !roceso, " el modelado se 1ace como la descom!osicin en funciones. El mantenimiento de estos sistemas es dif:cil de realizar. Modelado con o6/etos Una vista contem!or&nea del modelado de soft0are toma la !ers!ectiva de la orientacin a o#jetos. En esta !ers!ectiva el #lo ue !rinci!al de todo el sistema de soft0are es la clase " el o#jeto. Un o#jeto re!resenta una a#straccin del !ro#lema a solucionar. La clase es la descri!cin del conjunto de o#jetos similares. 'odos los o#jetos tienen una identidad, un estado " un com!ortamiento. La orientacin a o#jetos es una forma !rinci!al del modelado de soft0are. La orientacin a o#jetos !ro!orciona los conce!tos fundamentales !ara ensam#lar sistemas usando tecnolog:as como 9A/A )4ME. 8lo ues de construccin de UML El voca#ulario de UML ue com!rende tres ti!os de #lo ues de construccin( 1. Elementos ()osas) ,. de *elacin -. Diagramas. Elementos en UML( ?a" cuatro ti!os de Elementos en UML( 1. Estructurales ,. De com!ortamiento (#e1avioral) -. De Agru!amiento D. Anotaciones. Estructurales( Los lementos estructurales, son los sustantivos de los modelos de UML. Estos son en la ma"or:a !artes est&ticas de un modelo, re!resentando elementos ue o #ien conce!tuales o f:sicos. ?a" siete ti!os de elementos estructurales. 1. clase ,. interfaz -. cola#oracin D. caso de uso F. clases activas <. com!onentes >. nodos

Una clase es una descri!cin de un conjunto de o#jetos ue com!arten los mismos atri#utos, o!eraciones, relaciones " sem&nticas. Una clase lleva a ca#o una o m&s interfaces. 7r&ficamente, una clase es re!resentada con un rect&ngulo, usualmente inclu"endo su nom#re, atri#utos " o!eraciones, como en la figura ,.1. Una interfaz es una coleccin de o!eraciones ue es!ecifican un servicio de una clase o com!onente. As:, una interfaz descri#e el desem!e6o e%ternamente visi#le de ese o#jeto. Una interfaz !uede re!resentar el funcionamiento com!leto de una clase o com!onente o solo una !arte de ese desem!e6o. Una interfaz define un conjunto de es!ecificaciones de o!eracin ( ue es su signatura) !ero nunca un conjunto de im!lementaciones de o!eracin.

Fig. 2.1: Clases 7r&ficamente una interfaz se re!resenta con un c:rculo junto con su nom#re. Una interfaz raramente es .nica. Mejor dic1o, esta es t:!icamente agregada a las clases o com!onentes ue realizan la interfaz como en la figura ,., 3!elling Figura 2.2: nter!a" Una colaboracin define una iteracin " es una sociedad de roles " otros elementos ue tra#ajan a la vez !ara !ro!orcionar algunas funciones coo!erativas ue son ma"ores ue la suma de todos los elementos. Una clase dada !uede !artici!ar en diversas cola#oraciones. Estas cola#oraciones re!resentan la im!lementacin de !atrones ue integran un sistema. 7r&ficamente, una cola#oracin se re!resenta con una eli!se l:neas !unteadas, usualmente inclu"endo slo su nom#re, como en la figura ,.-.

Fig. 2.#: Cola$oraciones Un caso de uso es una descri!cin de un conjunto de secuencias de acciones ue un sistema desem!e6a !ara !ermitir un resultado de valor o#serva#le !ara un actor !articular. Un caso de uso es usado !ara estructurar los elementos de com!ortamiento(#e1avioral) de un modelo. 7r&ficamente, un caso de uso se re!resenta con una eli!se de l:neas slidas, usualmente inclu"endo slo su nom#re como en la fig. ,.D.

Fig. 2.%: Casos de uso Los tres Elementos restantes G clases activas, com!onentes " nodosG son todas clases semejantes en significado, ellos descri#en tam#i$n un conjunto de o#jetos ue com!arten los mismos atri#utos, o!eraciones, relaciones " sem&nticas. 3in em#argo estas tres son lo suficientemente diferentes " son necesarios !ara ciertos as!ectos de modelado de un sistema orientado a o#jetos. Una clase activa es una clase cu"os o#jetos reconocen uno o m&s !rocesos o 1ilos " !or lo tanto !ueden iniciar una actividad de control. Una clase activa es semejante a una clase e%ce!to ue sus o#jetos re!resentan elementos cu"a funcin es concurrente con otros elementos. 7r&ficamente una clase activa se re!resenta semejante a una clase !ero con l:neas m&s anc1as, usualmente inclu"endo su nom#re, atri#utos " o!eraciones, como en la figura ,.F. Figura. 2.&: Clases acti'as Los dos elementos restantesG com!onente " nodosG son tam#i$n diferentes. *e!resentan Elementos f:sicos, tal como los cinco Elementos anteriores re!resentan Elementos lgicos o conce!tuales. Un componente es un una !arte f:sica " reem!laza#le de un sistema ue conforma " !ro!orciona la realizacin de un conjunto de interfaces. En un sistema encontrar&s diferentes ti!os de com!onentes de estructuracin, tal como com!onentes )4ME o 9ava 8eans, adem&s de com!onentes ue son artefactos de !rocesos de desarrollo, tal como los arc1ivos de cdigo fuente. Un com!onente t:!icamente re!resenta el em!a uetado f:sico de diferentes elementos lgicos tal como clases, interfaces, " cola#oraciones. 7r&ficamente, un com!onente es re!resentado !or un rect&ngulo con !esta6as (ta#uladores), usualmente inclu"endo slo su nom#re como en la figura ,.<

Fig. 2.(: Com)onentes Un nodo es un elemento f:sico ue e%iste al tiem!o de ejecucin " re!resenta un recurso com!utacional, generalmente tiene al menos una memoria " frecuentemente ca!acidad de !rocesamiento. Un conjunto de com!onentes !uede residir en un nodo " !uede tam#i$n emigrar de un nodo a otro. 7r&ficamente un nodo es re!resentado !or un cu#o inclu"endo usualmente slo su nom#re como en la figura ,.>.

Fig. 2.*: Nodos Estos siete elementos G clases, interfaces, cola#oraciones, casos de uso, clases activas, com!onentes " nodos G son los Elementos estructurales #&sicos ue !uedes incluir en un modelo de UML. ?a" tam#i$n variaciones de estos siete, tal como actores, se6ales, " utilidades (ti!os de clase), !rocesos e 1ilos ('1reads, ti!os de clases activas), " a!licaciones, documentos, arc1ivos, li#rer:as, !&ginas " ta#las (ti!os de com!onentes). Elementos de comportamiento (#e1avioral)( 3on las !artes din&micas de los modelos UML. Estos son los ver#os de un modelo ue re!resentan la funcin so#re tiem!o " es!acio. De 1ec1o, 1a" dos ti!os !rinci!ales de Elementos de com!ortamiento. 1. iteracin ,. de estado Una iteracin es una funcin ue com!rende un conjunto de intercam#io de mensajes entre un conjunto de o#jetos con un conte%to !articular !ara lograr un !ro!sito es!ec:fico. La funcin de una asociacin de o#jetos o de una o!eracin individual !uede ser es!ecificada con una interaccin. Una interaccin involucra un n.mero de otros elementos inclu"endo mensajes, secuencias de accin (la funcin invocada !or un mensaje), ligas (la cone%in entre o#jetos). 7r&ficamente un mensaje se re!resenta con una l:nea dirigida inclu"endo slo el nom#re de su o!eracin. 'al como en la figura ,.H.

Fig. 2.+: Mensa,es Una m$quina de estado es una funcin ue es!ecifica la secuencia de estados de un o#jeto o una interaccin dada durante su tiem!o de vida en res!uesta a eventos, junto con las res!uestas de esos eventos. La funcin de una clase individual o una cola#oracin de clases !uede ser es!ecificada con una m& uina de estados. Una m& uina de estados involucra otros elementos inclu"endo estados, transiciones(el flujo de un estado a otro), eventos " actividades. 7r&ficamente se re!resenta con un rect&ngulo redondeado, inclu"endo usualmente su nom#re " sus su#estados si 1a" alguno, como en la figura ,.;.

Fig. 2.-: Estados. Las m& uinas de estado " las interacciones son los o#jetos funcionales #&sicos ue !uedes incluir en UML. 3em&nticamente, estos elementos est&n usualmente conectados a varios elementos estructurales, !rinci!almente clases, cola#oraciones " o#jetos. Elementos de a.rupamiento( 3on las !artes de organizacin de los modelos UML. Estos son cajas dentro de las cuales un modelo !uede ser descom!uesto. ?a" un ti!o !rinci!al de elemento de agru!amiento( 1. !a uete. Un paquete es un mecanismo de !ro!sito general !ara la organizacin de elementos en gru!os. Los Elementos estructurales, funcionales " aun los de agru!acin !ueden estar

situados dentro de un !a uete. A diferencia de los com!onentes (los cuales e%isten al tiem!o de ejecucin) un !a uete es !uramente conce!tual (significa ue e%iste durante el tiem!o de desarrollo). 7r&ficamente un !a uete se re!resenta con un folder ta#ulado inclu"endo usualmente su nom#re " en ocasiones su contenido, como en la figura ,G1=.

Fig. 2.1.: Pa/uetes. Los !a uetes son los Elementos de agru!amiento #&sicos con los cuales se !uede organizar un modelo de UML. ?a" variaciones, tal como Irame0orJs, modelos " su#sistemas (ti!os de !a uetes). Elementos de anotacin( 3on las !artes e%!licativas de los modelos de UML. 3on los comentarios ue se !ueden a!licar !ara descri#ir, iluminar " remarcar algunos elementos de un modelo. ?a" un ti!o !rinci!al de elemento de anotacin 1. la nota. Una nota es sim!lemente un s:m#olo !ara re!resentar las limitaciones " comentarios asociados a un elemento o una coleccin de elementos. 7r&ficamente una nota se re!resenta con un rect&ngulo con una es uina do#lada, junto con un comentario te%tual o gr&fico, como la figura ,.11. Fig. 2.11: Notas. Relaciones en UML( 1a" cuatro ti!os de relaciones en UML( 1. De!endencias ,. Asociacin -. 7eneralizacin D. *ealizacin Estas relaciones se usan !ara escri#ir modelos #ien formados. Una dependencia es una relacin sem&ntica entre dos Elementos tal ue un cam#io en un t1ing (el inde!endiente) !uede afectar al otro (el de!endiente). 7r&ficamente una de!endencia se re!resenta con una l:nea !unteada !osi#lemente dirigida " ocasionalmente inclu"e una eti ueta tal como en la figura ,G1,.

Fig. 2.12: 0e)endencias

Una asociacin es una relacin estructural ue descri#e un conjunto de ligas. Una liga es una cone%in entre o#jetos. Una agregacin es un ti!o es!ecial de asociacin ue re!resenta una relacin estructural entre un todo " sus !artes. 7r&ficamente una asociacin es re!resentada con una l:nea slida !osi#lemente dirigida, ocasionalmente inclu"e una eti ueta " frecuentemente contiene otros adornos tal como multi!licidad " nom#res de roles como en la figura ,G1-

Em)lo1er em)lo1ee Fig. 2.1#: 2sociaciones Una generali%acin es una relacin es!ecializacinKgeneralizacin en la cual los o#jetos del elemento es!ecializado (el 1ijo) son sustituidos !or elementos del elemento generalizado(el !adre). De esta forma, el 1ijo com!arte la estructura " funcin del !adre. 7r&ficamente una relacin de generalizacin es re!resentada con una l:nea slida con una flec1a vac:a 1acia el !adre como en la figura,G1D.

Fig. 2.1%: Generali"aciones Una reali%acin es una relacin sem&ntica entre clasificadores (classifiers) donde un clasificador es!ecifica un contrato ue otro clasificador garantiza llevar a ca#o. Las relaciones de realizacin se encuentran en dos !artes( entre interfaces " las clases com!onentes ue las realizan " entre casos de uso " las cola#oraciones ue las realizan. 7r&ficamente una relacin de realizacin se re!resenta !or un 1:#rido entre una relacin de generalizacin " una de de!endencia como en la figura ,G1F. Fig. 2.1&: reali"acin Diagramas en UML( Un diagrama es la re!resentacin gr&fica de un conjunto de elementos, m&s frecuentemente re!resentados como una gr&fica conectada de v$rtices (o#jetos) " arcos(relaciones). Los diagramas se utilizan !ara visualizar un sistema desde diferentes !ers!ectivas. As:, un diagrama es una !ro"eccin de un sistema. Un diagrama re!resenta un !anorama de los elementos ue integran un sistema. Los mismos elementos !ueden a!arecer en todos los diagramas, slo en una !arte de los diagramas o en ninguno(raramente sucede). En teor:a un diagrama !uede contener alguna com#inacin de o#jetos " relaciones. UML inclu"e nueve ti!os de diagramas(

1. Diagramas de clases ,. Diagramas de o#jetos -. Diagramas de casos de uso D. Diagramas de secuencia F. Diagramas de cola#oracin <. Diagramas de estado >. Diagramas de actividad H. Diagramas de com!onente ;. Diagrama de estructuracin(de!lo"ment) Un diagrama de clase muestra un conjunto de clases, interfaces " cola#oraciones " sus relaciones. Estos diagramas son los m&s comunes del modelado de sistemas orientados a o#jetos. Direccionan /ista de dise6o est&tico del sistema. Un diagrama de objeto muestra un conjunto de o#jetos " relaciones. *e!resentan instancias de los o#jetos encontrados dentro de diagramas de clase. Estos diagramas direccionan a /ista de dise6o est&tico o /ista de !roceso est&tico de un sistema tal como los diagramas de clase !ero desde la !ers!ectiva de casos reales o de un !rototi!o. Un diagrama de caso de uso muestra un conjunto de casos de uso " actores (un ti!o es!ecial de clases) " sus relaciones. Un diagrama de caso direcciona /ista de caso de uso est&tica de un sistema. 'anto los diagramas de secuencia " colaboracin son ti!os de diagramas de iteracin. Un diagrama de iteracin muestra una iteracin consistiendo de un conjunto de o#jetos " sus relaciones, inclu"endo los mensajes ue !ueden ser enviados entre ellos. Los diagramas de iteracin direccionan /ista din&mico de un sistema. Un diagrama de secuencia es un diagrama de iteracin ue enfatiza el ordenamiento del tiem!o de mensajesL un diagrama de coleccin es un diagrama de iteracin ue enfatiza la organizacin estructural de los o#jetos ue env:an " reci#en mensajes. Los diagramas de secuencia " cola#oracin son isomrficos, lo ue significa ue t. !uedes tomar uno " transformarlo en el otro. Un diagrama de estado muestra una m& uina de estados ue consiste de estados, transiciones, eventos " actividades. Direccionan /ista din&mico del sistema. 3on im!ortantes !ara modelar el desem!e6o de una interfaz, clase o cola#oracin reactivos de modelado " enfatiza el desem!e6o ordenado de eventos de un o#jeto el cual es es!ecialmente usado en modelado de sistemas reactivos. Un diagrama de acti&idad es un ti!o es!ecial de un diagrama de estado ue muestra el flujo de actividad de un sistema. Direcciona /ista din&mico de un sistema. 3on im!ortantes !ara modelar la funcin de un sistema " enfatiza el flujo de control de los o#jetos. Un diagrama de componente muestra las organizaciones " de!endencias de un conjunto de com!onentes. Estos diagramas direccionan /ista de im!lementacin est&tico. Est&n relacionados a diagramas de clases en donde un com!onente normalmente ma!ea uno o m&s clases, interfaces " cola#oraciones.

Un diagrama de instalacin (deployment) muestra la configuracin de los nodos !roces&ndose al tiem!o de ejecucin " los com!onentes ue ellos tienen. Direccionan /ista de estructuracin est&tico de una ar uitectura. Est&n relacionados a diagramas de com!onentes, en donde un nodo normalmente contiene a uno o m&s com!onentes. Re.las de UML Los #lo ues de construccin no !ueden ser modelados a la vez en forma aleatoria. UML tiene un conjunto de reglas ue un modelo #ien formado de#e contem!lar. Un modelo #ien formado es a uel ue es sem&nticamente consistente en s: mismo " en armon:a con sus modelos relacionados. UML tiene reglas de sem&ntica !ara( @om#res ()mo llamar a los Elementos, relaciones " diagramas. Alcance ( El conte%to ue da un significado es!ec:fico a un nom#re. /isi#ilidad. )mo esos nom#res !ueden ser vistos " usados !or otros. 5ntegridad( )mo los Elementos se relacionan adecuadamente " consistentemente con otros Ejecucin( Mu$ significa correr " simular un modelo din&mico. Es com.n ue un desarrollador constru"a no slo modelos ue son #ien formados, sino tam#i$n modelos ue sean( 4mitidos(Elided)( ciertos elementos son ocultos !ara sim!lificar /ista. 5ncom!letos( )iertos elementos !ueden ser olvidados. 5nconsistentes( La integridad de un modelo no es garantizada. Las reglas de UML te alientan, !ero no forzan a direccionar los as!ectos m&s im!ortantes de an&lisis, dise6o e im!lementacin !ara ue los modelos lleguen a ser #ien formados con res!ecto al tiem!o. Mecanismos comunes de UML UML cuenta con cuatro mecanismos comunes ue se a!lican consistentemente todo el tiem!o en el lenguaje. Es!ecificaciones Adornos(Adornments) Divisiones comunes Mecanismos de e%tensi#ilidad. Especi#icaciones( UML es m&s ue un lenguaje gr&fico. Mejor dic1o, detr&s de cada !arte de su notacin gr&fica 1a" una es!ecificacin ue !ro!orciona una declaracin te%tual de la sinta%is " sem&ntica de los #lo ues de construccin. +or ejem!lo, detr&s de un icono de clase esta una es!ecificacin ue !ro!orciona el conjunto de o!eraciones, atri#utos " funcin ue contem!la la clase.

Las es!ecificaciones de UML !ro!orcionan una sem&ntica regresiva ue contiene todas las !artes de todos los modelos de un sistema, cada !arte relacionada a otra en forma consistente. Adornos( La ma"or:a de los elementos de UML tienen una notacin gr&fica dirigida " .nica ue !ro!orciona una re!resentacin visual de los as!ectos m&s im!ortantes de los elementos. +or ejem!lo la figura ,.1< muestra una clase adornada !ara indicar ue es una clase a#stracta con dos o!eraciones !.#licas, una !rotegida " una !rivada.

Fig. 2.1(: 2dornos. ,i-isiones comunes7 En el modelado de sistemas orientados a o#jetos al menos se tienen dos formas de divisin. +rimeramente, la divisin de clases " o#jetos. Una clase es una a#straccinL un o#jeto es una manifestacin concreta de una a#straccin. En UML !uedes modelar clases tan #ien como o#jetos. )ada #lo ue de construccin en UML tiene el mismo ti!o de dicotom:a claseKo#jeto. +or ejem!lo, se !ueden tener casos de usos " sus instancias de casos de uso, com!onentes e instancias de com!onentes, nodos e instancias de nodo " as:. 7r&ficamente, el UML distingue un o#jeto usando el mismo s:m#olo ue su clase " su#ra"ando el nom#re del o#jeto como en la figura ,.1>.

Fig. 2.1*:Clases 1 o$,etos 3egundo, e%iste la se!aracin de interface e im!lementacin. Una interface declara un contrato(de agregacin) " una im!lementacin re!resenta una realizacin concreta de ese contrato, res!onsa#le de llevar a ca#o f&cilmente la sem&ntica com!leta de la interfaz. En UML se !uede modelar tanto las interfaces como sus im!lementaciones como en la figura ,.1H. en esta figura 1a" dos com!onentes llamadas s!elling0izard.dd ue im!lementan dos interfaces, 5unJno0n " 5s!elling.

Fig. 2.1+: nter!aces e im)lementaciones

Mecanismos de e%tensi#ilidad( UML !ro!orciona un lenguaje est&ndar !ara la escritura de !ro"ectos de soft0are. UML es un lenguaje a#ierto ue 1ace !osi#le ue uno !ueda e%tender en forma controlada. Los mecanismos de e%tensin inclu"en( Estereoti!os /alores de eti uetado(tagged) *estricciones(constraints) Un estereotipo e%tiende el voca#ulario de UML !ermitiendo crear nuevos #lo ues de construccin ue son derivados de unos e%istentes !ero ue son es!ec:ficos !ara el !ro#lema. +or ejem!lo si est&s tra#ajando en un lenguaje de !rogramacin como 9ava frecuentemente uerr&s modelar e%ce!ciones. En este lenguaje las e%ce!ciones son clases " son tratadas en forma mu" es!ecial en tus modelos son tratados como #lo ues de construccin #&sicos " se !ueden 1acer con un a!ro!iado estereoti!o. Un &alor de etiquetado e%tiende las !ro!iedades de un #lo ue de construccin de UML, !ermitiendo crear nueva informacin de la es!ecificacin de ese elemento. Una restriccin e%tiende la sem&ntica de un #lo ue de construccin de UML, !ermitiendo adicionar nuevas reglas o modificar algunas e%istentes. Ar4uitectura La visualizacin, es!ecificacin construccin " documentacin de un sistema de soft0are re uiere ue el sistema sea enfocado desde diferentes !ers!ectivas. Diferentes !ersonas G usuarios finales, analistas, desarrolladores, integradores del sistema, escritores t$cnicos " manejadores de !ro"ectosG cada uno a!orta diferentes agendas a un !ro"ecto " cada uno ve el sistema de diferentes formas, a diferente tiem!o durante el ciclo de vida del !ro"ecto. Una ar uitectura del sistema es uiz&s el artefacto ue !uede ser usado !ara manejar los diferentes !untos " as: controlar el desarrollo iterativo e incremental de un sistema durante su ciclo de vida. La ar uitectura es el conjunto de decisiones significativas acerca de( La organizacin de un sistema de soft0are La seleccin de los elementos estructurales " sus interfaces mediante las cuales se com!one el sistema. 3us funciones, es!ecificada en la s cola#oraciones entre estos elementos. La com!osicin de estos elementos estructural " funcionalmente !ara su#sistemas !rogresivamente m&s largos. El estilo de ar uitectura ue gu:a esta organizacin( los elementos est&ticos " din&micos sus interfaces, cola#oraciones " com!osiciones. La ar uitectura de soft0are no slo contem!la la estructura " desem!e6o, sino tam#i$n usos, funcionalidad, desem!e6o, elasticidad, reuso, com!resi#ilidad, contratos econmicos " tecnolgicos " todo lo ue concierne a est$tica.

En la figura ,.1; se ilustra como la ar uitectura de un sistema de soft0are !uede ser descrito desde cuatro !untos de vista. cada vista es una !ro"eccin dentro de la organizacin " estructura del sistema, enfoc&ndose en general a as!ectos de ese sistema. Fig. 2.1-: Modelando la ar/uitectura del sistema /ista de caso de uso de un sistema enfoca los casos de uso ue descri#e el desem!e6o del sistema tal como lo ven los usuarios finales, analistas " ensa"istas. E%iste !ara es!ecificar las fuerzas ue com!arte la ar uitectura de un sistema. En UML los as!ectos est&ticos dentro de este !anorama son ca!turados en diagramas de caso de uso " los din&micos en este !anorama son ca!turados en diagramas de iteraccin, de estado " de actividad. /ista de dise'o de un sistema a#arca las clases, interfaces, " cola#oraciones ue forman el voca#ulario del !ro#lema " su solucin. Este !anorama !rinci!almente so!orta los re uerimientos funcionales del sistema, es decir, los servicios ue el sistema de#e !ro!orcionar a sus usuarios. En UML el as!ecto est&tico de este !anorama es ca!turado en los diagramas de clases " los de o#jeto, el as!ecto din&mico de este !unto de vista son ca!turados en los diagramas de iteraccin, diagramas de estado " de actividad. /ista de proceso de un sistema enfoca los 1ilos de control " !rocesos ue conforman los mecanismos de concurrencia " sincronizacin. +rinci!almente, direcciona el desem!e6o, escala#ilidad " duracin del sistema. /ista de implementacin de un sistema com!rende los com!onentes " arc1ivos ue son usados !ara ensam#lar " li#erar el sistema f:sico. Este !anorama direcciona !rinci!almente el manejo de configuracin de la li#eracin del sistema. con UML el as!ecto est&tico de este !anorama es ca!turado en diagramas de com!onentesL " el as!ecto din&mico es ca!turado en los diagramas de iteraccin de estado " actividad. /ista de instalacin(de!lo"ment) de un sistema com!rende los nodos forman la to!olog:a de 1ard0are del sistema dentro de las cuales el sistema se ejecuta. Direcciona !rinci!almente la distri#ucin, entrega e instalacin de las !artes ue lleva a ca#o el sistema f:sico. En UML el as!ecto est&tico es ca!turado en los diagramas de estructura " el din&mico en los diagramas de iteraccin, estado " actividad. Ciclo de -ida del desarrollo del so#t$are El UML es un !roceso inde!endiente, lo ue significa ue no re uiere un ciclo de vida de desarrollo de soft0are !articular. +ara o#tener los mejores #eneficios de UML se de#en considerar un !roceso ue es( Un manejado !or casos de uso )entrado en la ar uitectura (enfocada a) 5terativo e incremental Manejado !or caso de uso significa ue los casos de uso son usados !rinci!almente como una 1erramienta !ara esta#lecer el funcionamiento deseado del sistema, !ara verificacin "

validacin de la ar uitectura del sistema, !rue#a " comunicacin entre las !ersonas del !ro"ecto. Un proceso iterati&o es a uel ue involucra el manejo de un flujo de li#eraciones ejecuta#les. Un !roceso incremental es a uel ue involucra la integracin continua de la ar uitectura del sistema !ara !roducir esos releases. )on cada nuevo release se inclu"en mejoras incrementales so#re el otro. Este manejo de caso de uso, centrado en ar uitectura " los !rocesos iterativos incrementales !ueden dividirse en fases. Una fase es la duracin de tiem!o dos c&lculos del !roceso, cuando un conjunto de o#jetivos es conocido, los artefactos son com!letados " las decisiones realizadas !ara llevar a ca#o la !r%ima fase. ?a" cuatro fases en el ciclo de vida del desarrollo del soft0are( )once!tualizacin (ince!tion), ela#oracin, construccin " transicin. La conceptuali%acin es la !rimera fase del !roceso, cuando se tiene la idea !ara el desarrollo lleva al !unto lo suficientemente #ien fundamentado !ara garantizar !or com!leto la fase de ela#oracin. La ela#oracin es cuando la visin del !roducto es definida as: como su ar uitectura. En este !unto los re uerimientos del sistema son articulados, tienen su !rioridad " son referenciados. La construccin es la fase cuando el !roceso de soft0are ue lleva a ca#o la ar uitectura ejecuta#le !ara ue este lista !ara ser trans!ortada al am#iente del usuario. A u: tam#i$n los re uerimientos del sistema " su evaluacin son constantemente ree%aminados. La transicin es la fase donde el soft0are es turnado a las manos del usuario. Durante esta fase el sistema es continuamente mejorado.