Modelado para Desarrollo de Software

De WikiUDO

Unidad V - Análisis y Diseño de Sistemas de Información (071-4323)

Modelado para Desarrollo de Software, es el conjunto de herramientas utilizadas para tener una imagen o representación de un sistema real.

Contenido

¿Por que Modelamos?

Una entidad que produce de forma consistente software que satisface las necesidades de sus usuarios puede desarrollar el software de forma predecible y puntual con un uso eficiente y efectivo de recursos tanto humanos como materiales.

El producto principal de un equipo de desarrollo no son documentos ni reuniones muy importantes, es un buen software que satisfaga las necesidades de sus usuarios y la empresa.

Para desarrollar software rápido, efectiva y eficientemente es necesario:

  • Trabajo repetido.
  • Mínimo desecho de software.
  • Gente apropiada.
  • Enfoque apropiado.
  • Herramientas apropiadas.
  • Considerar las necesidades del problema y tecnología.

El modelado es una parte central de todas las actividades que conducen a la producción de buen software.Construimos modelos para:

  • Comunicar la estructura deseada y el comportamiento de nuestro sistema.
  • Visualizar y controlar la arquitectura de nuestro sistema.
  • Comprender qué estamos construyendo, muchas veces descubriendo oportunidades para la simplificación y reutilización.
  • Controlar el riesgo.

Importancia de Modelar

De acuerdo al tipo de emprendimiento, tanto en su tamaño como en características se necesitará de distintas herramientas, procesos, arquitectura, recursos humanos y las tecnologías. El truco está en crear el software apropiado y en imaginar cómo escribir menos software. Un proyecto puede ser concebido con respecto a su tamaño en un programa pequeño, y crecer enormemente, pero si no se han tenido en cuenta, previamente la arquitectura, el proceso o las herramientas, este colapse.

El modelado es común en los proyectos software exitosos.El modelado es una técnica de ingeniería probada y bien aceptada. Nos ayuda a:

  • Visualizar a sus usuarios el producto final.
  • Comprender mejor el sistema.
  • Comunicar las ideas a otros.

¿Que es un modelo?

Un Modelo es la simplificación de la realidad .Pueden involucrar planos detallados como planos más generales que ofrecen una visión global del sistema en consideración.

Construimos modelos para comprender mejor el sistema que estamos desarrollando. A través del modelado se consiguen cuatro objetivos:

  • Nos ayuda a visualizar como es ó queremos que sea un sistema.
  • Nos permite especificar la estructura ó el comportamiento de un sistema.
  • Nos proporcionan plantillas que nos guían en la construcción de un sistema.
  • Documentan las decisiones que hemos tomado.

El modelado es útil tanto en pequeños como en grandes sistemas. Mientras más grande y complejo sea el sistema el modelado se hace importante por una simple razón, construimos modelos de sistemas complejos porque no podemos comprender el sistema en su totalidad. A través del modelado, reducimos el problema que se está estudiando, centrándonos en un solo aspecto a la vez. Se puede modelar formal e informalmente, pero este último no proporciona un lenguaje común que se pueda compartir fácilmente con otros. Mientras más complejo sea el sistema, requiere modelaje. Si se construye un sistema simple y este es sencillo al principio no se piensa que este necesite de modelaje, pero si este evoluciona y crece, se lamentará no haberlo realizado.

Principios básicos del modelado

Existen cuatro principios básicos, estos principios son fruto de la experiencia en todas las ramas de la ingeniería.

  • La elección de qué modelos se creen influye directamente sobre cómo se acomete el problema. Hay que seleccionar el modelo adecuado para cada momento y dependiendo de que modelo se elija se obtendrán diferentes beneficios y diferentes costes. En la industria software se ha comprobado que un modelado orientado a objetos proporciona unas arquitecturas más flexibles y readaptables que otros por ejemplo orientados a la funcionalidad o a los datos.
  • Todo modelo puede ser expresado a diferentes niveles de precisión. Esto es necesario poder seleccionar el nivel de detalle que se desea ya que en diferentes partes de un proyecto y en diferentes etapas se tendrán unas determinadas necesidades
  • Los mejores modelos están ligados a la realidad. Lo principal es tener modelos que nos permitan representar la realidad lo más claramente posible, pero no sólo esto, tenemos quesaber, exactamente cuando se apartan de la realidad para no caer en la ocultación de ningún detalle importante.
  • Un único modelo no es suficiente. Cualquier sistema que no sea trivial se afronta mejor desde pequeños modelos casi independientes, que los podamos construir y estudiar independientemente y que nos representen las partes más diferenciadas del sistema y sus interrelaciones. 1

Modelado de Objetos

En la especificación del UML podemos comprobar que una de las partes que lo componen es un metamodelo formal. Un metamodelo es un modelo que define el lenguaje para expresar otros modelos. Un modelo en orientacion a objetos es una abstracción cerrada semánticamente de un sistema y un sistema es una colección de unidades conectadas que son organizadas para realizar un propósito específico. Un sistema puede ser descripto por uno o más modelos, posiblemente desde distintos puntos de vista.

Una parte del UML define, entonces, una abstracción con significado de un lenguaje para expresar otros modelos (es decir, otras abstracciones de un sistema, o conjunto de unidades conectadas que se organizan para conseguir un propósito). Lo que en principio puede parecer complicado no lo es tanto si pensamos que uno de los objetivos del UML es llegar a convertirse en una manera de definir modelos, no sólo establecer una forma de modelo, de esta forma simplemente estamos diciendo que UML, además, define un lenguaje con el que podemos abstraer cualquier tipo de modelo.

El UML es una técnica de modelado de objetos y como tal supone una abstracción de un sistema para llegar a construirlo en términos concretos. El modelado no es más que la construcción de un modelo a partir de una especificación.

