Universidad de las Ciencias Informáticas
Facultad 3
Título: Herramientas para automatización en la Generación de Código Fuente en el proceso de desarrollo de Software.
Trabajo de Diploma para optar por el título de Ingeniero Informático
Autor: Alexander Osorio Leyva Tutor: Kiosmy Almenares
Ciudad de la Habana
Junio de 2008.
II
"Todo trabajo por mas humilde que sea dignifica al hombre."
Manuel Medina
III Declaro ser autor de la presente tesis y reconozco a la Universidad de las Ciencias Informáticas los derechos patrimoniales de la misma, con carácter exclusivo. Para que así conste firmo la presente a los ____ días del mes de ________ del año ________.
Alexander Osorio Leyva Ing. Kiosmy Almenares Herrera
______________ ______________
Firma del Autor Firma del Tutor
IV A Fidel, por hacerme partícipe de esta obra científica que ha creado.
A Arturo y Yoilda, ejemplos de padres, amigos, que me apoyaron en estos cinco años de carrera.
A mi Papá Hermenegildo y mi querida hermanita Kenia, que me sostuvieron desde la distancia.
A Ayme Perdomo, ejemplo de mujer, compañera, amiga, que en mis primeros años de carrera me sustento y me dio su ejemplo.
A mis compañeros del grupo ODISEO, en especial al profesor Rolan por confiar en mí.
A mis compañeros del Proyecto RN, especialmente, a Osmar, Eduardo, Handy, Alian, Armando, Alain, por todas las veces en que requerí su ayuda.
De manera especial a mi tutor Kiosmy, Carlos Yasmany, a Osmany Becerra y a Iosmel Rodriguez por su ayuda en este trabajo.
A todos, mil gracias y espero tener la dicha de servirles, siempre.
Alex.
V
DEDICATORIA
Dedico este trabajo de diploma a mis padres y mis hermanos, a quienes les debo todo lo que soy y quiero ser, especialmente a mi hermanita Kenia por quererme tanto y ser mi fuente de inspiración cada día.
De manera muy especial a Arturo y familia, porque siempre he sentido que son mi familia y a ellos también debo mí empeño en no fallar y particularmente a Alejandrito y Arturito, por los que me he esforzado para darles mi ejemplo.
A mis hermanos de siempre y para siempre, los que han seguido mi camino y me han alentado a esforzarme. Michel, Danyer, Arturo (hijo), Jorge Lancella y mi hermano de lucha, en buenas y malas, del que estoy muy orgulloso, Jose Alberto (Fernández, soy tu fan número uno).
VI
RESUMEN
El desarrollo de software con fines económicos ha alcanzado un nivel importante en la última década en nuestro país, en la Universidad de Ciencias Informáticas se lleva una intensa tarea de producción de software, con el propósito de aportar importantes ingresos a la economía del país. Buscar ideas que agilicen el proceso de desarrollo de software es una tarea a la que todos estamos llamados.
Las herramientas de generación de código juegan un papel primordial en la producción de software.
Con ellas se disminuye el tiempo en que se desarrolla un producto y las posibilidades de errores en la elaboración del mismo. Además se aumenta la calidad del software creado y se facilita su mantenimiento.
El propósito de este trabajo es construir una herramienta sencilla, práctica y adaptable a los estilos de programación de cada equipo de trabajo y cada desarrollador, pero que a su vez se rija por los estándares de estilos de codificación, contribuyendo así con la claridad del código fuente y un mejor entendimiento entre los equipos de desarrollo. Esto ahorrará en gran medida el tiempo de construcción, maximizando la calidad en los productos de software.
PALABRAS CLAVE
Generación de código, automatización, estándares, proceso de desarrollo.
VII ...
DEDICATORIA ... V RESUMEN ... VI
INTRODUCCIÓN ... 1
ESTRUCTURA DEL CONTENIDO DEL TRABAJO ... 3
1 CAPÍTULO 1: FUNDAMENTACIÓN TEÓRICA ... 4
INTRODUCCIÓN ... 4
1.1 ACERCA DE LA GENERACIÓN DE CÓDIGO ... 4
1.1.1 ¿Qué es la Generación de código? ... 4
1.1.2 Creación de generadores de código. ... 5
1.1.3 Softwares generadores de Código existentes. ... 7
1.1.4 Ventajas y Desventajas de los generadores de código. ... 9
1.2 PROCESO DE DISEÑO DE SOFTWARE ... 10
1.2.1 Diseño de Software: Estado Actual ... 11
1.2.2 Diseño de Software: Evolución ... 13
1.2.3 Diseño de Software: Principios ... 14
1.3 HERRAMIENTAS Y TECNOLOGÍAS... 15
1.3.1 Microsoft .Net ... 15
1.3.2 Lenguaje Unificado de Modelado (UML) ... 20
1.4 METODOLOGÍAS DE DESARROLLO ... 21
1.4.1 Proceso Unificado de Desarrollo (RUP). ... 21
1.4.2 Metodología XP ... 23
1.4.3 Microsoft Solution Framework (MSF) ... 24
1.5 PATRONES DE DISEÑO ... 26
1.5.1 ¿Qué son los Patrones de Diseño? ... 26
1.5.2 Origen de los Patrones de diseño. ... 27
1.5.3 ¿Qué ventajas ofrecen?... 27
1.5.4 Características de los Patrones ... 27
1.5.5 Clasificación ... 28
CONCLUSIONES ... 29
2 CAPÍTULO 2: CARACTERÍSTICAS DEL SISTEMA ... 30
INTRODUCCIÓN ... 30
VIII
2.1 DESCRIPCIÓN GENERAL DE LA PROPUESTA DEL SISTEMA ... 30
2.2 FUNCIONAMIENTO DEL SISTEMA ... 30
2.2.1 Fuente de datos para el diseño de la Plantilla. ... 32
2.2.2 Estructura y funcionamiento del Árbol de Datos ... 32
2.3 PLANTILLAS ... 33
2.3.1 ¿Qué son las Plantillas?... 33
2.3.2 Trascendencia de las Plantillas en la solución. ... 34
2.3.3 Formato y creación de un lenguaje para las Plantillas. ... 34
2.3.4 ¿Cómo se crea una plantilla? ... 38
2.4 FUNCIONAMIENTO DE LA MAQUINA GENERADORA (INTÉRPRETE DEL LENGUAJE DE LAS PLANTILLAS) ... 39
2.4.1 Uso de expresiones regulares como motor de búsqueda ... 39
2.4.2 Volcado de datos en el código de las plantillas para conformar las salidas. ... 40
2.4.3 Uso de Reflection para desensamblar objetos. ... 40
2.4.4 Generación de Salidas ... 41
2.5 MODELO DE DOMINIO ... 42
2.6 REQUISITOS FUNCIONALES ... 42
2.7 REQUISITOS NO FUNCIONALES ... 43
2.8 ACTORES DEL SISTEMA ... 43
2.9 DIAGRAMA DE CASOS DE USO DEL SISTEMA ... 44
2.10 RESULTADO DE PRIORIZAR LOS CASOS DE USO ... 44
2.11 DESCRIPCIÓN DE LOS CASOS DE USO DEL SISTEMA ... 44
2.12 PROPUESTA DE DISEÑO DEL SOFTWARE ... 51
2.12.1 Diagrama de clases y de colaboración del paquete Gestionar Plantillas ... 52
2.12.2 Diagrama de clases y de colaboración del paquete CU Gestionar Fuente de Datos ... 53
2.12.3 Diagrama de clases y de colaboración del paquete CU Generar Clases ... 54
2.12.4 Patrones de diseño empleados ... 55
CONCLUSIONES ... 59
3 CAPÍTULO 3: IMPLEMENTACIÓN Y PRUEBAS ... 60
INTRODUCCIÓN. ... 60
3.1 IMPLEMENTACIÓN ... 60
3.2 VALIDACIÓN DEL SISTEMA ... 62
3.2.1 Métricas Orientadas a Clases ... 63
3.2.2 Métricas propuestas por Lorenz y Kidd ... 65
3.3 MÉTRICAS APLICADAS AL DISEÑO DEL SISTEMA ... 66
IX
3.3.1 Métricas propuestas por Lorenz y Kidd ... 66
3.3.2 La serie de métricas de CK ... 69
3.3.3 Pruebas de Unidad ... 70
3.3.4 Resultados de las pruebas aplicadas al Sistema ... 75
CONCLUSIONES ... 76
CONCLUSIONES ... 77
RECOMENDACIONES ...¡ERROR! MARCADOR NO DEFINIDO. BIBLIOGRAFÍA ... 79
ANEXOS ... 81
ANEXO 1.DISEÑO DE CLASES DEL NEGOCIO. ... 81
ANEXO 2.DISEÑO DE CLASES DE LA CAPA DE PRESENTACIÓN ... 82
ANEXO 3.DISEÑO DE CLASES DEL COMPONENTE TXTRESERVADORICH. ... 83
ANEXO 4.VISTA PRINCIPAL DEL GENERPLANT. ... 84
ANEXO 5.MUESTRA DE ERRORES Y ADVERTENCIAS... 85
ANEXO 6.MUESTRA DE LA BARRA DE HERRAMIENTAS ... 87
ANEXO 7.MUESTRA DEL GENERADOR DE REPORTES USANDO GENERPLANT DE BASE... 88
GLOSARIO DE TÉRMINOS ... 92
1
INTRODUCCIÓN
El objetivo de toda empresa dedicada a la producción de software se centra principalmente en construir sus productos de software de una manera rápida, eficiente y con costes de tiempo mínimos.
Esto es un reto difícil de lograr, dado que las demandas de los clientes son siempre mayores que las capacidades productivas de estas empresas. La solución se ha buscado optimizando todas las áreas de desarrollo, desarrollando nuevas tecnologías, framework, perfeccionando metodologías.
Una de las áreas en las que se puede seguir mejorando, es en el perfeccionando de herramientas de generación de código. Siendo el uso de estas herramientas un factor clave en la calidad, rapidez y eficiencia de los proyectos de software. Para tener una idea del valor que implica en el desarrollo el uso de estas herramientas, nada mas hay que fijarse en el precio del generador de códigos CodeSmith, que sobrepasa los tres mil dólares.
La Universidad de las Ciencias Informáticas, desde que fue fundada, se ha dedicado a la producción de software, funcionando como una gran empresa productora de software, además de ser un centro de estudios, con el propósito de autofinanciarse y de esta manera ayudar al país económicamente, desplegando para ello un amplio parque tecnológico en materia de hardware y software, que permitan la construcción de aplicaciones informáticas robustas, eficientes y con costes de tiempos mínimos.
Es necesario para lograr la eficiencia en la producción, minimizar los tiempos de producción, logrando un entendimiento entre los diferentes polos productivos que hay actualmente en la universidad, en cuanto a estándares de codificación y utilización de herramientas que agilizan el desarrollo del software.
En el desarrollo de las aplicaciones independientes del negocio en el que se utilicen, existen una serie de patrones comunes que hacen al desarrollador repetir el código varias veces, cambiando solo algunas diferencias, siendo así una situación problemática la pérdida de tiempo de trabajo de los desarrolladores.
Esta situación problémica presupone:
Demoras excesivas a la hora de implementar el negocio.
Gestión de grandes cantidades de código fuente para detectar errores en la escritura manual de los desarrolladores.
2 Desentendimiento entre proyectos, módulos, desarrolladores en cuanto a estilo de programación y estándares de codificación. Lo que hace más difícil la tarea de soporte y mantenimiento del software una vez desplegado.
A partir de todo lo anteriormente expuesto podemos establecer como nuestro problema: ¿Cómo reducir los errores en el código, minimizar el tiempo de desarrollo y reducir el trabajo manual de los desarrolladores a la hora de escribir el código de las aplicaciones en los proyectos productivos?
El Objeto de Estudio de este trabajo es: “La simplificación del trabajo manual de los desarrolladores”
y el campo de acción: “Las herramientas de generación de código”.
Existen muchas herramientas que generan código, eso evidencia la importancia que los desarrolladores le confieren al uso de las mismas. Esta investigación se propone como objetivo general el diseño e implementación de una herramienta que ayude a los desarrolladores a crear sus propios generadores de código, para lo cual se plantean los siguientes objetivos específicos:
Hacer un levantamiento de los principales requisitos que debe cumplir este tipo de herramientas.
Diseñar e implementar una herramienta que sirva de soporte para crear herramientas generadoras de código.
Las tareas específicas para cumplir con los objetivos propuestos son:
Documentarse sobre la generación de código.
Estudio de las herramientas de generación de código más reconocidas, para extraer sus ventajas y buscar posibles mejoras.
Levantamiento de los requisitos de la herramienta propuesta.
Diseño de la herramienta generadora de código.
Implementación de la herramienta.
Como antecedente a esta investigación se tiene la implementación de una herramienta Generadora de Clases, Esquemas y Reportes para la plataforma Microsoft .Net, la cual lleva dos años de explotación en el proyecto Registros y Notarias para la hermana República de Venezuela. El uso de esta herramienta por los desarrolladores de R&N permitió aumentar el rendimiento en la producción. Esto puede darnos una idea de cuánto se puede perfeccionar, en el campo de la automatización en la generación de código fuente en los proyectos productivos de la Universidad.
3
Estructura del contenido del trabajo.
Capítulo I. Fundamentación teórica: En este capítulo se hace un estudio del estado del arte de las herramientas actuales utilizadas para la generación de código. Las tendencias existentes, las técnicas utilizadas, la tecnología y herramientas empleadas para el análisis, diseño e implementación de la herramienta.
Capítulo II. Características del sistema: Se trata el objeto de informatización, logrando una propuesta del sistema, modelando el negocio, especificando requisitos funcionales y no funcionales que debe cumplir el sistema, y definiendo los casos de uso, así como patrones de diseños más empleados en la solución.
Capítulo III. Implementación y Prueba: Aborda la parte de implementación donde se muestran las dependencias entre las partes del código del sistema (diagrama de componentes), los diagramas de componentes se utilizan para modelar la vista de implementación estática de un sistema. Abordándose además la etapa en la que se realizaron las pruebas al diseño para evaluar la calidad del producto de software desarrollado.
.
4
1 CAPÍTULO 1: FUNDAMENTACIÓN TEÓRICA.
Introducción
En este capítulo se hace un estudio del estado del arte donde se brinda una visión general de los aspectos relacionados con las herramientas generadoras de código, sus características, y una descripción de los principales conceptos asociados al problema para un entender mejor la propuesta de solución. Se describe la tecnología, herramientas y técnicas que serán empleadas para la construcción del software.
1.1 Acerca de la generación de código.
En la actualidad la generación de código se ha reafirmado más como una solución a los problemas de eficiencia y ahorro de tiempo en los proyectos, pero aun no se puede hablar de una herramienta que resuelva todos los problemas. Tampoco existe una cultura de utilización por parte de los desarrolladores de estas herramientas.
1.1.1 ¿Qué es la Generación de código?
“En programación, la generación de código es una de las fases mediante el cual un compilador convierte un programa sintácticamente correcto en una serie de instrucciones a ser interpretadas por una máquina. La entrada en esta fase viene representada, típicamente, por un Árbol Sintáctico, un Árbol de Sintaxis Abstracta, o una Representación Intermedia; la máquina destino puede ser un microprocesador o una máquina abstracta tal como una máquina virtual o un lenguaje intermedio, legible por un humano. Compiladores más sofisticados realizan múltiples traducciones en cadena (pipelining) con el fin de poder construir código para múltiples plataformas y evitar tener que construir todas las capas del compilador.” [17].
En términos más generales, la generación de código es usada para construir programas de una manera automática evitando que los programadores tengan que escribir el código a mano.
Constituyendo un ahorro de tiempo en el desarrollo de proyectos y aplicaciones.
En tiempos más recientes la generación de código, gracias al avance de la ingeniería del software, se ha llevado a un nivel superior; donde se encuentran programas generadores de pantallas, reportes y consultas, estas son herramientas de gran utilidad; pero se debe, en la mayoría de los casos, pagar una gran cantidad de dinero por ellos.
Existen varios tipos de generaciones de código, las cuales se clasifican fundamentalmente de acuerdo al código generado.
5
Tipos de generaciones de código.
Existen tres tipos fundamentales para la generación de código, enumerados a continuación: [32]
Plantillas (Templating). Se genera un armazón (o esbozo) de código fuente no funcional para ser editado, con el que se evita tener que escribir la parte más repetitiva del código. Generalmente poco complejo, recomendable.
Parcial. Se genera código fuente que implementa parcialmente la funcionalidad requerida, pero que el programador usará como base para modificar, integrar y/o adaptar a sus necesidades. No suele ser recomendable.
Total. Se genera código fuente funcionalmente completo pero que no va a ser modificado por el programador, sino que si es necesario se vuelve a regenerar. Por lo general tampoco suele ser un código excesivamente complejo. Recomendable.
Una vez visto qué es la generación de código y los tipos de generaciones, es posible analizar que es necesario para la creación de generadores de código, lo cual veremos en el próximo epígrafe.
1.1.2 Creación de generadores de código.
Para la creación de generadores de código se deben considerar los siguientes aspectos: [26, 32]
La arquitectura de software para la cual se va a desarrollar el generador.
Las características especificas del lenguaje de programación para el que se va a desarrollar.
El lenguaje con el que se desarrollará el propio generador.
Responder las interrogantes: [26]
¿La generación de código se realizará a partir de modelos como UML?
¿La generación de código se hará a partir de las tablas de una base de datos?
¿Se realizará un generador de código que su resultado sea fragmentos de código que son de uso más frecuente en el software?
¿Se creará un generador genérico que "genere" código para diferentes lenguajes?
Las reglas de utilización del generador, en otras palabras, la forma adecuada para que los usuarios del generador obtengan el mayor provecho.
En síntesis para crear un generador de código se deben hacer muchas de las tareas que realizan los compiladores; algunas de estas tareas son: [26]
La búsqueda de patrones.
La escritura de código.
6 El análisis sintáctico.
El análisis léxico.
La optimización de código.
Estas tareas las realiza el desarrollador una vez, para una arquitectura específica, pero antes de plantear una arquitectura se debe conocer cómo funciona un generador de código
Funcionamiento de un generador de código.
Los generadores de código implementan las siguientes fases en este orden: [32]
Carga: La fase de carga consiste en la lectura desde un repositorio (puede ser un fichero binario, XML, una base de datos, o un diagrama UML) del modelo a traducir y crear una representación de éste en memoria. La representación de este modelo en memoria, no tiene porqué ser completa (cargar toda la información de modelo), ni tampoco seguir la misma estructura del modelo. Al contrario, la carga y las estructuras pueden ser adaptadas para cargar sólo la información necesaria y disponerla del modo que sea más conveniente para la tarea de traducción a realizar.
Inferencia: Si se han definido una serie de mecanismos de inferencia, que completan la información de modelado, éstos se ejecutan. Las estructuras del modelo en memoria son completadas y extendidas. Es necesario llevar a cabo este proceso antes de proceder a la generación propiamente dicha. El proceso es responsable de realizar pre cálculos útiles y de disponer adecuadamente la información para la fase posterior.
Generación: La última fase es la de generación. En función del código destino a producir, se recorren secuencialmente, y de modo anidado, los elementos de modelo en sucesivas pasadas.
Por ejemplo: para cada clase, para cada servicio y para cada argumento. Como resultado de esta fase se obtiene el código generado.
Ahora que entendemos el funcionamiento de los generadores y los tipos de generaciones existentes, podemos clasificar los Generadores atendiendo a sus métodos de generación de código.
Tipos de generadores de código.
Los Softwares generadores de código se clasifican en activos o pasivos, según sus métodos de generación. [33]
Los generadores activos son aquellos que permiten generar varias veces sobre el mismo código generado a partir de cambios en la entrada. Estos generadores definen espacios de código seguros donde el programador puede hacer los cambios que desee sin que éstos se pierdan en las sucesivas generaciones de código.
7 Los generadores pasivos generan el código una vez y no vuelven a tener interacción con él.
Tienen la desventaja de que si se corrige un error en los mecanismos de generación o se cambia el diseño y se vuelve a generar se pierde todo lo que se codificó manualmente.
En el campo de generación de código existe un gran número de herramientas generadoras de código, que siguiendo estos métodos de generación. Permiten automatizar procesos que normalmente los desarrolladores haríamos manualmente. En el siguiente epígrafe se describen algunas de las principales existentes.
1.1.3 Softwares generadores de Código existentes.
CodeSmith.
Fig. 1: CodeSmith.
El CodeSmith es un generador de código fuente para distintos lenguajes (C#, Java, VB, PHP, ASP.Net, SQL, etc.) a partir de plantillas. Las cuales se pueden crear usando un diseñador de plantillas. Posee plantillas predefinidas para la generación de arquitecturas reconocidas como (.NetTiers, CSLA, NHibernate, PLINGO, y más). Se pueden modificar las plantillas o escribir plantillas propias para generar el código exactamente como se requiere. Es reconocida por sus prestaciones, y si tomamos en cuenta el alto coste de las licencias podemos decir que los desarrolladores le dan mucha importancia a este tipo de herramientas. Pero el uso del CodeSmith es bastante complejo, la creación y edición de plantillas requiere de altos conocimientos de programación y específicamente del lenguaje XML, su principal desventaja es el alto coste de las licencias. [1, 2]
CodeSmith Professional Edition Precio(USD)
Licencia para un desarrollador $399
Licencia para un equipo de cinco desarrolladores $1,795
8 Licencia para un equipo de 10 desarrolladores $3,391
CodeSmith SDK $2,499
Tabla 1: Precios y licencias del CodeSmith. [14].
TierDeveloper.
Fig. 2: TierDeveloper.
Es una herramienta para generar capas de acceso a datos bajo el framework .Net. Soporta gestores de base de datos (SQL Server, Oracle, Microsoft Access y IBM db2). Con este generador podría reducirse el tiempo de desarrollo de un 50 % a un 70 % según su aplicación. Puede generar negocio y objetos de acceso de datos. Puede usar propios objetos de esfera y generar el código de persistencia para ellos. Su costo en el mercado es de $1495 para su uso indefinido por un desarrollador. [34]
Visual Paradigm.
Fig. 3: Visual Paradigm.
Es una herramienta Visual para el modelado UML. Está diseñada para ingenieros de software, analistas de sistemas, analistas de negocio, arquitectos y desarrolladores. Está orientada a la creación de diseños usando el paradigma de programación orientada a objetos. Visual Paradigm incluye una herramienta Visual Architect que permite la generación de código para el manejo de las bases de dato.
Con esta herramienta se puede generar código para lenguajes C#, Java, PHP y para los gestores de base de dato SQL Server, Oracle, PostgreSQL, MySQL y otros. Entre sus limitaciones está que el
9 código generado hace uso de librerías protegidas, limitando a los desarrolladores, el uso de sus propias librerías de acceso a datos y haciendo más engorroso el entendimiento y mantenimiento del código. Es una herramienta propietaria que tiene un costo elevado. La Enterprise Edition tiene un costo en el mercado de $1399. [30]
CODECHARGE STUDIO.
Fig. 4: CodeCharge Studio.
Es una solución muy productiva para visualmente crear aplicaciones Web con la cantidad mínima de codificación. Es bastante fácil y amigable. Genera conexión con base de datos Access, MS SQL, MySQL, Oracle. Pero además es capaz de generar los códigos en PHP, ASP, JSP, Perl, ColdFusion y ASP.NET. Este sistema tiene un gran problema, pues es software propietario y tiene un costo en el mercado de $139.95. [27, 28]
1.1.4 Ventajas y Desventajas de los generadores de código.
Estas herramientas son una prueba de que la ingeniería del software está evolucionando rápidamente, y que los ingenieros están buscando nuevas formas de construir aplicaciones., creando programas que construyen programas.
Los programas anteriores descritos son buenos mejorando la eficiencia y contribuyen al ahorro de tiempo y la calidad en un proyecto de software. De ahí que se han analizado, para construir la propuesta en base a sus ventajas y previendo sus deficiencias. Las cuales describimos a continuación:
La mayoría son programas propietarios y hay que pagar para su utilización, lo que implica un coste adicional para el proyecto. Generalmente entre más prestaciones brindan, más altos son los precios que hay que pagar por su uso.
Presentan una arquitectura compleja y engorrosa, lo que implica que las salidas generadas tengan un estilo inentendible por los desarrolladores que utilizan las herramientas.
Arman su estructura a partir de un diagrama que a veces hay que especificarle tan detalladamente que resulta muy complejo utilizarlo.
10 Una vez diseñadas las plantillas hacen dependientes a los desarrolladores del uso del Generador de Códigos, para generar sus salidas. No permitiéndoles, implementar sus propios generadores, para así personalizar sus fuentes de datos y hacer más extensible la Herramienta.
Por la complejidad de sus diseños requieren un profundo adiestramiento previo, para manipular las plantillas creadas y conocimientos avanzados del lenguaje XML
La herramienta propuesta está basada en la generación de código a partir de plantillas diseñadas visualmente, con corrección de errores. Con juegos de datos definidos visualmente, formando una estructura de clases fácilmente manipulables o cargando la estructura desde un ensamblado. También propone un ensamblado que referenciándolo en otras aplicaciones permitirían a desarrolladores, construir sus propios generadores, diseñando sus entradas de datos y sus plantillas, para generar salidas con el formato deseado.
Con esta aplicación se puede generar código con una arquitectura específica, y no se necesitan amplios conocimientos de programación para modificar la estructura del código generado. Lo principal que aporta es lo extensible que es para el programador que la usa, por la forma en que se pueden personalizar las salidas.
Se analizaron un conjunto de herramientas generadoras de código que apoyan el proceso de construcción de software, algunas de las cuales hacen uso de plantillas por la facilidad que estas proveen, como es el caso del CodeSmith. La generación de código con el propósito de automatizar procesos manuales de los desarrolladores y lograr que el sistema sea lo suficiente flexible, suele ser una tarea difícil. Las herramientas analizadas presentan deficiencias en este sentido, porque no son lo suficiente modernas o porque son demasiado costosas. Por esto que el diseño de la solución propuesta significa la posibilidad del paso a la implementación de una herramienta integral.
1.2 Proceso de Diseño de Software.
La importancia del Diseño de Software se puede definir en una sola palabra Calidad, dentro del diseño es donde se fomenta la calidad del proyecto.
El Diseño es la única manera de materializar con precisión los requerimientos del cliente.
El Diseño del software es un proceso y un modelador a la vez.
El proceso de Diseño es un conjunto de pasos repetitivos que permiten al diseñador describir todos los aspectos del Sistema a construir, en lo largo del diseño se evalúa la calidad del desarrollo del proyecto con un conjunto de revisiones técnicas.
11 El Diseño debe Implementar todos los requisitos explícitos contenidos en el modelo de análisis y
acumular todos los requisitos implícitos que desea el cliente.
Debe ser una guía que puedan leer y entender los que construyan el código y los que prueban y mantienen el software.
Debe proporcionar una completa idea de lo que es el software, enfocando los dominios y datos, funcional y comportamiento desde el punto de vista de la Implementación.
Para evaluar la calidad de una presentación del diseño, se deben establecer criterios técnicos para un buen diseño como son:
Un diseño debe presentar una organización jerárquica que haga un uso inteligente del control entre los componentes del software.
El diseño debe ser modular es decir se debe hacer una partición lógica del Software en elementos.
Un diseño debe contener abstracciones de datos y procedimientos.
Debe producir módulos que presenten características de funcionamiento independiente.
Debe conducir interfaces que reduzcan la complejidad de las conexiones entre los módulos con el entorno exterior.
Debe producir un diseño usando un método que pudiera repetirse según la información obtenida durante el análisis de requisitos de Software.
Estos criterios no se consiguen de casualidad. El proceso de Diseño del software exige buena calidad a través de la aplicación de principios fundamentales de Diseño, Metodología sistemática y una reforma exhaustiva. Cuando se va a diseñar un Sistema de Computadoras se debe tener presente que el proceso de diseño incluye, concebir y planear algo en la mente, así como hacer un dibujo, modelo o croquis. [18]
1.2.1 Diseño de Software: Estado Actual.
Actualmente el concepto de diseño es orientado a diferentes aristas como la que plantea Grady Bosch que “el diseño es el proceso de determinar una implementación efectiva y eficiente que realice las funciones y tenga la información del análisis de dominio” [28], o la que plantea R.S. Pressman que “el diseño del software se encuentra en el núcleo técnico de la ingeniería del software y se aplica independientemente del modelo de diseño de software que se utilice. Una vez que se analizan y especifican los requisitos del software, el diseño del software es la primera de las tres actividades técnicas - diseño, generación de código y pruebas - que se requieren para construir y verificar el software. Cada actividad transforma la información de manera que de lugar por último a un software de
12 computadora validado” [4]. Otra idea importante que refiera Pressman consiste en la importancia del diseño del software, pues según él, se puede describir con una sola palabra para este flujo -calidad-.
“El diseño es el lugar en donde se fomentan la calidad en la ingeniería del software. El diseño proporciona las representaciones del software que se pueden evaluar en cuanto a calidad. El diseño es la única forma de convertir exactamente los requisitos de un cliente en un producto o sistema de software finalizado. El diseño del software sirve como fundamento para todos los pasos siguientes del soporte del software y de la ingeniería del software. Sin un diseño, corremos el riesgo de construir un sistema inestable un sistema que falla cuando se lleven a cabo cambios; un sistema que puede resultar difícil de comprobar; y un sistema cuya calidad no puede evaluarse hasta muy avanzado el proceso, sin tiempo suficiente y con mucho dinero gastado” [4, 5].
En el caso de las metodologías como por ejemplo RUP, los criterios sobre el diseño de sistemas plantean que es el flujo del trabajo donde el arquitecto y los diseñadores de sistema, describen de una forma más concreta y acorde al tipo de tecnología, el cómo serán implementadas las funcionalidades del sistema en construcción, basándose en los tipos de colaboración, la relación que existe entre las clases, y las responsabilidades de cada unidad de código. Otra metodología muy utilizada es XP (Extreme Programming), la misma describe el diseño con en un enfoque práctico y dinámico para el cual el diseño de sistema es una actividad que construye un proceso de diseño evolutivo que se basa en refactorizar un sistema simple en cada iteración. Todo el diseño se centra en la iteración actual y no se hace nada anticipadamente para necesidades futuras. Sin dudas algunas uno de los principios de la programación extrema es la simplicidad de aquí que el diseño no escape a esta filosofía. El diseño debe ser lo más simple posible. El paradigma KISS ("Keep It Small and Simple" para unos o "Keep it Simple, Stupid" para otros) se lleva hasta las últimas consecuencias. Por ejemplo, se hace énfasis en no añadir funcionalidad al diseño del sistema nunca antes de lo necesario, por las sencillas razones de que probablemente ahora mismo no sea lo más prioritario o porque quizás nunca llegue a ser necesaria. [23]
Algunas empresas, como DEADELUS, plantean que el diseño de sistemas se ocupa de desarrollar las directrices propuestas durante el análisis en términos de aquella configuración que tenga más posibilidades de satisfacer los objetivos planteados tanto desde el punto de vista funcional como del no funcional. El proceso de diseño de un sistema complejo se suele realizar de forma descendente:
Diseño de alto nivel (o descomposición del sistema a diseñar en subsistemas menos complejos), diseño e implementación de cada uno de los subsistemas, especificación consistente y completa del subsistema de acuerdo con los objetivos establecidos en el análisis, desarrollo según la especificación, prueba, integración de todos los subsistemas, validación del diseño.
13 Microsoft por su parte plantea en su modelo MSF (Microsoft Solution Framework) para el desarrollo de sistemas de software, que el diseño es una actividad que debe ser realizada con el fin de establecer el comportamiento dinámico del sistema, es decir, como debe reaccionar ante los acontecimientos. Para su desarrollo también se utilizan los lenguajes de modelado. El resultado obtenido de la etapa de diseño facilita enormemente la implementación posterior de los sistemas, pues proporciona la estructura básica del sistema y como los diferentes componentes actúan y se relacionan entre ellos. [5]
1.2.2 Diseño de Software: Evolución.
Si se analiza la evolución del diseño de software se tendría que comenzar diciendo que los intentos por desarrollar programas que con cierta modularidad y métodos para perfeccionar las estructuras de forma descendente fueron los primeros las primeras cosas hechas en materia de diseño.
En la década del sesenta surgen manifestaciones de lo que más tarde se llamó Programación Estructurada, posteriormente se liberó el conjunto de las llamadas "Técnicas para mejoramiento de la productividad en programación", siendo la Programación Estructurada una de ellas.
Los programas fueron escribiéndose con un mayor grado de estructuración, lo cual les permitía ser fácilmente comprensibles en actividades tales como pruebas, mantenimiento y modificación de los mismos. Mediante la programación Estructurada todas las bifurcaciones de control de un programa se encuentran estandarizadas, de forma tal que es posible leer la codificación del mismo desde su inicio hasta su terminación en forma continua, sin tener que saltar de un lugar a otro del programa siguiendo el rastro de la lógica establecida por el programador, como es la situación habitual con codificaciones desarrolladas bajo otras técnicas.
Posteriormente se proponen métodos para el flujo de datos o estructura de datos en una definición de diseño[23, 24]. Enfoques más recientes proponen el diseño orientado a objetos.
Considerando el paradigma de la orientación a objetos, el diseño orientado a objetos es más complejo que el diseño estructurado clásico, ya que lo que se busca es crear un diseño genérico, abierto y concreto. El diseño orientado a objetos se define como un diseño de sistemas que utiliza objetos auto- contenidos y clases de objetos.
En la actualidad se busca básicamente un diseño basado en la arquitectura de software.
En su forma más simple, la arquitectura es la estructura jerárquica de los componentes del programa (módulos), la manera en que los componentes interactúan y la estructura de datos que van a utilizar los componentes. Sin embargo, en un sentido más amplio, los componentes se pueden generalizar para representar los elementos principales del sistema y sus interacciones. Un objetivo del diseño del software es derivar una representación arquitectónica de un sistema. Esta representación sirve como marco de trabajo desde donde se llevan a cabo actividades de diseño más detalladas. Un conjunto de
14 patrones arquitectónicos permiten que el ingeniero del software reutilice los conceptos a nivel de diseño.
Se puede señalar que independientemente del modelo de diseño que se emplee en el desarrollo de software, se deberán aplicar un conjunto de principios fundamentales y conceptos básicos para el diseño a nivel de componentes, de interfaz, arquitectónico y de datos. [5]
1.2.3 Diseño de Software: Principios.
El diseño de software es tanto un proceso como un modelo. El proceso de diseño es una secuencia de pasos que hacen posible que el diseñador describa todos los aspectos del software que se va construir. Sin embargo, es importante destacar que el proceso de diseño simplemente no es un recetario. Un conocimiento creativo, experiencia en el tema, un sentido de lo que hace que un software sea bueno, y un compromiso general con la calidad son factores críticos de éxito para un diseño competente.
El modelo de diseño es el equivalente a los planes de un arquitecto para una casa. Comienza representando la totalidad de todo lo que se va a construir y refina lentamente lo que va a proporcionar la guía para construir cada detalle. De manera similar, el modelo de diseño que se crea para el software proporciona diversas visiones de lo que se quiere construir. Los principios básicos de diseño hacen posible que el ingeniero del software navegue por el proceso de diseño con una mayor garantía de éxito que si se hace de modo improvisado y sin una guía metodológica.
Algunos autores sugieren un conjunto de principios para el diseño del software, los cuales han sido adaptados y ampliados en la lista siguiente: [4, 5]
En el proceso de diseño deberá pensarse dinámico. Un buen diseñador deberá tener en cuenta enfoques alternativos, juzgando todos los que se basan en los requisitos del problema, los recursos disponibles para realizar el trabajo y los conceptos de diseño ya estandarizados.
El diseño deberá garantizar una trazabilidad desde el flujo de requerimientos hasta él. Dado que un solo elemento del modelo de diseño puede o no hacer un seguimiento de los múltiples requisitos, es necesario tener un medio de rastrear como se han satisfecho los requisitos por el modelo de diseño.
El diseño no deberá pensarse desde el principio de la reutilización. Los sistemas se construyen utilizando un conjunto de patrones de diseño, muchos de los cuales probablemente ya se han encontrado antes. Estos patrones deberán elegirse siempre como una alternativa para reinventar.
El tiempo de diseño se deberá invertir en la representación verdadera de ideas nuevas y en la integración de esos patrones que ya existen.
15 El diseño deberá presentar uniformidad e integración. Un diseño es uniforme si parece que fue una persona la que lo desarrolló por completo. Las reglas de estilo y de formato deberán definirse para un equipo de diseño antes de comenzar el trabajo sobre el diseño. Un diseño se integra si se tiene cuidado a la hora de definir interfaces entre los componentes del diseño.
El diseño deberá estructurarse para admitir cambios. Los conceptos de diseño estudiados en la sección siguiente hacen posible un diseño que logra este principio.
El diseño deberá estructurarse con una estrategia de tratamiento de errores atenuante, incluso cuando se enfrenta con datos, sucesos o condiciones de operación aberrantes debe buscar alternativas de recuperación. El diseño debe adaptarse a circunstancias inusuales, y si debe terminar de funcionar, que lo haga de forma suave.
El diseño deberá evaluarse en función de la calidad y guiados por los requisitos mientras se va creando, no después de terminarlo. Para ayudar al diseñador en la evaluación de la calidad se dispone de conceptos de diseño, de medidas de diseño y del cumplimiento de los requerimientos implicados.
El diseño deberá revisarse para minimizar los errores conceptuales (semánticos). Un equipo de diseñadores deberá asegurarse de haber afrontado los elementos conceptuales principales antes de preocuparse por la sintaxis del modelo del diseño.
Es importante comprender que no es suficiente con que un programa funcione, sino que es necesario que lo haga correctamente y para ello es imprescindible que se haya realizado un correcto diseño del mismo en función de los requerimientos. [5]
A continuación se realiza una breve descripción de las principales herramientas y tecnologías a considerar en el desarrollo del software:
1.3 Herramientas y Tecnologías.
1.3.1 Microsoft .Net.
16 Fig. 5: Microsoft .NET.
Es una nueva plataforma de desarrollo de software con énfasis en transparencia de redes, con independencia de plataforma de hardware y que permite un rápido desarrollo de aplicaciones. Basado en ella, la empresa desarrolla una estrategia horizontal que integra todos sus productos, desde el sistema operativo hasta las herramientas de mercado.
.NET podría considerarse una respuesta de Microsoft al creciente mercado de los negocios en entornos Web, como competencia a la plataforma Java de Sun Microsystems. Su propuesta es ofrecer una manera rápida y económica, a la vez que segura y robusta, de desarrollar aplicaciones o como la misma plataforma las denomina, soluciones permitiendo una integración más rápida y ágil entre empresas y un acceso más simple y universal a todo tipo de información desde cualquier tipo de dispositivo. [16]
Microsoft define la plataforma .NET como entorno para la construcción, desarrollo y ejecución de servicios web y otras aplicaciones que consiste en tres partes fundamentales: el Common Language Runtime (entorno de ejecución), el Framework de Clases (clases de la plataforma) y ASP.NET. Vamos a ver en detalle cada una de estas tres partes y sus características. [16]
17 Fig. 6: Capas de la plataforma .Net.
Las características fundamentales de esta plataforma son las siguientes:
Portabilidad: Debido a la abstracción del programador respecto al SO, una aplicación .NET puede ser ejecutada en cualquier SO de cualquier máquina que disponga de una versión de la plataforma.
En estos omentos la plataforma .NET tan sólo está disponible para la familia Windows aunque se está desarrollando una versión para Linux de Corel.
Multilenguaje: Cualquier lenguaje de programación puede adaptarse a la plataforma .NET y ejecutarse en ella.
Interoperabilidad: La interoperabilidad entre diferentes trozos de código escritos en diferentes lenguajes es total.
.Net Framework 2.0.
Fig. 7: Capas del .Net Framework.
El .Net Framework constituye la base de la plataforma .NET y denota la infraestructura sobre la cual se reúnen un conjunto de lenguajes, herramientas y servicios que simplifican el desarrollo de aplicaciones en entorno de ejecución distribuido. Bajo el nombre .NET Framework se encuentran reunidas una serie de normas impulsadas por varias compañías además de Microsoft (como Hewlett-Packard, Intel, IBM, Fujitsu Software, Plum Hall, la Universidad de Monash e ISE), entre las cuales se encuentran:
18 La norma que define las reglas que debe seguir un lenguaje de programación para ser considerado
compatible con el marco de trabajo .NET (ECMA-335, ISO/IEC 23271)
Por medio de esta norma se garantiza que todos los lenguajes desarrollados para la plataforma ofrezcan al programador un conjunto mínimo de funcionalidad, y compatibilidad con todos los demás lenguajes de la plataforma.
La norma que define el lenguaje C# (ECMA-334, ISO/IEC 23270)
Este es el lenguaje insignia del marco de trabajo .NET, y pretende reunir las ventajas de lenguajes como C/C++ y Visual Basic en un solo lenguaje.
La norma que define el conjunto de funciones que debe implementar la librería de clases base (BCL por sus siglas en inglés) (incluido en ECMA-335, ISO/IEC 23271)
Tal vez el más importante de los componentes de la plataforma, esta norma define un conjunto funcional mínimo que debe implementarse para que el marco de trabajo sea soportado por un sistema operativo. Aunque Microsoft implementó esta norma para su sistema operativo Windows, la publicación de la norma abre la posibilidad de que sea implementada para cualquier otro sistema operativo existente o futuro, permitiendo que las aplicaciones corran sobre la plataforma independientemente del sistema operativo para el cual haya sido implementada. El Proyecto Mono emprendido por Ximian pretende realizar la implementación de la norma para varios sistemas operativos adicionales bajo el marco del software libre o código abierto. [16]
Visual Studio .NET 2005.
Fig. 8: Visual Studio .NET 2005.
Visual Studio .NET es la herramienta que Microsoft distribuye junto a la plataforma que permite construir y desarrollar aplicaciones .NET. Esta nueva versión no revoluciona la anterior sino que se limita a añadir una serie de nuevas características y funciones. Es una mezcla de los diferentes entornos que Microsoft utilizaba hasta ahora (Visual Basic 6 IDE, Visual InterDev...). La principal diferencia respecto a versiones anteriores es que Microsoft utiliza exactamente el mismo entorno para
19 todos los lenguajes incluidos en la plataforma. De hecho, este entorno está creado para poder manejar proyectos que usen más de un lenguaje a la vez, teniendo en cuenta la característica multilenguaje de la plataforma. El Visual Studio.NET incluye los siguientes lenguajes de programación:
Visual Basic.NET es la adaptación de Visual Basic a la plataforma .NET.
Visual C++.NET permite tanto escribir código adaptado a la plataforma .NET (código gestionado o compilado a MSIL) como código C++ nativo (código no gestionado o no compilado a MSIL).
Visual J#.NET (J Sharp) es la adaptación de Visual J++ para la plataforma .NET.
Visual C#.NET (C Sharp) es un nuevo lenguaje de programación orientado a objetos con el que se ha desarrollado parte de la plataforma .NET. [16]
Visual C#.NET 2.0(C Sharp) es el nuevo lenguaje de programación introducido por Microsoft en la plataforma .NET. Es el lenguaje mejor adaptado a la plataforma ya que ha sido exclusivamente creado para trabajar sobre ella. De hecho, las Framework Clases o clases de la plataforma han sido programadas con C# luego a pesar de ser un lenguaje de reciente creación ya ha servido como base para un desarrollo complejo, lo cual ha contribuido enormemente a su mejora. C# es definido por muchos autores como un sub-conjunto más simple y más seguro de Visual C++ para crear código gestionado (código ejecutable por el Common Language Runtime o CLR de la plataforma .NET). El código fuente de C#, al igual que todos los lenguajes de la plataforma, es compilado a MSIL y ejecutado por el CLR. Según Microsoft, C# es «un lenguaje de programación con la potencia de C, la productividad de Visual Basic y la elegancia de Java» Ciertamente, si vemos un fragmento de código de C# nos daremos cuenta del asombroso parecido con Java. A su vez tenemos la sintaxis utilizada en Visual C++ y determinadas características que lo hacen muy potente (como la sobrecarga de operadores) combinada con la sencillez y facilidad de Visual Basic que hace que sea un lenguaje muy productivo. Desde otro punto de vista, Microsoft ha creado un lenguaje completo, orientado a objetos, que se acopla perfectamente con el desarrollo Web.
Hasta ahora Microsoft hacía uso de lenguajes de script para desarrollar productos para la web (Visual Basic Script, Java Script...) pero en estos momentos la web necesita algo más que un lenguaje de script para su desarrollo. Necesita lenguajes estructurados orientados a objetos que puedan separar la lógica de la aplicación de la presentación. Microsoft ofrece su solución, la plataforma .NET, y dentro de ésta un lenguaje que se adapta perfectamente: Visual C#.NET. [16]
20
Rational Rose 2003.
Es una herramienta de software para el Modelado Visual mediante UML de sistemas software.
Permite Especificar, Analizar, Diseñar el sistema antes de Codificarlo. [7]
Entre sus características podemos resaltar:
Mantiene la consistencia de los modelos del sistema software.
Chequeo de la sintaxis UML.
Generación Documentación automáticamente.
Generación de Código a partir de los Modelos.
Ingeniería Inversa (crear modelo a partir código).
1.3.2 Lenguaje Unificado de Modelado (UML).
El Lenguaje Unificado de Modelado 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. [9,10]
UML se puede usar para modelar distintos tipos de sistemas:
Sistemas de software.
Sistemas de hardware.
Organizaciones del mundo real.
UML ofrece nueve diagramas en los cuales modelar sistemas:
Diagramas de Casos de Uso para modelar los procesos 'Business'.
Diagramas de Secuencia para modelar el paso de mensajes entre objetos.
Diagramas de Colaboración para modelar interacciones entre objetos.
Diagramas de Estado para modelar el comportamiento de los objetos en el sistema.
Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones.
Diagramas de Clases para modelar la estructura estática de las clases en el sistema.
Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema.
Diagramas de Componentes para modelar componentes.
Diagramas de Implementación para modelar la distribución del sistema.
UML será el lenguaje de modelado de software de uso universal pues existen razones para ello como:
En el desarrollo han participado investigadores de reconocido prestigio.
21 Ha sido apoyado por prácticamente todas las empresas importantes de informática.
Se ha aceptado como un estándar por la OMG.
Prácticamente todas las herramientas CASE y de desarrollo la han adaptado como lenguaje de modelado.
UML resuelve de forma bastante satisfactoria un viejo problema del desarrollo de software como es su modelado gráfico. Además, se ha llegado a una solución unificada basada en lo mejor que había hasta el momento, lo cual lo hace todavía más excepcional. [9,10]
1.4 Metodologías de Desarrollo.
El proceso de desarrollo de un producto de software es difícil de controlar, si no llevamos una metodología de desarrollo en qué apoyarnos. Sin embargo, muchas veces no se toma en cuenta el utilizar la metodología que más se adecue a las necesidades del proyecto. Y por lo general las consecuencias influyen en la calidad del producto, dejando clientes y desarrolladores insatisfechos con el trabajo.
Para dar una idea de qué metodología podemos utilizar y cual se adapta más a nuestro medio, mencionaré tres de ellas de las que considero las más importantes, tales como: RUP, XP y MSF.
1.4.1 Proceso Unificado de Desarrollo (RUP).
La metodología RUP, llamada así por su significado en inglés (Rational Unified Process), divide en 4 fases el desarrollo del software:
Inicio, El Objetivo en esta etapa es determinar la visión del proyecto.
Elaboración, En esta etapa el objetivo es determinar la arquitectura óptima.
Construcción, En esta etapa el objetivo es llevar a obtener la capacidad operacional inicial.
Transmisión, El objetivo es llegar a obtener el release del proyecto.
Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cual consiste en reproducir el ciclo de vida en cascada a menor escala. Los Objetivos de una iteración se establecen en función de la evaluación de las iteraciones precedentes.
Vale mencionar que el ciclo de vida que se desarrolla por cada iteración, es llevada bajo disciplinas:
Disciplinas de Desarrollo
Ingeniería de Negocios: Entendiendo las necesidades del negocio.
Requerimientos: Trasladando las necesidades del negocio a un sistema automatizado.
Análisis y Diseño: Trasladando los requerimientos dentro de la arquitectura de software.
22 Implementación: Creando software que se ajuste a la arquitectura y que tenga el comportamiento
deseado.
Pruebas: Asegurándose que el comportamiento requerido es el correcto y que todo los solicitado está presente.
Disciplina de Soporte
Configuración y administración del cambio: Guardando todas las versiones del proyecto.
Administrando el proyecto: Administrando horarios y recursos.
Ambiente: Administrando el ambiente de desarrollo.
Distribución: Hacer todo lo necesario para la salida del proyecto
Fig. 9: Fases e Iteraciones de la Metodología RUP.
Es recomendable que a cada una de estas iteraciones se les clasifique y ordene según su prioridad, y que cada una se convierte luego en un entregable al cliente. Esto trae como beneficio la retroalimentación que se tendría en cada entregable o en cada iteración.
Los elementos del RUP son:
Actividades, Son los procesos que se llegan a determinar en cada iteración.
Trabajadores, Vienen hacer las personas o entes involucrados en cada proceso.
Artefactos, Un artefacto puede ser un documento, un modelo, o un elemento de modelo.
23 Una particularidad de esta metodología es que, en cada ciclo de iteración, se hace exigente el uso de artefactos, siendo por este motivo, una de las metodologías más importantes para alcanzar un grado de certificación en el desarrollo del software.
Es una de las metodologías de desarrollo de software más exitosas en la actualidad, utilizadas para proyectos de corto plazo y equipo. La metodología consiste en una programación rápida o extrema, cuya particularidad es tener como parte del equipo, al usuario final, pues es uno de los requisitos para llegar al éxito del proyecto.
1.4.2 Metodología XP.
Fig. 10: Metodología Extreme Programing
La metodología se basa en: [20]
Pruebas Unitarias: se basa en las pruebas realizadas a los principales procesos, de tal manera que adelantándonos en algo hacia el futuro, podamos hacer pruebas de las fallas que pudieran ocurrir. Es como si nos adelantáramos a obtener los posibles errores.
Re fabricación: se basa en la reutilización de código, para lo cual se crean patrones o modelos estándares, siendo más flexible al cambio.
Programación en pares: una particularidad de esta metodología es que propone la programación en pares, la cual consiste en que dos desarrolladores participen en un proyecto en una misma estación de trabajo. Cada miembro lleva a cabo la acción que el otro no está haciendo en ese momento. Es como el chofer y el copiloto: mientras uno conduce, el otro consulta el mapa.
24
¿Qué es lo que propone XP? [20]
1. Empieza en pequeño y añade funcionalidad con retroalimentación continua.
2. El manejo del cambio se convierte en una parte sustantiva del proceso 3. El costo del cambio no depende de la fase o etapa
4. No introduce funcionalidades antes que sean necesarias 5. El cliente o el usuario se convierte en miembro del equipo
Derechos del Cliente
Decidir que se implementa.
Saber el estado real y el progreso del proyecto.
Añadir, cambiar o quitar requerimientos en cualquier momento.
Obtener lo máximo de cada semana de trabajo.
Obtener un sistema funcionando cada 3 o 4 meses.
Derechos del Desarrollador
Decidir cómo se implementan los procesos.
Crear el sistema con la mejor calidad posible.
Pedir al cliente en cualquier momento aclaraciones de los requerimientos.
Estimar el esfuerzo para implementar el sistema.
Cambiar los requerimientos en base a nuevos descubrimientos.
Lo fundamental en este tipo de metodología es:
La comunicación, entre los usuarios y los desarrolladores.
La simplicidad, al desarrollar y codificar los módulos del sistema.
La retroalimentación, concreta y frecuente del equipo de desarrollo, el cliente y los usuarios finales.
1.4.3 Microsoft Solution Framework (MSF).
Esta es una metodología flexible e interrelacionada con una serie de conceptos, modelos y prácticas de uso, que controlan la planificación, el desarrollo y la gestión de proyectos tecnológicos. MSF se centra en los modelos de proceso y de equipo dejando en un segundo plano las elecciones tecnológicas.
25 Fig. 11: Metodología MSF
MSF tiene las siguientes características: [10]
Adaptable: es parecido a un compás, usado en cualquier parte como un mapa, del cual su uso es limitado a un específico lugar.
Escalable: puede organizar equipos tan pequeños entre 3 o 4 personas, así como también, proyectos que requieren 50 personas a más.
Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente.
Tecnología Agnóstica: porque puede ser usada para desarrollar soluciones basadas sobre cualquier tecnología.
MSF se compone de varios modelos encargados de planificar las diferentes partes implicadas en el desarrollo de un proyecto: Modelo de Arquitectura del Proyecto, Modelo de Equipo, Modelo de Proceso, Modelo de Gestión del Riesgo, Modelo de Diseño de Proceso y finalmente el modelo de Aplicación.
Modelo de Arquitectura del Proyecto: Diseñado para acortar la planificación del ciclo de vida. Este modelo define las pautas para construir proyectos empresariales a través del lanzamiento de versiones. [10]
Modelo de Equipo: Este modelo ha sido diseñado para mejorar el rendimiento del equipo de desarrollo. Proporciona una estructura flexible para organizar los equipos de un proyecto. Puede ser escalado dependiendo del tamaño del proyecto y del equipo de personas disponibles.
Modelo de Proceso: Diseñado para mejorar el control del proyecto, minimizando el riesgo, y aumentar la calidad acortando el tiempo de entrega. Proporciona una estructura de pautas a seguir en el ciclo de vida del proyecto, describiendo las fases, las actividades, la liberación de versiones y explicando su relación con el Modelo de equipo. [10]
Modelo de Gestión del Riesgo: Diseñado para ayudar al equipo a identificar las prioridades, tomar las decisiones estratégicas correctas y controlar las emergencias que puedan surgir. Este modelo proporciona un entorno estructurado para la toma de decisiones y acciones valorando los riesgos que puedan provocar. [10]
26 Modelo de Diseño del Proceso: Diseñado para distinguir entre los objetivos empresariales y las necesidades del usuario. Proporciona un modelo centrado en el usuario para obtener un diseño eficiente y flexible a través de un enfoque iterativo. Las fases de diseño conceptual, lógico y físico proveen tres perspectivas diferentes para los tres tipos de roles: los usuarios, el equipo y los desarrolladores. [10]
Modelo de Aplicación: Diseñado para mejorar el desarrollo, el mantenimiento y el soporte, proporciona un modelo de tres niveles para diseñar y desarrollar aplicaciones software. Los servicios utilizados en este modelo son escalables, y pueden ser usados en un solo ordenador o incluso en varios servidores. [10]
A modo de conclusión podemos decir que la Metodología RUP es más adaptable para proyectos con un periodo de desarrollo extenso, XP es recomendable para proyectos de corto plazo, en cambio la metodología MSF se adapta a proyectos de cualquier dimensión y de cualquier tecnología. Podemos concluir además, que lo más importante antes de elegir una metodología de desarrollo de software, es determinar el alcance que tendrá.
Estas son algunas de las metodologías que más se destacan en el desarrollo del software, ahora explicaremos los patrones de diseño más aplicados.
1.5 Patrones de diseño.
1.5.1 ¿Qué son los Patrones de Diseño?
Con el desarrollo del Diseño Orientado a Objetos, han ido surgiendo ciertos tipos de problemas, con los cuales solemos encontrarnos en repetidas ocasiones. Esta situación es la que ha obligado a los implicados en la tarea de Diseñar Aplicaciones, a buscar soluciones que resuelvan cada uno de esos problemas. Este par Problema – Solución, aplicado al Diseño de Aplicaciones Software, es lo que se llama Patrón de Diseño. Las partes fundamentales de todo patrón son: [22]
Nombre: Es el nombre con el que ha sido registrado el patrón.
Problema: Es el problema específico que resuelve el patrón en cuestión.
Solución: Es la solución que se le da al problema.
Aplicación en la programación: Es un ejemplo concreto de cómo este patrón, que puede ser explicado mediante un ejemplo de la vida práctica
Ejemplo de Código: Es un pequeño ejemplo de la implementación del patrón
