UML

¿Qué es UML?

El Lenguaje Unificado de Modelado preescribe 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.

UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real.

UML es una consolidación de muchas de las notaciones y conceptos más usadas orientados a objetos. Empezó como una consolidación del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologías orientadas a objetos más populares.

Es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software. Se usa para entender, diseñar, configurar, mantener y controlar la información sobre los sistemas a construir

Objetivos de UML

• UML es un lenguaje de modelado de propósito general que pueden usar todos los modeladores. No tiene propietario y está basado en el común acuerdo de gran parte de la comunidad informática.
• UML no pretende ser un método de desarrollo completo. No incluye un proceso de desarrollo paso a paso. UML incluye todos los conceptos que se consideran necesarios para utilizar un proceso moderno iterativo, basado en construir una sólida arquitectura para resolver requisitos dirigidos por casos de uso.
• Ser tan simple como sea posible pero manteniendo la capacidad de modelar toda la gama de sistemas que se necesita construir. UML necesita ser lo suficientemente expresivo para manejar todos los conceptos que se originan en un sistema moderno, tales como la concurrencia y distribución, así como también los mecanismos de la ingeniería de software, como son la encapsulación y componentes.
• Debe ser un lenguaje universal, como cualquier lenguaje de propósito general.
• Imponer un estándar mundial.

DIAGRAMAS Y VISTAS EN UML

Vistas: Las vistas muestran diferentes aspectos del sistema modelado. Una vista no es una gráfica, pero sí una abstracción que consiste en un número de diagramas y todos esos diagramas juntos muestran una "fotografía" completa del sistema. Las vistas también ligan el lenguaje de modelado a los métodos o procesos elegidos para el desarrollo. Las diferentes vistas que UML tiene son:

• Vista casos de uso: Se forma con los diagramas de casos de uso, colaboración, estados y actividades.
• Vista de diseño: Se forma con los diagramas de clases, objetos, colaboración, estados y actividades.
• Vista de procesos: Se forma con los diagramas de la vista de diseño. Recalcando las clases y objetos referentes a procesos.
• Vista de implementación: Se forma con los diagramas de componentes, colaboración, estados y actividades.
• Vista de despliegue: Se forma con los diagramas de despligue, interacción, estados y actividades.

Diagramas: Los diagramas son las gráficas que describen el contenido de una vista. Se dispone de dos tipos diferentes de diagramas los que dan una vista estática del sistema y los que dan una visión dinámica.
Los diagramas estáticos son:

• Diagrama de clases: muestra las clases, interfaces, colaboraciones y sus relaciones. Son los más comunes y dan una vista estática del proyecto.
• Diagrama de objetos: Es un diagrama de instancias de las clases mostradas en el diagrama de clases. Muestra las instancias y como se relacionan entre ellas. Se da una visión de casos reales.
• Diagrama de componentes: Muestran la organización de los componentes del sistema. Un componente se corresponde con una o varias clases, interfaces o colaboraciones.
• Diagrama de despliegue.: Muestra los nodos y sus relaciones. Un nodo es un conjunto de componentes. Se utiliza para reducir la complejidad de los diagramas de clases y componentes de un gran sistema. Sirve como resumen e índice.
• Diagrama de casos de uso: Muestran los casos de uso, actores y sus relaciones. Muestra quien puede hacer que y relaciones existen entre acciones (casos de uso). Son muy importantes para modelar y organizar el comportamiento del sistema.

Los diagramas dinámicos son:

• Diagrama de secuencia, Diagrama de colaboración: Muestran a los diferentes objetos y las relaciones que pueden tener entre ellos, los mensajes que se envían entre ellos. Son dos diagramas diferentes, que se puede pasar de uno a otro sin perdida de información, pero que nos dan puntos de vista diferentes del sistema. En resumen, cualquiera de los dos es un Diagrama de Interacción.
• Diagrama de estados: muestra los estados, eventos, transiciones y actividades de los diferentes objetos. Son útiles en sistemas que reaccionen a eventos.
• Diagrama de actividades: Es un caso especial del diagrama de estados. Muestra el flujo entre los objetos. Se utilizan para modelar el funcionamiento del sistema y el flujo de control entre objetos.
  Se puede observar que el número de diagramas es muy alto, en la mayoría de los casos excesivos, y UML permite definir solo los necesarios, ya que no todos son necesarios en todos los proyectos.
  

CICLO DE VIDA DEL SOFTWARE

Ciclo de vida del software

Es el proceso que se sigue para construir, entregar y hacer evolucionar el software, desde la concepción de una idea, hasta la entrega y el retiro del sistema.
Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto de desarrollo de software.

Modelo de un ciclo de vida del software

Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociadas entre dichas etapas.
Un modelo de ciclo de vida del software:

