MODELAMIENTO DE SOFTWARE

MODELADO DEL SOFTWARE

El modelado de sistemas software es una técnica para tratar con la complejidad
inherente a estos sistemas. El uso de modelos ayuda a "visualizar" el sistema a
construir. Además, los modelos de un nivel de abstracción mayor pueden utilizarse
para la comunicación con el cliente. Por último, las herramientas de modelado y las
de Ingeniería de Software Automatizada. pueden ayudar a verificar la corrección del
modelo.

CONCEPTO DE MODELO
El modelo de desarrollo de software se compone de una mezcla de varios
elementos, entre los que se encuentran la filosofía, el modelo de negocio, y el
licenciamiento. Ni la calidad ni el desempeño dependen del modelo.
Se ha propuesto, igualmente, que un modelo es una estructura conceptual que
sugiere un marco de ideas para un conjunto de descripciones que de otra manera no
podrían ser sistematizadas. De esta manera, su estructura es diferente de la que se
supone existe en el conjunto de fenómenos de la naturaleza. El modelo concebido
en esta forma, impulsa la inteligibilidad y ayuda a la comprensión de los fenómenos,
ya que proporciona los canales de interconexión entre hechos que sin la existencia
de los lazos inferenciales, podrían permanecer aislados e independientes unos de
otros.

CONCEPTO DE MODELO DESARROLLO SOFTWARE

a. CONCEPTO DE SOFTWARE: Se denomina software, programática,
equipamiento lógico o soporte lógico a todos los componentes intangibles de un
ordenador o computadora, es decir, al conjunto de programas y procedimientos
necesarios para hacer posible la realización de una tarea específica, en
contraposición a los componentes físicos del sistema (hardware). Esto incluye
aplicaciones informáticas tales como un procesador de textos, que permite al
usuario realizar una tarea, y software de sistema como un sistema operativo, que
permite al resto de programas funcionar adecuadamente, facilitando la
interacción con los componentes físicos y el resto de aplicaciones.
b. CONCEPTO DE DESARROLLO DE SOFTWARE: Se persigue que a través de la
incursión coordinada por los principios, las técnicas, metodologías y tecnologías
de avanzada, se pueda tener una visión aplicada de los procesos de desarrollo
de software y del aseguramiento y certificación de la calidad en los mismos, de
tal forma que se logre evidenciar suficientemente la importancia y los beneficios
resultantes de la aplicación adecuada de dichos modelos en el producto final de
cualquier tipo de desarrollo.

HERRAMIENTAS DE MODELAMIENTO

Las herramientas de modelado de sistemas informáticos, son herramientas que se

emplean para la creación de modelos de sistemas que ya existen o que se
desarrollarán.

Las herramientas de modelado, permiten crear un "simulacro" del sistema, a bajo

costo y riesgo mínimo. A bajo costo porque, al fin y al cabo, es un conjunto de
gráficos y textos que representan el sistema, pero no son el sistema físico real (el
cual es más costoso). Además minimizan los riesgos, porque los cambios que se
deban realizar (por errores o cambios en los requerimientos), se pueden realizar
más fácil y rápidamente sobre el modelo que sobre el sistema ya implementado.

Las herramientas de modelado, permiten concentrarse en ciertas características

importantes del sistema, prestando menos atención a otras. Los modelos resultados,
son una buena forma de determinar si están representados todos los requerimientos
del sistema, como también saber si el analista comprendió qué hará el sistema.

Un sistema informático puede requerir diferentes herramientas de modelado, que

resultarán en diferentes tipos de modelos. Las herramientas de modelado utilizadas
dependen del analista, del tipo de sistema, de los requerimientos, etc.

Algunas herramientas de modelado

* Diagrama de flujo de datos.
* Diagrama de entidad relación.
* Diagrama de transición de estados.
* Diccionario de datos.
* Especificación de procesos.
* Diagramas HIPO e IPO.
* Diagrama de clases.

Características esperables de una herramienta de modelado

Las buenas herramientas de modelado cumplen con determinadas características:

* Permiten una visión descendente del sistema.

* Permiten particionar el sistema.
* Poseen componentes gráficos con algo de apoyo textual.
* El modelo resultado debe ser transparente (fácil de comprender).
* Poseen mínima redundancia (el aumento de redundancia, disminuye la
transparencia del modelo y aumenta las tareas de mantenimiento).

Balanceo
Un sistema puede modelarse empleando múltiples herramientas de modelado. Cada
herramienta resulta en uno o más diagramas (o esquemas) que representan el
sistema completo o parte del sistema.

