ESTADO DEL ARTE EN INGENIERIA DE SOFTWARE DESDE UNA MIRADA ACADEMICA

UNIVERSIDAD SANTO TOMA
VICERECTORIA DE UNIVERSIDAD A DISTANCIA
FACULTAD DE EDUCACION
FACULTAD DE CIENCIA Y TECNOLOGIAS
PROYECTO DE INVESTIGACIÓN:
ALFABETIZACIÓN CIENTÍFICA Y TECNOLÓGICA EN LAS INSTITUCIONES
EDUCATIVAS DE BÁSICA Y MEDIA Y EL DESARROLLO DE PENSAMIENTO
CRÍTICO, LÓGICO Y MATEMÁTICO COMO FACTOR GENERADOR DE UNA
INDUSTRIA DE SOFTWARE EN COLOMBIA
ARTICULO:
ESTADO DEL ARTE EN INGENIERIA DE SOFTWARE DESDE UNA MIRADA
ACADEMICA
MARIO DUSTANO CONTRERAS CASTRO
PROGRAMA INGENIERIA EN INFORMATICA
BOGOTA, JULIO DE 2017
1
ANTECEDENTE. FASES DE UN PROYECTO SOFTWARE
Hacia el interior del programa de Ingeniería en Informática de la Facultad de Ciencias y Tecnologías
de la VUAD de la Universidad Santo Tomás se sitúa al estudiante en un entorno informático, para
que él mismo, inicie un proyecto en un sistema informático en cuanto a: propuesta, mantenimiento,
mejoramiento en un Proyecto Software, Software Educativo, Sistema Telemático.
Intervención de un Estudiante en un Proyecto Software
Figura 1. Fases de un Proyecto Informático (Proyecto Software).
Fuente Propia
2
Figura 2. Modelado del Negocio. Fuente Propia
Figura 3. Ingeniería del Proyecto Modelo Análisis Orientado a Objetos.
Fuente Propia
3
Figura 4. Ingeniería del Proyecto Modelo Análisis Estructurado.
Fuente Propia
Notas Aclaratoria
Primera Nota. Las referencias son datos propiciados por terceros que faciliten la información
sobre un hecho o investigación realizada, el termino referencia describe el proceso por el cual se
menciona o se señala (que es lo mismo decir “se refiere”) a algún objeto o persona, es decir, son
las informaciones que permiten adquirir conocimientos una determinada cuestión de interés
personas, empleos, lugares, métodos, etc.
Segunda Nota. Las gráficas de Google Trends representan con cuánta frecuencia se realiza una
búsqueda de un término particular en varias regiones del mundo y en varios idiomas. El eje
horizontal de la gráfica representa el tiempo (desde algún momento de 2004), y el eje vertical
representa la frecuencia con la que se ha buscado el término globalmente.
Tercera Nota. Un Modelo es un prototipo que sirve de referencia y ejemplo para todos los que
diseñan y confeccionan productos de la misma naturaleza.
Cuarta Nota. Como metodología se denomina la serie de métodos y técnicas de rigor científico
que se aplican sistemáticamente durante un proceso de investigación para alcanzar un resultado
teóricamente válido. En este sentido, la Metodología es el conjunto de métodos, conceptos o
procedimientos basados en principios lógicos para alcanzar un objetivo
Quinta Nota. Para las Fases de Análisis y Diseño se hace uso de metodologías porque se
requiere de métodos, conceptos o procedimientos como diagramas, descripciones, diccionarios de
datos e inclusive modelos de datos en un rigor u orden determinado.
4
REFERENTES DESDE 1970 HASTA 2017
PRIMER REFERENTE. SISTEMA DE INFORMACIÓN
Referente:http://scielo.sld.cu/scielo.php?script=sci_arttext&pid=S1024-94352009001100006
Un Sistema de Información(SI) es un conjunto formal de procesos que, operando sobre una
colección de datos e información estructurados según las necesidades de la organización, recopilan,
elaboran y distribuyen la información (o parte de ella) necesaria para las operaciones, las
actividades de dirección y la toma de decisiones.
Actualmente, los SI se enfrentan a dos retos fundamentales. En primer lugar, su diseño, desarrollo
e implementación son procesos que confluyen en diferentes contextos, con distintos puntos de vista
y suposiciones acerca de determinado dominio. Esto provoca problemas de comunicación por falta
de entendimiento compartido y por la complejidad de la realidad. En segundo lugar, las
representaciones en los SI deben corresponderse, lo más estrechamente posible, con la realidad y
los procesos que ellos representan para que finalmente cumplan con los objetivos diseñados.
Las cuatro principales funciones del SI son:
• Recolección de la información: es la actividad de registrar o captar información para que pueda
utilizarse con posterioridad.
• Acopio o acumulación: consiste en la agrupación de la información recogida en lugares y
momentos diferentes.
• Tratamiento de la información: en él se pueden distinguir tres operaciones fundamentales: de
ordenamiento, de cálculo aritmético-lógico y de transferencia de información. Una vez transformada
la información, ella debe cumplir con una serie de requisitos de los cuales los más relevantes son:
claridad, precisión, ser oportuna, directamente utilizable, coordinada, completa, jerarquizada,
sintética y necesaria.
• Difusión de la información: el problema de la difusión consiste en dar respuesta a tres preguntas
fundamentales: cómo, cuándo y a quién.
Los SI cumplirán tres objetivos básicos en las organizaciones:
1. Automatización de procesos operativos.
2. Proporcionar información que sirva de apoyo al proceso de toma de decisiones.
3. Lograr ventajas competitivas por medio de su implantación y uso.
Los Sistemas de Información pueden ser:
Sistemas transaccionales.
Sistemas de apoyo de las decisiones.
Sistemas de Gestión de Información (SGI).
Figura 5. Interés Mundial por Sistemas de Información.
Fuente. https://www.google.es/trends
5
SEGUNDO REFERENTE. METODOLOGÍAS PARA DESARROLLO DE SOFTWARE
Referente: ww.dsic.upv.es/asignaturas/facultad/lsi/doc/IntroduccionProcesoSW.doc
Un proceso de software detallado y completo suele denominarse “Metodología”. Las metodologías
se basan en una combinación de los modelos de proceso genéricos (cascada, evolutivo,
incremental, etc.). Adicionalmente una metodología debería definir con precisión los artefactos,
roles y actividades involucrados, junto con prácticas y técnicas recomendadas, guías de adaptación
de la metodología al proyecto, guías para uso de herramientas de apoyo, etc. Habitualmente se
utiliza el término “método” para referirse a técnicas, notaciones y guías asociadas, que son
aplicables a una (o algunas) actividades del proceso de desarrollo, por ejemplo, suele hablarse de
métodos de análisis y/o diseño.
Si se toma como criterio las notaciones utilizadas para especificar artefactos producidos en
actividades de análisis y diseño, se puede clasificar las metodologías en dos grupos: Metodologías
Estructuradas y Metodologías Orientadas a Objetos. Por otra parte, considerando su filosofía de
desarrollo, aquellas metodologías con mayor énfasis en la planificación y control del proyecto, en
especificación precisa de requisitos y modelado, reciben el apelativo de Metodologías Tradicionales
(o peyorativamente denominada Metodologías Pesadas, o Peso Pesado). Otras metodologías,
denominadas Metodologías Ágiles, están más orientadas a la generación de código con ciclos muy
cortos de desarrollo, se dirigen a equipos de desarrollo pequeños, hacen especial hincapié en
aspectos humanos asociados al trabajo en equipo e involucran activamente al cliente en el proceso.
A continuación se revisan brevemente cada una de estas categorías de metodologías.
Metodologías Estructuradas
Los métodos estructurados comenzaron a desarrollarse a fines de los 70’s con la Programación
Estructurada, luego a mediados de los 70’s aparecieron técnicas para el Diseño (por ejemplo: el
diagrama de Estructura) primero y posteriormente para el Análisis (por ejemplo: Diagramas de Flujo
de Datos). Estas metodologías son particularmente apropiadas en proyectos que utilizan para la
implementación lenguajes de 3ra y 4ta generación.
Ejemplos de metodologías estructuradas de ámbito gubernamental: MERISE1 (Francia), MÉTRICA2
(España), SSADM3 (Reino Unido). Ejemplos de propuestas de métodos estructurados en el ámbito
académico: Gane & Sarson4, Ward & Mellor5, Yourdon & DeMarco6 e Information Engineering7.
Figura 6. Interés Mundial por Metodologías Estructuradas
Fuente. https://www.google.es/trends
1
http://perso.club-internet.fr/brouardf/SGBDRmerise.htm (7.5.2002)
http://www.map.es/csi/metrica3/ (7.5.2003)
3 http://www.comp.glam.ac.uk/pages/staff/tdhutchings/chapter4.html (7.5.2003)
4 http://portal.newman.wa.edu.au/technology/12infsys/html/dfdnotes.doc (29.8.2003)
5 http://www.yourdon.com/books/coolbooks/notes/wardmellor.html (29.8.2003)
6 http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?Yourdon%2FDemarco (29.8.2003)
7 http://gantthead.com/Gantthead/process/processMain/1,1289,2-12009-2,00.html (29.8.2003)
2
6
Metodologías de Análisis y Diseño Orientadas a Objetos
Su historia va unida a la evolución de los lenguajes de programación orientada a objeto, los más
representativos: a fines de los 60’s SIMULA, a fines de los 70’s Smalltalk-80, la primera versión de
C++ por Bjarne Stroustrup en 1981 y actualmente Java8 o C# de Microsoft. A fines de los 80’s
comenzaron a consolidarse algunos métodos Orientadas a Objeto.
En 1995 Booch y Rumbaugh proponen el Método Unificado con la ambiciosa idea de conseguir una
unificación de sus métodos y notaciones, que posteriormente se reorienta a un objetivo más
modesto, para dar lugar al Unified Modeling Language (UML) 9, la notación OO más popular en la
actualidad.
Algunos métodos OO con notaciones predecesoras de UML son: OOAD (Booch), OOSE
(Jacobson), Coad & Yourdon, Shaler & Mellor y OMT (Rumbaugh).
Algunas metodologías orientadas a objetos que utilizan la notación UML son: Rational Unified
Process (RUP)10, OPEN11, MÉTRICA (que también soporta la notación estructurada).
Figura 7. Interés Mundial por Metodologías de Análisis y Diseño Orientada a Objetos
Fuente. https://www.google.es/trends
Metodologías tradicionales (no ágiles)
Las metodologías no ágiles son aquellas que están guiadas por una fuerte planificación durante
todo el proceso de desarrollo; llamadas también metodologías tradicionales o clásicas, donde se
realiza una intensa etapa de análisis y diseño antes de la construcción del sistema.
Todas las propuestas metodológicas antes indicadas pueden considerarse como metodologías
tradicionales. Aunque en el caso particular de RUP, por el especial énfasis que presenta en cuanto
a su adaptación a las condiciones del proyecto (mediante su configuración previa a aplicarse),
realizando una configuración adecuada, podría considerarse Ágil.
Figura 8. Interés Mundial por Metodologías Tradicionales (no ágiles).
Fuente. https://www.google.es/trends
8
http://java.sun.com/ (7.5.2003)
http://www.uml.org/ (7.5.2003)
10 http://www.rational.com/products/rup/index.jsp (7.5.2003)
11 http://www.open.org.au/ (17.9.2003)
9
7
Metodologías ágiles
Un proceso es ágil cuando el desarrollo de software es incremental (entregas pequeñas de
software, con ciclos rápidos), cooperativo (cliente y desarrolladores trabajan juntos
constantemente con una cercana comunicación), sencillo (el método en sí mismo es fácil de
aprender y modificar, bien documentado), y adaptable (permite realizar cambios de último
momento).
Figura 9. Interés Mundial por Metodologías Agiles.
Fuente. https://www.google.es/trends
8
Entre las metodologías ágiles identificadas se destacan:
1. Extreme Programming (XP).
Figura 10. Metodología Programación Extrema XP.
Fuente. https://www.mindmeister.com/es/258146343/metodolog-a-programaci-n-extrema-xp
Figura 11. Interés Mundial por Metodología XP.
Fuente. https://www.google.es/trends
9
2. Metodología Scrum.
Referente. https://proyectosagiles.org/que-es-scrum/
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas
para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto.
Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera
de trabajar de equipos altamente productivos.
Un proyecto con Scrum se ejecuta en bloques temporales cortos y fijos (iteraciones que
normalmente son de 2 semanas, aunque en algunos equipos son de 3 y hasta 4 semanas, límite
máximo de feedback y reflexión). Cada iteración tiene que proporcionar un resultado completo,
un incremento de producto final que sea susceptible de ser entregado con el mínimo esfuerzo al
cliente cuando lo solicite.
El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa como plan
del proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor que le aportan
respecto
a
su
coste
y
quedan
repartidos
en
iteraciones
y
entregas.
Figura 12. Metodología SCRUM.
Fuente. https://proyectosagiles.org/que-es-scrum/
Figura 13. Interés Mundial por Metodología Scrum.
Fuente. https://www.google.es/trends
10
3. Familia de Metodologías Crystal.
El nombre Crystal deriva de la caracterización de los proyectos según 2 dimensiones, tamaño y
complejidad (como en los minerales, color y dureza).
Por ejemplo.
 Clear es para equipos de hasta 8 personas o menos.
 Amarillo para equipos entre 10 a 20 personas.
 Naranja para equipos entre 20 a 50 persona.
 Roja para equipos entre 50 a 100 personas.
 Azul para equipos entre 100 a 200 personas.