Un modelo es una abstracción de algo, que se elabora para comprender ese algo antes de construirlo. El modelo omite detalles que no resultan esenciales para la comprensión del original y por lo tanto facilita dicha comprensión.

Los modelos se utilizan en muchas actividades de la vida humana: antes de construir una casa el arquitecto utiliza un plano, los músicos representan la música en forma de notas musicales, los artistas pintan sobre el lienzo con carboncillos antes de empezar a utilizar los óleos, etc. Unos y otros abstraen una realidad compleja sobre unos bocetos, modelos al fin y al cabo. La OMT, por ejemplo, intenta abstraer la realidad utilizando tres clases de modelos OO: el modelo de objetos, que describe la estructura estática; el modelo dinámico, con el que describe las relaciones temporales entre objetos; y el modelo funcional que describe las relaciones funcionales entre valores. Mediante estas tres fases de construcción de modelos, se consigue una abstracción de la realidad que tiene en sí misma información sobre las principales características de ésta.

Los modelos además, al no ser una representación que incluya todos los detalles de los originales, permiten probar más fácilmente los sistemas que modelan y determinar los errores. Según se indica en la Metodología OMT (Rumbaugh), los modelos permiten una mejor comunicación con el cliente por distintas razones:

  • Es posible enseñar al cliente una posible aproximación de lo que será el producto final.
  • Proporcionan una primera aproximación al problema que permite visualizar cómo quedará el resultado.
  • Reducen la complejidad del original en subconjuntos que son fácilmente tratables por separado.

Se consigue un modelo completo de la realidad cuando el modelo captura los aspectos importantes del problema y omite el resto. Los lenguajes de programación que estamos acostumbrados a utilizar no son adecuados para realizar modelos completos de sistemas reales porque necesitan una especificación total con detalles que no son importantes para el algoritmo que están implementando. En OMT se modela un sistema desde tres puntos de vista diferentes donde cada uno representa una parte del sistema y una unión lo describe de forma completa. En esta técnica de modelado se utilizó una aproximación al proceso de implementación de software habitual donde se utilizan estructuras de datos (modelo de objetos), las operaciones que se realizan con ellos tienen una secuencia en el tiempo (modelo dinámico) y se realiza una transformación sobre sus valores (modelo funcional).

Lenguaje Unificado de Modelado (UML)

El Lenguaje Unificado de Modelado (UML por sus siglas en ingles) prescribe un conjunto de notaciones y diagramas estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos significan. Mientras que ha habido muchas notaciones y métodos usados para el diseño orientado a objetos, ahora los modeladores sólo tienen que aprender una única notación.3

¿Por que es necesario el UML?

En los principios de la computación, los programadores no realizaban análisis muy profundos sobre el problema por resolver. Con frecuencia comenzaban a escribir el programa desde un principio y el código necesario se escribia conforma se requeria. Aunque anteriormente esto agregaba un aura de aventura al proceso, en la actualidad es inapropiado en los negocios de alto riesgo.

Hoy en dia, es necesario contar con un plan bien analizado. Un cliente tiene que comprender que es lo que hara un equipo de desarrolladores; además tiene que ser capaz de señalar cambios si no se han captado claramente sus necesidades (o si cambia de opinión durante el proceso). A su vez, el desarrollo es un esfuerzo orientado a equipos, por lo que cada uno de sus miembros tiene que saber que lugar toma su trabajo en la solución final (asi como saber cual es la solución general).

Conforme aumenta la complejidad del mundo, los sistemas informáticos también deberían crecer en complejidad. En ellos se encuentran diversas piezas de hardware y software que comunican a grandes distancias mediante una red, misma que esta vinculada a bases de datos que, a su vez contienen enormes cantidades de información.

La clave esta en organizar el proceso de diseño de tal forma que los analistas, clientes, desarrolladores y otras personas involucradas en el desarrollo del sistemas lo comprendan y convengan con el UML proporciona organización.

Otra característica del desarrollo de sistemas contemporáneo es reducir el periodo de desarrollo. Cuando los plazos se encuentran muy cerca uno del otro es absolutamente necesario contar con un diseño solido.

Hay otro aspecto de la vida moderna que demanda diseño solido: las adquisiciones corporativas. Cuando una empresa adquiere a otra, la nueva organización debe tener la posibilidad de modificar aspectos importantes de un proyecto de desarrollo que este en progreso (la herramienta de desarrollo, el lenguaje de codificación y otras cosas). Un ante proyecto bien diseñado facilitara la conversión. Si el diseño es solido, un cambio en la implementación procederá sin problemas.2

Concepción del UML

El UML es la creación de Grady Booch, James Rumbaugh e Ivar Jacobson. Estos caballeros, apodados “Los tres amigos”, trabajaban en empresas distintas durante la década de los años 80 y principios de los 90 y cada uno diseño su propia metodología para el análisis y diseño orientado a objetos. Sus metodologías predominaron sobre las de sus competidores. A mediados de los años 90 empezaron a intercambiar ideas entre si y decidieron desarrollar su trabajo en conjunto.

En 1994 Rumbaugh ingreso a Rational Software Corporation, donde ya trabajaba Booch. Jacobson ingreso a Rational un año después; el resto, como dicen es historia.

Los anteproyectos del UML empezaron a circular en la industria del software y las reacciones resultantes trajeron consigo considerables modificaciones. Conforme diversos coorporativos vieron que el UML era útil a sus propósitos, se conformo un consorcio del UML. Entre los miembros se encuentran DEC, Hewlet-Packard, Intellicorp, Microsoft, Oracle, Texas Instruments y Rational. En 1997 el consorcio produjo la versión 1.0 del UML y lo puso a consideración del OMG (grupo de administración de objetos) como respuesta a su propuesta para un lenguaje de modelado estándar.

