Diagrama de clases DIAGRAMAS DE CLASES: Los diagramas de clases se utilizan para modelar la visin esttica de un sistema.

Esta visin soporta los requisitos funcionales del sistema, en concreto, los servicios que el sistema debera proporcionar a sus usuarios finales. Normalmente contienen: clases, interfaces y relaciones entre ellas: de asociacin, de dependencia y/o de generalizacin. ES Los diagramas de clases tambin pueden contener a paquetes o subsistemas, que se usan para agrupar elementos del modelo en partes ms grandes (por ejemplo, paquetes que a su vez contienen a varios diagramas de clases). Al igual que otros diagramas, en los diagramas de clases pueden aparecer notas explicativas y restricciones.

Encapsulacin: En un lenguaje de programacin, la encapsulacin se utiliza para referirse a uno de los dos conceptos relacionados pero distintos, ya veces a la combinacin [1] [2] del mismo: Un mecanismo de idioma para restringir el acceso a algunos de los objetos de los componentes de 's Una construccin del lenguaje que facilita la agrupacin de los datos con los mtodos (u otras funciones) que operan sobre esos datos. [5] [6]

Algunos investigadores del lenguaje de programacin y acadmicos utilizar el sentido primero solos o en combinacin con el segundo como una caracterstica distintiva de la programacin orientada a objetos , mientras que otros lenguajes de programacin que proporcionan cierres lxicos ver encapsulacin como una caracterstica de la lengua ortogonal a la orientacin del objeto.

La segunda definicin est motivada por el hecho de que en muchos lenguajes OOP se esconden de los componentes no es automtico ni puede ser anulado, por lo que la ocultacin de informacin se define como un concepto separado por aquellos que prefieren la segunda definicin. En general, la encapsulacin es uno de los 4 fundamentos de POO (programacin orientada a objetos). La encapsulacin es esconder las variables o algo dentro de una clase, evitando que terceros no autorizados para su uso. As que los mtodos pblicos como getter y setter acceder a ella y las otras clases llamar a estos mtodos para acceder. ENCAPSULAMIENTO DE UN PAQUETE

NOTACIN GRFICA: La complejidad de un proyecto de desarrollo Web requiere de una metodologa escalonada que normalmente es abordada por un equipo multidisciplinario. Dentro de este proceso podemos distinguir: 1. 2. 3. 4. 5. 6. 7. Estrategia Investigacin de usuarios Definicin de arquitectura de informacin Definicin de interaccin Diseo de interfaz Produccin Testeo

A lo largo de este proceso, los lenguajes de representacin y formalizacin (mapas de navegacin, wireframes, esquemas de datos, diagramas de flujo, etc.) van marcando cada etapa pero carecemos de un sistema que permita transversalizar el producto final: la experiencia del usuario. Este lenguaje propone un sistema de notacin que pueda acompaar el proyecto desde la etapa de estrategia (alto grado de abstraccin) hasta la etapa final de implementacin en cdigo (alto grado de especificidad), permitiendo a cada actor del proyecto (estrategas, diseadores y programadores) comprender el total y cuidar el cumplimiento de la visin original. Se trata de un sistema que permite coreografiar y orquestar cuidadamente el dagolo en continuidad entre la persona y el servicio.

Cmo funciona Las partituras de interaccin descomponen el dilogo entre la persona y el servicio en 3 distintas capas horizontales: 1. 2. 3. Acciones del usuario: la intensionalidad del usuario expresada en sus acciones concretas lnea de interaccin Contacto directo: los elementos de interfaz que permiten al usuario ejecutar tales acciones lnea de visibilidad Proceso: las funciones que permiten al sistema (servidor) dar respuesta en el dilogo con el usuario

Cada mdulo de interaccin se compone como un comps en esta partitura. Estos compases (o patrones de interaccin) permiten ensamblarse para verificar la lgica y la calidad de la experiencia en determinados escenarios de uso, as como detectar incosistencias o puntos crticos en el servicio. Esperamos que esta herramienta se constituya como una ayuda para el desarrollo de aplicaciones y servicios para Internet, as como un facilitador del dilogo dentro de los equipos de diseo. Este proyecto se encuentra en fase de evaluacin, por lo tanto, para poder avanzar en su afinacin es de vital contar con tus comentarios.

