Repblica Bolivariana de Venezuela Ministerio del Poder Popular para la Educacin Superior Instituto Universitario de Tecnologa Readic UNIR

Sistema de Informacin II

Emir Gotera Jesus Romero Juan Lobo

Diagrama de paquetes Muestra cmo un sistema est dividido en agrupaciones lgicas mostrando las dependencias entre esas agrupaciones. Dado que normalmente un paquete est pensado como un directorio, los diagramas de paquetes suministran una descomposicin de la jerarqua lgica de un sistema. Los Paquetes estn normalmente organizados para maximizar la coherencia interna dentro de cada paquete y minimizar el acoplamiento externo entre los paquetes. Con estas lneas maestras sobre la mesa, los paquetes son buenos elementos de gestin. Cada paquete puede asignarse a un individuo o a un equipo, y las dependencias entre ellos pueden indicar el orden de desarrollo requerido.

Diagrama de clase Un diagrama de clases es un tipo de diagrama esttico que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de anlisis y diseo de los sistemas, donde se crea el diseo conceptual de la informacin que se manejar en el sistema, y los componentes que se encargarn del funcionamiento y la relacin entre uno y otro. En un diagrama de clases se pueden distinguir principalmente dos elementos: clases y sus relaciones.

Diagrama de Casos 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 resultado concreto y tangible. Los casos de uso son descriptores de las interacciones tpicas entre los usuarios de un sistema y ese mismo sistema. Representan el interfaz 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 sencillas 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)

Los casos de uso pueden tener relaciones con otros casos de uso. Los tres tipos de relaciones ms comunes entre casos de uso son:

<<include>> que especifica una situacin en la que un caso de uso tiene lugar dentro de otro caso de uso <<extends>> que especifica que en ciertas situaciones, o en algn punto (llamado punto de extensin) un caso de uso ser extendido por otro. Generalizacin que especifica que un caso de uso hereda las caractersticas del super caso de uso, y puede volver a especificar algunas o todas ellas de una forma muy similar a las herencias entre clases.

Actor Un actor es una entidad externa (de fuera del sistema) que interacciona con el sistema participando (y normalmente iniciando) en un caso de uso. Los actores pueden ser gente real (por ejemplo, usuarios del sistema), otros ordenadores 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 objetos Los diagramas de objetos son utilizados durante el proceso de Anlisis y Diseo de los sistemas informticos en la metodologa UML. Se puede considerar un caso especial de un diagrama de clases en el que se muestran instancias especficas de clases (objetos) en un momento particular del sistema. Los diagramas de objetos utilizan un subconjunto de los elementos de un diagrama de clase.

Los diagramas de objetos no muestran la multiplicidad ni los roles, aunque su notacin es similar a los diagramas de clase. Una diferencia con los diagramas de clase es que el compartimiento de arriba va en la forma Nombre de objeto: Nombre de clase. Objeto es una entidad discreta con lmites bien definidos y con identidad, es una unidad atmica que encapsula estado y comportamiento. La encapsulacin en un objeto permite una alta cohesin y un bajo acoplamiento. el Objeto es reconocido tambin como una instancia de la clase a la cual pertenece. La encapsulacin presenta tres ventajas bsicas: 1. 2. 3. Se protegen los datos de accesos indebidos El acoplamiento entre las clases se disminuye Favorece la modularidad y el mantenimiento

Un objeto se puede ver desde dos perspectivas relacionadas: como una entidad de un determinado instante de tiempo que posee un valor especfico (Un objeto puede caracterizar una entidad fsica -coche-) y como un poseedor de identidad que tiene distintos valores a lo largo del tiempo (abstracta -ecuacin matemtica-). Cada objeto posee su propia identidad exclusiva y se puede hacer referencia a l mediante una denominacin exclusiva que permite accederle. El Modelado de Objetos permite representar el ciclo de vida de los objetos a travs de sus interacciones. En UML, un objeto se representa por un rectngulo con un nombre subrayado.