El consorcio aumento y genero la versión 1.1, misma que se puso nuevamente a consideración del OMG. El grupo adopto esta versión a finales de 1997. El OMG se encargo de la conservación del UML y produjo otras dos versiones en 1998. El UML ha llegado a ser el estándar de facto de la industria del software, y su evolución continua.2

Visión General del UML

El lenguaje UML se compone de tres elementos básicos, los bloques de construcción, las reglas y algunos mecanismos comunes. Estos elementos interaccionan entre sí para dar a UML el carácter de completitud y no-ambigüedad que antes comentábamos. Los bloques de construcción se dividen en tres partes: Elementos, que son las abstracciones de primer nivel, Relaciones, que unen a los elementos entre sí, y los Diagramas, que son agrupaciones interesantes de elementos. Existen cuatro tipos de elementos en UML, dependiendo del uso que se haga de ellos: elementos estructurales, elementos de comportamiento, elementos de agrupación y elementos de anotación. Las relaciones, a su vez se dividen para abarcar las posibles interacciones entre elementos que se nos pueden presentar a la hora de modelar usando UML, estas son: relaciones de dependencia, relaciones de asociación, relaciones de generalización y relaciones de realización. Se utilizan diferentes diagramas dependiendo de qué, nos interese representar en cada momento, para dar diferentes perspectivas de un mismo problema, para ajustar el nivel de detalle, por esta razón UML soporta un gran numero de diagramas diferentes aunque, en la practica, sólo se utilicen un pequeño número de combinaciones.

UML proporciona un conjunto de reglas que dictan las pautas a la hora de realizar asociaciones entre objetos para poder obtener modelos bien formados, estas son reglas semánticas que afectan a los nombres, al alcance de dichos nombres, a la visibilidad de estos nombres por otros, a la integridad de unos elementos con otros y a la ejecución, o sea la vista dinámica del sistema.

UML proporciona una serie de mecanismos comunes que sirven para que cada persona o entidad adapte el lenguaje a sus necesidades, pero dentro de un marco ordenado y siguiendo unas ciertas reglas para que en el trasfondo de la adaptación no se pierda la semántica propia de UML. Dentro de estos mecanismos están las especificaciones, que proporcionan la explicación textual de la sintaxis y semántica de los bloques de construcción. Otro mecanismo es el de los adornos que sirven para conferir a los modelos de más semántica, los adornos son elementos secundarios ya que proporcionan más nivel de detalle, que quizá en un primer momento no sea conveniente descubrir. Las divisiones comunes permiten que los modelos se dividan al menos en un par de formas diferentes para facilitar la comprensión desde distintos puntos de vista, en primer lugar tenemos la división entre clase y objeto (clase es una abstracción y objeto es una manifestación de esa abstracción), en segundo lugar tenemos la división interfaz / implementación donde la interfaz presenta un contrato (algo que se va a cumplir de una determinada manera) mientras que la implementación es la manera en que se cumple dicho contrato. Por ultimo, los mecanismos de extensibilidad que UML proporciona sirven para evitar posibles problemas que puedan surgir debido a la necesidad de poder representar ciertos matices, por esta razón UML incluye los estereotipos, para poder extender el vocabulario con nuevos bloques de construcción, los valores etiquetados, para extender las propiedades un bloque, y las restricciones, para extender la semántica.1

Bloques de Construcción de UML

A continuación se van a describir todos los elementos que componen los bloques estructurales de UML, así como su notación, para que nos sirva de introducción y se vaya generando un esquema conceptual sobre UML. En temas sucesivos se tratará con más profundidad cada uno de los bloques.

Elementos Estructurales

Los elementos estructurales en UML, es su mayoría, son las partes estáticas del modelo y representan cosas que son conceptuales o materiales.

Clases

Una clase es una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Una clase implementa una o más interfaces. Gráficamente se representa como un rectángulo que incluye su nombre, sus atributos y sus operaciones.

Interfaz

Una interfaz es una colección de operaciones que especifican un servicio de una determinada clase o componente. Una interfaz describe el comportamiento visible externamente de ese elemento, puede mostrar el comportamiento completo o sólo una parte del mismo. Una interfaz describe un conjunto de especificaciones de operaciones (o sea su signatura) pero nunca su implementación. Se representa con un circulo, y rara vez se encuentra aislada sino que más bien conectada a la clase o componente que realiza

Colaboración

Define una interacción y es una sociedad de roles y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos. Las colaboraciones tienen una dimensión tanto estructural como de comportamiento. Una misma clase puede participar en diferentes colaboraciones. Las colaboraciones representan la implementación de patrones que forman un sistema. Se representa mediante una elipse con borde discontinuo.

Casos de Uso

Un caso de uso es la descripción de un conjunto de acciones que un sistema ejecuta y que produce un determinado resultado que es de interés para un actor particular. Un caso de uso se utiliza para organizar los aspectos del comportamiento en un modelo. Un caso de uso es realizado por una colaboración. Se representa como un elipse con borde continuo.

Nodos

Un nodo es un elemento físico que existe en tiempo de ejecución y representa un recurso computacional que, por lo general, dispone de algo de memoria y, con frecuencia, de capacidad de procesamiento. Un conjunto de componentes puede residir en un nodo.

Elementos de comportamiento

Los elementos de comportamiento son las partes dinámicas de un modelo. Se podría decir que son los verbos de un modelo y representan el comportamiento en el tiempo y en el espacio. Los principales elementos son los dos que siguen.

Interacción

Es un comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto particular para conseguir un propósito específico. Una interacción involucra otros muchos elementos, incluyendo mensajes, secuencias de acción (comportamiento invocado por un objeto) y enlaces (conexiones entre objetos). La representación de un mensaje es una flecha dirigida que normalmente con el nombre de la operación.

Maquinas de estados