Asociacin Una asociacin es una relacin estructural que especifica que los objetos de una clase estn conectados con los objetos de otra. Cuando una asociacin es una conexin semntica entre los objetos de dos clases, se llama asociacin binaria. Aunque no es lo comn, se pueden tener asociaciones que conecten ms de dos clases; stas se llaman asociaciones n-arias. Tambin es posible que, dado un objeto de una clase, se pueda enlazar con otros objetos de la misma clase. Normalmente una asociacin es binaria y bidireccional (se puede navegar en ambas direcciones). Se dibuja como una lnea slida entre dos clases. Tambin se puede representar una asociacin binaria y unidireccional, aadiendo una flecha al final de la lnea. Esta flecha indica que la asociacin slo se puede utilizar en la direccin de la flecha. Cada asociacin puede presentar algunos elementos adicionales que dan detalle a la relacin, como son:

 Nombre Una asociacin puede tener un nombre, que se usa para describir la naturaleza de la relacin. As no hay ambigedad sobre su significado. Para indicar la direccin en que se debe leer el nombre se emplea un tringulo. Rol Cuando una clase participa en una asociacin, juega un rol especfico en dicha relacin. Se puede designar de forma explcita mediante un nombre a los finales de la lnea, el cual describe la semntica de la asociacin en el sentido indicado. Multiplicidad La multiplicidad describe la cardinalidad de la relacin, es decir, cuntos objetos estn conectados en una instancia de una asociacin (enlace). Cuando se establece una multiplicidad al final de la lnea de una asociacin, indica que para cada objeto de la clase en el lado opuesto existen varios objetos en el otro extremo. El rango puede ser tres (3), cero-a-uno (0..1), cero-a-muchos (0..* *), uno-a-muchos (1..*), etc. Restricciones Los elementos anteriores son suficientes para detallar una relacin de asociacin. Pero si queremos especificar un mayor significado, UML define cinco restricciones que se pueden aplicar. Por ejemplo, si queremos que los objetos de una clase al final de una asociacin (con una multiplicidad mayor que uno) estn en un orden explcito, debemos escribir {ordenado} al final de la misma y cerca de la clase. En la Figura de abajo se muestran los dos tipos de navegacin en una asociacin entre las clases Persona y Coche. En el primer caso un coche puede tener uno o ms propietarios y una persona es propietaria de cero o ms coches. Mientras que en el segundo caso la asociacin navegable nos dice que una persona puede poseer varios coches o ninguno, pero no nos informa sobre cuntas personas son propietarias de un coche.

Tipos de asociacin Los tipos de asociaciones presentes en un diagrama de clases son: 1. Asociacin normal Una asociacin normal entre dos clases representa una relacin estructural entre sus objetos, lo que significa que ambas clases estn conceptualmente al mismo nivel, ninguna es ms importante que la otra. Se trata de una relacin no muy fuerte. 2. Agregacin Una agregacin sirve para modelar una relacin todo-parte, lo que significa que un objeto del todo tiene objetos de la parte. Podemos distinguir: Agregacin normal Una agregacin normal se denota dibujando una lnea con un rombo sin rellenar al final de la misma del lado del todo (del lado de la clase que contiene a la otra clase). Tambin puede tener