Cada diagrama "ayuda" al otro, permitiendo una mejor comprensión de la parte del
sistema que modela.

El balanceo entre diagramas es la tarea de comprobar la consistencia entre los

distintos diagramas del sistema. Esta tarea puede ser manual o automática. Cuando
está comprobada, se dice que los diagramas están balanceados.

El balanceo de diagramas permite descubrir y corregir errores, inconsistencias o

faltantes.
 MODELOS DE DESARROLLO EN CASCADA

En Ingeniería de software el desarrollo en cascada, también llamado modelo en

cascada, es el enfoque metodológico que ordena rigurosamente las etapas del ciclo
de vida del software, de tal forma que el inicio de cada etapa debe esperar a la
finalización de la inmediatamente anterior.
Un ejemplo de una metodología de desarrollo en cascada es:
1. Análisis de requisitos
2. Diseño del Sistema
3. Diseño del Programa
4. Codificación
5. Pruebas
6. Implantación
7. Mantenimiento

De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce

necesariamente al rediseño y nueva programación del código afectado, aumentando
los costes del desarrollo. La palabra cascada sugiere, mediante la metáfora de la
fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases
más avanzadas de un proyecto.

Si bien ha sido ampliamente criticado desde el ámbito académico y la industria,

sigue siendo el paradigma más seguido al día de hoy.

Fases del modelo

Análisis de requerimientos
En esta fase se analizan las necesidades de los usuarios finales del software para
determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD
(documento de especificación de requisitos), que contiene la especificación completa
de lo que debe hacer el sistema sin entrar en detalles internos.
Es importante señalar que en esta etapa se debe consensuar todo lo que se
requiere del sistema y será aquello lo que seguirá en las siguientes etapas, no
pudiéndose requerir nuevos resultados a mitad del proceso de elaboración del
software.

Diseño del Sistema

Se descompone y organiza el sistema en elementos que puedan elaborarse por
separado, aprovechando las ventajas del desarrollo en equipo. Como resultado
surge el SDD (Documento de Diseño del Software), que contiene la descripción de la
estructura relacional global del sistema y la especificación de lo que debe hacer
cada una de sus partes, así como la manera en que se combinan unas con otras.

Es conveniente distinguir entre diseño de alto nivel o arquitectónico y diseño

detallado. El primero de ellos tiene como objetivo definir la estructura de la solución
(una vez que la fase de análisis ha descrito el problema) identificando grandes
módulos (conjuntos de funciones que van a estar asociadas) y sus relaciones. Con
ello se define la arquitectura de la solución elegida. El segundo define los algoritmos
empleados y la organización del código para comenzar la implementación.

Diseño del Programa

Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de
los requerimientos del usuario así como también los análisis necesarios para saber
que herramientas usar en la etapa de Codificación.

Codificación
Es la fase en donde se implementa el código fuente, haciendo uso de prototipos así
como de pruebas y ensayos para corregir errores.
Dependiendo del lenguaje de programación y su versión se crean las bibliotecas y
componentes reutilizables dentro del mismo proyecto para hacer que la
programación sea un proceso mucho más rápido.
Pruebas
Los elementos, ya programados, se ensamblan para componer el sistema y se
comprueba que funciona correctamente y que cumple con los requisitos, antes de
ser entregado al usuario final.

Implantación
Es la fase en donde el usuario final ejecuta el sistema, para ello el o los
programadores ya realizaron exhaustivas pruebas para comprobar que el sistema no
falle.

Mantenimiento
Una de las etapas que creo considerables porque se destina un 75% de los
recursos, es el mantenimiento del Software ya que al utilizarlo como usuario final
puede ser que no cumpla con todas nuestras expectativas.

Variantes
Existen variantes de este modelo; especialmente destacamos la que hace uso de
prototipos y en la que se establece un ciclo antes de llegar a la fase de
mantenimiento, verificando que el sistema final este libre de fallos.

Desventajas
En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala
implementación del modelo, lo cual hace que lo lleve al fracaso.
El proceso de creación del software tarda mucho tiempo ya que debe pasar por el
proceso de prueba y hasta que el software no esté completo no se opera. Esto es la
base para que funcione bien.
Cualquier error de diseño detectado en la etapa de prueba conduce necesariamente
al rediseño y nueva programación del código afectado, aumentando los costos del
desarrollo.

MODELOS DE DESARROLLO EN ESPIRAL

El desarrollo en espiral es un modelo de ciclo de vida del software definido por
primera vez por Barry Boehm en 1988, utilizado generalmente en la Ingeniería de
software. Las actividades de este modelo se conforman en una espiral, en la que
cada bucle o iteración representa un conjunto de actividades. Las actividades no
están fijadas a priori, sino que las siguientes se eligen en función del análisis de
riesgo, comenzando por el bucle interior.