Es un comportamiento que especifica las secuencias de estados por las que van pasando los objetos o las interacciones durante su vida en respuesta a eventos, junto con las respuestas a esos eventos. Una maquina de estados involucra otros elementos como son estados, transiciones (flujo de un estado a otro), eventos (que disparan una transición) y actividades (respuesta de una transición).

Elementos de agrupación

Forman la parte organizativa de los modelos UML. El principal elemento de agrupación es el paquete, que es un mecanismo de propósito general para organizar elementos en grupos. Los elementos estructurales, los elementos de comportamiento, incluso los propios elementos de agrupación se pueden incluir en un paquete.

Un paquete es puramente conceptual (sólo existe en tiempo de desarrollo). Gráficamente se representa como una carpeta conteniendo normalmente su nombre y, a veces, su contenido.1

Orientación a Objetos

La orientación a objetos es un paradigma de programación que facilita la creación de software de calidad por sus factores que potencian el mantenimiento, la extensión y la reutilización del software generado bajo este paradigma. Trata de amoldarse al modo de pensar del hombre y no al de la máquina, lo cual es posible gracias a la forma racional con la que se manejan las abstracciones que representan las entidades del dominio del problema, y a propiedades como la jerarquía o el encapsulamiento. Este tipo de orientación tiene como elemento fundamental al objeto, que no es más que la representación de un concepto para un programa, y contiene toda la información necesaria para abstraer dicho concepto: los datos que describen su estado y las operaciones que pueden modificar dicho estado, y determinan las capacidades del objeto.4

Un Objeto Consta de

  • Tiempo de vida: La duración de un objeto en un programa siempre está limitada en el tiempo. La mayoría de los objetos sólo existen durante una parte de la ejecución del programa. Los objetos son creados mediante un mecanismo denominado instanciación, y cuando dejan de existir se dice que son destruidos.
  • Estado: Todo objeto posee un estado, definido por sus atributos. Con él se definen las propiedades del objeto, y el estado en que se encuentra en un momento determinado de su existencia.
  • Comportamiento: Todo objeto ha de presentar una interfaz, definida por sus métodos, para que el resto de objetos que componen los programas puedan interactuar con él.4

Aspectos de la Orientación a Objetos

Abstracción

La abstracción es el proceso en el cual separamos las propiedades más importantes de un objeto, de las que no lo son. Es decir, por medio de la abstracción definimos las características esenciales de un objeto del mundo real, los atributos y comportamientos que lo definen como tal, para después modelarlo en un objeto de software.5

Herencia

Es la característica que permite un gran aumento en la reutilización de código, La posibilidad de crear nuevas clases basadas en otras pre-existentes, permite, entre otras cosas, crear bibliotecas genéricas, en base a las cuales realizar pequeños ajustes para adaptarlas a las necesidades puntuales de cada aplicación.5


Polimorfismo

Es la propiedad por la cual una entidad puede tomar diferentes formas. Generalmente está entidad es una clase, y la forma en que se consigue que tome diferentes formas es por medio de nombrar a los métodos de dicha clase con un mismo nombre pero con diferentes implementaciones.

Capacidad que tiene los objetos de una clase de responder al mismo mensaje o evento en función de los parámetros utilizados durante su invocación.5


Encapsulamiento

También referido como ocultación de la información, es la propiedad de la orientación a objetos que nos permite asegurar que la información de un objeto le es desconocida a los demás objetos en la aplicación.5

Vistas

La modularidad y ocultación de datos que permite deslindar los cambios de la representación interna del mundo exterior se basa en dos vistas para una clase-objeto. La visibilidad que se manejan son:

  • Pública (public)
  • Privada (private)
  • Protegida (protected)

Envió de Mensajes

Los mensajes son invocaciones a los métodos de los objetos. Un objeto es inútil si está aislado. El medio empleado para que un objeto interactúe con otro son los mensajes. Por medio de los mensajes que se le indica a los objetos la función a ejecutar.5

Relaciones entre Clases

Es posible interrelacionar dos o más clases (cada uno con características y objetivos diferentes).

Cardinalidad de Relaciones

En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relación y éstas pueden ser:

  • Uno o muchos: 1..* (1..n)
  • Cero o muchos: 0..* (0..n)
  • Número fijo: m (m denota el número). 6


Herencia (Especialización/Generalización)

Indica que una subclase hereda los métodos y atributos especificados por una Super Clase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Super Clase (public y protected).

Ejemplore.jpg
Ejemplo de Herencia de las Subclases Auto y Camioneta desde la Superclase Vehículo

En el ejemplo se especifica que Auto y Camión heredan de Vehículo, es decir, Auto posee las Características de Vehículo (Precio, VelMax, etc) además posee algo particular que es Descapotable, en cambio Camión también hereda las características de Vehiculo (Precio, VelMax, etc) pero posee como particularidad propia Acoplado, Tara y Carga.

Cabe destacar que fuera de este entorno, lo único "visible" es el método Características aplicable a instancias de Vehículo, Auto y Camión, pues tiene definición pública, en cambio atributos como Descapotable no son visibles por ser privados. 6

Agregación

Agregaci.jpg
Símbolo que representa Agregación

Para modelar objetos complejos, no bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación, tenemos dos posibilidades:

  • Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido está condicionado por el tiempo de vida del que lo incluye. Este tipo de relación es comúnmente llamada Composición (el Objeto base se construye a partir del objeto incluido, es decir, es "parte/todo").
  • Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es comúnmente llamada Agregación (el objeto base utiliza al incluido para su funcionamiento).
Ejemplo
Ejemplo_simb.jpg
Ejemplo de Agregación

En donde se destaca que:

  • Un Almacen posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias).
  • Cuando se destruye el Objeto Almacen también son destruidos los objetos Cuenta asociados, en cambio no son afectados los objetos Cliente asociados.
  • La composición (por Valor) se destaca por un rombo relleno.
  • La agregación (por Referencia) se destaca por un rombo transparente.