Objeto = Identidad + Estado + Comportamiento El estado est representado por los valores de los atributos.

Un atributo toma un valor en un dominio concreto.

La regla general para la notacin de instancias consiste en utilizar el mismo smbolo geomtrico que el descriptor. En la instancia se muestran los posibles valores pero las propiedades compartidas slo se pone de manifiesto en el descriptor. La notacin cannica es un rectngulo con tres compartimientos. En el primero va el nombre del objeto, en el segundo sus atributos y en el tercero sus operaciones. Este ltimo puede ser omitido si as se prefiere. Oid (Object Identifier) Cada objeto posee un oid. El oid establece la identidad del objeto y tiene las siguientes caractersticas: Constituye un identificador nico y global para cada objeto dentro del sistema. Es determinado en el momento de la creacin del objeto. Es independiente de la localizacin fsica del objeto, es decir, provee completa independencia de localizacin. Es independiente de las propiedades del objeto, lo cual implica independencia de valor y de estructura. No cambia durante toda la vida del objeto. Adems, un oid no se reutiliza aunque el objeto deje de existir.

No se tiene ningn control sobre los oids y su manipulacin resulta transparente. Sin embargo, es preciso contar con algn medio para hacer referencia a un objeto utilizando referencias del dominio (valores de atributos). Caractersticas alrededor de un objeto: Estado: El estado evoluciona con el tiempo. Algunos atributos pueden ser constantes, el comportamiento agrupa las competencias de un objeto y describe las acciones y reacciones de ese objeto. Las operaciones de un objeto son consecuencia de un estmulo externo representado como mensaje enviado desde otro objeto. Persistencia: La persistencia de los objetos designa la capacidad de un objeto trascender en el espacio/tiempo, podremos despus reconstruirlo, es decir, cogerlo de memoria secundaria para utilizarlo en la ejecucin (materializacin del objeto). Los lenguajes OO no proponen soporte adecuado para la persistencia, la cual debera ser transparente, un objeto existe desde su creacin hasta que se destruya.

Comunicacin: Un sistema informtico puede verse como un conjunto de objetos autnomos y concurrentes que trabajan de manera coordinada en la consecucin de un fin especfico. El comportamiento global se basa pues en la comunicacin entre los objetos que la componen. Categoras de objetos:

Activos o Pasivos Cliente -- Servidores, Agentes

1. Objeto Activo: posee un hilo de ejecucin (thread) propio y puede iniciar una actividad. 2. Objeto Pasivo: no puede iniciar una actividad pero puede enviar estmulos una vez que se le solicita un servicio. 3. Cliente es el objeto que solicita un servicio. 4. Servidor es el objeto que provee el servicio solicitado. 5. Los agentes renen las caractersticas de clientes y servidores. Son la base del mecanismo de delegacin. Introducen indireccin: un cliente puede comunicarse con un servidor que no conoce directamente. Mensajes: La unidad de comunicacin entre objetos se llama mensaje. El mensaje es el soporte de una comunicacin que vincula dinmicamente los objetos que fueron separados previamente en el proceso de descomposicin. Adquiere toda su fuerza cuando se asocia al polimorfismo y al enlace dinmico. Un estmulo causar la invocacin de una operacin, la creacin o destruccin de un objeto o la aparicin de una seal. Un mensaje es la especificacin de un estmulo. Tipos de flujo de control: 1. 2. 3. 4. 5. 6. Llamada a procedimiento o flujo de control anidado Flujo de control plano Retorno de una llamada a procedimiento Otras variaciones Esperado (balking) Cronometrado (time-out)

Diagrama de colaboracin Un diagrama de colaboracin en las versiones de UML 1.x es esencialmente un diagrama que muestra interacciones organizadas alrededor de los roles. A diferencia de los diagramas de secuencia, los diagramas de colaboracion, tambien llamados diagramas de comunicacin, muestran explcitamente las relaciones de los roles. Por otra parte, un diagrama de comunicacin no muestra el tiempo como una dimensin aparte, por lo que