La Metodología Crystal puede ser usada en proyectos pequeños y como casi todos los otros
métodos consisten en valores, técnicas y procesos.
Se hace menos énfasis en la documentación exhaustiva y más en versiones que corran y puedan
ser probadas.
La Metodología Crystal da vital importancia a las personas que componen el equipo de un
proyecto, y por tanto sus puntos de estudio son:
- Aspecto humano del equipo
- Tamaño de un equipo (número de componentes)
- Comunicación entre los componentes
- Distintas políticas a seguir
- Espacio físico de trabajo
Figura 14. Interés Mundial por Familia de Metodologías Crystal.
Fuente. https://www.google.es/trends
4. Feature Driven Development.
Es una metodología ágil diseñada para el desarrollo de software, basada en la calidad y el
monitoreo constante del proyecto.
Ayuda a contrarrestar situaciones como el exceso en el presupuesto, fallas en el programa o el
hecho de entregar menos de lo deseado.
Propone tener etapas de cierre cada dos semanas. Se obtienen resultados periódicos y tangibles.
Se basa en un proceso iterativo con iteraciones cortas que producen un software funcional que
el cliente y la dirección de la empresa pueden ver y monitorear.
Define claramente entregas tangibles y formas de evaluación del progreso del proyecto.
No hace énfasis en la obtención de los requerimientos sino en cómo se realizan las fases de
diseño y construcción.
11
Figura 15. Interés Mundial por Familia de Metodología Feature Driven Development.
Fuente. https://www.google.es/trends
2. Proceso Unificado Rational (RUP), una configuración ágil.
Es una metodología cuyo fin es entregar un producto de software. Se estructura todos los
procesos y se mide la eficiencia de la organización.
Es un proceso de desarrollo de software el cual utiliza el lenguaje unificado de modelado UML,
constituye la metodología estándar más utilizada para el análisis, implementación y
documentación de sistemas orientados a objetos.
El RUP es un conjunto de metodologías adaptables al contexto y necesidades de cada organiza
Principales características
Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)
Pretende implementar las mejores prácticas en Ingeniería de Software.
Desarrollo iterativo
Administración de requisitos
Uso de arquitectura basada en componentes
Control de cambios
Modelado visual del software
Verificación de la calidad del software
Figura 16. Interés Mundial por RUP.
Fuente. https://www.google.es/trends
12
5. Dynamic Systems Development Method (DSDM).
El Método de Desarrollo de Sistemas Dinámicos (en inglés Dynamic Systems Development
Method o DSDM) es un método que provee un framework para el desarrollo ágil de software,
apoyado por su continua implicación del usuario en un desarrollo iterativo y creciente que sea
sensible a los requerimientos cambiantes, para desarrollar un sistema que reúna las necesidades
de la empresa en tiempo y presupuesto
Su meta es entregar los sistemas del software a tiempo y en el presupuesto mientras ajustando
para los requisitos cambiantes a lo largo del proceso de desarrollo. DSDM es uno de varios
métodos Ágiles para el software en vías de desarrollo, y forma una parte de la Alianza Ágil.
Figura 17. Interés Mundial por DSDM.
Fuente. https://www.google.es/trends
6. Adaptive Software Development (ASD).
El método ágil ASD (Adaptive Software Development) traducido en español significa Desarrollo
Adaptable de Software es un modelo de implementación de patrones ágiles para desarrollo de
software. Al igual que otras metodologías ágiles, su funcionamiento es cíclico y reconoce que en
cada iteración se producirán cambios e incluso errores.
El desarrollo de software adaptable (Adaptive Software Development - ASD) es una metodología
de desarrollo que hace énfasis en aplicar las ideas que se originaron en el mundo de los sistemas
complejos, adaptación continua del proceso al trabajo.
Sus principales características del ASD son:
- Iterativo.
- Orientado a los componentes de software (la funcionalidad que el producto va a tener,
características, etc.) más que a las tareas en las que se va a alcanzar dicho objetivo.
- Tolerante a los cambios.
- Guiado por los riesgos
- La revisión de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de
desarrollo
Figura 18. Interés Mundial por ASD.
Fuente. https://www.google.es/trends
13
7. Open Source Software Development.
Desarrollo del software de código abierto es el proceso por el que se desarrolla el software de código
abierto, o de manera similar aquel software cuyo código fuente está disponible de manera pública.
Estos son productos de software disponibles con su código fuente bajo una licencia de código
abierto que permite estudiar, cambiar y mejorar el diseño de estos programas. Ejemplos de algunos
productos populares de software de código abierto son Mozilla Firefox, Google Chromium, Android,
LibreOffice y el paquete de oficina Apache OpenOffice Suite.
El uso de software de código abierto es común porque los desarrolladores encuentran que pueden
obtener un prototipo en pruebas y producción más rápido y prácticamente sin costo alguno. El
resultado es un tiempo más corto para el mercado a un costo menor – es obvio para cualquier
empresa que busque prosperar en el mercado-.
Las bases de datos NoSQL subieron en popularidad sobre la ola de estas tendencias. Normalmente,
de código abierto y construido con prácticas de software moderno en mente, las bases de datos
NoSQL permiten un desarrollo más rápido a menor costo que con la antigua generación de bases
de datos relacionales.
Figura 19. Interés Mundial por Open Source Software Development.
Fuente. https://www.google.es/trends
14
TERCER REFERENTE. MODELOS DE PROCESO DE DESARROLLO DE SOFTWARE
Referente: ww.dsic.upv.es/asignaturas/facultad/lsi/doc/IntroduccionProcesoSW.doc
Un proceso de desarrollo de software tiene como propósito la producción eficaz y eficiente
de un producto software que reúna los requisitos del cliente. Dicho proceso, en términos
globales se muestra en la Figura 20. Este proceso es intensamente intelectual, afectado
por la creatividad y juicio de las personas involucradas. Aunque un proyecto de desarrollo
de software es equiparable en muchos aspectos a cualquier otro proyecto de ingeniería,
en el desarrollo de software hay una serie de desafíos adicionales, relativos
esencialmente a la naturaleza del producto obtenido.
Figura 20. Proceso de Desarrollo de Software.
Fuente ww.dsic.upv.es/asignaturas/facultad/lsi/doc/IntroduccionProcesoSW.doc
El proceso de desarrollo de software no es único. No existe un proceso de software
universal que sea efectivo para todos los contextos de proyectos de desarrollo. Debido a
esta diversidad, es difícil automatizar todo un proceso de desarrollo de software.
A pesar de la variedad de propuestas de proceso de software, existe un conjunto de
actividades fundamentales que se encuentran presentes en todos ellos:
1. Especificación de software: Se debe definir la funcionalidad y restricciones
operacionales que debe cumplir el software.
2. Diseño e Implementación: Se diseña y construye el software de acuerdo a la
especificación.
3. Validación: El software debe validarse, para asegurar que cumpla con lo que quiere el
cliente.
4. Evolución: El software debe evolucionar, para adaptarse a las necesidades del cliente.
Un modelo de proceso de software se define como “Una representación simplificada de un
proceso de software, representada desde una perspectiva específica. Por su naturaleza los
modelos son simplificados, por lo tanto un modelo de procesos del software es una
abstracción de un proceso real.”
Los Modelos de Proceso de Software se pueden enunciar como:
1. Modelo Codificar y Corregir
Este es el modelo básico utilizado en los inicios del desarrollo de software. Contiene dos
pasos:
 Escribir código.
 Corregir problemas en el código.
