1. UNIVERSIDAD REGIONAL AUTONOMA DELOS ANDESSISTEMAS MERCANTILESUNIANDESNOMBRE : DARIO RAMIREZNIVEL : SEXTOCARRERA : SISTEMAS 2011 - 2012 2. INTRODUCCINEste captulo proporciona una introduccin rpida a las caractersticas bsicasde UML. Tenga en cuenta que no se trata de un manual de referencia de UMLsino de una breve introduccin. Si desea ms informacin sobre UML, o sobre elanlisis y diseo del software en general, le recomendamos que lea cualquier delos libros publicados sobre el tema. Tambin hay una buena cantidad detutoriales en Internet, que puede utilizar como punto de partida.El lenguaje unificado de diagrama o notacin (UML) sirve para especificar,visualizar y documentar esquemas de sistemas de software orientado a objetos.UML no es un mtodo de desarrollo, lo que significa que no sirve paradeterminar qu hacer en primer lugar o cmo disear el sistema, sino quesimplemente le ayuda a visualizar el diseo y a hacerlo ms accesible para otros.UML est controlado por el grupo de administracin de objetos (OMG) y es elestndar de descripcin de esquemas de software.UML est diseado para su uso con software orientado a objetos, y tiene un usolimitado en otro tipo de cuestiones de programacin. 3. PAUTAS GENERALES PARA DESARROLLAR USANDO UML Elementos de UML Diagrama de casos de usoLos diagramas de casos de uso describen las relaciones y lasdependencias entre un grupo de casos de uso y los actoresparticipantes en el proceso.Es importante resaltar que los diagramas de casos de uso no estnpensados para representar el diseo y no puede describir loselementos internos de un sistema. Los diagramas de casos de usosirven para facilitar la comunicacin con los futuros usuarios delsistema, y con el cliente, y resultan especialmente tiles paradeterminar las caractersticas necesarias que tendr el sistema. Enotras palabras, los diagramas de casos de uso describen qu es lo quedebe hacer el sistema, pero no cmo. 4. PAQUETES Empleo el trmino diagrama de paquetes para indicar un diagramaque muestra los paquetes de clases y las dependencias entre ellos. Hablando estrictamente, los paquetes y las dependencias sonelementos de un diagrama de clases, por lo cual un diagrama depaquetes es slo una forma de un diagrama de clases. En laprctica dibujo estos diagramas por diferentes razones, as que megusta manejar nombres diferentes. 5. DEPENDENCIA Existe una (dependency) dependencia entre dos elementos si los cambios a ladefinicin de un elemento pueden causar cambios al otro. En las clases, ladependencia existe por varias razones: una clase enva un mensaje a otra;una clase tiene a otra como parte de sus datos; una clase menciona a otracomo parmetro para una operacin. Si una clase cambia su interfaz,entonces los mensajes que enva pueden dejar de ser vlidos. En forma ideal, slo los cambios a una interfaz de clase deberan afectar aotra clase. El arte del diseo en gran escala implica minimizar lasdependencias, de modo tal que se reduzcan los efectos del cambio y serequiera de menos esfuerzo para cambiar el sistema. 6. Diagrama de Casos de Uso Diagrama de casos de usoLos diagramas de casos de uso describen las relaciones y las dependencias entre un grupo de casos de uso y los actores participantes enel proceso.Es importante resaltar que los diagramas de casos de uso no estn pensados para representar el diseo y no puede describir loselementos internos de un sistema. Los diagramas de casos de uso sirven para facilitar la comunicacin con los futuros usuarios delsistema, y con el cliente, y resultan especialmente tiles para determinar las caractersticas necesarias que tendr el sistema. En otraspalabras, los diagramas de casos de uso describen qu es lo que debe hacer el sistema, pero no cmo. Caso de uso Un caso de uso describe, desde el punto de vista de los actores, un grupo de actividades de un sistema que produce un resultadoconcreto y tangible.Los casos de uso son descriptores de las interacciones tpicas entre los usuarios de un sistema y ese mismo sistema. Representan elinterfaz externo del sistema y especifican qu requisitos de funcionamiento debe tener este (recuerde, nicamente el qu, nunca el cmo).Cuando se trabaja con casos de uso, es importante tener presentes algunas secillas reglas: Cada caso de uso est relacionado como mnimo con un actor Cada caso de uso es un iniciador (es decir, un actor) Cada caso de uso lleva a un resultado relevante (un resultado con valor intrnseco) 7. Los casos de uso pueden tener relaciones con otros casos de uso. Los tres tipos de relaciones ms comunes entre casos de uso son: que especifica una situacin en la que un caso de uso tiene lugar dentro de otro caso de uso que especifica que en ciertas situaciones, o en algn punto (llamado punto de extensin) un casode uso ser extendido por otro. Generalizacin que especifica que un caso de uso hereda las caractersticas del super caso de uso, y puedevolver a especificar algunas o todas ellas de una forma muy similar a las herencias entre clases. ActorUn actor es una entidad externa (de fuera del sistema) que interacciona con el sistema participando (y normalmenteiniciando) en un caso de uso. Los actores pueden ser gente real (por ejemplo, usuarios del sistema), otrosordenadores o eventos externos.Los actores no representan a personas fsicas o a sistemas, sino su rol. Esto significa que cuando una persona interacta con el sistema de diferentes maneras (asumiendo diferentes papeles), estar representado por varios actores. Por ejemplo, una persona que proporciona servicios de atencin telefnica a clientes y realiza pedidos para los clientes estara representada por un actor equipo de soporte y por otro actor representante de ventas. Descripcin de casos de uso Las descripciones de casos de uso son reseas textuales del caso de uso. Normalmente tienen el formato de una nota o un documento relacionado de alguna manera con el caso de uso, y explica los procesos o actividades que tienen lugar en el caso de uso. Diagrama de clases Los diagramas de clases muestran las diferentes clases que componen un sistema y cmose relacionan unas con otras. Se dice que los diagramas de clases son diagramasestticos porque muestran las clases, junto con sus mtodos y atributos, as comolas relaciones estticas entre ellas: qu clases conocen a qu otras clases o quclases son parte de otras clases, pero no muestran los mtodos mediante los que seinvocan entre ellas. 8. ClaseUna clase define los atributos y los mtodos de una serie de objetos. Todos los objetosde esta clase (instancias de esa clase) tienen el mismo comportamiento y el mismoconjunto de atributos (cada objetos tiene el suyo propio). En ocasiones se utiliza eltrmino tipo en lugar de clase, pero recuerde que no son lo mismo, y que el trminotipo tiene un significado ms general.En , las clases estn representadas por rectngulos, con el nombre de la clase, ytambin pueden mostrar atributos y operaciones de la clase en otros doscompartimentos dentro del rectngulo.AtributosEn UML, los atributos se muestran al menos con su nombre, y tambin pueden mostrarsu tipo, valor inicial y otras propiedades. Los atributos tambin pueden ser mostradosvisualmente: + Indica atributos pblicos # Indica atributos protegidos - Indica atributos privados 9. Diagrama de Secuencia y diagramade Colaboracin Diagramas de secuenciaLos diagramas de secuencia muestran el intercambio de mensajes (es decir la forma en que seinvocan) en un momento dado. Los diagramas de secuencia ponen especial nfasis en el ordeny el momento en que se envan los mensajes a los objetos.En los diagramas de secuencia, los objetos estn representados por lneas intermitentesverticales, con el nombre del objeto en la parte ms alta. El eje de tiempo tambin es vertical,incrementndose hacia abajo, de forma que los mensajes son enviados de un objeto a otro enforma de flechas con los nombres de la operacin y los parmetros. - Diagramas de colaboracinLos diagramas de colaboracin muestran las interacciones que ocurren entre los objetos queparticipan en una situacin determinada. Esta es ms o menos la misma informacin que lamostrada por los diagramas de secuencia, pero destacando la forma en que las operaciones seproducen en el tiempo, mientras que los diagramas de colaboracin fijan el inters en lasrelaciones entre los objetos y su topologa.En los diagramas de colaboracin los mensajes enviados de un objeto a otro se representanmediante flechas, mostrando el nombre del mensaje, los parmetros y la secuencia del mensaje.Los diagramas de colaboracin estn indicados para mostrar una situacin o flujo programaespecficos y son unos de los mejores tipos de diagramas para demostrar o explicarrpidamente un proceso dentro de la lgica del programa. 10. Diagrama de EstadosDiagrama de estadoLos diagramas de estado muestran los diferentes estados de un objeto durante su vida, y los estmulos que provocan loscambios de estado en un objeto.Los diagramas de estado ven a los objetos como mquinas de estado o autmatas finitos que pueden estar en un conjuntode estados finitos y que pueden cambiar su estado a travs de un estmulo perteneciente a un conjunto finito. Por ejemplo,un objeto de tipo NetServer puede tener durante su vida uno de los siguientes estados: Listo Escuchando Trabajando Detenido y los eventos que pueden producir que el objeto cambie de estado son Se crea el objeto El objeto recibe un mensaje de escucha Un cliente solicita una conexin a travs de la red Un cliente finaliza una solicitud La solicitud se ejecuta y ser termina El objeto recibe un mensaje de detencin etc 11. Diagrama de Componentes Diagramas de componentesLos diagramas de componentes muestran los componentes del software (ya sea las tecnologasque lo forman como Kparts, componentes CORBA, Java Beans o simplemente secciones delsistema claramente distintas) y los artilugios de que est compuesto como los archivos decdigo fuente, las libreras o las tablas de una base de datos.Los componentes pueden tener interfaces (es decir clases abstractas con operaciones) quepermiten asociaciones entre componentes. Diagramas de implementacin Los diagramas de implementacin muestran las instancias existentes al ejecutarseas como sus relaciones. Tambin se representan los nodos que identifican recursosfsicos, tpicamente un ordenador as como interfaces y objetos (instancias de lasclases). Diagramas de relacin de entidad Los diagramas de relaciones de entidad (diagramas ER) muestran el diseoconceptual de las aplicaciones de bases de datos. Representan varias entidades(conceptos) en el sistema de informacin y las relaciones y restricciones existentesentre ellas. Una extensin de los diagramas de relaciones de entidad llamadodiagramas de relaciones de entidad extendida o diagramas de relaciones deentidad mejoradas (EER), se utiliza para incorporar las tcnicas de diseoorientadas a objetos en los diagramas ER 12. Diagrama de Despliegue El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza paramodelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes. Los elementos usados por este tipo de diagrama son nodos (representados como un prisma), componentes(representados como una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones. En el UML 2.0 los componentes ya no estn dentro de nodos. En cambio, puede haber artefactos u otros nodosdentro de un nodo. Este tipo de diagrama debemos tambin aadir que no van a existir actores para relacionarsecon los nodos (no es un diagrama de casos de uso) si no que las relaciones que pueda haber siempre seran entrelos nodos y por ejemplo con una base de datos. Un artefacto puede ser algo como un archivo, un programa, una biblioteca, o una base de datos construida omodificada en un proyecto. Estos artefactos implementan colecciones de componentes. Los nodos internos indicanambientes, un concepto ms amplio que el hardware propiamente dicho, ya que un ambiente puede incluir allenguaje de programacin, a un sistema operativo, un ordenador o un cluster de terminales. La mayora de las veces el modelado de la vista de despliegue implica modelar la topologa del hardware sobre elque se ejecuta el sistema. Aunque UML no es un lenguaje de especificacin hardware de propsito general, se hadiseado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingenierosoftware pueda especificar la plataforma sobre la que se ejecuta el software del sistema. 13. CONCLUSIONES Explica como usar los diagramas depaquetes, que permiten mostrar las clasesque contiene el paquete y sus relaciones., opor el contrario, las relaciones de los paquetesentre si y las dependencias del sistema 14. REFERENCIAS Fowler, Martn UML, gota a gota Addison Wesley Longman de Mxico,SA de CV Mxico 1.999 ISBN: 968-44-364-1 Formato 17x23 Paginas 224