La flecha en este tipo de relación indica la navegabilidad del objeto referenciado. Cuando no existe este tipo de particularidad, la flecha se elimina. 6

Asociación

Asociacion.jpg
Símbolo que representa la Asociación

La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre sí. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro.

Ejemplo
Ejemplo_asociacion.jpg
Ejemplo de Asociación entre Cliente y Ordenes de Compra

Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una orden de compra sólo puede tener asociado un cliente. 6

Dependencia o Instanciación

Dependencia_o_Instanciaci%C3%B3n.jpg
Símbolo que representa la Instanciacion

Representa un tipo de relación muy particular, en la que una clase es instanciada (su instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada.

El uso más particular de este tipo de relación es para denotar la dependencia que tiene una clase de otra, como por ejemplo una aplicación grafica que instancia una ventana (la creación del Objeto Ventana está condicionado a la instanciación proveniente desde el objeto Aplicación):

Ejemplo_Dependencia_o_Instanciaci%C3%B3n.jpg
Ejemplo de Instanciacion


Cabe destacar que el objeto creado (en este caso la Ventana gráfica) no se almacena dentro del objeto que lo crea (en este caso la Aplicación). 6

Diagramas

Los diagramas se utilizan para representar diferentes perspectivas de un sistema, de forma que un diagrama, es una proyección del mismo. UML proporciona un amplio conjunto de diagramas que normalmente se usan en pequeños subconjuntos para poder representar las cinco vistas principales de la arquitectura de un sistema. 6

Diagrama de Clases

Muestran un conjunto de clases, interfaces y colaboraciones, así como sus relaciones. Estos diagramas son los más comunes en el modelado de sistemas orientados a objetos y cubren la vista de diseño estática o la vista de procesos estática (sí incluyen clases activas). 6

Clase

Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.).

En UML, una clase es representada por un rectángulo que posee tres divisiones:

Una_clase_es_representada_por_un_rect%C3%A1ngulo_que_posee_tres_divisiones.jpg
Representación de una Clase en UML

En donde:

  • Superior: Contiene el nombre de la Clase
  • Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser private, protected o public).
  • Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).

Ejemplo

Una Cuenta Corriente que posee como característica:

  • Balance

Puede realizar las operaciones de:

  • Depositar
  • Girar
  • Balance

El diseño asociado es:

El_dise%C3%B1o_asociado_es.jpg
Ejemplo de la Clase Cuenta en UML

Diagrama de Casos de Uso

Los diagramas de casos de uso documentan el comportamiento de un sistema desde el punto de vista del usuario. Por lo tanto los casos de uso determinan los requisitos funcionales del sistema, es decir, representan las funciones que un sistema puede ejecutar. Su ventaja principal es la facilidad para interpretarlos, lo que hace que sean especialmente útiles en la comunicación con el cliente

Elementos Basicos

  • Actores: Los actores representan un tipo de usuario del sistema. Se entiendo como usuario cualquier cosa externa que interactúa con el sistema. No tiene por qué ser un ser humano, puede ser otro sistema informático o unidades organizativas o empresas.
  • Caso de uso: Es una tarea que debe poder llevarse a cabo con el apoyo del sistema que se está desarrollando. Se representan mediante un óvulo. Cada caso de uso debe detallarse, habitualmente mediante una descripción textual.
  • Escenario: es una interacción entre el sistema y los actores, que puede ser descrito mediante una secuencia de mensajes. Un caso de uso es una generalización de un escenario. Los escenarios pueden y deben posteriormente documentarse mediante diagramas de secuencia.
  • Limites del sistema: Resulta útil dibujar los límites del sistema cuando se pretende hacer un diagrama de casos de uso para parte del sistema.
  • Asociaciones: Hay una asociación entre un actor y un caso de uso si el actor interactúa con el sistema para llevar a cabo el caso de uso.


Simbolos.png
Simbolos

Tipos de Asociaciones

Existen cuatro tipos de asociación o relaciones en los diagramas de casos de uso:

  • Include: Se puede incluir una relación entre dos casos de uso de tipo “include” si se desea especificar comportamiento común en dos o más casos de uso.
Fghj.png
Ejemplo de Include


  • Extend: Se puede incluir una relación entre dos casos de uso de tipo “include” si se desea especificar diferentes variantes del mismo caso de uso. Es decir, esta relación implica que el comportamiento de un caso de uso es diferente dependiendo de ciertas circunstancias. En principio esas variaciones pueden también mostrarse como diferentes descripciones de escenarios asociadas al mismo caso de uso.
Socio_biblioteca.png
Ejemplo de Extend


  • Generalizaciones: En un diagrama de casos de uso también pueden mostrarse generalizaciones (relaciones de herencia) para mostrar que diferentes elementos están relacionados como tipos de otros. Son aplicables a actores o casos de uso, pero para estos últimos la semántica es muy similar a las relaciones “extend”.
Bibliotec_invetigad.png
Ejemplo de Generalizaciones


  • Agrupamiento: Puede que en determinados diagramas de casos de uso sea necesario organizar los casos de uso, sobre todo en sistemas grandes que consten de varios subsistemas. La forma más directa de organización será agrupar los casos de uso que estén relacionados en un paquete

Casos de Uso Temporales

Los casos de uso tienen un actor que los inicia, y uno o más actores que participan de él. En muchos casos, el inicio de una determinada funcionalidad del sistema es provocado exclusivamente por el paso del tiempo.

Sit_de_ventas.png
Ejemplo de Casos de Uso Temporales

Diagramas de Estados