Se trata de primero implementar algo de código y luego pensar acerca de requisitos, diseño,
validación, y mantenimiento.
15
Figura 21. Interés Mundial por Modelo Codificar y Corregir.
Fuente. https://www.google.es/trends
2. Modelo en cascada
El primer modelo de desarrollo de software que se publicó se derivó de otros procesos de
ingeniería. Éste toma las actividades fundamentales del proceso de especificación,
desarrollo, validación y evolución y las representa como fases separadas del proceso.
El modelo en cascada consta de las siguientes fases:
1. Definición de los requisitos: Los servicios, restricciones y objetivos son establecidos
con los usuarios del sistema. Se busca hacer esta definición en detalle.
2. Diseño de software: Se particiona el sistema en sistemas de software o hardware.
Se establece la arquitectura total del sistema. Se identifican y describen las
abstracciones y relaciones de los componentes del sistema.
3. Implementación y pruebas unitarias: Construcción de los módulos y unidades de
software. Se realizan pruebas de cada unidad.
4. Integración y pruebas del sistema: Se integran todas las unidades. Se prueban en
conjunto. Se entrega el conjunto probado al cliente.
5. Operación y mantenimiento: Generalmente es la fase más larga. El sistema es
puesto en marcha y se realiza la corrección de errores descubiertos. Se realizan
mejoras de implementación. Se identifican nuevos requisitos.
Figura 22. Interés Mundial por Modelo en Cascada.
Fuente. https://www.google.es/trends
16
3. Modelo de Desarrollo Evolutivo
La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial,
exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el
sistema adecuado. En la Figura 23 se observa cómo las actividades concurrentes:
especificación, desarrollo y validación, se realizan durante el desarrollo de las versiones
hasta llegar al producto final.
Una ventaja de este modelo es que se obtiene una rápida realimentación del usuario, ya
que las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.
Figura 23. Modelo de desarrollo evolutivo.
Fuente: www.dsic.upv.es/asignaturas/facultad/lsi/doc/IntroduccionProcesoSW.doc
Existen dos tipos de desarrollo evolutivo:
 Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los
requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que
se tiene más claras. El sistema evoluciona conforme se añaden nuevas
características propuestas por el usuario.

Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y
trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo
exploratorio, se comienza por definir los requisitos que no están claros para el usuario
y se utiliza un prototipo para experimentar con ellos. El prototipo ayuda a terminar de
definir estos requisitos.
Figura 24. Interés Mundial por Modelo Desarrollo Evolutivo.
Fuente. https://www.google.es/trends
17
4. Método Formal de Sistemas
Este modelo se basa en transformaciones formales de los requisitos hasta llegar a un
programa ejecutable.
Desiciones
Desarrollo
Formal
Especificación
Informal
Especificación
Especificación
de alto nivel
(prototipo)
Tranformación
Interactiva
Especificación
de bajo nivel
Transformación
Automática
Código
Fuente
Optimización
Validación de
Especificación
Mantenimiento
Figura 25. Paradigma de Programación Automática.
Fuente: www.dsic.upv.es/asignaturas/facultad/lsi/doc/IntroduccionProcesoSW.doc
La Figura 25 ilustra un paradigma ideal de programación automática. Se distinguen dos
fases globales: especificación (incluyendo validación) y transformación. Las características
principales de este paradigma son: la especificación es formal y ejecutable constituye el
primer prototipo del sistema), la especificación es validada mediante prototipación.
Posteriormente, a través de transformaciones formales la especificación se convierte en la
implementación del sistema, en el último paso de transformación se obtiene una
implementación en un lenguaje de programación determinado. El mantenimiento se realiza
sobre la especificación (no sobre el código fuente), la documentación es generada
automáticamente y el mantenimiento es realizado por repetición del proceso (no mediante
parches sobre la implementación).
Observaciones sobre el Método Formal de Sistemas:
 Permite demostrar la corrección del sistema durante el proceso de transformación.
Así, las pruebas que verifican la correspondencia con la especificación no son
necesarias.
 Es atractivo sobre todo para sistemas donde hay requisitos de seguridad y
confiabilidad importantes.
 Requiere desarrolladores especializados y experimentados en este proceso para