• Describe las fases principales de desarrollo de software,
• define las fases primarias esperadas de ser ejecutadas durante esas fases,
• ayuda a administrar el progreso del desarrollo y,
• provee un espacio de trabajo para la definición de un detallado proceso de desarrollo de software.

Tipos de modelos de un ciclo de vida del software

Modelo Cascada

Este el más básico de todos los modelos, y sirve como bloque de construcción para los demás modelos de ciclo de vida.
Este modelo dice que el desarrollo de software puede ser a través de una secuencia simple de fases. Cada fase tiene un conjunto de metas bien definidas, y las actividades dentro de una fase contribuyen a la satisfacción de metas de esa fase o quizás a una subsecuencia de metas de la fase.

Un modelo de ciclo de vida cascada, tiene algunos principios básicos:

• Planear un proyecto, antes de embarcarse en él.
• Definir el comportamiento externo deseado del sistema antes de diseñar su arquitectura interna.
• Documentar los resultados de cada actividad.
• Diseñar un sistema antes de codificarlo.
• Someter a un control o prueba un sistema después de construirlo.

Modelo de Desarrollo Incremental

Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma de reducir los riesgos es construir sólo una parte del sistema, reservando otros aspectos para niveles posteriores. El desarrollo incremental es el proceso de construcción siempre incrementando subconjuntos de requerimientos del sistema. Típicamente, un documento de requerimientos es escrito al capturar todos los requerimientos para el sistema completo.

Algunos de los beneficios que proporciona el desarrollo incremental para los proyectos son:

• Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande.
• Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los requerimientos planeados para los niveles subsiguientes son correctos.
• Si un error importante es realizado, solo la última iteración necesita ser descartada.
• Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo.
• Si un error importante es realizado, el incremento previo puede ser usado.
• Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del próximo incremento.

Modelo de Desarrollo Evolutivo

Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo construye una serie de grandes versiones sucesivas de un producto. Sin embargo, mientras que la aproximación incremental presupone que el conjunto completo de requerimientos es conocido al comenzar, el modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto.

En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y sólo esos que son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementación parcial del sistema que recibe sólo estos requerimientos.

El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentación a los desarrolladores. Basada en esta retroalimentación, la especificación de requerimientos es actualizada, y una segunda versión del producto es desarrollada y desplegada. El proceso se repite indefinidamente.

El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulación de documentos, programas, datos de test, etc. desarrollados para distintas versiones del software. Cada paso debe ser registrado, la documentación debe ser recuperada con facilidad, los cambios deben ser efectuados de una manera controlada.

Modelo de Prototipado de Requerimientos

El prototipado de requerimientos es la creación de una implementación parcial de un sistema, para el propósito explícito de aprender sobre los requerimientos del sistema. Un prototipo es construido de una manera rápida tal como sea posible. Esto es dado a los usuarios, clientes o representantes de ellos, posibilitando que ellos experimenten con el prototipo. Estos individuos luego proveen la retroalimentación sobre lo que a ellos les gustó y no les gustó acerca del prototipo proporcionado, quienes capturan en la documentación actual de la especificación de requerimientos la información entregada por los usuarios para el desarrollo del sistema real. El prototipado puede ser usado como parte de la fase de requerimientos (determinar requerimientos) o justo antes de la fase de requerimientos (como predecesor de requerimientos).
En otro caso, el prototipado puede servir su papel inmediatamente antes de algún o todo el desarrollo incremental en modelos incremental o evolutivo.

Modelo Espiral

El modelo espiral de los procesos software es un modelo del ciclo de meta−vida. En este modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno completa un esfuerzo de desarrollo, otro comienza. Además, en cada desarrollo ejecutado, se pueden pueden seguir estos cuatros pasos:

• Determinar que se quiere lograr.
• Determinar las rutas alternativas que se pueden tomar para lograr esas metas. Por cada una, analizar los riesgos y resultados finales, y seleccionar la mejor.
• Seguir la alternativa seleccionada en el paso 2.
• Establecer que se tiene terminado.

El modelo espiral tiene algunos principios básicos:

• Decidir qué problema se quiere resolver antes de viajar a resolverlo.
• Examinar las múltiples alternativas de acción y elegir una de las más convenientes.
• Evaluar qué se tiene hecho y qué se tiene que haber aprendido después de hacer algo.
• No ser tan ingenuo para pensar que el sistema que se está construyendo será "EL" sistema que el cliente necesita, y
• Conocer (comprender) los niveles de riesgo, que se tendran que tolerar.

Modelo Concurrente

Como el modelo espiral, el modelo concurrente provee una meta−descripción del proceso software. Mientras que la contribución primaria del modelo espiral es en realidad que esas actividades del software ocurran repetidamente, la contribución del modelo concurrente es su capacidad de describir las múltiples actividades del software ocurriendo simultáneamente.