resulta necesario etiquetar con nmeros de secuencia tanto la secuencia de mensajes como los hilos concurrentes.

Muestra cmo las instancias especficas de las clases trabajan juntas para conseguir un objetivo comn. Implementa las asociaciones del diagrama de clases mediante el paso de mensajes de un objeto a otro. Dicha implementacin es llamada "enlace".

Un diagrama de comunicacin es tambin un diagrama de clases que contiene roles de clasificador y roles de asociacin en lugar de slo clasificadores y asociaciones. Los roles de clasificador y los de asociacin describen la configuracin de los objetos y de los enlaces que pueden ocurrir cuando se ejecuta una instancia de la comunicacin. Cuando se instancia una comunicacin, los objetos estn ligados a los roles de clasificador y los enlaces a los roles de asociacin. El rol de asociacin puede ser desempeado por varios tipos de enlaces temporales, tales como argumentos de procedimiento o variables locales del procedimiento. Los smbolos de enlace pueden llevar estereotipos para indicar enlaces temporales. Usos Un uso de un diagrama de colaboracin es mostrar la implementacin de una operacin. La comunicacin muestra los parmetros y las variables locales de la operacin, as como asociaciones ms permanentes. Cuando se implementa el comportamiento, la secuencia de los mensajes corresponde a la estructura de llamadas anidadas y el paso de seales del programa. Un diagrama de secuencia muestra secuencias en el tiempo como dimensin geomtrica, pero las relaciones son implcitas. Un diagrama de comunicacin muestra relaciones entre roles geomtricamente y relaciona los mensajes con las relaciones, pero las secuencias temporales estn menos claras. Tipos Es til marcar los objetos en cuatro grupos: los que existen con la interaccin entera; los creados durante la interaccin (restriccin {new}); los destruidos durante la interaccin (restriccin {destroyed}); y los que se crean y se destruyen durante la interaccin (restriccin {transient}). Aunque las comunicaciones muestran directamente la implementacin de una operacin, pueden tambin mostrar la realizacin de una clase entera. En este uso, muestran el contexto necesario para implementar todas las operaciones de una clase. Esto permite que el modelador vea los roles mltiples que los objetos pueden desempear en varias operaciones. No hay ejemplos de los diagramas, diferentes casos o sistemas

UML modela el negocio area o empresa asi como los sistemas que requieren ? Mensajes Los mensajes se muestran como flechas etiquetadas unidas a los enlaces. Cada mensaje tiene un nmero de secuencia, una lista opcional de mensajes precedentes, una condicin opcional de guarda, un nombre y una lista de argumentos y un nombre de valor de retorno opcional. El nombre de serie incluye el nombre (opcional) de un hilo. Todos los mensajes del mismo hilo se ordenan secuencialmente. Los mensajes de diversos hilos son concurrentes a menos que haya una dependencia secuencial explcita. Flujos Generalmente, un diagrama de comunicacin contiene un smbolo para un objeto durante una operacin completa. Sin embargo, a veces, un objeto contiene diferentes estados que se deban hacer explcitos. Por ejemplo, un objeto pudo cambiar de localizacin o sus asociaciones pudieron diferenciarse. Los diferentes smbolos de objeto que representan un objeto se pueden conectar usando flujos "become" o "conversion". Un flujo "become" es una transicin, a partir de un estado de un objeto a otro. Se dibuja como una flecha de lnea discontinua con el estereotipo "become" o "conversin" y puede ser etiquetado con un nmero de serie para mostrar cuando ocurre. Un flujo de conversin tambin se utiliza para mostrar la migracin de un objeto a partir de una localizacin a otra distinta para otro lugar tambien se deben marcar con el numero en secuencias.