llevarse a cabo.
Figura 26. Interés Mundial por Método Formal de Sistemas.
Fuente. https://www.google.es/trends
18
5. Modelo de Desarrollo Basado en Reutilización de Componentes
Este modelo consta de 4 fases según Figura 27.
Figura 27. Desarrollo basado en reutilización de componentes
Fuente: www.dsic.upv.es/asignaturas/facultad/lsi/doc/IntroduccionProcesoSW.doc
A continuación se describe cada fase:
1. Análisis de componentes: Se determina qué componentes pueden ser utilizados para
el sistema en cuestión. Casi siempre hay que hacer ajustes para adecuarlos.
2. Modificación de requisitos: Se adaptan (en lo posible) los requisitos para concordar
con los componentes de la etapa anterior. Si no se puede realizar modificaciones en
los requisitos, hay que seguir buscando componentes más adecuados (fase 1).
3. Diseño del sistema con reutilización: Se diseña o reutiliza el marco de trabajo para el
sistema. Se debe tener en cuenta los componentes localizados en la fase 2 para
diseñar o determinar este marco.
4. Desarrollo e integración: El software que no puede comprarse, se desarrolla. Se
integran los componentes y subsistemas. La integración es parte del desarrollo en
lugar de una actividad separada.
Figura 28. Interés Mundial por Desarrollo basado en reutilización de componentes.
Fuente. https://www.google.es/trends
19
6. Modelo de Desarrollo iterativo incremental
El Modelo de Desarrollo iterativo incremental es una forma de reducir la repetición del
trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones
en los requisitos hasta adquirir experiencia con el sistema (ver Figura 15). Es una
combinación del Modelo de Cascada y Modelo Evolutivo.
Figura 28. Modelo de desarrollo iterativo incremental.
Fuente: www.dsic.upv.es/asignaturas/facultad/lsi/doc/IntroduccionProcesoSW.doc
Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para
retrasar las decisiones hasta tener experiencia en el sistema.
Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o
evolutivo, dependiendo del conocimiento que se tenga sobre los requisitos a
implementar. Si se tiene un buen conocimiento, se puede optar por cascada, si es
dudoso, evolutivo.
Figura 29. Interés Mundial por Modelo de Desarrollo iterativo incremental
Fuente. https://www.google.es/trends
20
7. Modelo de Ciclo de Desarrollo en Espiral
El ciclo de desarrollo en Espiral se representa como una espiral (ver Figura 30), en lugar de
una serie de actividades sucesivas con retrospectiva de una actividad a otra.
Figura 30. Modelo de Ciclo de Desarrollo en Espiral
Fuente: www.dsic.upv.es/asignaturas/facultad/lsi/doc/IntroduccionProcesoSW.doc
Cada ciclo de desarrollo se divide en cuatro fases:
8. Definición de objetivos: Se definen los objetivos. Se definen las restricciones del
proceso y del producto. Se realiza un diseño detallado del plan administrativo. Se
identifican los riesgos y se elaboran estrategias alternativas dependiendo de estos.
9. Evaluación y reducción de riesgos: Se realiza un análisis detallado de cada riesgo
identificado. Pueden desarrollarse prototipos para disminuir el riesgo de requisitos
dudosos. Se llevan a cabo los pasos para reducir los riesgos.
10. Desarrollo y validación: Se escoge el modelo de desarrollo después de la evaluación
del riesgo. El modelo que se utilizará (cascada, sistemas formales, evolutivo, etc.)
depende del riesgo identificado para esa fase.
11. Planificación: Se determina si continuar con otro ciclo. Se planea la siguiente fase del
proyecto.
21
Figura 31. Interés Mundial por Modelo de Ciclo de Desarrollo en Espiral
Fuente. https://www.google.es/trends
22
CUARTO REFERENTE. PROCESOS DE NEGOCIO
Referente:https://www.ibm.com/support/knowledgecenter/es/SSAVUV_7.5.0/com.ib
m.wbpm.wid.bpel.doc/topics/cunder.html
Los procesos de negocio determinan la forma como un conjunto de actividades pueden
lograr los objetivos específicos de una organización describiendo su forma de operar, tomar
decisiones y establecer el flujo de la información necesario entre los participantes del
proceso. Cada proceso es motivado por un evento interno o externo a la organización; se
procesa la información de entrada, se manipulan los objetos necesarios, se toman las
decisiones requeridas y se generan la información y los eventos de salida. Los procesos
están restringidos por un conjunto de reglas de negocio, que determinan las políticas y la
estructura de la información del negocio.
Un proceso puede estar compuesto de subprocesos o actividades, reglas del negocio y de
flujos de control (Figura 32).
Figura 32. Representación de Procesos, Subproceso y Actividad.
Fuente Propia
Los procesos del negocio son la base de todo buen desarrollo de software y normalmente
se identifican en la primera fase del proceso. Facilitan la abstracción del problema para
construir la solución informática, y su análisis está orientado a la identificación de los
objetivos generales, los requisitos del software, la selección del tipo de sistema de
información y la arquitectura sobre la cual se debe construir el sistema.
Figura 32. Interés Mundial por Proceso de Negocio.
Fuente. https://www.google.es/trends
23
QUINTO REFERENTE. FLUJOS DE TRABAJO (WORKFLOWS)
Referente: http://es.ccm.net/contents/221-workflow-gestion-de-los-procesoscomerciales
El término "Workflow", que se traduce literalmente como "flujo de trabajo", hace referencia
a la gestión modelada y computarizada de todas las tareas que deben llevarse a cabo y de
los distintos protagonistas involucrados en realizar el proceso de negocios (también llamado
proceso operativo). También puede traducirse el término Worflow como gestión electrónica
de procesos de negocios.
Un proceso de negocios representa interacciones bajo la forma de un intercambio de
información entre los distintos protagonistas, por ejemplo:
•
Personas
•
Aplicaciones o servicios
•
Procesos de terceros
En la práctica, un Workflow puede describir:
•
El circuito de validación.
•
Las tareas que deben realizarse entre los distintos participantes de un proceso.
•
Los plazos que deben respetarse.
•
Los modos de validación.
En la figura 33 presentan un mapa conceptual de cómo un proceso del negocio puede ser
automatizado desde su definición y su uso en un sistema (motor) administrador de workflow.
Figura 33. Mapa Conceptual de un WorkFlow. Fuente Propia
24
Figura 34. Interés Mundial por WorkFlow.
Fuente. https://www.google.es/trends
25
SEXTO REFERENTE. DIAGRAMAS UML
Referente:http://biblo.una.edu.ve/docu.7/bases/marc/texto/t38840.pdf
Un Diagrama es una representación gráfica de una colección de elementos de modelado,
a menudo dibujada como un grafo conexo de arcos (relaciones) y vértices (otros elementos
del modelo). Un diagrama no es un elemento semántico, un diagrama muestra
representaciones de elementos semánticos del modelo, pero su significado no se ve
afectado por la forma en que son representados. Un diagrama está contenido dentro de un
paquete.
La mayoría de los diagramas de UML y algunos símbolos complejos son grafos que
contienen formas conectadas por rutas. La información está sobre todo en la topología, no
en el tamaño o la colocación de los símbolos (hay algunas excepciones como el diagrama
de secuencia con un eje métrico de tiempo). Hay tres clases importantes de relaciones
visuales: conexión (generalmente de líneas a formas de dos dimensiones), contención (de
símbolos por formas cerradas de dos dimensiones), y adhesión visual (un símbolo que está
"cerca" de otro en un diagrama). Estas relaciones geométricas se re asignan a conexiones
entre nodos en un gráfico en la forma analizada de la notación.
La notación de UML está pensada para ser dibujada en superficies bidimensionales.
Algunas formas bidimensionales son proyecciones de formas tridimensionales tales como
cubos, pero todavía se representan como íconos en una superficie bidimensional.
Hay cuatro clases de construcciones gráficas que se usan en la notación de UML: íconos,
símbolos bidimensionales, rutas y cadenas.
Un ícono es una figura gráfica con un tamaño y forma fijos. No se amplía para contener a
su contenido. Los iconos pueden aparecer dentro de símbolos de área, como terminadores
en las rutas o como símbolos independientes que puedan o no conectar con las rutas.
Los símbolos de dos dimensiones tienen altura y anchura variables, y pueden ampliarse
para permitir otras cosas tales como listas de cadenas o de otros símbolos. Muchos de ellos
están divididos en compartimientos similares o de tipos diferentes. Las rutas se conectan
con los símbolos, el arrastrar o suprimir uno de ellos afecta a su contenido y las rutas
conectadas.
Una ruta es una secuencia de segmentos de recta o de curva que se unen en sus puntos
finales. Conceptualmente una ruta es una sola entidad topológica, aunque sus segmentos
se pueden manipular gráficamente. Un segmento no debería existir separado de su ruta.
Las rutas siempre van conectadas en ambos extremos.
Las cadenas presentan varias clases de información en una forma "no analizada", UML
asume que cada uso de una cadena en la notación tiene una sintaxis por la cual pueda ser
analizada la información del modelo subyacente. Las cadenas pueden existir como el
contenido de un compartimiento, como elementos en las listas, como etiquetas unidas a los
símbolos o a las rutas, o como elementos independientes en un diagrama.
Se presenta los diagramas UML:
26
Área
Vista
Diagramas
Clase, asociación,
generalización, dependencia,
realización, interfaz.
Vista Estática
Diagrama
Clases
Vista de Casos de Uso
Caso de Uso, Actor,
Diagramas de
asociación, extensión,
Casos de Uso
generalización.
Vista de Implementación
Diagramas de Componente, interfaz,
Componentes dependencia, realización.
Vista de Despliegue
Diagramas de Nodo, componente,
Despliegue
dependencia, localización.
Estructura
Vista de
máquina
Estados
Vista de actividad
de
Conceptos Principales
de Diagramas de Estado, evento, transición,
Estados
acción.
Diagramas de Estado, actividad, transición,
Actividad
determinación, división, unión.
Diagramas de Interacción, objeto, mensaje,
Secuencia
activación.
Comportamiento
Vista de interacción
Diagramas de Colaboración, interacción, rol
Colaboración de colaboración, mensaje.
Administración o Vista de
Gestión de modelo modelo
Extensión de UML Todas
Gestión
de Diagramas de
Paquete, subsistema, modelo.
Clases
Todos
Restricción, estereotipo,
valores, etiquetados.
27
Figura 35. Interés Mundial por Diagramas UML.
Fuente. https://www.google.es/trends
28
SEPTIMPO REFERENTE. ARQUITECTURA DE UN SISTEMA SOFTWARE
Referente: http://www.lsi.us.es/docencia/get.php?id=5807
Definición de arquitectura de un sistema software (según Barbacci et al en 1998)
“Es la estructura o estructuras del sistema, incluyendo: sus componentes software, las
propiedades observables de dichos componentes y las relaciones entre ellos.”
♦ Diseño Arquitectónico: Concepción original (proceso) de la Arquitectura Software de un
Sistema a fin de construirlo con la máxima calidad y dentro de un plazo y tiempo
determinado.
Figura 36. Arquitectura Software.
Fuente http://www.lsi.us.es/docencia/get.php?id=5807
Programas= Algoritmos + Estructura de Datos
♦ ¿y la estructura de un sistema software?
♦ Aumento en complejidad de un sistema software: mayor importancia al diseño y
especificación de la estructura global del sistema que a la elección de algoritmos y
estructuras de datos (micro arquitectura)
♦ Es el primer documento en el que se establece una prioridad entre propiedades de
calidad al tiempo que se recogen todos los requisitos y restricciones (funcionales,
infraestructurales, estructurales…)
♦ Se recomienda comenzar en un alto grado de abstracción y refinar sucesivamente hasta
alcanzar el nivel de componente
♦ Se recomienda seguir ‘buenas prácticas’
29
Figura 37. Interés Mundial por Arquitectura de Software.
Fuente. https://www.google.es/trends
30
OCTAVO REFERENTE. PATRONES DE SOFTWARE
Referente:https://sophia.javeriana.edu.co/~acarrillo/POO/Material/CursoPOOAplicaci
onesJava-BuenasPracticas.pdf
Los patrones de software describen un problema que ocurre repetidas veces en algún
contexto determinado del proceso de desarrollo de software, y entregan una buena
solución ya probada. Esto ayuda a diseñar correctamente en menos tiempo, ayuda a
construir problemas reutilizables y extensibles, y facilita la documentación y la
comunicación con otros miembros del equipo de desarrollo.
La idea de patrones de software tuvo su origen del campo de la arquitectura. Christopher
Alexander, un arquitecto, escribió dos libros revolucionarios que describían patrones en
arquitectura de construcción y planificación urbana: A Pattern Language: Towns,
Buildings, Construction (Oxford University Press, 1977) y The Timeless Way of Building
(Oxford University Press, 1979). Las ideas presentadas en estos libros son aplicables a
varios campos además de la arquitectura, incluyendo el software. En 1987, Ward
Cunningham y Kent Beck usaron algunas de las ideas de Alexander y desarrollaron cinco
patrones para el diseño de interfaces de usuario (UI), que publicaron en un artículo de
OOPSLA'87 llamado Using Pattern Languages for Object-Oriented Programs. En 1994
Erich Gamma, Richard Helm, John Vlissides y Ralph Johnson publicaron uno de los libros
más influyentes de esta década: Design Patterns. Este libro, también llamado "Gang of
Four" (o GoF), popularizó la idea de patrones.
Figura 38. Interés Mundial por Patrones de Software.
Fuente. https://www.google.es/trends
31
NOVENO REFERENTE. PATRONES DE DISEÑO
Referente:https://msdn.microsoft.com/es-es/library/bb972240.aspx
“Los patrones de diseño son el esqueleto de las soluciones a problemas comunes en el
desarrollo de software.”
En otras palabras, brindan una solución ya probada y documentada a problemas de
desarrollo de software que están sujetos a contextos similares. Debemos tener presente
los siguientes elementos de un patrón: su nombre, el problema (cuando aplicar un patrón),
la solución (descripción abstracta del problema) y las consecuencias (costos y beneficios).
Grande fue mi sorpresa al averiguar que existen varios patrones de diseño popularmente
conocidos, los cuales se clasifican como se muestra a continuación:
Patrones Creacionales: Inicialización y configuración de objetos.
Patrones Estructurales: Separan la interfaz de la implementación. Se ocupan de cómo las
clases y objetos se agrupan, para formar estructuras más grandes.
Patrones de Comportamiento: Más que describir objetos o clases, describen la
comunicación entre ellos.
Figura 39. Interés Mundial por Patrones de Diseño.
Fuente. https://www.google.es/trends
32
DECIMO REFERENTE. PATRONES ARQUITECTONICOS
Referente: https://ingeniods.wordpress.com/2013/09/16/patrones-arquitectonicos/
Los patrones arquitectónicos se utilizan para expresar una estructura de organización base
o esquema para un software. Proporcionando un conjunto de sub-sistemas predefinidos,
especificando sus responsabilidades, reglas, directrices que determinan la organización,
comunicación, interacción y relaciones entre ellos.
Los patrones arquitectónicos heredan mucha de la terminología y conceptos de patrones
de diseño, pero se centran en proporcionar modelos y métodos re-utilizables
específicamente para la arquitectura general de los sistemas de información. En otras
palabras, quiere decir que a diferencia de los patrones de diseño estas son plantillas
incompletas y no se pueden aplicar directamente al código con modificaciones meramente
contextuales. Los patrones arquitectónicos a su vez se salen del código puro de la
aplicación y suben e incluyen software, hardware, redes, inclusos las personas.
Dentro de los patrones arquitectónicos podemos encontrar:
Modelo Vista Controlador. Separa los datos (modelo) y la interfaz de usuario (vista/GUI),
permitiendo modificaciones independientes en cada una las partes sin afectar la otra, o
sea, para que los cambios realizados en la interfaz de usuario (GUI) no afectan el manejo
de datos, y los datos pueden ser reorganizados sin cambiar la interfaz de usuario.
Inyección de Dependencias. Es una aplicación de la “Inversión de Control – IoC”,
concepto que hace exactamente eso, se invierte el flujo de control. El modelo permite que
se inyecte no dependencias en sí, sino en su lugar, la información para satisfacerlas la
relación a las dependencias.
Arquitectura dirigida por eventos (Event-driven architecture o EDA). Es un patrón de
arquitectura software que para orquestar su comportamiento se centra en torno a la
producción, detección, consumo y respuestas ante “eventos”.
Arquitectura orientada a servicios (SOA). La ‘Arquitectura Orientada a Servicios de
cliente’ (Service Oriented Architecture), es un concepto de arquitectura de software donde
el software consta de una composición de servicios, prestaciones y reglas, y son los
requisitos del negocio los que dictaminan la manera en la que estas se ínter-relaciona. Está
diseñado para que el sistema sea altamente escalable y flexible a nuevos requerimientos.
Figura 40. Interés Mundial por Patrones Arquitectónicos.
Fuente. https://www.google.es/trends
33
DECIMO PRIMER REFERENTE. INGENIERIA DE REQUERIMIENTOS
Referente: http://sedici.unlp.edu.ar/bitstream/handle/10915/4057/2__Ingenier%C3%ADa_de_requerimientos.pdf?sequence=4
Es el proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema
de software. La meta de la ingeniería de requerimientos es entregar una especificación de
requerimientos de software correcta y completa. La ingeniería de requerimientos apunta a
mejorar la forma en que se comprende y define los sistemas de software complejos.
Existen varias definiciones de requerimientos, de entre las cuales podemos citar las
siguientes:
Los Requerimientos fueron definidos por la IEEE como [IEEE90]:
1. Condición o capacidad requerida por el usuario para resolver un
problema o alcanzar un objetivo
2. Condición o capacidad que debe satisfacer o poseer un sistema o una
componente de un sistema para satisfacer un contrato, un standard, una
especificación u otro documento formalmente impuesto
3. Representación documentada de una condición o capacidad como en 1 o 2.
Según Zave:
• Rama de la ingeniería del software que trata con el establecimiento de los objetivos,
funciones y restricciones de los sistemas software.
• Asimismo, se ocupa de la relación entre estos factores con el objeto de establecer
especificaciones precisas.
Según Boehm:
• Ingeniería de Requerimientos es la disciplina para desarrollar una especificación
completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes
entre todas las partes involucradas y en dónde se describen las funciones que realizará el
sistema.
Según Loucopoulos:
• Trabajo sistemático de desarrollo de requisitos, a través de un proceso iterativo y
cooperativo de análisis del problema, documentando los resultados en una variedad de
formatos y probando la exactitud del conocimiento adquirido.
Figura 41. Interés Mundial por Ingeniería de Requerimientos.
Fuente. https://www.google.es/trends
34
DECIMO SEGUNDO REFERENTE. FRAMEWORKS JAVA
Referente: Estado del Arte de Frameworks Java
Los patrones de diseño en la construcción de software se especifican acorde a la etapa
donde se aplican: modelos de dominio, patrones arquitecturales (estilos), patrones de
diseño, patrones de código específicos a una tecnología (idioms), patrones de diseño
implementados en una API (Frameworks), patrones de procesos.
Antes de formular que es Framework, se hace necesario definir que la Arquitectura de
Componentes Software (Figura 42 es el conjunto de componentes12 y sus relaciones13, sus
interfaces14, obligaciones, servicios o contratos15.
Figura. 42. Arquitectura de Componentes Software. Adaptación
Un Framework se define como un cascaron o una estructura en bruto donde se van
colocando los componentes acorde con una necesidad, requerimiento o una exigencia
basado en un análisis de alto nivel, como también, en una valoración crítica. Entones, un
Framework es una abstracción de un componente de software (su construcción se basa en
la experiencia) para resolver un problema en UN CONTEXTO (ojo no confundir con
PATRON DE DISEÑO que es para resolver un problema en CUALQUIER contexto).
Figura 43. Interés en Framework Java en el Mundo.
Fuente https://www.google.es/trends
12
Representa una unidad coherente de funcionalidad
13
Indican que aspectos de un componente son usados por otros componentes y cómo la comunicación entre
componentes procede sobre el tiempo
14
Es una estructura que especifica obligaciones o contratos de un Componente Software
15
Conjunto o una colección de operaciones a realizar por un componente software
35
Figura 44. Interés en Framework Java en Colombia.
Fuente https://www.google.es/trends
En la Figura 43, se observa el interes hacia el desarrollo deFramework Java en los últimos
cinco años( desde 2011) ha permanecido con algunas excepciones hasta un 50% de la
población de programación java.
Figura 44. Interés en Microsoft .net Frameworks en el Mundo.
Fuente https://www.google.es/trends
Figura 45. Interés en Microsoft .net Frameworks en Colombia.
Fuente https://www.google.es/trends
36
Hibernate Java
Persistir objetos Java es la manera de almacenar permanentemente objetos en una tabla
de una base de datos relacional o sea convertir objetos Java a columnas/registros de una
base de datos y viceversa. Por lo tanto, la persistencia es serializar objetos Java 16
estructurados en forma de árbol a una base de ratos relacional estructurada de forma
tabular y viceversa requiriendo el mapeo de los objetos Java a columnas y registros de la
base de datos de una manera optimizada en velocidad y eficiencia.
Hibernate Java es una herramienta de persistencia "objeto-java-a-base-de-datos" o de
Mapeo Objeto-Relacional (ORM) haciendo de archivos declarativos (XML) para representar
la transformación de los datos de un modelo relacional a un modelo orientado a objetos
(Pojo) y viceversa.
Figura 46. Interés por Hibernate Java.
Fuente https://www.google.es/trends
Frameworks Struts
Teoría Comprobada. Framework Struts es un framework que implementa el patrón de
arquitectura MVC en Java. El patrón de arquitectura MVC (Model-View-Controller) se define
en el Model (Objetos de Negocio), la View (interfaz con el usuario u otro sistema) y el
Controller (controlador del workflow17 de la aplicación).
El Framework Struts 1.x implementa el patrón de arquitectura MVC separando el modelo o
workflow de la aplicación (se puede programar desde un archivo XML), del modelo de
objetos de negocio y de la generación de interfaz.
Las acciones se ejecutan sobre el Model (Objetos de Negocio) y se implementan
basándose en clases predefinidas por el framework a partir de un patrón de diseño Facade.
La generación de la View (interfaz con el usuario u otro sistema) se realiza a partir de un
conjunto de Tags predefinidos por Struts generando ventajas de mantenimiento y de
desempeño (pooling de Tags, caching, etc). Así mismo, separa el desarrollo de interfaz del
workflow y lógica de negocio permitiendo desarrollar ambas en paralelo.
El Framework Struts 1.x permite la reutilización de componentes y puede hacer uso de
múltiples interfaces de usuario (Html, sHtml, Wml, Desktop applications, etc.) y de múltiples
idiomas, localismos, etc.
16
Consiste en obtener una secuencia de bytes que represente el estado de dicho objeto
17
Estudio de los aspectos operacionales de una actividad de trabajo: cómo se estructuran las tareas, cómo se realizan, cuál es su orden
correlativo, cómo se sincronizan, cómo fluye la información que soporta las tareas y cómo se le hace seguimiento al cumplimiento de
las tareas
37
El Controller (controlador) Struts se encarga de tres tareas:
1. Validaciones simples: extendiendo la clase ActionForm, se realiza validaciones
simples sin acceder al modelo, haciendo uso de expresiones regulares
(comprobación formato y longitud de datos)
2. Validaciones Complejas: extendiendo la clase Action, se comprueba las reglas de
negocio (modelo). Por ejemplo: Se realizan consultas contra la base de datos y se
obtienen los errores de integridad, etc.
Control de flujo o de Navegación: a través de un archivo de configuración (struts-conf) se
gestiona el flujo de navegación entre páginas, que también se logra extendiendo la clase
ActionForm y Action.
Figura 47. Interés por Framework Struts Java.
Fuente https://www.google.es/trends
Frameworks Spring
Teoría Comprobada. Spring es un framework liviano que generalmente los objetos que se
programan no tienen dependencias en clases específicas de Spring. Sus características
principales son inyección de dependencias y programación orientada a aspectos.
Inyección de dependencias. El objetivo es lograr un bajo acoplamiento entre los objetos
de una aplicación. Con el Patrón Inversión de Control18 (IoC), los objetos no crean o
buscan sus dependencias (objetos con los cuales colabora) sino que éstas son dadas al
objeto. El contenedor (la entidad que coordina cada objeto en el sistema) es el encargado
de realizar este trabajo al momento de crear el objeto. Se invierte la responsabilidad en
cuanto a la manera en que un objeto obtiene la referencia a otro objeto.
De esta manera, los objetos conocen sus dependencias por su interfaz. Así la dependencia
puede ser intercambiada por distintas implementaciones a través del contenedor. En
resumen, se programa orientado a interface y se inyecta las implementaciones a través del
contenedor.
Programación orientada a aspectos (AOP). Se trata de un paradigma de programación
que intenta separar las funcionalidades secundarias19 de la lógica de negocios.
Módulos de Spring. En la Figura 48 se muestran los módulos del Spring. En su núcleo
(Core) se encuentra el BeanFactory – el contenedor fundamental de Spring y quien se
18
IoC permite instanciar una clase (crear objetos) olvidando las dependencias que tiene. Para eso, primero se registran las clases en un
Contenedor (IoC Container). Segundo, haciendo uso de Dependency Injection, se generan los Constructores de las clases registradas
en el Contenedor (IoC Container), para así, recuperar fácilmente cualquier clase en cualquier otra clase. IoC también es famoso por
el principio de HollyWood: “don’t call us, we’ll call you” (No nos llames, nosotros le llamaremos.)
19
“cross-cutting concerns” algo que se traduciría como “preocupaciones transversales”
38
encarga de la inyección de dependencias. El contenedor ApplicationContext se basa en
BeanFactory, eventos de ciclo de vida, validación y mejor integración con AOP.
Figura 48. Modulo del Framework Spring.
Fuente http://www.j2eebrain.com/wp-content/uploads/Spring-Framework.png
Figura 49. Interés por Framework Spring Java.
Fuente https://www.google.es/trends
39
DECIMO TERCER REFERENTE. BUENAS PRÁCTICAS
Referente:https://dsdsoa.wordpress.com/2016/10/09/buenas-practicas-soa/
Por buenas prácticas se entiende como un conjunto coherente de acciones que han rendido
buen o incluso excelente servicio en un determinado contexto y que se espera que, en
contextos similares, rindan similares resultados.
Figura 50. Interés por Buenas Prácticas.
Fuente https://www.google.es/trends
Una de las mayores ventajas de usar Arquitectura Orientada a Servicios (SOA) un servicio
puede ser reutilizado en la evolución y desarrollo de un proceso de negocio.
Se debe entender que tal acercamiento a la construcción de aplicaciones compuestas y a
procesos de negocios no funciona en ausencia de una plataforma de cumplimiento de
estándares para la construcción de tales servicios.
Para poder garantizar un correcto desarrollo de un sistema bajo los conceptos propuesto
por SOA, se tiene que asegurar que los desarrolladores tengo bien en claro los siguientes
aspectos:
1. Interfaces simples y de fácil consumo que esconden la complejidad
2. Reutilización futura sin límites
3. Complejidad técnica de la implementación en cada sistema de soporte
4. Necesidad de coordinación entre las diferentes líneas de negocios
5. Diferencia entere lógica de flujos de servicios y lógica de aplicación subyacente
6. Necesidades de seguridad de servicios diferentes de seguridad de aplicaciones de
soporte
7. Los servicios como componentes de TI con gestión independiente
Sumado a estos aspectos, hay buenas prácticas que los desarrollos basados en SOA
deberían seguir o al menos tener en consideración:
Mantener suites de pruebas de integración de servicios automatizadas: La suite
debe ser ejecutable según las necesidades, con escaso o nulo tiempo de configuración, y
debe “impactar” en los principales componentes dentro de cada nivel de la pila de
servicio.
Adoptar un marco de pruebas de servicios: A fin de automatizar y mantener suites de
pruebas de integración de servicios, existen ciertas capacidades comunes que se deben
desarrollar y reutilizar. Entre ellas se encuentran:
1. La capacidad de producir agentes de prueba en ausencia de la interfaz de usuario
de una aplicación
2. Generación de mensajes de prueba, basados en la descripción del servicio Web
Services Description Language (WSDL)
3. Variación de datos de entrada, usando una tabla de datos
40
4.
5.
6.
7.
Scripts de desmontaje y configuración de datos
Datos de salida de informes de pruebas
Definición de resultados esperados
Ejecución de pruebas en cada nivel integrado de la pila (por lo general, a través de
un entorno de prueba unitaria)
8. Emulación de servicios externos (falsos)
9. Inspección y validación de mensajes de servicio de aplicaciones consumidoras
10. Envío de múltiples mensajes de prueba a través de subprocesos separados
11. Planificar pruebas de rendimiento: Es necesario tomar medidas de rendimiento
para la implementación del servicio de manera temprana y permanente. No se
puede esperar hasta el final, ya que los cambios de diseño pueden ser costosos.
12. Adicionalmente se deben tomar en cuenta toda buena práctica de desarrollo en
general, como TDD (Desarrollo guiado por pruebas de software, o Test-driven
development), para poder automatizar las pruebas sobre pequeñas partes de
código/funcionalidad, y así lograr un mayor control sobre futuras actualizaciones.
41
DECIMO CUARTO REFERENTE. SOFTWARE A LA MEDIDA
Referente: http://deviatan.com/software-a-la-medida/
Se puede contar con un software personalizado o a la medida hacia el interior de cualquier
organización. Este software personalizado se convierte en un activo importante porque
funciona de manera más efectiva y realiza las operaciones acorde con los requerimientos.
Entonces, el software hecho a la medida es una solución que atiende las necesidades de
cada empresa y canaliza los requerimientos de esta hacia una plataforma productiva y
confiable.
En la acción de determinar si su empresa u organización necesita un software hecho a la
medida puede tener en cuenta los siguientes factores:
- La empresa maneja una gran cantidad de entrada de datos
- Si realiza actividades repetitivas día con día
- Si desea ahorrar en mano de obra para ciertas actividades
- Si necesita un manejo más eficaz en la relación con sus clientes
- Si desea simplificar el tiempo en realizar tareas mundanas de la empresa
- Si desea reducir significativamente los errores en ciertas tareas de su empresa.
- Si desea cubrir una necesidad que ningún software genérico de su conocimiento
puede realizar
Es importante resaltar, que todo software a la medida desarrollado, debe de seguir un
proceso de evaluación del prototipo y una vez que el software se encuentre correctamente
testeado e instalado, es necesario que reciba el mantenimiento adecuado y de forma
oportuna.
Figura 51. Ejemplos de Software a la Medida.
Fuente: http://deviatan.com/software-a-la-medida/
42
Figura 52. Interés por Software a la Medida.
Fuente https://www.google.es/trends
43