La Ingeniería de software, se vale y establece a partir de una serie de modelos que

establecen y muestran las distintas etapas y estados por lo que pasa un producto
software, desde su concepción inicial, pasando por su desarrollo, puesta en marcha
y posterior mantenimiento, hasta la retirada del producto. A estos modelos se les
denomina «modelos de ciclo de vida del software». El primer modelo concebido fue
el de Royce, más comúnmente conocido como desarrollo en cascada o desarrollo
lineal secuencial. Este modelo establece que las diversas actividades que se van
realizando al desarrollar un producto software se suceden de forma lineal.
Boehm, autor de diversos artículos de ingeniería del software; modelos de
estimación de esfuerzo y tiempo que se consume en hacer productos software; y
Modelos de Ciclo de Vida; ideó y promulgó un modelo desde un enfoque distinto al
tradicional en Cascada: El Modelo Evolutivo Espiral. Su Modelo de Ciclo de Vida en
Espiral tiene en cuenta fuertemente el riesgo que aparece a la hora de desarrollar
software. Para ello, se comienza mirando las posibles alternativas de desarrollo, se
opta por la de riesgo más asumible y se hace un ciclo de la espiral. Si el cliente
quiere seguir haciendo mejoras en el software, se vuelve a evaluar las distintas
nuevas alternativas y riesgos y se realiza otra vuelta de la espiral, así hasta que
llegue un momento en el que el producto software desarrollado sea aceptado y no
necesite seguir mejorándose con otro nuevo ciclo.
Este modelo fue propuesto por Boehm en 1988. Básicamente consiste en una serie
de ciclos que se repiten en forma de espiral, comenzando desde el centro. Se suele
interpretar como que dentro de cada ciclo de la espiral se sigue un Modelo Cascada,
pero no necesariamente debe ser así. El Espiral puede verse como un modelo
evolutivo que conjuga la naturaleza iterativa del modelo MCP con los aspectos
controlados y sistemáticos del Modelo Cascada, con el agregado de gestión de
riegos.
En cada vuelta o iteración hay que tener en cuenta

Los Objetivos: Que necesidad debe cubrir el producto.

Alternativas: Las diferentes formas de conseguir los objetivos de forma exitosa,

desde diferentes puntos de vista como pueden ser:
1. Características: experiencia del personal, requisitos a cumplir, etc.
2. Formas de gestión del sistema.
3. Riesgo asumido con cada alternativa.

Desarrollar y Verificar: Programar y probar el software.

Si el resultado no es el adecuado o se necesita implementar mejoras o
funcionalidades
Se planificaran los siguientes pasos y se comienza un nuevo ciclo de la espiral. La
espiral tiene una forma de caracola y se dice que mantiene dos dimensiones, la
radial y la angular:

1. Angular: Indica el avance del proyecto del software dentro de un ciclo.

2. Radial: Indica el aumento del coste del proyecto, ya que con cada nueva
iteración se pasa más tiempo desarrollando.

Este sistema es muy utilizado en proyectos grandes y complejos como puede ser,
por ejemplo, la creación de un Sistema Operativo.
Al ser un modelo de Ciclo de Vida orientado a la gestión de riesgo se dice que uno
de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique
tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente
los riesgos.

Tareas
Para cada ciclo habrá cuatro actividades:
- Determinar Objetivos
- Análisis del riesgo
- Planificación
- Desarrollar y probar
Determinar o fijar objetivos
• Fijar también los productos definidos a obtener: requerimientos,
especificación, manual de usuario.
• Fijar las restricciones.
• Identificación de riesgos del proyecto y estrategias alternativas para evitarlos.
• Hay una cosa que solo se hace una vez: planificación inicial o previa.

Análisis del riesgo

Desarrollar, verificar y validar (probar)
• Tareas de la actividad propia y de prueba.
• Análisis de alternativas e identificación resolución de riesgos.
• Dependiendo del resultado de la evaluación de los riesgos, se elige un
modelo para el desarrollo, el que puede ser cualquiera de los otros existentes,
como formal, evolutivo, cascada, etc. Así si por ejemplo si los riesgos en la
interfaz de usuario son dominantes, un modelo de desarrollo apropiado podría
ser la construcción de prototipos evolutivos. Si lo riesgos de protección son la
principal consideración, un desarrollo basado en transformaciones formales
podría ser el más apropiado.

Planificar
• Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos
con las fases siguientes y planificamos la próxima actividad.