Los diagramas de estado describen gráficamente los eventos y los estados de los objetos. Los diagramas de estado son útiles, entre otras cosas, para indicar los eventos del sistema en los casos de uso, muestran los diferentes estados de un objeto durante su vida, y los estímulos que provocan los cambios de estado en un objeto.

  • Eventos: Es una ocurrencia que puede causar la transición de un estado a otro de un objeto. Esta ocurrencia puede ser una de varias cosas.
  1. Condición que toma el de verdadero o falso.
  2. Recepción de una señal de otro objeto en el modelo.
  3. Recepción de un mensaje.
  4. Paso de cierto período de tiempo, después de entrar al estado o de cierta hora y fecha particular.
  • Transición Simple: Es una relación de tres o más estados en una transición de múltiples fuentes o múltiples destinos y del siguiente formato:

Event-signature”[” guard – condition]”/” action – expresión “^" send - clause

  • Transición Interna: Es una transición que pertenece en el mismo estado en vez de involucrar dos estados distintos representa un evento que no causa cambio de estado se denota como una cadena adicional en el compartimiento de acciones del estado
  • Acciones:Podemos especificar la solicitud de un servicio a otro objeto como consecuencia de la transición se especifica al ejecutar una acción como consecuencia de entrar salir estar en un estado o por la ocurrencia de un evento.

Generalización de Estados

Podemos reducir la complejidad de estos diagramas usando la generalización de estados. Distinguimos así entre superestado y subestados. Un estado puede contener varios subestados disjuntos. Los subestados heredan las variables de estado y las transiciones externas. La agregación de estados es la composición de un estado a partir de varios estados independientes. La composición es concurrente por lo que el objeto estará en alguno de los estados de cada uno de los subestados concurrentes. La destrucción de un objeto es efectiva cuando el flujo de control del autómata alcanza un estado final no anidado. La llegada a un estado final anidado implica la subida al superestado asociado, no el fin del objeto.

  • Subestados: Un estado puede descomponerse en subestados, con transiciones entre ellos y conexiones al nivel superior. Las conexiones se ven al nivel inferior como estados de inicio o fin, los cuales se suponen conectados a las entradas y salidas del nivel inmediatamente superior.
  • Transacción Compleja: Una transición compleja relaciona tres o más estados en una transición de múltiples fuentes y/o múltiples destinos. Representa la subdivisión en threads del control del objeto o una sincronización. Se representa como una línea vertical de la cual salen o entran varias líneas de transición de estado.
  • Transición a estados anidados: Una transición de hacia un estado complejo (descrito mediante estados anidados) significa la entrada al estado inicial del subdiagrama. Las transiciones que salen del estado complejo se entienden como transiciones desde cada uno de los subestados hacia afuera (a cualquier nivel de profundidad).
  • Transiciones temporizadas: Las esperas son actividades que tienen asociada cierta duración. La actividad de espera se interrumpe cuando el evento esperado tiene lugar. Este evento desencadena una transición que permite salir del estado que alberga la actividad de espera. El flujo de control se transmite entonces a otro estado.

Adiciones de Detalles al Icono de Estado

El UML le da la opción de agregar detalles a la simbología. Así como es posible dividir símbolo de clase en 3 áreas, puede dividir el icono de estado de igual forma. El área superior contendrá el nombre del estado, el área central las variables del estado y el área inferior sus actividades.

Inicio_terminar.jpg
Ejemplo de Dividir el icono de estado

Diagramas de Secuencia

El Diagrama de Secuencia es uno de los diagramas más efectivos para modelar interacción entre objetos en un sistema, muestran la forma en que un grupo de objetos se comunican (interactúan) entre sí a lo largo del tiempo.

  • Línea de vida de un objeto (lifeline): La línea de vida de un objeto representa la vida del objeto durante la interacción. En un diagrama de secuencia un objeto se representa como una línea vertical punteada con un rectángulo de encabezado y con rectángulos a través de la línea principal que denotan la ejecución de métodos (activación). El rectángulo de encabezado contiene el nombre del objeto y el de su clase.
Persona.png
Ejemplo de un objeto
  • Activación: Muestra el período de tiempo en el cual el objeto se encuentra desarrollando alguna operación, bien sea por sí mismo o por medio de delegación a alguno de sus atributos. Se denota como un rectángulo delgado sobre la línea de vida del objeto.
  • Mensaje: El envío de mensajes entre objetos se denota mediante una línea sólida dirigida, desde el objeto que emite el mensaje hacia el objeto que lo ejecuta.
Mensajesdif.png
Ejemplo de Mensaje
  • Tiempos de transición: En un entorno de objetos concurrentes o de demoras en la recepción de mensajes, es útil agregar nombres a los tiempos de salida y llegada de mensajes.
Ejemplo_diagrama_de_frecuencia.png
Ejemplo de Tiempo de Transición


Formas de los Diagramas de Secuencia

  • Forma Genérica: Describe la iteración para un caso de uso; utiliza ramificaciones, condiciones y bucles.
  • Forma de Instancia: Describe un escenario especifico( un escenario es una instancia de la ejecución de los diagramas de uso)

Como Representar la Recursividad

En ocasiones un objeto un objeto cuenta con una operación que se invoca a si misma. A esto se le conoce como recursividad, y es una característica fundamental de varios lenguajes de programación.

Para representar esto en el UML, dibujara una flecha de mensaje fuera de la activación que signifique la operación, y un pequeño rectángulo sobrepuesto en la activación.

Calculadora_intereses.png
Ejemplo de Recursividad

Diagrama de Comunicación o Colaboración

Un diagrama de colaboración es esencialmente un diagrama que muestra interacciones organizadas alrededor de los roles. A diferencia de los diagramas de secuencia, los diagramas de colaboración, también llamados diagramas de comunicación, muestran explícitamente las relaciones de los roles. Un diagrama de colaboración es un diagrama de clases que contiene roles de clasificador y roles de asociación en lugar de solo clasificadores y asociaciones. Los roles de clasificador y los roles de asociación describen la configuración de los objetos y de los enlaces que pueden ocurrir cuando se ejecuta una instancia de la colaboración. Cuando se instancia la colaboración, los objetos están ligados a los roles de clasificador y los enlaces están ligados a los roles de asociación. El rol de asociación también puede ser desempeñado por varios tipos de enlaces temporales, tales como argumentos de procedimientos o variables locales de procedimiento.10