un nombre (con direccin) y ser navegable, as como aadir roles en el lado de la parte (lado de la clase contenida). Una agregacin normal es un caso especial de la multiplicidad de una asociacin, pues la cardinalidad del lado del todo slo puede ser uno. Agregacin compartida Una agregacin compartida es aquella en la que las partes pueden ser partes en varios todos. Se representa de la misma forma que una agregacin normal. Para que una agregacin se considere compartida es necesario que la multiplicidad en el lado del todo sea superior a uno. Una agregacin compartida es un caso especial de una agregacin normal. Agregacin de composicin Una agregacin de composicin se denota dibujando una lnea con un rombo relleno al final de la misma del lado del todo (del lado de la clase que contiene a la otra clase). La multiplicidad en el lado del todo puede ser uno (1) cero-a-uno (0..1), pero la multiplicidad en el lado de la parte puede ser cualquier intervalo. Se trata de una relacin de pertenencia muy fuerte. Diferencias entre los tipos de asociacin La asociacin expresa un acoplamiento dbil; las clases asociadas siguen siendo relativamente independientes una de otra. Se trata de una relacin no muy fuerte, es decir, no se exige dependencia existencial ni encapsulamiento. La agregacin es una forma particular de asociacin que expresa un acoplamiento ms fuerte entre clases; una de las clases cumple una funcin ms importante que la otra en la relacin. La agregacin normal y compartida son relaciones no muy fuertes, con las mismas caractersticas que la asociacin a la hora de implementarlas. Pero la agregacin de composicin es una asociacin muy fuerte, que implica dependencia existencial (la clase dependiente desaparece al destruirse la que la contiene y, si es de cardinalidad uno, es creada al mismo tiempo) y pertenencia fuerte (la clase contenida es parte constitutiva y vital de la que la contiene). Una forma de implementar una agregacin de composicin es incluir fsicamente las partes dentro de la clase del todo (encapsulamiento). En la forma de implementacin es donde podemos hallar otra diferencia entre los tipos de agregaciones. Mientras que en la agregacin de composicin la clase del todo tiene el control del ciclo de vida de sus partes (al mismo tiempo que la clase es eliminada, se destruyen las partes), en las otras dos los tiempos de vida de la clase del todo y de sus partes no coinciden. Ejemplos de asociaciones normales En la Figura de abajo podemos ver las clases y las relaciones de asociacin normal, junto con sus elementos adicionales, correspondientes a una compaa de seguros. Observando el ejemplo, podemos darnos cuenta que: Una compaa de seguros tiene contratos de seguros, cada uno de los cuales se refieren a uno o ms clientes. Un cliente tiene cero o ms contratos de seguros, cada uno referido a una compaa de seguros. En consecuencia, un contrato de seguros se refiere a uno o varios clientes y a una compaa de seguros. El contrato de seguros est expresado en una (cero o una) pliza de seguros. La pliza de seguros se refiere a una compaa de seguros. La multiplicidad especifica que el contrato de seguros est expresado en una (cero o una) pliza de seguros (contrato escrito) y que la pliza de seguros se refiere a una compaa de seguros. Si llamas por telfono a la compaa y aseguras tu coche, hay un contrato de seguros, pero no una pliza. La pliza de seguros ser enviada ms tarde por correo. Es importante modelar el mundo real. Si hubisemos modelado la compaa de seguros basndonos slo en la pliza de seguros, habran surgido problemas. Por ejemplo, qu ocurrira si un cliente, que ha asegurado el coche por telfono, tuviese un accidente con l un minuto ms tarde (no hay pliza de seguros, pero s un acuerdo oral con el agente). Una clase puede jugar diferentes roles en diferentes asociaciones. En el diagrama de clases de la Figura 3.3, la clase Compaa de Seguros juega el papel de aseguradora y la clase Persona el papel de marido, mujer o asegurado. Si nos fijamos en el ejemplo, todas las clases estn conectadas mediante asociaciones binarias, excepto la clase Persona, donde un objeto de esta clase se puede enlazar con otros objetos de la misma clase. Un marido est casado con una mujer. Tanto el marido como la mujer son personas. Si una persona no est

casada, entonces ni l ni ella juegan el papel de marido o mujer, lo que significa que la asociacin (en este caso, casado con) no se aplica.