Mecanismos de control
• La dimensión radial mide el coste.
 • La dimensión angular mide el grado de avance del proyecto.

Variaciones del Modelo En Espiral

• Modelo en Espiral Típico de seis regiones.
• Modelo en espiral WIN WIN.

Ventajas
El análisis del riesgo se hace de forma explícita y clara. Une los mejores elementos
de los restantes modelos.
• Reduce riesgos del proyecto
• Incorpora objetivos de calidad
• Integra el desarrollo con el mantenimiento, etc.
Además es posible tener en cuenta mejoras y nuevos requerimientos sin romper con
la metodología, ya que este ciclo de vida no es rígido ni estático.

Desventajas
• Genera mucho tiempo en el desarrollo del sistema
• Modelo costoso
• Requiere experiencia en la identificación de riesgos

Inconvenientes
Planificar un proyecto con esta metodología es a menudo imposible, debido a la
incertidumbre en el número de iteraciones que serán necesarias. En este contexto la
evaluación de riesgos es de la mayor importancia y, para grandes proyectos, dicha
evaluación requiere la intervención de profesionales de gran experiencia.

LENGUAJE UNIFICADO DE MODELADO.

Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modelling
Language) es el lenguaje de modelado de sistemas de software más conocido en la
actualidad; aún cuando todavía no es un estándar oficial, está apoyado en gran
manera por el OMG (Object Management Group). Es un lenguaje gráfico para
visualizar, especificar, construir y documentar un sistema de software. El UML ofrece
un estándar para escribir un "plano" del sistema, incluyendo aspectos conceptuales
tales como procesos de negocios y funciones del sistema, y aspectos concretos
como expresiones de lenguajes de programación, esquemas de bases de datos y
componentes de software reutilizables.

El punto importante para notar aquí es que el UML es un "lenguaje" para especificar
y no un método o un proceso. El UML se usa para definir un sistema de software;
para detallar los artefactos en el sistema, para documentar y construir -es el lenguaje
en el que está escrito el plano-. El UML se puede usar en una gran variedad de
formas para soportar una metodología de desarrollo de software (tal como el
Proceso Unificado de Rational) -pero no especifica en sí mismo qué metodología o
proceso usar.

El UML cuenta con varios tipos de modelos, los cuales muestran diferentes aspectos
de las entidades representadas.

¿Qué es UML?

Es un lenguaje estándar para la especificación, visualización, construcción y

documentación de artefactos de sistemas de Software, muy bueno para la
modelación de negocios y otros sistemas que no son Software. El UML representa
una colección de las mejores prácticas de ingeniería que tienen una probación
exitosa en la modelación de sistemas largos y complejos

El UML es una parte muy importante para el desarrollo de Software Orientados a

Objetos y en el Proceso de Desarrollo de Software. Utiliza, en su mayor parte,
notaciones gráficas para expresar para expresar los proyectos de diseño del
Software. Utilizando el ayudante del UML puede comunicar el equipo de proyecto,
explorar el potencial de diseños, y validar el diseño de la arquitectura del Software.

Las principales metas del UML fueron:

• Proveer usuarios con un "ready-to-use" (facilidad de uso), lenguaje de

modelación visual expresivo donde ellos puedan desarrollar e intercambiar
modelos significativos.
• Proveer extensamente y específicamente mecanismos para extender el
núcleo de conceptos.
 • Ser independientes en los lenguajes de programación particulares y procesos
de desarrollo.
• Proveer una base formal para el entendimiento del lenguaje de modelación.
• Fomentar el crecimiento de las herramientas del mercado Orientado a
Objetos.
• Soportar el concepto de desarrollo en alto nivel tal como colaboraciones,
sistemas, modelos y componentes.
• Integrar mejores prácticas.

¿Por qué Utilizar el UML?

Como la estrategia de evaluación incrementa en muchas compañías, las industrias

la observa como técnicas de automatización la producción del Software y para
mejorar la calidad y reducir los costos y el tiempo del mercado. Éstas técnicas
incluyen el componente tecnológico, la programación visual, modelos y sistemas.
Los negocios también observan técnicas para manejar la complexión de sistemas,
así ellos aumentan en ámbito y en escala.

En particular, ellos reconocen la necesidad de resolver problemas que ocurran en la

arquitectura, tales como la distribución física, concurrencia, réplicas, seguridad,
carga balanceada y tolerancia de culpa. Adicionalmente, el desarrollo de la World
Wide Web (Mundo de la Ancha Telaraña), mientras se hacen algunas cosas simples,
tiene exacerbada ese problema de arquitectura.

La UML fue desarrollada para responder todas esas necesidades.