Diagrama de secuencia En un diagrama de secuencia ponemos varios de los objetos o clases que forman parte de nuestro programa y ponemos qu llamadas van haciendo unos a otros para realizar una tarea determinada. Hacemos un diagrama de secuencia por cada caso de uso o para una parte de un caso de uso (lo que llamo subcaso de uso). En nuestro ejemplo de ajedrez, podemos hacer diagramas de secuencia para "jugar partida" o bien para partes de "jugar partida", como puede ser "mover pieza". El detalle del diagrama depende de la fase en la que estemos, lo que pretendamos contar con el diagrama y a quin. En una primera fase de diseo podemos poner clases grandes y ficticias, que representen un paquete/librera o, si nuestro programa est compuesto por varios ejecutables corriendo a la vez, incluso clases que representen un ejecutable.

Si estamos en una fase avanzada, estamos diseando el programa y queremos dejar bien atados los detalles entre dos programadores, que cada uno va a programar una de las clases que participan, entonces debemos posiblemente ir al nivel de clase real de codificacin y mtodo, con parmetros y todo, de forma que los programadores tengan claro que mtdos van a implementar, que deben llamar de la clase del otro, etc. Incluso si es un diagrama para presentar al cliente, podemos hacer un diagrama de secuencia en el que slo salga el actor "jugador" y una nica clase "juego ajedrez" que representa nuestro programa completo, de forma que el cliente vea qu datos y en qu orden los tiene que meter en el programa y vea qu salidas y resultados le va a dar el programa. El siguiente puede ser un diagrama de secuencia de nuestro ejemplo del ajedrez a un nivel de diseo muy preliminar.

Diagrama de secuencia El diagrama de secuencia es un tipo de diagrama usado para modelar interaccin entre objetos en un sistema segn UML. En ingls se pueden encontrar como "sequence diagram", "event-trace diagrams", "event scenarios" o "timing diagrams"1

Ejemplo de Diagrama de Secuencia

Utilidad Un diagrama de secuencia muestra la interaccin de un conjunto de objetos en una aplicacin a travs del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementacin del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes intercambiados entre los objetos. Tpicamente se examina la descripcin de un caso de uso para determinar qu objetos son necesarios para la implementacin del escenario. Si se dispone de la descripcin de cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qu objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con lneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales. Tipos de mensajes Existen dos tipos de mensajes: sincrnicos y asincrnicos. Los mensajes sincrnicos se corresponden con llamadas a mtodos del objeto que recibe el mensaje. El objeto que enva el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se representan con flechas con la cabeza llena. Los mensajes asincrnicos terminan

inmediatamente, y crean un nuevo hilo de ejecucin dentro de la secuencia. Se representan con flechas con la cabeza abierta. Tambin se representa la respuesta a un mensaje con una flecha discontinua. Pueden ser usados en dos formas:

De instancia: describe un escenario especifico (un escenario es una instancia de la ejecucin de un caso de uso). Genrico: describe la interaccin para un caso de uso; Utiliza ramificaciones ("Branches"), condiciones y bucles.

Estructura Los mensajes se dibujan cronolgicamente desde la parte superior del diagrama a la parte inferior; la distribucin horizontal de los objetos es arbitraria. Durante el anlisis inicial, el modelador tpicamente coloca el nombre 'business' de un mensaje en la lnea del mensaje. Ms tarde, durante el diseo, el nombre 'business' es reemplazado con el nombre del mtodo que est siendo llamado por un objeto en el otro. El mtodo llamado, o invocado, pertenece a la definicin de la clase instanciada por el objeto en la recepcin final del mensaje. Diagrama de estados Los diagramas de estado muestran el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicacin en respuesta a eventos (por ejemplo, mensajes recibidos, tiempo rebasado o errores), junto con sus respuestas y acciones. Tambin ilustran qu eventos pueden cambiar el estado de los objetos de la clase. Normalmente contienen: estados y transiciones. Como los estados y las transiciones incluyen, a su vez, eventos, acciones y actividades, vamos a ver primero sus definiciones. Al igual que otros diagramas, en los diagramas de estado pueden aparecer notas explicativas y restricciones Diagrama de actividad Un diagrama de Actividad demuestra la serie de actividades que deben ser realizadas en un uso-caso, as como las distintas rutas que pueden irse desencadenando en el uso-caso. Es importante recalcar que aunque un diagrama de actividad es muy similar en definicin a un diagrama de flujo (tpicamente asociado en el diseo de Software), estos no son lo mismo. Un diagrama de actividad es utilizado en conjuncin de un diagrama uso-caso para auxiliar a los miembros del equipo de desarrollo a entender como es utilizado el sistema y cmo reacciona en determinados eventos. Lo anterior, en contraste con un diagrama de flujo que ayuda a un programador a desarrollar cdigo a travs de una descripcin lgica de