Ejemplos de agregaciones En la Figura de abajo podemos encontrar tres ejemplos con los tres tipos de agregaciones: normal, compartida y la de composicin. El primer ejemplo se trata de una agregacin normal. La flota contiene muchos barcos de guerra. Algunos barcos pueden ser eliminados y todava es una flota. Lo mismo ocurre si se aaden barcos, pues sigue siendo una flota. Esto es significativo para una agregacin normal, pero no para una agregacin de composicin. Las partes (los barcos de guerra) componen el todo (flota). El rombo sin rellenar en el lado del todo, junto con la multiplicidad 1, nos indica que se trata de una agregacin normal. En el segundo ejemplo la agregacin es compartida. Un remix (mezcla de sonidos) est compuesto de varias bandas sonoras; la misma banda sonora podra formar parte de varias mezclas musicales. Se diferencia de la agregacin normal en que la multiplicidad en el lado del todo es superior a 1. Los objetos tanto de la clase Remix como de la clase Banda Sonora se encuentran ordenados, lo cual est indicado por la restriccin {ordenado}. El tercer ejemplo se trata de una agregacin de composicin. La ventana contiene muchos textos, cajas de listado de elementos, botones y mens. El tiempo de vida de las partes coincide con la clase del todo, en este caso, la clase Ventana. El rombo relleno en el lado del todo, junto con la multiplicidad 0..1 o 1, nos indica que se trata de una agregacin de composicin.

Generalizacin Una generalizacin es una relacin de clasificacin entre un elemento ms general y otro ms especfico. La generalizacin es utilizada por clases y casos de uso y por otros elementos de modelado como los paquetes. La generalizacin normal es una relacin de herencia entre clases, entre una general y otra especfica. La clase especfica, llamada subclase, hereda todo de la clase general, llamada superclase. Los atributos, las operaciones y todas las asociaciones son heredadas. Los atributos y las operaciones con visibilidad pblica en la superclase sern tambin pblicos en la subclase. Los atributos y las operaciones que tengan visibilidad privada tambin sern heredados, pero no sern accesibles dentro de la subclase. Para proteger los atributos y las operaciones de accesos desde fuera de la superclase y de la subclase, los podemos declarar con visibilidad protegida. No se puede acceder a ellos desde otras clases, pero estn disponibles para la superclase y para cualquiera de sus subclases. La relacin de generalizacin se representa por una lnea continua desde la clase ms especfica (subclase) hasta la clase ms general (superclase), con un tringulo sin rellenar al final de la lnea en la superclase. Una clase abstracta es aquella que no tiene objetos. Slo se utiliza para heredar a partir de ella, es decir, en una clase abstracta se describen los atributos y las operaciones comunes para otras clases. Se especifica de forma explcita poniendo {abstracta} dentro del compartimento del nombre de la clase y debajo de su nombre. Normalmente una clase abstracta tiene operaciones abstractas. Una operacin abstracta es aquella que no tiene mtodo de implementacin en la superclase donde est definida. Se especifica de forma explcita escribiendo {abstracta} despus del nombre de la operacin en la superclase. Lo contrario de una clase abstracta es una clase concreta, lo que significa que es posible crear objetos a partir de la clase y que tiene implementaciones para todas las operaciones. A la hora de modelar aplicaciones sencillas es suficiente con la relacin de generalizacin normal. Sin embargo, el modelado de ciertos dominios complejos (como puede ser el modelado de todas las aplicaciones de una empresa) requiere especificar un mayor significado, debido principalmente a la existencia de un gran nmero de subclases. Por ello UML define un estereotipo y cuatro restricciones que se pueden aplicar. El estereotipo es implementation. Las restricciones, que nos indican si se pueden aadir o no ms hijos en la generalizacin, son: {completo} e {incompleto}. Las otras dos restricciones son: {disjoint} y {overlapping} y se aplican slo en el contexto de herencia mltiple, es decir, cuando una clase tiene ms de un padre. Ejemplos de generalizaciones La Figura de abajo nos muestra un conjunto de cuatro clases junto con sus asociaciones y dependencias, referidas a tipos de vehculos. CAPTULO 3: DIAGRAMAS DE CLASES En nuestro ejemplo la clase Vehculo muestra las cosas comunes entre coches y barcos, incluyendo la relacin de asociacin a la clase Persona. Se trata de una clase abstracta que no tiene objetos, mientras que las clases Coche y Barco son concretas. Estas subclases heredan el atributo color y la operacin Conducir de la superclase Vehculo. Dicha operacin est redefinida en las clases Coche y Barco, ya que no est implementada en la clase Vehculo al aparecer junto a la operacin la palabra {abstracta} y adems su implementacin es diferente dependiendo del tipo de objeto: coche o barco.