¿Qué es un Modelo?

La modelización (bien matemática o física) es un mecanismo efectivo para el análisis

técnico de sistemas basados en computadora. La figura ilustra el flujo global de
información del proceso de modelización. El modelo se crea a partir de la
observación del mundo real o de una aproximación basada en los objetivos del
sistema. El analista comprueba el comportamiento del modelo y lo compara con el
del mundo real o con el del sistema esperado, obteniendo la información de
viabilidad técnica para el sistema propuesto.
Blanchard y Fabrycky [BLA81] definen un conjunto de criterios para el uso de
modelos durante el análisis técnico de sistemas:

1. El modelo debe representar la dinámica de la configuración del sistema

que está siendo evaluado.
2. El modelo debe realzar aquellos factores que sean más relevantes para
el problema en cuestión y suprimir (con discreción) aquellos que no sean
importantes.
3. El modelo debe ser amplio, incluyendo "todos" los factores relevantes,
y fiable en cuanto a repetición de resultados.
4. El diseño del modelo debe ser lo suficientemente simple como para
permitir una rápida implementación de la resolución del problema.
5. El diseño del modelo debe incorporar previsiones para poder
modificarlo y/o expandirlo fácilmente y permitir la evaluación de factores
adicionales si se requieren.

Los resultados del análisis técnico son la base de otra decisión del tipo "seguir/no
seguir" con el sistema. Si el riesgo técnico es alto, si los modelos indican que la
funcionalidad o el rendimiento deseados no pueden ser alcanzados, o si las piezas
no encajan bien- ¡Hay qué volver a la mesa de trabajo!

Tipos de Modelo.

• Funcional: Muestra la funcionalidad del sistema desde el punto de vista del

usuario, incluye:
o Diagramas de caso de uso

• Objetos: Muestra la estructura y la subestructura del sistema usando objetos,

atributos, operaciones y asociaciones, incluye:
o Diagramas de clase

• Dinámico: Muestra el comportamiento interno del sistema, incluye:

o Diagramas de secuencia
o Diagramas de actividad
o Diagramas de estados

Software Libre para Modelado en UML.

 • Poseidon for UML, Herramienta de modelado UML escrita en java que cuenta
con una completa versión gratuita denominada Community Edition.
• ArgoUml, Herramienta de modelado UML escrito en java.
• Dia, Puede ser usado para modelar varios tipos de diagramas UML.
• Umbrello, Herramienta para modelado UML para el entorno KDE.
• MonoUML, Herramienta CASE para la plataforma mono.
• UMLet, Herramienta para modelado rápido de UML también escrita en Java.
• gModeler, Herramienta para modelado de UML basada en Flash (utilizable desde
el navegador), que permite generar codigo Action Script 2.0 Compatible.

Estandarización de UML.

Además de haberse convertido en un estándar de facto, UML es un estándar

industrial promovido por el grupo OMG al mismo nivel que el estándar CORBA para
intercambio de objetos distribuidos. Para la revisión de UML se formaron dos
"corrientes" que promovían la aparición de la nueva versión desde distintos puntos
de vista. Finalmente se impuso la visión más industrial frente a la académica.
Recientemente se ha publicado la versión 2.0 en la que aparecen muchas
novedades y cambios que, fundamentalmente, se centran en resolver carencias
prácticas. Además, esta versión recibe diversas mejoras que provienen del lenguaje
SDL.

Críticas a UML.

A pesar de su status de estándar ampliamente reconocido y utilizado, UML siempre

ha sido muy criticado por su carencia de una semántica precisa, lo que ha dado
lugar a que la interpretación de un modelo UML no pueda ser objetiva.

Otro problema de UML es que no se presta con facilidad al diseño de sistemas

distribuidos. En tales sistemas cobran importancia factores como transmisión,
serialización, persistencia, etc. UML no cuenta con maneras de describir tales
factores. No se puede, por ejemplo, usar UML para señalar que un objeto es
persistente, o remoto, o que existe en un servidor que corre continuamente y que es
compartido entre varias instancias de ejecución del sistema analizado.

Su Utilización.
El estándar UML 2.0 está con nosotros. En Julio de 2003la superestructura UML2.0
fue publicado y desde entonces éste tuvo abundante especulación sobre los
cambios y su impacto sobre la comunidad UML.

Los cambios más obvios del UML 1.x al 2.0 fueron la introducción de nuevos
diagramas. Los nuevos diagramas incluyen:

* Diagrama de Estructura.
* Diagrama Compuesta.
* Diagrama de Comunicación.
* Diagrama de Oportunidad.
* Diagrama de Interacción por Repaso.