MISIÓN: Satistacer totalmente las necesidades de logística y comunicacion integral de nuestros clientes, a traves de la excelencia en el servicio, el desarrollo integral de nuestros líderes de acción y el sentido de compromiso con nuestra familia y nuestro país.
VISIÓN:
Queremos que servientrega sea un modelo de empresa líder en servicios de logística y comunicación, por seguridad, oportunidad y cubrimiento en América
Hoy en día, UML ("Unified Modeling Language") está consolidado como el lenguaje estándar en el análisis y diseño de sistemas de cómputo. Mediante UML es posible establecer la serie de requerimientos y estructuras necesarias para plasmar un sistema de software previo al proceso intensivo de escribir código.
En otros términos, así como en la construcción de un edificio se realizan planos previo a su construcción, en Software se deben realizar diseños en UML previa codificación de un sistema, ahora bien, aunque UML es un lenguaje, éste posee más características visuales que programáticas, mismas que facilitan a integrantes de un equipo multidisciplinario participar e intercomunicarse fácilmente, estos integrantes siendo los analistas, diseñadores, especialistas de área y desde luego los programadores.
Complejidad / Objetos
Entre más complejo es el sistema que se desea crear más beneficios presenta el uso de UML ("Unified Modeling Language"), las razones de esto son evidentes, sin embargo, existen dos puntos claves : El primero se debe a que mediante un plano/visión global resulta más fácil detectar las dependencias y dificultades implícitas del sistema, y la segunda razón radica en que los cambios en una etapa inicial (Análisis) resultan más fáciles de realizar que en una etapa final de un sistema como lo sería la fase intensiva de codificación.
Puesto que UML es empleado en el análisis para sistemas de mediana-alta complejidad, era de esperarse que su base radique en otro paradigma empleado en diseños de sistemas de alto nivel que es la orientación a objetos, por lo que para trabajar en UML puede ser considerado un pre-requisito tener experiencia en un lenguaje orientado a objetos.
Hoy en día, entre los lenguajes orientados a objetos más utilizados se encuentran Java y C#, además de otros más antiguos como C++ y SmallTalk, aunque el programar en todos estos lenguajes requiere experiencia previa sobre la sintaxis y bloques específicos, el paradigma empleado en todos ellos es el mismo: Objetos.
Lo anterior permite que un análisis en UML sea realizado independiente del lenguaje en el que finalmente sea implementando el Sistema (Java,C#,C++,SmallTalk), misma característica que permite a personal no familiarizado en lenguajes de programación participen en el análisis y diseño de un sistema.
Conceptos / Diagramas
Entre los conceptos fundamentales de orientación a objetos se encuentran los siguientes:
·Un modelo es una abstracción del problema que se intenta resolver.
·Un dominio es el mundo de donde proviene el problema.
·Un modelo consiste de objetos que interactúan entre sí enviándose mensajes.
·Cada objeto posee características propias (atributos) y operaciones que puede realizar (métodos);los valores asignados a un objeto en determinado momento determinan su estado.
·Una clase es un molde para describir un objeto que agrupa características (atributos) y comportamientos (métodos).
·Los objetos son instancias de Clases.
A continuación se enumeran los 9 diagramas que forman la base de UML, y dictan la manera en que es diseñado un sistema:
Un diagrama Uso-Caso describe lo que hace un sistema desde el punto de vista de un observador externo, debido a esto, un diagrama de este tipo generalmente es de los más sencillos de interpretar en UML, ya que su razón de ser se concentra en un Que hace el sistema, a diferenciade otros diagramas UML que intentan dar respuesta a un Como logra su comportamiento el sistema.
Un Uso-Caso está muy relacionado con lo que pudiera ser considerado un escenario en el sistema, esto es, lo que ocurre cuando alguien interactúa con el sistema: "Acude un mesero a colocar la orden, la orden es tomada por el cocinero, y posteriormente se abona a la cuenta del cliente el cargo".
Un Uso-Caso es empleado con más frecuencia en alguna de las siguientes etapas:
·Determinación de Requerimientos: Por lo general nuevos requerimientos de sistema generan nuevos usos-casos, conforme es analizado y diseñado el sistema.
·Comunicación con el Cliente: Debido a la sencillez de este tipo de diagramas, son fáciles de emplear para comunicarse con el cliente final del proyecto.
·Generación de pruebas de Sistemas: A través de los diagramas uso-caso se pueden generar una serie de pruebas de sistema.
Composición
·Actor: Un actor representa quien o que inicia una acción dentro del sistema, en otras palabras, es simplemente un rol que es llevado a cabo por una persona o cosa. Un Actor en un diagrama Uso-Caso es representado por una figura en forma de persona.
·Uso-Caso: El uso-caso en sí es representado por un ovalo que describe la funcionalidad a grosso modo que se requiere por el sistema.
·Comunicación: Este elemento representa la relación que existe entre un Uso-Caso y un Actor, dicho elemento es representado simplemente por una línea recta que se extiende de la figura del actor hacia el ovalo del uso-caso.
·Limite de Sistema (System Boundry): Empleado para delimitar los límites del sistema, y representado por un rectángulo con color de fondo distintivo.
·Inclusión: Una inclusión es utilizada para indicar que un uso-caso (ovalo) depende de otro caso, dicho de otra manera, significa que la funcionalidad de determinado caso se requiere para realizar las tareas de otro. Este elemento es representado por una línea punteada con flecha y comentario <> que se extiende del uso-caso base hacia el uso caso de inclusión.
·Extensión:Una extensión representa una variación de un uso-caso a otro, una extensión representa una dependencia específica. Este elemento es representado por una línea punteada con flecha y comentario <> que origina del uso-caso base hacia el uso caso de extensión.
Ilustración
En un diagrama de casos de uso presentamos en una caja el programa que estamos haciendo. Dentro de esa caja dibujamos unas elipses indicando qué cosas puede hacer alguien que use nuestro programa. Ese alguien puede ser una persona que use el programa, un aparato externo que se comunique con nuestro programa para recoger o enviar datos o incluso otro programa que no tenga nada que ver con nosotros. Estos agentes externos a nuestro programa y que "hablan" con él se llaman actores. También los dibujamos, como unos pequeños "monigotes", en nuestro diagrama de casos de uso, con unas líneas indicando qué cosas puede hacer cada uno.
Como todos los diagramas de UML, no hay un diagrama correcto o no. Simplemente hay un diagrama que expresa algo a alguien. El diagrama está bien si es lo suficientemente claro como para que se entienda. Con esto quiero decir que no es necesario poner un diagrama de casos de uso con TODOS los casos de uso. Es mejor un diagrama con unos pocos casos de uso importantes, de forma que se puedan leer bien. Si hay muchos casos de uso, es mejor partirlo en varios diagramas por temas, por cada actor, por cada tipo de cosa que se puede hacer.
Los actores no tienen por qué ser personas físicamente distintas. Son simplemente "papeles" distintos que puede desempeñar una misma persona. Por ejemplo, si "Felipe Elipe" compra nuestro programa, unas veces hará de jugador y otras veces hará de maestro.
Cuando vamos entrando en el diseño más detallado, es posible que podamos extraer casos de uso secundarios, no tan importantes, pero que nos pueden ayudar a la hora de codificar u organizar las cosas. Por ejemplo, en el caso anterior podemos sacar un subcaso de uso "mover pieza". Tanto el maestro como el jugador tendrán que "mover pieza" cuando enseñan una apertura o cuando están jugando una partida. Los casos de uso "jugar partida" y "enseñar apertura" tendrán unas líneas que los unen con "mover pieza", indicando que para "jugar partida" hay que "mover pieza".
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 definición a un diagrama de flujo (típicamente asociado en el diseño de Software), estos no son lo mismo. Un diagrama de actividad es utilizado en conjunción de un diagrama uso-caso para auxiliar a los miembros del equipo de desarrollo a entender como es utilizado el sistema y cómo reacciona en determinados eventos. Lo anterior, en contraste con un diagrama de flujo que ayuda a un programador a desarrollar código a través de una descripción lógica de un proceso. Se pudiera considerar que un diagrama de actividad describe el problema, mientras un diagrama de flujo describe la solución.
Composición
·Inicio: El inicio de un diagrama de actividad es representado por un círculo de color negro sólido.
·Actividad: Una actividad representa la acción que será realizada por el sistema la cual es representada dentro de un ovalo.
·Transición: Una transición ocurre cuando se lleva a cabo el cambio de una actividad a otra, la transición es representada simplemente por una línea con una flecha en su terminación para indicar dirección.
Ramificación (Branch): Una ramificación ocurre cuando existe la posibilidad que ocurra más de una transición (resultado) al terminar determinada actividad. Este elemento es representado a través de un rombo.
Unión (Merge): Una unión ocurre al fusionar dos o más transiciones en una sola transición o actividad. Este elemento también es representado a través de un rombo.
Expresiones Resguardadas (Guard Expressions) : Una expresión resguardada es utilizada para indicar una descripción explicita acerca de una transición. Este tipo de expresión es reprsentada mediante corchetes ([...] y es colocada sobre la linea de transición.
Fork: Un fork representa una necesidad de ramificar una transición en más de una posibilidad. Aunque similar a una ramificación (Branch) la diferencia radica en que un fork representa más de una ramificación obligada, esto es, la actividad debe proceder por ambos o más caminos, mientras que una ramificación (Branch) representa una transición u otra para la actividad (como una condicional). Un fork es representado por una línea negra solida, perpendicular a las líneas de transición.
Join: Una join ocurre al fusionar dos o más transiciones provenientes de un fork, y es empleado para dichas transiciones en una sola,tal y como ocurria antes de un fork .Un fork es representado por una linea negra solida, perpendicualar a las lineas de transición .
Fin : El fin de un diagrama de actividad es representado por un círculo, con otro circulo concentrico de color negro sólido.
Canales (Swimlanes) : En determinadas ocasiones ocurre que un diagrama de actividad se expanda a lo largo de más de un entidad o actor, cuando esto ocurre el diagrama de actividad es particionada en canales (swimlines), donde cada canal representa la entidad o actor que está llevando a cabo la actividad.
Un diagrama de actividades puede considerarse como un caso especial de un diagrama de estados en el cual casi todos los estados son estados acción (identifican una acción que se ejecuta al estar en él) y casi todas las transiciones evolucionan al término de dicha acción (ejecutada en el estado anterior). Un diagrama de actividades puede dar detalle a un caso de uso, un objeto o un mensaje en un objeto. Permiten representar transiciones internas al margen de las transiciones o eventos externos. En la figura 5.7 se presenta un ejemplo de diagrama de actividades para un mensaje de un objeto.
La interpretación de un diagrama de actividades depende de la perspectiva considerada: en un diagrama conceptual, la actividad es alguna tarea que debe ser realizada; en un diagrama de especificación o de implementación, la actividad es un método de una clase. Generalmente se suelen utilizar para modelar los pasos de un algoritmo.
Figura 5.7: Ejemplo de diagrama de actividades
Un estado de acción representa un estado con acción interna, con por lo menos una transición que identifica la culminación de la acción (por medio de un evento implícito). No deben tener transiciones internas ni transiciones basadas en eventos, ya que si fuera este el caso, se representaría con un diagrama de estados. Los estados de acción se representan por un rectángulo con bordes redondeados, y permiten modelar un paso dentro de un algoritmo.
Las flechas dirigidas entre estados de acción representan transiciones con evento implícito que, en el caso de decisiones, pueden tener una condición o guarda asociada (que al igual que en los diagramas de estado evalúa a true o a false).
Las decisiones se representan mediante una transición múltiple que sale de un estado y donde cada camino tiene una etiqueta distinta. Se representa mediante un rombo al cual llega la transición del estado origen y del cual salen las múltiples transiciones de los estados destino. Un ejemplo se muestra en la figura 5.7 cuando no hay café y se toma una decisión entre hay cola o no hay cola.
En un diagrama de actividades también pueden existir barras de sincronización (synchronization bar), como la que sigue a [found cofee] en la figura 5.7, a las que se encuentran asociadas varios caminos salientes. Cada camino saliente se dirige a una actividad (Put Coffee in Filter, Add Water to Reservoir y Get Cups), realizándose dichas actividades en paralelo. Esto quiere decir que el orden en que se realicen dichas actividades es irrelevante, siendo válido cualquier orden entre ellas.
Dado que el diagrama de actividades permite expresar el orden en que se realizan las cosas, resulta adecuado para el modelado de organizaciones (business modeling) y el de programas concurrentes (permiten representa gráficamente los hilos de ejecución).
Como la mayoría de las técnicas de modelado de comportamiento, los diagramas de actividades tienen sus puntos fuertes y sus puntos débiles, de forma que es necesario utilizarlos en combinación con otras técnicas. Su principal aportación al modelado del comportamiento es que soportan el comportamiento paralelo, lo que resulta adecuado para el modelado de flujo de trabajo ( workflow) y programación multihilo (multi-thread). Por contra, su principal desventaja es que no muestran de una forma clara los enlaces existentes entre las acciones y los objetos, siendo mucho más apropiado para ello los diagramas de interacción.
En general resulta adecuado utilizar diagramas de actividades para:
Análisis de casos de uso: Durante el an'alisis de los casos de uso no estamos interesados en asociar acciones a objetos, sino en entender qué acciones se necesitan llevar a cabo y cuales son las dependencias en el comportamiento.
Comprensión del flujo de trabajo a lo largo de diferentes casos de uso.
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 quién. En una primera fase de diseño podemos poner clases grandes y ficticias, que representen un paquete/librería 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 diseñando 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 codificación y método, con parámetros y todo, de forma que los programadores tengan claro que métodos 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 sólo 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 diseño muy preliminar.
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 quién. En una primera fase de diseño podemos poner clases grandes y ficticias, que representen un paquete/librería 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 diseñando 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 codificación y método, con parámetros y todo, de forma que los programadores tengan claro que métodos 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 sólo 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 diseño muy preliminar.
Aquí ya hemos decidido que vamos a hacer tres librerías/paquetes, una para la interface de usuario, otra para contener el tablero y reglas del ajedrez (movimientos válidos y demás) y otra para el algoritmo de juego del ordenador. Hemos puesto una clase representando cada uno de los paquetes y hemos representado el caso de usa "mover pieza".
En el diagrama de secuencia no se ponen situaciones erróneas (movimientos inválidos, jaques, etc) puesto que poner todos los detalles puede dar lugar a un diagrama que no se entiende o difícil de leer. El diagrama puede acompañarse con un texto en el que se detallen todas estas situaciones erróneas y particularidades. Si se quiere dejar muy claro que un determinado error se contempla, por ejemplo, un movimiento no válido por el usuario, entonces sí se puede poner en el diagrama de secuencia, siempre que no "embarulle" demasiado.
En este diagrama sencillo ya vamos dejando algunas cosas claras, como por ejemplo, que la interface de usuario hace llamadas y, por tanto, ve a los otros dos, mientras que algoritmo sólo ve al tablero/reglas. El tablero/reglas aparentemente ve a la interface de usuario, pero no nos interesa si seguimos un patrón modelo-vista-controlador, así que ese "Refresca pantalla" lo implementaremos con un patrón observador, pero eso son detalles que quizás no vienen al caso ahora.
Un diagrama de colaboración es una forma de representar interacción entre objetos, alterna al diagrama de secuencia. A diferencia de los diagramas de secuencia, pueden mostrar el contexto de la operación (cuáles objetos son atributos, cuáles temporales, ... ) y ciclos en la ejecución. Se toma como ejemplo el caso de uso PedirProducto ya descrito como diagrama de secuencia.
Objeto
Un objeto se representa con un rectángulo, que contiene el nombre y la clase del objeto en un formato nombreObjeto: nombreClase.
Enlaces
Un enlace es una instancia de una asociación en un diagrama de clases. Se representa como una linea contínua que une a dos objetos. Esta acompañada por un número que indica el orden dentro de la interacción y por un estereotipo que indica que tipo de objeto recibe el mensaje. Pueden darse varios niveles de subindices para indicar anidamiento de operaciones. Los estereotipos indican si el objeto que recibe el mensaje es un atributo (association y se asume por defecto), un parámetro de un mensaje anterior, si es un objeto local o global.
Flujo de mensajes
Expresa el envío de un mensaje. Se representa mediante una flecha dirigida cercana a un enlace.
Marcadores de creación y destrucción de objetos
Puede mostrarse en la gráfica cuáles objetos son creados y destruidos, agregando una restricción con la palabra new o delete, respectivamente, cercana al rectángulo del objeto
Objeto compuesto
Es una representación alternativa de un objeto y sus atributos. En esta representación se muestran los objetos contenidos dentro del rectángulo que representa al objeto que los contiene. Un ejemplo es el siguiente objeto ventana
Conceptos avanzados en un Diagrama de Colaboración
Patrón de diseño
Un diagrama de colaboración puede especificar un contrato entre objetos, parte esencial para la descripción de un patrón de diseño. Este diagrama contiene todos los elementos citados de un diagrama de colaboración, dejándo libres posiblemente los tipos exactos de algunos objetos o con nombres genéricos para los mensajes. Una "instanciación" del patrón se representa como una elipse unida mediante flechas puenteadas a los objetos o clases que participan realmente en el patrón. Estas flechas pueden tener roles, indicando cuál es el papel de cada elemento dentro del patrón. Por ejemplo, una instanciación del patrón de observador puede verse como
Contexto
Un contexto es una vista de uno o más elementos dentro del modelo que colaboran en el desarrollo de una acción. Se usa para separar los demás elementos en el modelo de este problema en particular y darle énfasis. Puede mostrar solo los detalles relevantes de las clases u objetos que contiene, para resaltar su utilidad. Un ejemplo es la definición del siguiente tipo:
Se representa como un contexto un tipo Registro de Dinero y se muestran los detalles relevantes de Producto, Item y Venta para este tipo. Las relaciones de las clases con otras no visibles dentro del contexto pueden omitirse o conectarse al borde del contexto.
Objeto activo
Un objeto activo es el que contiene su propio flujo de control, a diferencia de un objeto pasivo que encapsula datos y solo reacciona al enviarle mensajes. Un objeto activo se representa con un rectángulo de bordes gruesos. Puede contener otros objetos pasivos o activos. Se presenta a continuación un ejemplo en el contexto de una producción en línea robotizada. Se tiene un ente administrador, un robot y un horno (tres objetos activos) que interactúan para desarrollar su tarea.
Los mensajes entre objetos pasivos se denotan mediante una flecha completa, mientras que los mensajes entre objetos activos se denotan con una media flecha. Los trheads de ejecución se denotan con las letras A y B antes del número de orden del mensaje. La sincronización entre threads se muestra mediante un '/ ' y el nuevo númoer de orden. Por ejemplo en A2, B2 / 2: completed( job ).
Un diagrama de implementación muestra las dependencias entre las partes de código del sistema (diagrama de componentes) o la estructura del sistema en ejecución (diagrama de despliegue): los diagramas de componentes se utilizan para modelar la vista de implementación estática de un sistema, mientras que los diagramas de despliegue se utilizan para modelar la vista de despliegue estática.
Diagrama de Componentes
Lo que distingue a un diagrama de componentes de otros tipos de diagramas es su contenido. Normalmente contienen componentes, interfaces y relaciones entre ellos. Y como todos los diagramas, también puede contener paquetes utilizados para agrupar elementos del modelo.
Un diagrama de componentes muestra las organizaciones y dependencias lógicas entre componentes software, sean éstos componentes de código fuente, binarios o ejecutables. Desde el punto de vista del diagrama de componentes se tienen en consideración los requisitos relacionados con la facilidad de desarrollo, la gestión del software, la reutilización, y las restricciones impuestas por los lenguajes de programación y las herramientas utilizadas en el desarrollo. Los elementos de modelado dentro de un diagrama de componentes serán componentes y paquetes. En cuanto a los componentes, sólo aparecen tipos de componentes, ya que las instancias específicas de cada tipo se encuentran en el diagrama de despliegue (6.1.2).
Dado que los diagramas de componentes muestran los componentes software que constituyen una parte reusable, sus interfaces, y su interrelaciones, en muchos aspectos se puede considerar que un diagrama de componentes es un diagrama de clases a gran escala. Cada componente en el diagrama debe ser documentado con un diagrama de componentes más detallado, un diagrama de clases, o un diagrama de casos de uso.
Un paquete en un diagrama de componentes representa un división física del sistema. Los paquetes se organizan en una jerarquía de capas donde cada capa tiene una interfaz bien definida. Un ejemplo típico de una jerarquía en capas de este tipo es: Interfaz de usuario; Paquetes específicos de la aplicación; Paquetes reusables; Mecanismos claves; y Paquetes hardware y del sistema operativo.
Un diagrama de componentes se representa como un grafo de componentes software unidos por medio de relaciones de dependencia (generalmente de compilación). Puede mostrar también que un componente software contiene una interfaz, es decir, la soporta. Un ejemplo es el de la figura 6.1.
Figura 6.1: Ejemplo de diagrama de componentes
En el caso de la figura 6.1 tenemos tres componentes, GUI que depende de interfaz, update provista por Planner, Planner dependiendo de la interfaz y reservations provista por Scheduler.
Normalmente los diagramas de componentes se utilizan para modelar código fuente, versiones ejecutables, bases de datos físicas, entre otros:
Código fuente: En el modelado de código fuentes se suelen utilizar para representar las dependencias entre los ficheros de código fuente, o para modelar las diferentes versiones de estos fichero. Para ello se deben identificar el conjunto de archivos de código fuente de interés y estereotiparlos como archivos file, agruparlos en paquetes, utilizar valores etiquetados para la información de versiones y modelar las dependencias de compilación.
Código ejecutable: Se utiliza para modelar la distribución de una nueva versión a los usuarios. Para tal propósito se identifican el conjunto de componentes ejecutables que intervienen, se utilizan estereotipos para los diferentes tipos de componentes (ejecutables, bibliotecas,tablas,archivos, documentos, etc), se consideran las relaciones entre dichos componentes que la mayoría de las veces incluirán interfaces que son exportadas (realizadas) por ciertos componentes e importadas (utilizadas) por otros.
Bases de datos física: UML permite el modelado de bases de datos físicas así como de los esquemas lógicos de bases de datos.
Así si tenemos en cuenta las dependencas asociadas al proceso de compilación un componente podría ser:
Código fuente que depende de otros componentes (no necesariamente código fuente) que deben estar disponibles durante la compilación del componente.
Código objeto binario, como por ejemplo una librería, que puede depender de algún código objeto con el que se linka.
Código ejecutable que puede depender de otros programas ejecutables con los que interacciones en tiempo de ejecución.
Se pueden utilizar estereotipos como <> o <> para distingir la distinta naturaleza de las dependencias. Igualemte se pueden definir estereotipos para las distintas clases de componentes. UML proporciona algunos estereotipos predefinidos como: <>, <>, <>, <
> y document>>.
Diagrama de Despliegue
Un diagrama de despliegue muestra las relaciones físicas entre los componentes hardware y software en el sistema final, es decir, la configuración de los elementos de procesamiento en tiempo de ejecución y los componentes software (procesos y objetos que se ejecutan en ellos). Estarán formados por instancias de los componentes software que representan manifestaciones del código en tiempo de ejecución (los componentes que sólo sean utilizados en tiempo de compilación deben mostrarse en el diagrama de componentes).
Un diagrama de despliegue es un grafo de nodos unidos por conexiones de comunicación. Un nodo puede contener instancias de componentes software, objetos, procesos (caso particular de un objeto). En general un nodo será una unidad de computación de algún tipo, desde un sensor a un mainframe. Las instancias de componentes software pueden estar unidas por relaciones de dependencia, posiblemente a interfaces (ya que un componente puede tener más de una interfaz).
Figura: Ejemplo de diagrama de ejecución
Un ejemplo de diagrama de ejecución es el de la figura 6.2. En este caso se tienen dos nodos, AdminServer y Joe'sMachine. AdminServer contiene la instancia del componente Scheduler y un objeto activo (proceso) denominado meetingsDB. En Joe'sMachine se encuentra la instancia del componente softwarePlanner, que depende de la interfaz reservations, definida por Scheduler (figura 6.1).
Un nodo es un objeto físico en tiempo de ejecución que representa un recurso computacional, generalmente con memoria y capacidad de procesamiento. Pueden representarse instancias o tipos de nodos que se representa como un cubo 3D en los diagramas de implementación.
Las instancias de componentes de software muestran unidades de software en tiempo de ejecución y generalmente ayudan a identificar sus dependencias y su localización en nodos. Pueden mostrar también qué interfaces implementan y qué objetos contienen. Su representación es un rectángulo atravesado por una elipse y dos rectángulos más peque nos. Un ejemplo de componente que implementa dos interfaces es el de la figura 6.3.
Figura 6.3: Ejemplo de componente
Los diagramas de despliegue muestran la configuración en funcionamiento del sistema, incluyendo su hardware y su software. Para cada componente de un diagrama de despliegue se deben documentar las características técnicas requeridas, el tráfico de red esperado, el tiempo de respuesta requerido, etc.
La mayoría de las veces el modelado de la vista de despliegue estática implica modelar la topología del hardware sobre el que se ejecuta el sistema. Los diagramas de despliegue son fundamentalmente diagramas de clases que se ocupan de modelar los nodos de un sistema. Aunque UML no es un lenguaje de especificación hardware de propósito general, se ha dise nado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificarla plataforma sobre la que se ejecuta el software del sistema y para que un ingeniero de sistemas pueda manejar la frontera entre el hardware y el software cuando se trata de la relación entre hardware y software se utilizan los diagramas de despliegue para razonar sobre la topología de procesadores y dispositivos sobre los que se ejecuta el software.
Esta vista cubre principalmente la distribución, entrega e instalación de las partes que configuran un sistema físico. Los diagramas de despliegue se suelen utilizar para modelar:
Sistemas empotrados: Un sistema empotrado es un colección de hardware con una gran cantidad de software que interactúXa con el mundo físico. Los sistemas empotrados involucran software que controla dispositivo (motores,actuadores) que a su ves están controlados por estímulos externos como sensores.
Sistemas cliente-servidor: Los sistemas cliente-servidor son un extremos del espectro de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de red de los clientes a los servidores y sobre la distribución física de los componentes software del sistemas a a través de nodos.
Sistemas completamente distribuidos: En el otro extremo encontramos aquellos sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen varios niveles de servidores Tales sistemas contienen a menudo varias versiones de componentes software, alguno de los cuales pueden incluso migrar de un nodo a otro. El dise no de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topología del sistema.