LA CRISIS DEL SOFTWARE Y SUS POSIBLES SOLUCIONES

Crisis del Software

La expresión «crisis del software» es recurrente en mucha bibliografía técnica, tanto que ya suena a expresión vacía. El caso es que esta crisis existe y para ello basta comparar el desarrollo del hardware y su relación coste/potencia con el del software. En el hardware hay una reutilización sistemática y ahorros de coste continuos a merced de la reducción de materias primas en cada generación de productos, la reutilización de diseños previos, las economías de escala, etc. En el caso del software, donde todas las economías podrían ser de escala, al menos en teoría, no solo no ha ocurrido así sino que el coste no solo no se ha mantenido sino que ha aumentado. Y por otro lado la productividad que ofrece es muy limitada: hoy día el mundo del software ofrece aplicaciones, no soluciones, no se adapta a la forma natural de trabajar de los seres humanos y son sólo poderosas herramientas, a veces incluso sobredimensionadas, en lugar de adaptarse a las actividades del ser humano.

Un fenómeno muy importante es el del despilfarro económico que muchas sociedades realizan con la idea de avanzar en la inclusión digital. Es conocida la ley de Moore, que aún hoy marca la pauta del incremento regular de la relación potencia/coste del hardware. Menos conocida es la de Gilder aplicada de manera semejante a la conectividad. El resultado es que en tres años el hardware es obsoleto incluso a efectos contables. Eso no sería un problema si se hubiera podido amortizar tanta potencia con soluciones software. Pero esas soluciones no existen. Siguen siendo aplicaciones de «bajo nivel».

La crisis del software es el hecho de que el software que se construye no solamente no satisface los requerimientos ni las necesidades pedidos por el cliente, sino que además excede los presupuestos y los horarios de tiempos. La industria del software no ha podido satisfacer la demanda. La complejidad del software producido y demandado se incrementa constantemente. El software es solicitado para ejecutar las tareas demandantes de hoy y está presente en todos los sistemas que van desde los más se los más sencillos hasta los de misión crítica. Las aplicaciones de software son complejas porque modelan la complejidad del mundo real. En estos días, las aplicaciones típicas son muy grandes y complejas para que un individuo las entienda y, por ello, lleva gran tiempo implementar software.

El término “crisis del software” se acuñó en 1968, en la primera conferencia organizada por la OTAN (Organización del Tratado del Atlántico Norte) sobre desarrollo de software; y con él se etiquetaron a los problemas que surgían en el desarrollo de sistemas de software. En la misma conferencia se utilizó por primera vez el término "ingeniería del software" para describir el conjunto de conocimientos que existían en aquel estado inicial. Algunas referencias útiles para comprender cuáles eran los conocimientos estables para el desarrollo de software en 1968 son:

• En 1962 se publicó el primer algoritmo para búsquedas binarias.
• C.Böhm y G. Jacopini publicaron en 1966 el documento que creaba una fundación para la eliminación de "GoTo" y la creación de la programación estructurada.
• En 1968 los programadores se debatían entre el uso de la sentencia GoTo, y la nueva idea de programación estructurada; ese era el caldo de cultivo en el que Edsger Dijkstra escribió su famosa carta "GoTo Statement Considered Harmful" en 1968.
• La primera publicación sobre programación estructurada no vio la luz hasta 1974, publicada por Larry Constantine, Glenford Myers y Wayne Stevens.
• El primer libro sobre métrica de software fue publicado en 1977 por Tom Gilb.
• El primer libro sobre análisis de requisitos apareció en 1979.

El término fue usado para referirse a los rápidos incrementos de la tecnología en la computación y la complejidad de los problemas a los cuales pudieran enfrentarse. En efecto, se refiere a la dificultad de escribir correcta, entendible y verificablemente los lenguajes de programación. Las raíces de la crisis del software son complejas y variables.

"Síntomas"

Uno de los principales problemas en el desarrollo de software de hoy en día es que muchos proyectos empiezan la programación tan pronto se definen y concentran mucho de su esfuerzo en la escritura de código. Últimamente el desarrollo de software se ha relentizado. El estudio de este fenómeno es importante porque la existencia de software científico libre facilita que cualquier laboratorio del mundo pueda desarrollar ciencia libre usando este software como herramienta de trabajo.

Algunos “síntomas” que indican que el software se encuentra en un periodo de crisis son:

• Baja Calidad del Software.
• Tiempo y Presupuesto Excedido.
• Confiabilidad Cuestionable.
• Altos Requerimientos de Personal para desarrollo y mantenimiento.

Factores de Influencia