un proceso. Se pudiera considerar que un diagrama de actividad describe el problema, mientras un diagrama de flujo describe la solucin. En la siguiente seccin se describen los diversos elementos que componen un diagrama de Actividad. Composicin Inicio: El inicio de un diagrama de actividad es representado por un crculo de color negro slido. Actividad: Una actividad representa la accin que ser realizada por el sistema la cual es representada dentro de un ovalo. Transicin: Una transicin ocurre cuando se lleva acabo el cambio de una actividad a otra, la transicin es representada simplemente por una lnea con una flecha en su terminacin para indicar direccin.

Diagrama de componentes Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de Modelado. Un diagrama de componentes representa cmo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes fsicos incluyen archivos, cabeceras, bibliotecas compartidas, mdulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema. Debido a que estos son ms parecidos a los diagramas de casos de usos estos son utilizados para modelar la vista esttica y dinmica de un sistema. Muestra la organizacin y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema. En l se situarn libreras, tablas, archivos, ejecutables y documentos que formen parte del sistema. Uno de los usos principales es que puede servir para ver qu componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema.

Caractersticas:

Los diagramas de componentes describen los elementos fsicos del sistema y sus relaciones Muestran las opciones de realizacin incluyendo cdigo fuente, binario y ejecutable Los componentes representan todos los tipos de elementos software que entran en la fabricacin de aplicaciones informticas Pueden ser simples archivos, paquetes, bibliotecas cargadas dinmicamente, etc.

Diagrama de despliegue El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para modelar 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 nodos dentro de un nodo. Este tipo de diagrama debemos tambin aadir que no van a existir actores para relacionarse con los nodos (no es un diagrama de casos de uso) si no que las relaciones que pueda haber siempre sern entre los 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 o modificada en un proyecto. Estos artefactos implementan colecciones de componentes. Los nodos internos indican ambientes, un concepto ms amplio que el hardware propiamente dicho, ya que un ambiente puede incluir al lenguaje 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 el que se ejecuta el sistema. Aunque UML no es un lenguaje de especificacin hardware de propsito general, se ha diseado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el software del sistema.

Caractersticas:

Los Diagramas de Distribucin muestran la disposicin fsica de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos Un nodo es un elemento fsico que existe en tiempo de ejecucin y representa un recurso computacional, que generalmente tiene algo de memoria y, a menudo, capacidad de procesamiento. Los nodos se utilizan para modelar la topologa del hardware sobre el que se ejecuta el sistema. Representa tpicamente un procesador o un dispositivo sobre el que se pueden desplegar los componentes. Los componentes son los elementos que participan en la ejecucin de un sistema. Los nodos son los elementos donde se ejecutan los componentes. Los componentes representan el empaquetamiento fsico de los elementos lgicos. Los nodos representan el despliegue fsico de los componentes. La relacin entre un nodo y el componente que despliega puede mostrarse con una relacin de dependencia, o listando los nodos desplegados en un compartimiento adicional dentro del nodo. Los estereotipos permiten precisar la naturaleza del equipo: Procesadores: Nodo con capacidad de procesamiento. Puede ejecutar un componente. Dispositivos: Nodo sin capacidad de procesamiento. Representa cualquier otro dispositivo hardware. Los nodos se relacionan mediante conexiones bidireccionales (en principio) que pueden a su vez estereotiparse. Las conexiones se modelan como asociaciones, con todas las caractersticas que implica.