Hora 1 - Introduccin a UML La finalidad de los diagramas es presentar diversas perspectivas de un sistema, las cuales se conocen como modelo.

UML describe lo que har el sistema, pero no cmo lo har. Diagrama de clases: las cosas que nos rodean tienen atributos y realizan acciones y estn categorizadas. Estas categor as se llaman clases. Una clase es una categor a o un grupo de cosas que tienen atributos y acciones similares.

Los diagramas de clases facilitan las representaciones a partir de las cuales los desarrolladores podrn traba!ar. " su vez, colaboran con el anlisis, permitiendo hablar con los clientes en su propia terminolog a, lo que hace que ellos puedan detallar me!or los problemas a resolver. Diagrama de objetos: un ob!eto es una instancia de una clase, tiene valores espec ficos para los atributos y las acciones. #e diferencia de la clase en que el nombre se subraya. El nombre de la instancia se encuentra a la izquierda de los dos puntos $%& y el nombre de la clase a la derecha.

Diagrama de casos de uso: un caso de uso es una descripcin de las acciones de un sistema desde el punto de vista del usuario. 'ermite obtener los requerimientos del sistema desde el punto de vista del usuario.

" la figura correspondiente al usuario se lo conoce como actor. La elipse representa el caso de uso. El actor, que es quien inicia el caso de uso, puede ser una persona o un sistema.

Diagrama de estados: en cualquier momento, un ob!eto se encuentra en un estado particular. El s mbolo que est en la parte superior de la figura representa el estado inicial y el de la parte inferior el estado final.

Diagrama de secuencias: los diagramas de clases y ob!etos presentan informacin esttica. El diagrama de secuencia muestra la mecnica de la interaccin con base en el tiempo. El diagrama de secuencia captura las interacciones que se realizan a trav(s del tiempo.

Diagrama de actividades: las actividades que ocurren dentro de un caso de uso o dentro del comportamiento de un ob!eto se dan secuencialmente.

Diagrama de colaboraciones: los elementos de un sistema traba!an en con!unto para cumplir con los ob!etivos.

Diagrama de componentes: est ntimamente ligado con el mundo de los sistemas informticos. El desarrollo de soft)are se realiza mediante componentes, lo que es importante en los procesos de desarrollo en equipo.

Diagramas de distribucin: muestra la arquitectura f sica de un sistema informtico, representando los equipos, dispositivos, intercone*iones y el soft)are que hay en cada mquina.

Otras caractersticas: a!uetes: permiten mostrar que ciertas clases o componentes son parte de un subsistema en particular.

"otas: son el equivalente grfico de un papel adherente. 'ermiten e*plicar me!or alguna parte del diagrama.

#stereotipos: permiten tomar elementos propios del UML y convertirlos en otros. #e representan con un nombre entre dos pares de mayor y menor $++ ,,& y despu(s se los aplica correctamente. E!emplo% interfaz. La interfaz es una clase que tiene operaciones pero no atributos. #on acciones que seguro se usan mucho en el modelo. Entonces, en vez de inventar un nuevo elemento para la interfaz, se usa el s mbolo de una clase con ++-nterfaz,, situada !usto sobre el nombre de la clase.

La diversidad de diagramas nos permite tener variados y amplios puntos de vistas y modelos del sistema, lo que nos beneficia al tener muchas ms perspectivas y poder abarcar me!or el problema. Los sistemas pueden estar modelados con un subcon!unto de los diagramas, no hace falta que est(n todos.

Hora $ - Orientacin a Objetos Es una metodolog a basada en componentes donde se genera un sistema mediante un con!unto de ob!etos, el cual luego podremos ampliar y modificar, agregando nuevos componentes. Esto nos permite reutilizar los ob!etos y reducir sustancialmente el tiempo de desarrollo. Objeto: es una instancia de una clase. .iene una estructura formada por atributos y acciones. Las acciones son actividades que el ob!eto realiza. Las clases sirven como plantilla para fabricar ob!etos.

El propsito de la orientacin a ob!etos es desarrollar soft)are que refle!e particularmente $que modele& un esquema del mundo. "lgunos conceptos% %bstraccin: es quitar las propiedades y acciones de un ob!eto para de!ar solo aquellas que son necesarias. /ependiendo del tipo de problema, requeriremos ms o menos informacin. En cualquier caso, lo que tendremos luego de tomar la decisin de lo que se incluir o desechar, ser una abstraccin del problema. Herencia: 0omo instancia de una clase, un ob!eto tiene todas las caracter sticas de la clase que proviene. 0a!a ob!eto hereda los atributos y operaciones de dicha clase. Un ob!eto no solo hereda de una clase, sino que una clase tambi(n puede heredar de otra. Esto genera !erarqu as de clases con subclases y superclases. 0ada subclase puede ser superclase tambi(n y viceversa.

olimor&ismo: #e refiere a la posibilidad de acceder a un variado rango de funciones distintas a trav(s del mismo interfaz. Es decir, que una operacin tenga el mismo nombre en diferentes clases y en cada caso har algo diferente. 0ada clase 1sabe2 cmo realizar dicha operacin. .ambi(n tenemos la sobrecarga que implica que una