Para poder llevar el estado del proceso de software como un estado de crisis, los críticos han destacado ciertas características que han permitido esta postura del software respecto a otras etapas de su corta historia. Algunos de esos factores son:

• Aumento del poder computacional.
• Reducción del costo del hardware.
• Rápida obsolescencia de hardware y software.
• Aceptación de la computarización en las empresas.
• Incremento en el número de usuarios de los sistemas de software.
• Tipo de usuario no homogéneo aun en sistemas hechos a la medida.
• Personal de desarrollado y mantenimiento diferente.
• La magnitud del proyecto impacta en:
• Tiempo costo y número de desarrolladores,
• Control administrativo y detalles técnicos
• Aumento en el conocimiento del problema.
• Cambios en el entorno:
• Tecnológicos (Internet, redes, ERP, CRM, SCM).
• Económicos (crisis económicas, globalización, etcétera).
• Sociales (nuevas necesidades, costumbres nuevas, etcétera).

Posibles causas de la crisis del software

Hay varias razones que pueden ser propuestas como causa de la crisis. No son mutuamente excluyentes; de hecho, es posible que la verdadera causa sea una mezcla de todas ellas. Sin embargo, todas tienen en común que son causadas por el método de valorar los avances científicos y el mecanismo actual de financiación de la actividad científica. Las causas de la crisis del software fueron vinculadas a la complejidad en general del proceso de software y a la relativa madurez de la ingeniería de software como una profesión. La crisis se manifestó a sí misma en varias maneras:

• Proyectos gestionados con un sobre-presupuesto.
• Proyectos gestionados con sobre tiempo.
• Software de baja calidad.
• El software a menudo no satisfacía los requerimientos deseados.
• Los proyectos fueron inmanejables, con un código difícil de mantener.

La crisis del software fue dirigida por la implementación de varios procesos y metodologías, siendo la más notable el modelo de cascada de Royce.

Posibles soluciones al problema del software científico

La primera solución puede ser la existencia de una licencia libre, mas que recoja las singularidades del software científico. Esta licencia debería compartir el espíritu de la GPL (General Public License es una licencia creada por la Free Software Foundation a mediados de los 80, y está orientada principalmente a proteger la libre distribución, modificación y uso de software. Su propósito es declarar que el software cubierto por esta licencia es software libre y protegerlo de intentos de apropiación que restrinjan esas libertades a los usuarios) y gran parte de su letra; y debería asegurar la preservación de las libertades propuestas por RMS. Por otro lado, también debería incluir algunas restricciones, fáciles de cumplir y que no limitan la libertad final del código según los criterios expuestos por RMS (Richard Matthew Stallman), como son:

• Si se usa el programa para realizar una investigación, y esa investigación termina en uno o varios artículos publicados, los artículos de dicha investigación deben reconocer qué programas fueron usados, así como citar los artículos en los que fueron descritos. Esta restricción no impide la libertad de libre uso, y, de hecho, la totalidad de los programas libres científicos la incluyen; este sistema hasta ahora parece funcionar. La principal objeción a esta restricción es similar a la crítica que RMS hizo a la licencia BSD ; sin embargo, en este caso no se produce el exceso de verborrea en las citaciones; ya que, en caso de que alguien pueda publicar un artículo en una revista indexada, por la naturaleza de revisadas por asesores externos de estas revistas, ha de ser cierta importancia la aportación al código.
• Si se modifica el código, se ha de identificar adecuadamente la parte modificada como tal. Esto no impide la libertad de modificación, mas permite que, en caso de que la modificación suponga una mejora en el rendimiento o la calidad de los resultados, el autor de la modificación tenga el debido reconocimiento; y, en caso de que la modificación introduzca errores, evita manchar el nombre del programa y del grupo que lo desarrolló.
• Por último, sería interesante abrir un debate en el seno de la comunidad del software libre sobre hasta qué punto es ético usar software libre para desarrollar ciencia no libre.

La segunda solución que puede tener el problema del software científico libre es la creación de una revista indexada destinada específicamente a productos cuya licencia sea libre.

La tercera solución es el apoyo de las instituciones gubernamentales. En una primera solución, financiando proyectos libres, como ya hace el gobierno alemán, solo que en el área de software científico libre. Otra posibilidad es abrir grandes proyectos temáticos de software libre científico.

La última solución, es que aquellos proyectos financiados con dinero del estado deben ser libres.

La última corresponde a la universidad: liberando los resultados de proyectos fin de carrera, de resultados de investigación y de tesis de doctorado bajo GPL de documentación, y el código desarrollado bajo una hipotética GPL científica con las características anteriormente comentadas, ganamos todos. La comunidad porque cuenta con más código libre para compartir, y el investigador porque ve compensado su trabajo con el reconocimiento, los artículos y las citaciones que necesitará para conseguir becas y fondos para seguir investigando.