EJERCICIOS de DIAGRAMAS 1 Y 2

Diagramas UML

El UML está compuesto por diversos elementos gráficos que se combinan para conformar diagramas. Debido a que el UML es un lenguaje, cuenta con reglas para combinar tales elementos.

La finalidad de los diagramas es presentar diversas perspectivas de un sistema, a las cuales se les conoce como modelo.

A continuación se describirán los diagramas más comunes del UML y los conceptos que representan:

Diagrama de Clases

Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenimiento.

Elementos:

  •Clase: Atributos, métodos y visibilidad (public+, private-, protected#)

  •Relaciones: Herencia, composición, agregación, asociación y Uso.

Diagramas de caso de uso

Los Casos de Uso no forma parte de la llamada Fase de Diseño, sino parte de la fase de Análisis, respondiendo el interrogante ¿Qué?. De forma que al ser parte del análisis ayuda a describir que es lo que el sistema debe hacer.

Estos diagramas muestran operaciones que se esperan de una aplicación o sistema y como se relaciona con su entorno, es por ello que se ve desde el punto de vista del usuario. Describen un uso del sistema y como éste interactúa con el usuario.

Los casos de usos se representan en el diagrama por una elipses la cual denota un requerimiento solucionado por el sistema.

El conjunto de casos de usos representa la totalidad de operaciones que va a desarrollar el sistema. Por último a estos elipses lo acompaña un nombre significativo de manera de rótulo.

Diagrama de objeto

Se puede considerar un caso especial de un diagrama de clase. Los diagramas de objetos usan un sub conjunto de elementos de un diagrama de clase para enfatizar la relación entre las instancias de las clases en algún punto en el tiempo. Estos son útiles para entender los diagramas de clases. Estos no muestran nada diferente en su arquitectura a los diagramas de secuencia, pero reflejan multiplicidad y roles.

Diagramas de Componentes

Ilustran las piezas del software, controladores embebidos, etc. que conformarán un sistema. Un diagrama de Componentes tiene un nivel más alto de abstracción que un diagrama de clase – usualmente un componente se implementa por una o más clases (u objetos) en tiempo de ejecución. Estos son bloques de construcción, como eventualmente un componente puede comprender una gran porción de un sistema.

Elementos

•Representación de componentes

•Interfaces requeridas (Conector de Ensamble)

•Componentes con puertos

Diagrama de actividad

Un Diagrama de Actividades representa un flujo de trabajo paso a paso de negocio y operacionales de los componentes en un sistema.

En UML 1, un diagrama de actividades es una variación del Diagrama de Estados UML donde los estados representan operaciones y las transiciones representan las actividades que ocurren cuando la operación es completa.

En la actualidad, el diagrama de actividades en UML 2.0 es similar al aspecto del diagrama en UML 1, solo que ahora la semántica esta basada en lo que se conoce como Redes de Petri. En UML 2.0, el diagrama general de interacción está basado en el diagrama de Actividad.

Componentes:

• Inicio: el inicio de un diagrama de actividades 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 representa dentro de un óvalo.
• Transición: Una transición ocurre cuando se lleva acabo 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 su dirección.

Diagrama de Secuencia

Un Diagrama de Secuencias muestra una interacción ordenada según la secuencia temporal de eventos y el intercambio de mensajes. Los diagramas diagramas de secuencia ponen especial énfasis en el orden y el momento en el que se envían los mensajes a los objetos.

En los diagramas de Secuencias los elementos están representados por líneas intermitentes verticales, con el nombre del objeto en la parte más alta.

Los mensajes pueden ser o bien síncronos, el tipo normal de llamada del mensaje donde se pasa el control a objeto llamadohasta que el método finalize, o asíncronos donde se devuelve el control directamente al objeto que realiza la llamada.

Los mensajes síncronos tienen una caja vertical en un lateral del objeto invocante que muestra el flujo del control del programa.

Diagrama de Despliegue

Básicamente este tipo de diagrama se utiliza para modelar el Hardware utilizado en la implementación del sistema y la relaciones entre sus componentes.

Los elementos usados por este tipo de diagrama son nodos, componentes y asociaciones. En el UML 2.0 los componentes ya no están dentro de nodos, en cambio puede haber artefactos (archivo, un programa, una biblioteca o Base de datos) u otros nodos dentro de nodos.

Además los Diagramas de Despliegue muestran la configuración en funcionamiento del sistema incluyendo su software y su hardware. Para cada componente de un diagrama es necesario que se deba documentar las características técnicas requeridas, el trafico de red, el tiempo de respuesta, etc.

CUESTIONARIO:

Cuestionario 1: ingeniería de software 

 1. ¿Cuál es la diferencia entre Ingeniería de software y Ciencias de la computación?

Ciencias de la computación es una disciplina que se ocupa del estudio de cómputo incluyendo procesos algorítmicos y principios que involucran el diseño de software y hardware, Pero la  Ingeniería de software se ocupa del diseño e implementación de software complejo de una manera confiable y eficiente, aplicando principios y prácticas de la ingeniería, combinan la experiencia en ciencias de la computación, ingeniería y matemáticas para diseñar, definir y organizar diversos aspectos de un producto software.

2. ¿Cuál es la diferencia entre  Ingeniería de Software e Ingeniería de Sistemas?

La ingeniería de sistemas se refiere a todos los aspectos del desarrollo y de la evolución de sistemas complejos donde el software desempeña un papel principal. Por lo tanto, la ingeniería de sistemas comprende el desarrollo de hardware, políticas y procesos de diseño y distribución de sistemas, así como la ingeniería del software. Los ingenieros de sistemas están involucrados en la especificación del sistema, en la definición de su arquitectura y en la integración de las diferentes partes para crear el sistema final. Están menos relacionados con la ingeniería de los componentes del sistema (hardware, software, etc.).

La ingeniería de sistemas es más antigua que la del software. Por más de 100 años, las personas han especificado y construido sistemas industriales complejos, como aviones y plantas químicas. Sin embargo, puesto que se ha incrementado el porcentaje de software en los sistemas, las técnicas de ingeniería del software tales como el modelado de casos de uso y la gestión de la configuración se utilizan en el proceso de ingeniería de sistemas. En el Capítulo 2 se traía con mayor detalle la ingeniería de sistemas.

3. ¿Qué es un proceso de software?

Un proceso de software es un conjunto  ordenado de pasos a seguir para lograr la obtención de un producto software que resuelva un problema(Sommerville,2002). La complejidad de un  Proceso de software  dependerá de las características del mismo. Cada proceso de software tiene reglas preestablecidas y deben ser aplicadas en la creación del software ya que en caso contrario el proyecto no se completará o si bien si está completo no cumplirá los objetivos previstos presentando más de una error.  Cualquiera Proceso aplicado para la creación de un software siempre debe aplicar un Modelo de Ciclo de Vida (Norma IEEE 1074)[IEEE, 1999].

4. ¿Qué es un  modelo de proceso de software?

Un modelo de procesos del software es una descripción simplificada de un proceso del software que     presenta una visión de ese proceso. Estos modelos pueden incluir actividades que son parte de los procesos y productos de software y el papel de las personas involucradas en la ingeniería del software. Algunos ejemplos de estos tipos de modelos que se pueden producir son:

1. Un modelo de flujo de trabajo. Muestra la secuencia de actividades en el proceso junto con sus entradas, salidas y dependencias. Las actividades en este modelo representan acciones humanas.

2. Un modelo de flujo de datos o de actividad. Representa el proceso como un conjunto de actividades, cada una de las cuales realiza alguna transformación en los datos. Muestra cómo la entrada en el proceso, tal como una especificación, se transforma en una salida, tal como un diseño. Pueden representar transformaciones llevadas a cabo por las personas o por las computadoras.

3. Un modelo de rol/acción. Representa los roles de las personas involucrada en el proceso del software y las actividades de las que son responsables.

La mayor parte de los modelos de procesos del software se basan en uno de los tres modelos

generales o paradigmas de desarrollo de software:

1. El enfoque en cascada. Considera las actividades anteriores y las representa como fases de procesos separados, tales como la especificación de requerimientos, el diseño del software, la implementación, las pruebas, etcétera. Después de que cada etapa queda

definida «se firma» y el desarrollo continúa con la siguiente etapa.

2. Desarrollo iterativo. Este enfoque entrelaza las actividades de especificación, desarrollo y validación. Un sistema inicial se desarrolla rápidamente a partir de especificaciones muy abstractas. Este se refina basándose en las peticiones del cliente

para producir un sistema que satisfaga las necesidades de dicho cliente. El sistema puede entonces ser entregado. De forma alternativa, se puede reimplementar utilizando un enfoque más estructurado para producir un sistema más sólido y mantenible.

3. Ingeniería del software basada en componentes (CBSE). Esta técnica supone que       las partes del sistema existen. El proceso de desarrollo del sistema se enfoca en la integración de estas partes más que desarrollarlas desde el principio. En el Capítulo 19 se

estudia la CBSE.

5.¿Cuáles son los costos de la Ingeniería de Software?

Los costos de la ingeniería de software  denominan al costo del sistema o software desarrollado, dependiendo de la complejidad y eficiencia del proyecto software. Es costo es mayor si el producto es mas eficiencia, lo cual indica que cuesta mas mantener el software que desarrollarlo.

Ejemplos de Diagrama:

STAR UML

Metodología Orientada a Objeto UML

DEFINICIÓN Y CONCEPTO DE UML

UML son las siglas de “Unified Modeling Language” o “Lenguaje Unificado de Modelado”. Se trata de un estándar que se ha adoptado a nivel internacional por numerosos organismos y empresas para crear esquemas, diagramas y documentación relativa a los desarrollos de software (programas informáticos).

¿QUÉ ES Y PARA QUÉ SIRVE UML?

El término “lenguaje” ha generado bastante confusión respecto a lo que es UML. En realidad el término lenguaje quizás no es el más apropiado, ya que no es un lenguaje propiamente dicho, sino una serie de normas y estándares gráficos respecto a cómo se deben representar los esquemas relativos al software. Mucha gente piensa por confusión que UML es un lenguaje de programación y esta idea es errónea: UML no es un lenguaje de programación. Como decimos, UML son una serie de normas y estándares que dicen cómo se debe representar algo.

UML es una herramienta propia de personas que tienen conocimientos relativamente avanzados de programación y es frecuentemente usada por analistas funcionales (aquellos que definen qué debe hacer un programa sin entrar a escribir el código) y analistas-programadores (aquellos que dado un problema, lo estudian y escriben el código informático para resolverlo en un lenguaje como Java, C#, Python o cualquier otro). Por tanto si estás dando tus primeros pasos en programación, te recomendaríamos que te olvides de UML hasta que tengas unos conocimientos mínimos como uso de condicionales, bucles, y conocimiento de la programación orientada a objetos. Esto es solo una recomendación, en realidad prácticamente cualquier persona puede usar UML, incluso podría usarse para realizar esquemas o documentación de procesos que no tengan que ver con la informática.

Hemos dicho que UML es un estándar. Vamos a aclarar primero qué es un estándar. Supongamos que vamos a definir un estándar llamado “LMAPR” o lenguaje de modelado de aprenderaprogramar.com.

Un animal debe representarse con su nombre escrito enteramente en minúsculas enmarcado dentro de un rectángulo doble. Encima del nombre debe etiquetarse el tipo de animal así: <<Tipo de Animal>>. Por ejemplo, <<Gato>>.

Si un animal envía un mensaje a otro animal deben conectarse los dos animales con una línea punteada terminada en flecha encima de la cual debe figurar el texto msg(“Contenido del mensaje”).

Herramientas UML

Hoy en día en el mundo de la informática tenemos la fortuna de tener alguna herramienta que nos ayude en nuestra tareas cotidianas, desde mensajeros instantáneos para comunicarnos, hasta gestores de recetas de cocina para perpetuar el legado culinario de las abuelas, y por supuesto, el modelado con UML de software orientado a objetos no es la excepción.

Por desgracia, hay tal variedad de herramientas en el mercado que es difícil decidir cual es la mejor, personalmente sigo haciendo diagramas con lápiz y papel, pero llega un momento en el que es inmanejable (como muestra la persona en la foto :P). Creo que es difícil decir que una herramienta es la mejor, sin lugar a duda, la decisión depende de muchos factores, no solo el que cumplan al pie de la letra la especificación de UML, si no además, que sea una herramienta intuitiva y que no consuma demasiados recursos de nuestro ordenador.

Personalmente utilizo dos herramientas, tanto con fines docentes como de investigación, quizá no son las mejores pero al menos cumplen con lo que necesito ¿cómo tomé la decisión de cual era mejor? lo explicaré brevemente a continuación.

Para decidir que herramienta UML utilizar decidí hacer análisis de las herramientas existentes en el mercado, entre búsquedas en Internet y dos comparativas bastante buenas que encontré [(1) UML Tools por Mario Jeckle (2) Comparison of Unified Modeling Language Tools en Wikipedia], decidí crear mi propia lista de cualidades deseadas en una herramienta UML, tanto para la enseñanza como para uso comercial. Las características que finalmente analicé fueron las siguientes:

• Código abierto
• Tipo de licencia (siendo muy importante que hubiera un licenciamiento académico a un coste accesible)
• Lenguaje de programación utilizado
• Integración con entornos de desarrollo (y cuales)
• Coste
• Versión de UML
• Diagramas que soporta
• Soporte para MDA
• Soporte para XMI
• Generación de código (y que lenguajes de programación soporta)
• Capacidades de ingeniería inversa
• Sistema Operativo
• Requisitos de instalación

Las herramientas analizadas fueron:

• ArgoUML
• Poseidon for UML
• OpenAmeos
• Visual Paradigm for UML
• StarUML
• Rational Software Modeler (sucesor de Rational Rose)
• Enterprise Architect
• Umbrello UML Modeler
• UML Designer

Sin entrar en demasiados detalles de la evaluación, solo quiero comentar que todas las herramientas fueron instaladas y probadas modelando el mismo sistema orientado a objetos, donde además se analizó también la velocidad a la que se ejecutaban cada uno de ellos. Las pruebas siempre se hicieron utilizando el mismo ordenador.

Al final, dos herramientas satisficieron la calidad global deseada: Rational Software Modeler y Visual Paradigm for UML. Quiero destacar que ambas herramientas son muy potentes, soportan todos los diagramas de UML y además ayudan para la gestión de requisitos software, sin embargo, la que finalmente decidí utilizar fur Visual Paradigm for UML por su estabilidad de ejecución en diferentes sistemas operativos y la facilidad de abrir y trabajar con un modelo UML utilizando el mismo programa sin importar el sistema operativo y sin afectar en absoluto el trabajo hecho; además destacar que esta herramienta guarda todo el modelo en un solo fichero, así de simple, y basta con copiarse solo ese fichero y uno está seguro de que tiene todo el trabajo encapsulado en él. Finalmente, Visual Paradigm es una herramienta que trabaja bastante decente en ordenadores “poco potentes”.

Como el objetivo principal de mi análisis de herramientas era el de seleccionar un entorno de trabajo para mis alumnos, quiero destacar que tanto IBM como Visual Paradigm ofrecen sus herramientas de modelado para fines académicos sin coste alguno, y el proceso de gestión de licenciamiento es bastante sencillo.

Dado que Rational Software Modeler es también una estupenda herramienta, quiero simplemente comentar que la utilizamos dentro del Grupo SEL-UC3M como herramienta de modelado por parte de los estudiantes de doctorado.

Por último, no puedo dejar de mencionar como la Web 2.0 ha llegado también al mundo del modelado UML, y quiero recomendarles yUML, una herramienta que a pesar de estar en versión Beta, permite crear al vuelo y con una sintaxis poco compleja, diagramas UML que pueden compartirse a través de Internet con mucha facilidad, yo la veo como una herramienta muy útil al momento de tener reuniones virtuales o para crear sin mucha complejidad un diagrama UML que quiera ser compartido en algún blog o borrador de modelado. Esperemos que en el futuro, esta herramienta siga evolucionando y nos ofrezca más posibilidades de interacción y colaboración.