Simbologia del Diagrama de Colaboración

Simbolo Nombre Descripcion
Objeto_colaboracion.jpg Objeto Un objeto se representa con un rectángulo, que contiene el nombre y la clase del objeto
Enlaces.jpg 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
Flujo_de_mensajes.jpg Flujo de Mensajes Expresa el envío de un mensaje. Se representa mediante una flecha dirigida cercana a un enlace
Anidamiento.jpg Anidamiento Indica el orden dentro de la interacción
Iteracion.jpg Iteracion La iteración se indica con * seguido de una clausula de iteración opcional
Objeto_multiple.jpg Multiobjeto Colección de instancias u objetos
Objeto_activo.jpg 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.

Cambios de Estado

Un objeto dentro del diagrama de colaboración puede tener una transición de un estado a otro. Se utiliza el esteriotipo "conversion" o "become"

Cambios_de_estado.jpg
Ejemplo de Cambios de Estado en un Objeto

Crear y Destruir Objetos

Para mostrar la creación o la destrucción de un objeto se utilizan los estereotipos "crear" y "destruir" al mensaje que genera el objeto.

Crear_destruir.png
Ejemplo de Crear y Destruir Objeto

Iteracion sobre una colección

El indicador de multiplicidad * indica que el mensaje es enviado a cada objeto en la colección.

Multiple_objetos_uml.jpg
Ejemplo de Iteracion sobre múltiples objetos

Utilidad de los Diagramas de Colaboración

  • Maneja la comunicación entre los elementos del sistema.
  • Refleja como deben colaborar los objetos del sistema para llevar a cabo una operación.
  • Muestran cómo será implementada la operación
  • Son un medio el diseño de las clases del sistema.

Diagrama de Actividades

Un diagrama de actividades muestra un flujo de acciones, generalmente secuencial además presenta los resultados de dichas acciones.11

Diagrama_de_actividades.jpg
Ejemplo de Diagrama de Actividades


¿Para que sirve?

  • Capturar las acciones internas de un proceso
  • Capturar la especificación de un caso de uso
  • Mostrar flujos entre procesos del negocio


Elementos del Diagrama de Actividades

Elementos que se utilizan para la realización de un Diagrama de actividades.


Simbolo Nombre Descripcion
Nodo_Inicial.jpg Nodo Inicial Muestra el punto de partida del flujo de acciones
Actividad.jpg Acción Representa una actividad o acción. El nombre generalmente comienza con un verbo
Flujo_o_Transici%C3%B3n.jpg Flujo o Transición Muestra el orden de ejecución de las actividades
Nodo_final.jpg Nodo Final El final de todos los flujos de acciones en el diagrama
Decision.jpg Decisión Representa un punto en el flujo donde deben tomarse una decisión para saber con que actividad continuar. De un rombo de decisión salen dos o más flujos.
Union_UML.jpg Unión (Merge) A este punto llega una o más líneas y sale una sola. El proceso continua cuando cualquiera de los flujos llega a este punto
Fork_concurrencia.jpg (Fork) sincronización o concurrencia Es el comienzo de varias actividades que se realizan en paralelo. De la barra salen varias líneas
Join_concurrencia.jpg (Join) sincronización o concurrencia A esta barra llegan varias líneas y sale una sola. Indica que deben terminarse todas las actividades que llegan aquí para poder terminar
Indicaciones.jpg Indicaciones El símbolo para enviar información es un pentágono convexo y para recibir información es un pentágono cóncavo. Envía y recibe una indicación
Objeto_uml.jpg Objeto Representa un objeto que puede ser pasado de una actividad a otra


Marcos de Responsabilidades (Calles o Carriles)

Cuando se tienen un conjunto de actividades que están relacionadas, generalmente la relación esta dada por los actores que ejecutan las acciones. Para modelar esta relación se divide el diagrama en carriles o calles donde se visualizan quienes tienen las responsabilidades en un proceso.

Calles_o_Carriles.jpg
Ejemplo de Modelado con Calles

Diagramas Híbridos

Los Diagramas Híbridos permiten depurar una actividad para hacerla mas especifica. Estas actividades poseen símbolos que normalmente se asociarían con diferentes tipos de diagrama. Un diagrama hibrido también puede mostrar un diagrama de actividades dentro de un objeto.

Diagrama de Componentes

Un diagrama de componentes representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos, 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 los diagramas de componentes son más parecidos a los diagramas de casos de usos, éstos son utilizados para modelar la vista estática y dinámica de un sistema. Muestra la organización 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.12


Componente

Un componente es una parte física de un sistema (modulo, base de datos, programa ejecutable, etc.). Se puede decir que un componente es la materialización de una o más clases, porque una abstracción con atributos y métodos pueden ser implementados en los componentes.En un DC, un componente se representa con un rectángulo en el que se escribe su nombre y en él se muestran dos pequeños rectángulos al lado izquierdo.


Representación simple de un Componente

Representacion_simple_de_un_componente.png
Representación de un Componente


Representación expandida de un Componente

Los componentes se pueden agrupar en paquetes así como los objetos en clases, además pueden haber entre ellos relaciones de dependencia como:

  • Generalización
  • Asociación
  • Agregación
  • Realización


Representaci%C3%B3n_expandida_de_un_componente.png
Representación Expandida de un Componente

Estereotipos de Componentes

UML define cinco estereotipos estándar que se aplican en los componentes

  • Executable, componente que se puede ejecutar
  • Library, biblioteca de objetos estática o dinámica
  • Table, Componentes que representa una tabla de base de datos
  • File, componente que representa un documento que contiene código fuente o datos
  • Document, Comp. Que representa un documento.