misma funcin $mismo nombre& haga distintas cosas seg3n los argumentos que se le pasen o seg3n el ob!eto que la llame. El polimorfismo ayuda no slo al programador, sino tambi(n al modelador, quien podr comunicarse con el cliente en sus propias palabras, manteniendo una terminolog a sin tener que crear palabras artificiales para sustentar una unicidad innecesaria en los t(rminos. #ncapsulamiento: se refiere a la capacidad de agrupar y condensar en un entorno con l mites bien definidos distintos elementos. Es decir, cada ob!eto encapsula lo que hace, la funcionalidad interna. Esto permite reducir los errores potenciales, ya que cuando un ob!eto falla y hay que modificarlo, el ocultamiento podr a evitarnos tener que modificar otros ob!etos. 'ese a esto, todos los ob!etos deben presentar interfaces al mundo e*terior para poder interactuar. Esto se logra con el env o de mensa!es, que es cuando un ob!eto env a a otro un mensa!e para realizar una operacin y el receptor la e!ecuta4 o con las asociaciones, que son distintos tipos de relaciones que tienen entre s los ob!etos. Estas pueden ser% Unidireccionales o bidireccionales, dependiendo de qu( tipo de relacin tengan los ob!etos. Una clase se puede asociar con ms de una clase distinta. La multiplicidad es importante, ya que indica la cantidad de ob!etos de una clase que se relacionan con otro ob!eto de la clase asociada.

%gregacin: Es un tipo de asociacin donde un ob!eto est constituido por diversos tipos de componentes. 'omposicin: Es un tipo de agregacin especial, donde el componente se considera como tal slo como parte del ob!eto compuesto. Un ob!eto compuesto puede no tener el mismo tiempo de vida que sus componentes.

Hora ( - Uso de la orientacin a objetos Las clases se representan con un rectngulo. El nombre de la misma se escribe con una palabra con la primera letra en may3scula y se coloca en la parte superior del rectngulo. #i el nombre de la clase tiene 5 palabras, se unen y se inicia cada una con may3scula.

El paquete puede !ugar un papel en el nombre de la clase.

El par de dos puntos $%& separa al nombre del paquete, que est a la izquierda, del nombre de la clase que va a la derecha.

%tributos: #on propiedades de una clase y describen un rango de valores que dicha propiedad puede contener en los ob!etos. Una clase puede tener varios o ning3n atributo. #i el nombre del atributo es una sola palabra, se indica en min3scula. #i tiene ms de una, cada palabra se une a la anterior y comienza con una may3scula, a e*cepcin de la primera palabra.

.odo ob!eto de la clase tiene un valor espec fico en cada atributo. El nombre de un ob!eto se inicia con una letra min3scula y est precedido de dos puntos que a su vez estn precedidos del nombre de la clase y todo el nombre est subrayado.

UML da la opcin de indicar informacin adicional de los atributos. #e puede especificar un tipo para cada valor del atributo, usando los dos puntos para separar el nombre del atributo de su tipo. .ambi(n se puede indicar un valor predeterminado para el atributo.

Operaciones: Es algo que la clase puede realizar o que un usuario o sistema puede hacer a una clase. #u nombre se escribe en min3scula si tiene una sola palabra. #i tiene ms, se unen y se inician todas con may3scula e*cepto la primera.

En los par(ntesis que preceden al nombre de la operacin, se pueden mostrar los parmetros con los que funciona, as como el tipo de dato. .ambi(n se puede mostrar el tipo de valor que regresa.

%tributos) operaciones * concepcin 0uando se diagrama, se coloca ms de una clase a la vez. 'or ello, no siempre es 3til que se vean todos los atributos y operaciones, lo cual har a muy saturado al diagrama. 'or lo tanto podemos mostrar slo el nombre de la clase y de!ar vac as las reas de atributos u operaciones.

.ambi(n pueden mostrarse solo algunos atributos u operaciones, indicando luego de esa lista tres puntos suspensivos $6&, lo que nos genera una clase abreviada.

#i la lista de atributos y operaciones es larga, se pueden usar estereotipos para organizarla de manera que sea ms comprensible. Esto se indica con el nombre bordeado por dos pares de mayor y menor $++ ,,&.

+esponsabilidades * restricciones: 'odemos agregar otra informacin en cada clase. /eba!o de las operaciones, podemos mostrar la responsabilidad de la clase, es decir, una descripcin de lo que hace, lo que sus atributos y operaciones realizan en con!unto.

La idea de esto es incluir informacin suficiente para describir una clase de manera inequ voca. .ambi(n e*isten las restricciones, que especifican una o varias reglas que sigue la clase. #e indican con un te*to bordeado por llaves.

"otas adjuntas: 'or encima y deba!o de los atributos, operaciones, responsabilidades y restricciones, puede agregar mayor informacin a una clase con las notas ad!untas.

Estas notas pueden contener imgenes y te*to ,u- .acen las clases * cmo encontrarlas Las clases son el vocabulario y terminolog a de un rea del conocimiento. En las reuniones con los clientes, prestar atencin a los sustantivos que usan para describir las entidades. .ambi(n a los verbos, que se convertirn en operaciones. Los atributos surgen como sustantivos relacionados con los nombres de las clases. .ambi(n debemos preguntar qu( es lo que cada clase hace dentro del negocio. Estas respuestas nos indicarn la responsabilidad de cada clase.

Hora / - Uso de relaciones Las relaciones son las cone*iones entre las clases y su representacin. %sociaciones: es cuando las clases se conectan entre s de forma conceptual. #e representa con una l nea que conecta ambas clases con el nombre de la asociacin sobre la l nea. #e debe indicar la direccin de la relacin con un tringulo relleno que apunte a la direccin apropiada.

0uando una clase se asocia con otra, cada una de ellas !uega un papel dentro de la asociacin. Estos papeles se representan escribi(ndolos cerca de la l nea que se encuentra !unto a la clase que !uega el papel correspondiente.

La asociacin puede funcionar en direccin inversa. Esto se representa indicando ambas asociaciones en el diagrama con un tringulo relleno en cada direccin.

.ambi(n varias clases se pueden conectar a una.

7estricciones en las asociaciones% se indican !unto a la l nea de asociacin colocando la palabra entre llaves.

8tro tipo de restriccin es la relacin 8 $8r& en una l nea discontinua que conecta a dos l neas de asociacin.

0lases de asociacin% una asociacin puede tener atributos y operaciones, de manera de ser tratada como una clase estndar. #e usa una l nea discontinua para conectarla a la l nea de asociacin. Una clase de asociacin puede tener asociaciones con otras clases.

9 nculos% son instancias de una asociacin. 0onecta dos ob!etos en lugar de dos clases. #e debe subrayar el nombre del v nculo, como se hace en el nombre de un ob!eto.

Multiplicidad: Es la cantidad de ob!etos de una clase que se relacionan con un ob!eto de la clase asociada. #e colocan los n3meros sobre la l nea de asociacin !unto a la clase correspondiente.

.ipos de multiplicidad%

UML usa un asterisco para representar ms y para representar muchos. En un conte*to 8 $8r& se representa por dos puntos como en :..; $uno o ms&. En otro conte*to, 8 $8r& se representa por una coma, como en <,:= $cinco o diez&. 0uando la clase " tiene una multiplicidad de uno a ninguno o uno con la clase >, se dice que > es opcional para la clase ". %sociaciones cali&icadas: cuando un ob!eto de una clase tiene que buscar un ob!eto en particular de otro tipo para cumplir con un papel en la asociacin, la primera clase debe atenerse a un atributo en particular para localizar al ob!eto adecuado. Este atributo suele es un identificador que puede ser un n? de identidad. Esta informacin de identidad se llama calificador. El s mbolo es un peque@o rectngulo ad!unto a la clase que har la b3squeda.

%sociaciones re&le0ivas: asociacin de una clase consigo misma. Esto puede ocurrir cuando una clase tiene ob!etos que pueden !ugar diversos papeles. #e representa mediante una l nea de asociacin que sale y llega a la misma clase y sobre la l nea indicamos papeles, nombre, direccin y multiplicidad.

Herencia * 1enerali2acin: #urge del conocimiento que tenemos de una categor a de cosas, de donde deducimos algunas cosas que se pueden transferir a otras categor as. Aerencia o generalizacin es cuando una clase $secundaria o subclase& hereda los atributos y operaciones de otra clase $principal o superclase&. La clase principal es ms gen(rica que la secundaria. /onde quiera que hagamos referencia a la superclase, tambi(n referenciamos a la subclase, pero no viceversa. Una subclase puede ser superclase de otra subclase. En UML la herencia se representa con una l nea que conecte la superclase con laBlas subclases. En la parte de la l nea que se conecta con la clase principal, se coloca un tringulo sin rellenar que apunte a la misma. La relacin que se aplica para la herencia es 1es un tipo de2.

/escubrimiento de la herencia% Las clases candidatas que descubramos con los clientes pueden incluir tanto las superclases como las subclases. /ebemos darnos cuenta que los atributos y operaciones de una clase son generales y se pueden aplicar a varias clases. .ambi(n podemos notar que dos o ms clases tienen ciertos atributos y operaciones en com3n.

0lases abstractas% #on clases que no proporcionan ninguna instancia al modelo. Co proveen ob!etos. #e representan con el nombre en cursiva.

Dependencias: es cuando una clase usa a otra. El uso ms com3n es mostrar que la firma de la operacin de una clase utiliza a otra clase. #e representa con una l nea discontinua con una punta de flecha en forma de tringulo sin relleno que apunta a la clase de la que depende.

Hora 3 - %gregacin) composicin) inter&aces * reali2acin %gregacin: es cuando una clase consta de otras clases. Los componentes y la clase que constituyen son una asociacin que conforma un todo. #e representa como una !erarqu a dentro de la clase completa en la parte superior y los componentes por deba!o de ella. Una l nea conecta el todo con un componente mediante un rombo sin relleno que se coloca en la l nea ms cercana al todo.

7estricciones% #e puede establecer esta relacin dentro de una relacin 8 $8r&. #e indica la palabra 8 $8r& dentro de llaves con una l nea discontinua que conecte las dos l neas que conforman al todo.

'omposicin: es un tipo muy representativo de agregacin, donde cada componente dentro de una composicin slo puede pertenecer al todo. #e indica igual que la agregacin, pero con el rombo relleno.

'onte0to: cuando modelamos sistemas y surgen las relaciones anteriores, debemos enfocar la atencin en qu( grupo es y el diagrama de conte*to nos dar las caracter sticas del modelo que se requiera para tal fin. Las composiciones figuran en gran medida dentro de los diagramas de conte*to. Este diagrama es como un mapa detallado de alguna seccin de un mapa mayor. 'ueden necesitarse varias secciones para capturar la informacin detallada. Este diagrama muestra cmo los componentes estn relacionados entre s . Un diagrama de conte*to de composicin muestra los componentes de una clase como un diagrama anidado dentro de un enorme rectngulo de clase.

'ara mostrar el todo de la composicin en el conte*to mayor que lo abarca, hay que ampliar el mbito. Un diagrama de conte*to del sistema lo har por nosotros. #e muestra la forma en que la clase compuesta se conecta con las otras clases.

#e puede ver de cerca alguna otra clase y presentar sus detalles en otro diagrama de conte*to.

Inter&aces * reali2aciones: 0uando deseemos contar con alg3n medio para capturar todas las operaciones reutilizables del modelo, debemos usar una interfaz. La interfaz es la estructura de UML que nos permite hacer esto. Una interfaz es un con!unto de operaciones que especifica cierto aspecto de la funcionalidad de una clase y es un con!unto de operaciones que una clase presenta a otras. La interfaz puede establecer un subcon!unto de las operaciones de una clase y no necesariamente todas ellas. 'odemos modelar la interfaz igual que una clase, con un s mbolo rectangular. La diferencia es que la interfaz no tiene atributos. Las maneras de distinguir una interfaz de una clase que no muestra sus atributos son usando un estereotipo y especificando la palabra ++interfaz,, en el rectngulo, o colocar la letra D-E al principio del nombre de una interfaz. La relacin entre una clase y una interfaz se conoce como realizacin. Esta relacin se representa con una l nea discontinua con una punta de flecha en forma de tringulo sin rellenar que ad!unte y apunte a la interfaz.

Una clase puede realizar ms de una interfaz y una interfaz puede ser realizada por ms de una clase. 9isibilidad% se aplica a atributos y operaciones de una clase y define en qu( medida otras clases pueden usarlos $tambi(n aplicado a operaciones de interfaz& Aay tres niveles% '3blico% la funcionalidad se e*tiende a otras clases. Usa el s mbolo 45 'rotegido% la funcionalidad se otorga solo a las clases que heredan de la clase original. Usa el s mbolo 65 'rivado% solo la clase original puede usar la funcionalidad. Usa el s mbolo -5

La realizacin implica que el nivel p3blico se aplique a cualquier operacin en una interfaz. Fmbito% hay dos tipos% /e instancia% cada instancia cuenta con su propio valor en un atributo u operacin. Es el mbito ms com3n. "rchivado% solo hay un valor del atributo u operacin en todas las instancias de clase. "parece con el nombre subrayado. #e usa cuando un grupo espec fico de instancias tienen que compartir los valores de un atributo privado.

Hora 7 - Introduccin a los casos de uso Es importante la visin del usuario, comprender su punto de vista es clave para generar sistemas que sean 3tiles y funcionales. Esto implica que cumplan con los requerimientos y que sea fcil traba!ar con ellos. El modelado del sistema desde la perspectiva del usuario es el traba!o de los casos de uso. ,u- son los casos de uso El anlisis del caso de uso permite preguntar cmo se usar el producto o sistema que se va a comprar, de manera de que se obtenga algo que cumpla con las necesidades. Lo importante es saber cules son los requerimientos. La forma en que los usuarios usan el sistema nos da la pauta para dise@ar y crear. El caso de uso es una estructura que ayuda al analista a traba!ar con los usuarios para determinar la forma en que se usar un sistema. 0aso de uso% es una coleccin de situaciones respecto al uso de un sistema. 0ada situacin describe una secuencia de eventos que se inician por una persona, sistema, parte de hard)are o por el paso del tiempo. Las entidades que inician las secuencias se llaman actores. El resultado de la secuencia es algo utilizable, tanto por el actor que la inici o por otro. Importancia de los casos de uso5 #irven para estimular a que los usuarios hablen de un sistema desde su punto de vista. .ambi(n involucran a los usuarios en las etapas iniciales del anlisis y dise@o del sistema. Esto aumenta la probabilidad de que el sistema sea de mayor provecho para la gente a la que ayudar. Inclusin de los casos de uso " veces es com3n distinguir pasos en com3n en las distintas secuencias. 'odemos eliminar esta duplicacin, tomando cada secuencia com3n y conformando un caso de uso adicional a partir de ellos. 0on estos nuevos casos de uso, los casos de los que derivan los incluyen dentro de la secuencia. #0tensin de los casos de uso Es posible reutilizar un caso de uso de manera distinta a la inclusin. 'odemos crear un caso de uso agregndole algunos pasos a un caso de uso e*istente. Este nuevo caso de uso es una e*tensin del original. Inicio del an8lisis de un caso de uso :. Entrevistas a los clientes para armar los diagramas de clase. Esto nos dar cierta idea del rea de traba!o y una familiaridad con los t(rminos que usaremos. 5. Entrevistas a los usuarios para que nos indiquen qu( es lo que ellos har an con el sistema. #us respuestas conformaran el con!unto candidato de casos de uso. G. /escribimos brevemente cada caso y derivamos una lista de todos los actores que iniciarn y se beneficiar

Los casos de uso aparecern en varias fases del desarrollo y nos ayudarn con el dise@o de una interfaz de usuario, con la programacin y establecern las bases para probar el sistema generado.

Hora 9 - Diagramas de casos de uso Una de las finalidades del proceso de anlisis es generar una coleccin de casos de uso. La idea es poder catalogar y referenciar dicha coleccin, que es el punto de vista del usuario acerca del sistema. +epresentacin de un modelo de caso de uso Un actor inicia el caso de uso y otro $puede ser el mismo& recibir algo de valor de (l. #e representa con una elipse al caso de uso y una figura agregada al actor. El que inicia se indica a la izquierda del caso de uso y el que recibe a la derecha. El nombre del actor aparece deba!o de la figura y el del caso de uso adentro de la elipse o !usto aba!o. Una l nea asociativa conecta al actor con el caso de uso y representa la comunicacin entre ambos. >eneficios% los casos de uso muestran los confines del sistema. Heneralmente los actores estn fuera del sistema y los casos de uso adentro. #e usar un rectngulo con el nombre del sistema para representar los confines del mismo. El rectngulo envuelve los casos de uso.

:ecuencia de pasos en los escenarios 0ada caso de uso es una coleccin de escenarios y cada escenario una secuencia de pasos. 0ada diagrama tendr su propia pgina, de igual manera, cada escenario tendr su pgina, donde se listar% El actor que inicia el caso de uso 0ondiciones previas para el caso de uso 'asos en el escenario 0ondiciones posteriores cuando se finaliza el escenario El actor que se beneficia del caso de uso

.ambi(n podemos enumerar las con!eturas del escenario y una breve descripcin de una sola frase sobre el mismo. Escenarios alternativos% 'odemos incluir los mismos de manera separada o considerarlos como e*cepciones al primer escenario del caso de uso. 'oncepcin de las relaciones entre casos de uso -nclusin% volver a usar los pasos de un caso de uso dentro de otro. #e representa usando el s mbolo que usamos para la dependencia entre clases% una l nea discontinua con una punta de flecha que conecta los casos de uso apuntando al caso de uso incluido. #obre la l nea se agrega un estereotipo con la palabra ++incluir,,. En la notacin de te*to que sigue los pasos de la secuencia, indicamos los casos de uso incluidos.

E*tensin% 0rear un caso de uso adicionando pasos a uno e*istente, llamado caso de uso bsico o base. La e*tensin solo se puede realizar en puntos indicados de manera espec fica en la secuencia. Estos puntos se llaman puntos de extensin.

#e representa igual que la inclusin, pero con el estereotipo que muestra ++e*tender,,. /entro del caso de uso bsico, el punto de e*tensin aparece deba!o del nombre del caso de uso.

Heneralizacin% Es cuando un caso de uso hereda las acciones y significado del primario y adems agrega sus propias acciones. #e puede aplicar el caso de uso secundario en cualquier lugar donde apliquemos el primario. #e representa con una l nea discontinua con una punta de flecha en forma de tringulo sin rellenar que apunta al caso de uso primario.

Esta relacin puede establecerse entre actores tambi(n.

"grupamiento% Cos permite organizar y categorizar los casos de uso cuando tenemos, por e!emplo, muchos subsistemas dentro del sistema. La forma ms directa de organizarlos es agrupar los casos de uso en un paquete.

Diagramas de casos de uso en el proceso de an8lisis Las entrevistas con los usuarios comienzan en la terminolog a del dominio, pero deben alternarse con la terminolog a del usuario. El resultado inicial contendr los actores y casos de uso de alto nivel que describen los requerimientos funcionales en t(rminos generales, para definir los confines y el mbito del sistema. Las entrevistas posteriores profundizarn estos requerimientos y nos dar por resultado modelos de casos de uso que mostrarn los escenarios y las secuencias detalladamente. Esto puede generar nuevos casos de uso que satisfagan las relaciones de inclusin y e*tensin. #i no logramos comprender bien el dominio, crearemos demasiados casos de uso con demasiados detalles. %plicacin de los modelos de caso de uso 0omprensin del dominio% Entrevistar al cliente para crear el diagrama de clases.

0omprensin de los usuarios% enfocar a los usuarios para entender los tipos de funcionalidad para crear en el sistema. 'odremos mostrar a los usuarios en una !erarqu a de generalizacin.

0omprensin de los casos de uso% diagramas de aso de uso de alto nivel.

'rofundizacin% #e generan los modelos para cada caso de uso. En base a las entrevistas, indicaremos cuntos pasos se necesitan en casa caso de uso. #e analiza cada caso de uso y se detalla su modelo.

Dnde estamos Elementos estructurales% clases, ob!etos actores, interfaces, casos de uso son elementos estructurales de UML. .odos representan partes f sicas o conceptuales de un modelo. 7elaciones% asociacin, generalizacin, dependencia y realizacin son las relaciones en UML $inclusin y e*tensin son tipos de dependencia&. #in relaciones los modelos ser an solo listas. Las relaciones conectan los elementos entre s y conectan los modelos con la realidad. "grupamiento% el paquete es el 3nico elemento de agrupamiento en UML. Cos permite organizar los elementos. 'uede contener cualquier tipo de elemento y diferentes tipos tambi(n. "notacin% La nota es un elemento que nos permite ad!untar restricciones, comentarios, requerimientos y grficos a los modelos. E*tensin% los estereotipos nos permiten e*tender el lengua!e, creando nuevos elementos adems de los e*istentes, para modelar de manera adecuada la seccin de la realidad que nos ocupa.

anorama

Hora ; < Diagramas de estados "l contrario de los elementos anteriores, veremos ahora los elementos de comportamiento, que muestran la forma en que las partes de un modelo cambian con el tiempo. 0onforme el sistema interact3a con los usuarios y otros sistemas, los ob!etos pasan por cambios necesarios para a!ustarse a esas interacciones. ,u- es un diagrama de estados Es un diagrama que captura los cambios de estado de los ob!etos como consecuencia de ciertos sucesos o del paso del tiempo. 'resenta los estados en los que puede estar un ob!eto y las transiciones entre ellos, as como el punto inicial y final de una secuencia de cambio de estado. Este diagrama presenta las condiciones de un solo ob!eto, no varios. #imbolog a% rectngulo de v(rtices redondeados que representa un estado, una l nea continua y una punta de flecha que representan la transicin. La flecha apunta al estado siguiente. El c rculo relleno simboliza el punto inicial y el c rculo con un punto el final.

"dicin de detalles al cono de estado% podemos dividir el rectngulo en G. El rea superior contiene el nombre del estado, que debe aparecer siempre. El rea central, contiene las variables de estado y el rea inferior las actividades.

Las variables que sirvan de cronmetro o contadores, son 3tiles. Las actividades constan de sucesos y acciones. Las ms usadas son entrada% qu( pasa cuando el sistema entra al estado, salida% que pasa cuando el sistema sale del estado y hacer% qu( pasa cuando el sistema est en el estado. 'ueden agregarse otros.

#ucesos y acciones% se agregan a la l nea de transicin. 'odemos indicar un suceso que provoca una transicin $la desencadena& y la actividad de cmputo $accin& que se e!ecuta y hace que se modifique el estado. #e representan cerca de la l nea de transicin mediante una diagonal para separar un suceso desencadenado de una accin. Una transicin no desencadenada es aquella en la cual un evento la causa sin una accin asociada o cuando una transicin se da porque un estado finaliza una actividad. La interfaz grfica de usuario $HU-& con la que interactuamos, nos dar e!emplos de estos detalles de transicin, en este y los siguientes cap tulos. La HU- puede establecerse en G estados% Iniciali2acin) operacin * apagar5

0ondiciones de seguridad% se dan cuando ha pasado cierto tiempo sin que haya interaccin con el usuario. La HU- hace una transicin del estado 8peracin a otro estado. #e define como una e*presin booleana.

:ubestados 0uando un ob!eto est en estado 8peracin, hay muchas cosas que ocurren detrs, aunque no sean evidentes. 'or e!emplo, la HU- espera constantemente que el usuario haga algo. Luego registra tales acciones y modifica lo que se presenta en pantalla. 0on esto, la HU- atraviesa varios cambios mientras est en operacin, estos cambios don de estado y como estn dentro de un estado, se conocen como subestados. Aay dos tipos% #ecuenciales% suceden uno detrs de otro. En el caso de la HU- ser a% " la espera de la accin del usuario, registro de la accin, representacin de la accin. Luego de la secuencia la HU- vuelve a 1" la espera de accin del usuario2.

0oncurrentes% puede suceder, que adems de la secuencia indicada arriba, la HU- haga otras cosas $por e!emplo, verificar el cronmetro del sistema y actualizar la aplicacin luego de un tiempo&. "mbas secuencias son concurrentes entre s . Esto se representa con una l nea discontinua entre los estados concurrentes.

El estado Operacin, es un estado compuesto, ya que consta slo de subestados secuenciales. #stados .istricos Un estado compuesto recuerda su subestado activo cuando el ob!eto trasciende fuera del estado compuesto. El s mbolo es la letra 1A2 encerrada en un c rculo conectada con una l nea continua al subestado por recordar, con una flecha que apunta a dicho subestado.

0uando un estado histrico recuerda los subestados en todos los niveles de anidacin, se denomina profundo. #i slo recuerda el subestado principal, se llama superficial. Uno profundo se representa agregando un ; a la 1A2 en el c rculo. El estado histrico y el inicial, son conocidos como pseudoestados, porque no tienen variables de estado ni actividades. Mensajes * se=ales Los ob!etos se comunican mediante env o de mensa!es. En el e!emplo, el suceso que desencadena es un mensa!e de un ob!eto $usuario& a otro $la HU-&. Un ob!eto que desencadena una transicin se denomina seal. En orientacin a ob!etos, enviar una se@al es igual a crear un ob!eto se@al y transmitirlo al ob!eto receptor. El ob!eto se@al puede tener atributos y se puede crear una !erarqu a de herencia de se@ales. or!u- son importantes los diagramas de estados 'ermiten a los analistas, dise@adores y desarrolladores comprender el comportamiento de los ob!etos de un sistema. "l comprender esto, se puede programar me!or el soft)are. Estos diagramas nos permiten saber qu( es lo que harn los ob!etos para evitar sorpresas y producir un sistema que cumpla todo lo requerido.

Hora > < Diagrama de secuencia Muestra la forma en que los ob!etos se comunican entre s al transcurrir el tiempo. " diferencia de los diagramas de estados, que se centran en un solo ob!eto, este diagrama muestra la interaccin de varios ob!etos que se realizan en una secuencia establecida, la cual se toma su tiempo en ir del principio al fin. ,u- es un diagrama de secuencias 8b!etos% se colocan en la parte superior del diagrama de izquierda a derecha. La e*tensin que hay deba!o de cada ob!eto es una l nea discontinua llamada lnea de vida de un ob!eto. Iunto con la l nea se encuentra un peque@o rectngulo conocido como activacin que muestra la e!ecucin de una operacin que realiza el ob!eto. La longitud del rectngulo es la duracin de la activacin.

Mensa!e% va de un ob!eto a otro y pasa de la l nea de vida de uno a la de otro. Un ob!eto puede enviarse un mensa!e a s mismo. 'uede ser%

simple% transferencia de control de un ob!eto a otro. sincrnico% espera la respuesta a un mensa!e antes de continuar su traba!o. asincrnico% no espera una respuesta antes de continuar.

.iempo% se representa en direccin vertical. #e inicia en la parte superior y avanza hacia la parte inferior. Un mensa!e que est( ms cerca de la parte superior ocurrir antes que uno que est( ms aba!o.

La 1UI - La secuencia :. 5. G. J. <. K. La HU- notifica al sist. op. que se oprimi una tecla. El sist. op. le notifica a la 0'U. El sist. op. actualiza la HU-. La 0'U notifica a la placa de video. La tar!eta de video env a un mensa!e al monitor. El monitor presenta el carcter alfanum(rico en la pantalla.

El diagrama de secuencias%

'odemos mostrar los estados de uno o varios ob!etos en el diagrama. La secuencia se origina y finaliza en el estado operativo de la HU-.

El caso de uso% cuando representamos grficamente las interacciones de un caso de uso, el diagrama de secuencias delinea el caso de uso dentro del sistema.

Instancias * gen-ricos /iagrama de secuencias de instancias% se denomina as al diagrama de secuencia que se centra en un escenario $una instancia& del caso de uso.

/iagrama de secuencias gen(rico% cuando tomamos en cuenta todos los escenarios de un caso de uso al momento de crear el diagrama de secuencias. 'odemos generar este diagrama a partir del diagrama de secuencias de instancias. 'ara esto deberemos !ustificar el control de flu!o, es decir, representar las condiciones y consecuencias. La condicin en la secuencia se representa con un 1si2 $condicional& entre corchetes, arriba de las flechas. 0ada condicin causa una bifurcacin del control en el mensa!e, que separa el mensa!e en rutinas distintas. 0omo cada ruta va al mismo ob!eto, la bifurcacin causa una ramificacin del control en la l nea de vida del ob!eto receptor y separa las l neas de vida en rutas distintas. En alg3n lugar de la secuencia, las ramas del mensa!e confluyen, como las bifurcaciones en las l neas de vida.

Un diagrama de secuencias est impl cito en cada caso de uso. 'reacin de un objeto en la secuencia L0mo representamos la creacin de un ob!eto en la secuencia de interacciones de ob!etosM /e manera usual, con un rectngulo con nombre. La diferencia es que no lo colocar en la parte superior del diagrama, sino !unto con la dimensin vertical, de modo que su ubicacin corresponda al momento en que se cree. El mensa!e que crea al ob!eto se llama 10rear$&2. Los par(ntesis indican operacin. En el caso de 1mientras2, a este control de flu!o se lo representa colocando la condicin mientras entre corchetes con un asterisco antes del primer corchete.

'mo representar la recursividad #e dibu!a una flecha de mensa!e fuera de la activacin que significa la operacin y un peque@o rectngulo sobrepuesto en la activacin. 8tra flecha apunta al rectngulo y otra regresa al ob!eto que inici la recursividad.

anorama

Hora 1? - Diagrama de colaboraciones Muestran la forma en que los ob!etos colaboran entre s , al igual que el diagrama de secuencia. "mbos representan la misma informacin y puede convertirse uno en el otro. Un diagrama de colaboracin destaca el conte*to y organizacin general de los ob!etos que interact3an. El diagrama de secuencia se organiza en base al tiempo y el de colaboracin en base al espacio. Nu( es un diagrama de colaboracin Es una e*tensin de uno de ob!etos. Muestra las relaciones entre ob!etos y los mensa!es que se env an entre s . Evita la multiplicidad. Un mensa!e se representa con una flecha cerca de la l nea de asociacin entre 5 ob!etos que apunta al ob!eto receptor. El tipo de mensa!e se muestra en una etiqueta cerca de la flecha. El mensa!e le indica al ob!eto receptor que e!ecute una de sus operaciones. El mensa!e finaliza con un par de par(ntesis, donde se colocan los parmetros. 'ara convertir un diagrama de secuencias en uno de colaboraciones o viceversa, agregamos una cifra a la etiqueta de un mensa!e, que corresponde a la secuencia propia del mensa!e. La cifra y el mensa!e que separa mediante dos puntos $%&.

La 1UI El diagrama inferior muestra la figura agregada que representa al usuario que inicia la secuencia, aunque la figura no es parte de la simbolog a de este diagrama.

0ambios de estado% el estado se muestra en el rectngulo del ob!eto. #e agrega otro rectngulo al diagrama que hace las veces de ob!eto e indica el estado modificado. Los dos se conectan con una l nea discontinua y se etiqueta la l nea con el estereotipo ++se torna,,.

La anidacin surge cuando tenemos pasos dentro de un paso del diagrama. 0uando agregamos una condicin, se agrega una bifurcacin en el control de flu!o. Cumeramos esta bifurcacin como un mensa!e anidado.

'reacin de un objeto #e muestra agregando un estereotipo ++crear,, al mensa!e que genera el ob!eto. Usaremos instrucciones si $if& y mensa!es anidados. .ambi(n usaremos un ciclo 1mientras2 $)hile&. 0omo en el diagrama anterior, lo representamos entre corchetes y antecedemos al del lado izquierdo con un asterisco.

%lgunos conceptos m8s 9arios ob!etos receptores en una clase% un ob!eto puede enviar mensa!es a varios ob!etos de una misma clase. Estos ob!etos se representan como una pila de rectngulos que se e*tienden 1desde atrs2. #e agrega una condicin entre corchetes precedida de un asterisco indicando que el mensa!e es para todos los ob!etos.

El orden del mensa!e puede ser importante. Esto se representa con un 1mientras2 cuya condicin implica orden, !unto al mensa!e y la pila de rectngulos.

7epresentacin de los resultados% un mensa!e podr a ser la peticin a un ob!eto para que realice un clculo y devuelva un valor. Esto se representa escribiendo una e*presin que tenga el nombre del valor devuelto a la izquierda seguido de 1%O2, luego del nombre de la operacin y las cantidades con que opera para producir el resultado.

8b!etos activos% es un ob!eto que controla el flu!o. Este puede enviar mensa!es a los ob!etos pasivos e interactuar con otros ob!etos activos. "l proceso de que dos o ms procesos activos hagan sus tareas al mismo tiempo se conoce como concurrencia. El ob!eto activo se representa con el borde grueso y ms oscuro.

#incronizacin% es cuando un ob!eto puede enviar un mensa!e slo cuando otros mensa!es han sido enviados. El ob!eto debe sincronizar todos los mensa!es en el orden debido. #e representa antecediendo el mensa!e con una lista de mensa!es que deben completarse antes de que se realice, en vez de la etiqueta num(rica. La lista de mensa!es se separa con una coma y finaliza con una B.

anorama

Hora 11 < Diagrama de actividades Este diagrama muestra los pasos en una operacin o proceso. Es similar a un diagrama de flu!o. Muestra tambi(n puntos de decisin y bifurcacin. Es 3til para mostrar lo que ocurre en un proceso de negocios u operacin. ,u- es un diagrama de actividades Muestra una visin simplificada de lo que ocurre durante una operacin o proceso. Es una e*tensin del diagrama de estados que resalta las actividades intermedias del mismo. 0ada actividad se representa por un rectngulo con las esquinas redondeadas $ms angosto y ovalado que el rectngulo de estado&. Una flecha representa la transicin de una actividad a otra. #e muestra un punto inicial y uno final.

/ecisiones, decisiones, decisiones% 0asi siempre una secuencia de actividades llega a un punto de decisin. #eg3n la condicin se tomar un camino u otro. Esto se representa de dos maneras. 8 mostrando las rutas posibles que parten directamente de una actividad o llevando la transicin a un rombo $elemento del diagrama de flu!o& y que de all salgan las rutas de decisin.

7utas concurrentes% a veces podremos separar una transicin en dos rutas que se e!ecutan al mismo tiempo y luego se re3nan. La divisin se representa con una l nea gruesa perpendicular a la transicin y las rutas parten de all . La reincorporacin se indica con ambas rutas apuntando a otra l nea gruesa.

-ndicaciones% durante la secuencia de actividades es posible enviar una indicacin, que provoca que se e!ecute una actividad. #u s mbolo es un pentgono conve*o y el que la recibe un pentgono cncavo. En UML el pentgono conve*o simboliza el env o de un evento y el cncavo la recepcin del evento.

%plicacin de los diagramas de actividades 8peracin que calcula la serie de Pibonacci%

0reacin de un documento%

Marcos de responsabilidad Un aspecto muy 3til del diagrama es el poder e*pandirse y mostrar qui(n tiene las responsabilidades en un proceso. 'ara esto debemos separar el diagrama en segmentos paralelos, conocidos como marcos de responsabilidad. 0ada marco muestra el nombre de un responsable en la parte superior y las actividades de cada uno. Las transiciones pueden llevarse a cabo de un marco a otro. "ba!o veremos un diagrama sin los marcos y el mismo con los marcos.

Diagramas .bridos 0ontienen s mbolos que normalmente se asocian con otros diagramas.

/iagrama de actividades dentro de un ob!eto. anorama

Hora 1$ < Diagrama de componentes +epresentan entidades reales: componentes de so&t@are5 Nu( es un componente Es una parte f sica del sistema y se encuentra en la computadora. E!emplo% tabla, archivo de datos, e!ecutable, biblioteca de v nculos dinmicos, documentos, etc. Un componente es la personificacin en soft)are de una clase, aunque un componente puede implementar ms de una clase. Es 3til modelar componentes para que% Los clientes pueden ver la estructura del sistema final. Los desarrolladores tengan una estructura para traba!ar en adelante. Los que escriben notas t(cnicas y documenten, sepan de qu( escribirn. Usted se aliste para reutilizar componentes% si podemos crear componentes para un sistema y reutilizarlo en otro, me!oraremos los tiempos, la productividad y la competitividad empresarial.

'omponentes e inter&aces "l tratar con componentes, tratamos con sus interfaces. 7efrescamos conocimientos de horas anteriores% algunas clases pueden no estar relacionadas con una clase principal, pero sus acciones pueden incluir operaciones con las mismas firmas. #e pueden reutilizar estas operaciones de clase en clase. La interfaz es, en UML, la que nos permite hacerlo. La interfaz es un con!unto de operaciones que presenta una clase a otra. La relacin entre una clase y su interfaz se llama realizacin. Una interfaz puede ser f sica o conceptual. La interfaz que usa una clase es la misma que usa su implementacin de soft)are $componente&. 7epresentaremos igual una interfaz para una clase que para un componente. UML no distingue entre interfaces f sicas y conceptuales. #olo se pueden e!ecutar las operaciones de un componente mediante su interfaz. La relacin entre un componente y su interfaz tambi(n se llama realizacin. Un componente puede usar los servicios de otro componente. El que sirve, se dice que provee una interfaz de exportacin, y el que accede, se dice que usa una interfaz de importacin. #ustitucin y reutilizacin% podemos sustituir un componente con otro si el nuevo contiene las mismas interfaces que el anterior. .ambi(n podr reutilizar un componente en otro sistema si (ste puede acceder al componente reutilizado mediante sus interfaces. 'odremos simplificar la vida del desarrollador que intente sustituir o reutilizar un componente si la informacin de su interfaz est disponible como un modelo. Aipos de componentes /e distribucin% conforman el fundamento de los sistemas e!ecutables $dll, e!ecutables, controles active*, !ava beans, etc.&. 'ara traba!ar en el producto% a partir de los cuales se crean los componentes de distribucin $archivos de bd, cdigo, etc.&. /e e!ecucin% creados como resultado de un sistema en e!ecucin.

,u- es un diagrama de componentes 0ontiene componentes, interfaces y relaciones, as como otros s mbolos ya vistos. 7epresentacin de un componente% rectngulo que tiene otros dos sobrepuestos en su lado izquierdo. El nombre se coloca dentro del s mbolo.

#i el componente es miembro de un paquete, podemos usar el nombre del mismo como prefi!o para el nombre del componente. .ambi(n podemos agregar informacin que detalle al componente.

El s mbolo de la derecha del diagrama superior, muestra las clases que implementa un componente en particular. Esto se puede representar como en el diagrama de aba!o, aunque desordena al diagrama.

0mo representar las interfaces% :. Mostrar la interfaz como un rectngulo que contiene la informacin que se le relaciona y conectarla al componente con una l nea discontinua y una punta de flecha con un tringulo sin rellenar que visualiza la realizacin.

5. 7epresenta la interfaz como un peque@o c rculo que se conecta al componente por una l nea continua que representa la realizacin.

#e puede representar la dependencia, que es la relacin entre un componente y una interfaz de importacin, con una l nea discontinua con una punta de flecha.

%plicacin de los diagramas de componentes BejemplosC 'rograma en !ava

'o)er.oys Q .)eaRU-

anorama: el diagrama *a est8 en el panorama de UML

Hora 1( < Diagramas de distribucin Un dise@o slido de distribucin de hard)are es bsico para el dise@o de un sistema. UML nos da los s mbolos para crear una imagen clara de la forma en que debe lucir el hard)are final. ,u- es un diagrama de distribucin #u elemento primordial es el nodo que designa a cualquier tipo de recurso de cmputo. Aay 5 tipos de nodo% el procesador, que e!ecuta un componente, y el dispositivo, que no lo e!ecuta. Un dispositivo tiene contacto de alguna manera con el mundo e*terior.

El nombre es una cadena de te*to. #i el nodo es parte de un paquete, su nombre puede contener el nombre del paquete. 'uede dividir al cubo en compartimentos que agreguen informacin.

8tra forma de indicar los componentes distribuidos es en relaciones de dependencia con un nodo.

Una l nea que asocia dos cubos representa una cone*in entre ellos. 'odemos usar un estereotipo para dar informacin respecto a dicha cone*in.

Es posible utilizar agregacin, dependencia u otras tambi(n. Las representamos de la misma manera que ya se ha visto. %plicacin de los diagramas de distribucin '0 dom(stica%

7ed .oRen 7ing%

.hin Ethernet%

7ed inalmbrica 7icochet de Metricom%

anorama

Hora 1/ < "ociones de los &undamentos de UML #e ve luego de los otros :G cap tulos, ya que UML es como aprender un idioma e*tran!ero. Lo me!or es sumergirse en el, con lo ya visto y un e!emplo completo, y luego captar las reglas generales, para las cuales ya estaremos preparados. #structura de UML Los diagramas nos permiten ver el sistema desde diferentes puntos. Sa que hay varias personas a las que les interesa ver el sistema, debemos ser capaces de comunicar una visin consistente del mismo de diversas formas. Lo que veremos ahora es la parte formal de UML para asegurar que los elementos ya vistos muestren una idea clara del sistema. UML tiene una arquitectura de J capas. "rquitectura hace referencia a una forma de resumir un con!unto de decisiones para organizar un sistema. /ecisiones que se enfocan en los elementos del sistema, es decir, qu( son, qu( hacen, cmo se comportan, cmo se relacionan y cmo se combinan. 0apa de ob!etos del usuario% la vimos cuando seguimos un e!emplo o cuando realizamos un e!ercicio. Es la capa ms espec fica, donde el usuario es quien usa UML, no quien usa el sistema. 0apa de modelado% la vimos cuando vimos las clases. Los primeros estados del anlisis tienen que ver con esta capa% traba!ar con un e*perto o un cliente para obtener informacin del dominio y con un usuario para comprender los casos de uso que se tienen que tomar en cuenta. 0apa de metamodelado% la vimos cuando aprendimos conceptos nuevos. Esta capa define el lengua!e para un modelo espec fico. 0apa de metametamodelado% es una forma de definir un lengua!e que especifique todos los elementos de UML. 'ocas veces el analista trata con esta capa. #e denomina s porque define lo que va en el metamodelado.

'apa del metamodelado: cercano * personal Esta capa es la base del panorama que ya vimos en los otros cap tulos. Est formada por G paquetes%

Pundamentos% 0ontiene J paquetes% C3cleo, elementos au*iliares, tipos de datos y mecanismos de e*tensin.

C3cleo% define lo que necesita para crear un modelo UML. 0ada uno de los elementos definidos es abstracto, es decir, no se crean instancias de ellos o concreto, es decir, s se crean instancias. "bstractos% Elemento/eModelo, ElementoHeneralizable y 0lasificador. 0oncretos% 0lase, -nterfaz, "sociacin y .ipo/e/atos. Los elementos concretos se derivan de los abstractos, por lo tanto hablamos de clases y herencia. En este caso las denominamos metaclases. 'or lo tanto un clasificador es una metaclase. Elementos au*iliares% define la /ependencia, 0omponentes y Codos, entre otros. .ipo de /atos% especifica los tipos de datos que UML usa, incluyendo los tipos primitivos y enumeraciones $listan los valores posibles&. Mecanismos de E*tensin% especifica cmo puede e*tender a UML e incluye algunas e*tensiones ya hechas.

Elementos de comportamiento% consta de J paquetes% colaboraciones, casos de uso, mquinas de estado y comportamiento com3n.

0omportamiento com3n% proporciona los conceptos de los elementos dinmicos y soporta a los otros paquetes% casos de uso, mquinas de estado y colaboraciones. Estos 1conceptos2 incluyen% #e@a, Enlace y 'unto final de asociacin. 0olaboraciones% abarca ms que los diagramas de colaboracin. "qu , una colaboracin describe la forma en que los clasificadores y sus asociaciones traba!an en con!unto para realizar una tarea. Los clasificadores conforman al contexto de la colaboracin% las asociaciones conforman la interaccin. 0asos de uso% detalla los conceptos de los casos de uso $actor, caso de uso, etc.&. "mbos conceptos son clasificadores. El ob!etivo general es poder describir el comportamiento de un sistema sin entrar en detalles. Mquinas de estado% da los detalles formales de los conceptos de los diagramas de estados y de actividad. "dministracin de modelos% define al Modelo, Subsistema y Pa uete. La meta de estos elementos es agrupar los !lementos"eModelo de todo tipo.

#0tensin de UML 'odemos pulir los diagramas con detalles que e*pliquen me!or su significado $estereotipos, restricciones y valores etiquetados&. 'odemos crear una e*tensin sobre la marcha para a@adir al modelo cuestiones e ideas importantes del dominio. #stereotipos #irven para e*tender un elemento de UML para que sea una instancia de una nueva metaclase y se escriben entre dos pares de mayor y menor $++ ,,&. Esto agrega fle*ibilidad, ya que podremos usar un elemento e*istente como base para crear nuevos elementos, que capturen alg3n aspecto propio del dominio de nuestro sistema de una manera que UML no podr a hacerlo.

Las herramientas de modelado, tienen que almacenar y mane!ar las clases para generar cdigo e informes. El mecanismo del estereotipo les permite hacerlo con nuestras propias creaciones. .ipos de estereotipos generados% /ependencia% puede tomar la mayor cantidad de estereotipos ya creados. 0ada uno e*tiende una relacin de dependencia entre un origen y un destino. ++se convierte en,,% muestra que el origen y el destino son el mismo ob!eto en distintos momentos. ++llamar,,% tiene una operacin como origen y una como destino. ++copiar,,% el destino es una copia e*acta del origen. ++derivar,,% el origen se deriva en el destino. ++reunir,, o ++friend,,% el origen tiene acceso al destino sin importar la visibilidad. ++e*tender,,% los comportamientos del caso de uso de destino se agregan al de origen. ++usar,,% algunos casos de uso tienen cierto comportamiento en com3n. Esto permite usar dicho comportamiento sin repetirlo una y otra vez. ++importar,,% agrega el contenido del destino al espacio de nombres del origen. ++instancia,,% el origen es una instancia del destino, que siempre es un clasificador. Es una dependencia de ++metadestino,,% tanto el destino como el origen son clasificadores y el destino la metaclase de origen. ++enviar,,% el origen es una operacin y el destino una se@al. 0lasificador% Los estereotipos e*tienden a los clasificadores de varias maneras. ++metaclase,,% el clasificador al que est ad!unto es una metaclase de otra clase. ++tipodeautoridad,,% un clasificador tiene ob!etos que provienen de un antecesor en particular. .ambi(n se usa en una dependencia para mostrar que el destino es un tipo de potestad del origen. ++proceso,, y ++subproceso,,% indican que su clasificador es una clase activa, es decir, sus ob!etos pueden iniciar la actividad de control. +utiler a,,% es una coleccin titulada de atributos y operaciones que no son miembros de tal clasificador% un clasificador que no tiene instancias. ++estereotipo,,% el clasificador funciona como un estereotipo y permite modelar !erarqu as de estereotipos. 0lase% son ms espec ficos que en los clasificadores. ++tipo,,% es una clase que establece un dominio de ob!etos !unto con sus atributos, operaciones y asociaciones. Co contiene m(todos $algoritmos e!ecutables&. ++clase/e-mplementacion,,% es lo contrario a ++tipo,,. 7epresenta la implementacin de una clase en un lengua!e de programacin. Heneralizacin% relacin entre clasificadores con su propio con!unto de estereotipos.

++heredar,,% las instancias del subtipo no pueden sustituirse por instancias del supertipo. ++subclase,,% las instancias de la subclase no son sustituible por las instancias de la superclase. ++privado,,% herencia e*clusiva, oculta los atributos heredados y operaciones de una clase a sus ancestros. 'aquete% son estereotipos directos. ++fachada,,% es un paquete que contiene referencias a elementos de otros paquetes y no tiene elementos propios. ++sistema,,% es una coleccin de modelos de un sistema. ++cabo,,% es un paquete que proporciona solo las partes p3blicas de otro paquete. Un paquete puede incluir patrones. Un patrn es un tipo de colaboracin entre los elementos que ha probado su efectividad en diversas situaciones. ++marco/e.raba!o,, es un paquete estereotipado que solo contiene patrones. Sa que los paquetes pueden tener otros paquetes adentro, nos sirve tener un estereotipo que indique cul paquete est en el nivel superior. Este es el ++paquete/eCivel#uperior,,. 0omponente% son muy directos. 'odemos mostrar que un componente es un documento, un e!ecutable, un archivo, una tabla de datos o una biblioteca. Los estereotipos son ++documento,,, ++e!ecutable,,, ++archivo,,, ++tabla,, y ++biblioteca,,. "lgunos otros estereotipos% un comentario que aparece en una nota ad!unta puede tener un estereotipo ++requerimiento,, que indica que el comentario establece un requisito para el elemento ad!unto. /entro de una clase una operacin puede crear o destruir una instancia. .ales caracter sticas se indican mediante ++crear,, y ++destruir,,. Las restricciones tambi(n funcionan con estereotipos. ++condicion'revia,, o ++condicion'osterior,, se usan para indicar !ustamente las condiciones de una operacin. " veces podremos ad!untar una restriccin a un con!unto de clasificadores o relaciones y necesitaremos indicar que las condiciones de la restriccin debern tener todos los clasificadores, relaciones e instancias. 'ara esto usamos ++invariable,,. Estereotipos grficos% por e!emplo, figuras de procesadores o dispositivos que reemplacen a los cubos de un diagrama de distribucin.

+estricciones #e encuentran entre llaves. -ndican condiciones para las asociaciones, e*tremos de v nculos, generalizaciones y peticiones $transmisin de se@ales o llamadas a operaciones&. La restriccin ToU se aplica a un con!unto de asociaciones y muestra que solo una puede usarse. 8tra restriccin basada en asociaciones, Timpl citoU, indica que una asociacin es conceptual. Los e*tremos de v nculos que son puntos finales de v nculos entre ob!etos, pueden contener muchas restricciones. 0ada una indica el porqu( el ob!eto en el e*tremo del v nculo es visible% TparmetroU% muestra que el ob!eto es un valor necesario relativo al v nculo. TpropioU% indica que el ob!eto es el despachador de una peticin. TglobalU y TlocalU% indican el mbito de un ob!eto respecto al v nculo. TasociacinU% denota que el ob!eto es visible por su coalicin. Un con!unto de generalizaciones puede ser% TcompletoU% todos su subtipos han sido especificados. TincompletoU% a3n pueden agregarse subtipos. TtraslapadoU% ms de un subtipo puede funcionar como un tipo de instancia. TdesarticuladoU% slo un subtipo puede ser un tipo de instancia, lo que es predeterminado en la generalizacin. #i una peticin se env a a diversas instancias de destino, en un orden no especificado, es una TdifusinU. #i varias instancias devuelven valores y la mayor a de los mismos determinan un solo valor, la restriccin ser un TvotoU. 9alores etiquetados #e escriben entre llaves. Es una eti ueta un O y un valor.

#on adecuados para los clasificadores, componentes, atributos, instancias y operaciones. Una etiqueta Tdocumentacin O U se aplica a cualquier elemento y debemos indicar una descripcin, e*plicacin o comentario respecto del elemento al que ad!untamos el valor etiquetado. Tubicacin O U% para un clasificador, proporcionamos de cual es parte. 'ara un componente, indicar el nodo donde se encuentra. Tpersistencia O U% puede ir en un atributo, clasificador o instancia. -ndica permanencia del estado del elemento al que lo hemos ad!untado. 9alores% permanente $el estado persiste cuando la instancia se destruye& y transitorio $el estado se destruye con la instancia&. Tsemntica O U% especifica el significado de un clasificador o una operacin. Tresponsabilidad O U% es una obligacin de un clasificador.