Interfaces

Es el lazo de unión entre varios componentes.


Ejem_interfaz.png
Ejemplo de una Interfaz


Donde C es el nombre de la interfaz.


Las interfaces pueden representarse de varias formas, como vemos en la grafica:


Repreentaciones_de_la_interfaz.png
Representaciones de las interfaces


Además se pueden representar de dos maneras de forma icónica y expandida.


Representaciones_iconicas_y_expandidas.png
Interfaz iconica e Interfaz expandida


Simbologia de los Diagramas de Componentes

Simbologia utilizada para realizar los Diagramas de Componentes


Simbolo Nombre
Simbologia_de_los_componentes._puntos_de_entrada.png Puntos de Entrada
Simbologia_de_los_componente._relacion_de_uso.png Relación de Uso


Pasos para la elaboración de un Diagrama de Componentes

  • Previamente al diagrama de componentes debemos de tener hecho el diagrama de clases.
  • Se debe identificar a todos las clases que participaran en el sistema o subsistema a desarrollar.
  • Una vez identificado las clases, se procede a identificar sus métodos.
  • Estos métodos pasaran a ser módulos con líneas de código independientes.
  • Estos módulos serán los componentes de nuestro diagrama.
  • Estos componentes se relacionan entre sí por medio de sus interfaces.


Ventajas de un Diagrama de Componentes

  • Permite ver el modelado de un sistema o subsistema.
  • Permite especificar un componente con interfaces bien definidas.


Tipos de Diagramas de Componentes

Los diagramas de componentes se pueden clasificar en tres categorías:

  • Componentes de despliegue: necesarios y suficientes para formar un sistema ejecutable. Por ejemplo: bibliotecas dinámicas (dll), ejecutables (exe).
  • Componentes productos de trabajo: surgen durante el proceso de desarrollo y queda al final del mismo. Por ejemplo: buscarCliente.jar, cliente.db.
  • Componentes de ejecución: se crea como consecuencia d un sistema de ejecución. Por ejemplo: objetos que se instancian a partir de una dll.

Diagramas de Distribución

Los Diagramas de Distribución muestran la disposición física de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos. Un nodo es un elemento físico que existe en tiempo de ejecución y representa un recurso computacional, que generalmente tiene algo de memoria y, a menudo, capacidad de procesamiento. Los nodos se utilizan para modelar la topología del hardware sobre el que se ejecuta el sistema. 13

Representa típicamente un procesador o un dispositivo sobre el que se pueden desplegar los componentes.


Diagrama_de_actividades.png
Diagrama de Distribución


La relación entre nodos puede representarse como se muestra a continuación:


Relacion_de_los_nodos.png
Ejemplo de Relación entre Nodos


Elementos del Diagrama de Distribución

  • Nodo: Representa un recurso de cómputo que puede alojar artefactos y que se puede interconectar con otros nodos para describir topologías de redes.
  • Dispositivo: Representa un recurso físico de cómputo que posé capacidad de procesamiento; se representa igual que un nodo.
  • Entorno Ejecutable: Representa un recurso lógico de cómputo dentro del cual se alojan manifestaciones de componentes de cierto tipo.
  • Rutas de Comunicación: Asociación que se modela sólo entre objetivos de distribución (nodos, dispositivos o entornos ejecutables) indicando que estos pueden intercambiar mensajes y señales.
  • Componente: Representa unidades autocontenidas de software que realizan a las clases o a cualquier elemento empacable.
  • Artefacto: Representa la manifestación de un componente en el mundo físico.


Elementos_del_Diagrama_de_Distribuci%C3%B3n.gif
Elementos del Diagrama de Distribución

Véase También

Sistemas de información

Analista de sistemas

Técnicas y Herramientas para el Desarrollo de Software

Metodologías para el desarrollo de software

Referencias

1. ALARCON, Raul. Diseño Orientado a Objetos con UML. Grupo EIDOS. Madrid 2000

2. SCHMULLER, Joseph. Aprenda UML en 24 horas. Prentice-Hall. Madrid 2001

3. Wikipedia, “Lenguaje de Modelado Unificado”. Disponible en: http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado

4. Universidad de Burgos. "Introducción a la Programación Orientada a Objetos". Disponible en: http://pisuerga.inf.ubu.es/lsi/loop/Invest/Java/Tuto/I_1.htm

5. MENDOZA, Daniel. "Programación orientada a objetos POO". Disponible en: http://danieldsmp.blogspot.com/2010/04/programacion-orientada-objetos_19.

6. Universidad de Chile. "Tutorial de UML: Modelo de Clases". Disponible en: http://users.dcc.uchile.cl/~psalinas/uml/modelo.html

7. CALERO, Coral, MORAGA, Maria y PIATTINI, Mario. "Calidad del Producto y Proceso Software". Editorial Ra-ma 2010

8. SOMMERVILLE, Ian. "Ingeniería del Software". Séptima edición, PEARSON EDUCACION, S.A., Madrid 2006

9.RAMOS, Benjamín y RIBAGORDA, Arturo. "Avances En Criptología Y Seguridad De La Información". Ediciones Díaz de Santos, S.A.

10. RUMBAUGH,James, JACOBSON,Ivar y BOOCH,Grady. "El Lenguaje Unificado de Modelado-Manual de Referencia". Pearson Educación. Madrid 2000

11. LARMAN, Craig. "UML y Patrones". Prentice-Hall, Madrid 2001

12.Wikipedia,"Diagrama de Componentes". Disponible en:http://es.wikipedia.org/wiki/Diagrama_de_componentes

13. AREVALO, Maria E. "UML Modelado Dinámico: Diagramas de Distribución". Disponible en: http://arevalomaria.wordpress.com/2010/12/02/uml-modelado-dinamico-diagramas-de-distribucion/

Herramientas personales