MODELOS DEL PROCESO ESPECIALIZADO

TAREA V
Arturo Rangel Castillo
SUS USOS
La necesidad de desarrollar aplicaciones software complejas en periodos de tiempo
cada vez más cortos está produciendo importantes cambios en la forma de construirlas,
siendo el desarrollo de software basado en componentes (DSBC) uno de los mecanismos
más efectivos para conseguir este objetivo. Esta nueva disciplina se basa en componentes
software comercial, construido y probado previamente, que se conocen como componentes
COTS (Commercial-Off-The-Shelf).
Esto permite construir una aplicación buscando y ensamblando componentes,
desarrollados por terceros y cuyo código no se puede modificar, que combinados
adecuadamente satisfacen los requisitos del sistema. Trabajos recientes de calidad software
proponen un modelo de calidad específico para componentes, señalando las características
y atributos de calidad más relevantes para este tipo de producto software. Para cada atributo
existen diversas métricas que lo pueden cuantificar y que permiten describir y medir no
sólo su funcionalidad sino también sus aspectos extra funcionales.
Por tanto, un punto importante del DSBC debe ser la documentación de los
componentes. Sin embargo, la información que necesitan los desarrolladores para poder
valorar y seleccionar un componente no suele estar disponible ni en los repositorios
software ni en los sitios de los vendedores de componentes COTS.
En este trabajo valoramos y analizamos la información que los principales
vendedores de componentes COTS ofrecen de sus productos, tratando de adecuar esta
información con las métricas definidas para un modelo de calidad de componentes
software.
Nuestro objetivo ha sido estimar la diferencia existente entre la información que se
necesita para realizar la selección y valoración de componentes y la información que
ofrecen los principales vendedores de componentes software. Además, se ofrecen algunas
recomendaciones y sugerencias para tratar de disminuir estas diferencias.
 El Desarrollo de Software Basado en Componentes (DSBC) aparece como una nueva
disciplina que ayuda a los desarrolladores de software a realizar sus productos con menores
esfuerzos tanto humanos como económicos.
Las normas ISO 9126 [ISO, 2001] e ISO 14598 [ISO, 1999], encargadas de
especificar estos temas, se encuentran ahora mismo en proceso de revisión. El proyecto
SQuaRE [Azuma, 2001] es el encargado de tratar de hacerlas converger, eliminando
algunas de las lagunas e inconsistencias que presentan.
FUNCIONALIDADES
Una de las principales ventajas del desarrollo de software basado en componentes se
basa en la “reutilización” de los mismos. De esta forma, los componentes se diseñan y
desarrollan con el objetivo de poder ser reutilizados en otras aplicaciones, reduciendo el
tiempo de desarrollo, mejorando la fiabilidad del producto final (al usar componentes ya
probados previamente), y siendo más competitivos en costes.
Aunque hasta ahora la reutilización suele suceder principalmente en el ámbito interno
de las organizaciones, el uso de los componentes comerciales comienza a extenderse.
De esta forma se habla de componentes COTS, que han sido definidos como una
clase especial de componentes software, normalmente de grano grueso, que presentan las
siguientes características [Bass et al., 1999]: − Son vendidos o licenciados al público en
general − Los mantiene y actualiza el propio vendedor, quien conserva los derechos de la
propiedad intelectual − Están disponibles en forma de múltiples copias, todas idénticas
entre sí − Su código no puede ser modificado por el usuario
La disponibilidad y uso cada vez mayor de este tipo de componentes está impulsando
notablemente la creación de un mercado global de componentes COTS, que está pasando
de ser la utopía de hace unos años a una realidad cada vez más cercana. La tecnología
básica de componentes comienza a estar los suficientemente madura (a través de
plataformas de objetos distribuidos como EJB, CORBA o .NET) como para que numerosas
empresas la adopten en sus nuevos desarrollos y sistemas de información. Incluso el
gobierno y el ejército norteamericano han anunciado su uso, y han empezado a apostar por
la utilización de componentes comerciales como única vía de mantener sus costes de
desarrollo y mantenimiento de software bajo control [Sweeney et al., 2001].
 SERVICIOS QUE BRINDA CADA COTS
Funcionalidad: Esta característica mantiene el mismo sentido para los componentes
que para un producto software. Podríamos expresarla como la capacidad del componente
para proporcionar las funciones que satisfagan las necesidades establecidas o implícitas
cuando se usa bajo las condiciones especificadas.
Fiabilidad: Es aplicable directamente a los componentes, y fundamental para su
reutilización la subcaracterística de Madurez la medimos en función de los cambios que
sufren las versiones comerciales y la velocidad a la que aparecen la Recuperabilidad, en
función de una serie de atributos que pueden estar presentes o no en su diseño, indicando
los métodos que se utilizan para implementarlos.
Facilidad de Uso: Esta característica, y todas sus subcaracterísticas cambian de
sentido, dado que un componente no será utilizado por un usuario final directamente sino
por los diseñadores y desarrolladores de aplicaciones software la facilidad de uso real de un
componente debe interpretarse como la capacidad del componente para ser utilizado en la
construcción de un producto o sistema software. En este sentido buscaremos atributos que
midan la facilidad de uso del componente durante el diseño de las aplicaciones.
Eficiencia: Vamos a respetar la definición y clasificación que hace la ISO de esta
característica (en Comportamiento Temporal y Utilización de Recursos), aunque la mayoría
de las propuestas de otros autores prefieren hablar de Rendimiento (Performance) y usan
otra subclasificación. En cualquier caso, los atributos que vamos a definir para medir estas
características son aplicables de forma independiente al nombre y clasificación que se
utilice.
Mantenibilidad: La facilidad de mantenimiento o mantenibilidad mide la capacidad
de un producto software de ser modificado, entendiendo por modificación cualquier
corrección, mejora o adaptación del software. En este sentido, y aunque las 6
modificaciones internas no serán realizadas por el usuario del componente (desarrollador),
sí necesitará probar el componente antes de incluirlo en su aplicación o cambiar alguno de
los parámetros que se pueden particularizar. Por ello, las subcaracterísticas Cambiabilidad y
Facilidad de Prueba son las que deben ser medidas para los componentes.
Portabilidad: Esta característica se define como la capacidad del producto software
para poder ser reutilizado en distintos entornos.
 En COTS, esa es la esencia misma de los componentes, que son diseñados y
desarrollados específicamente para ser reutilizados. (Es importante observar que en la
Ingeniería del software Basada en Componentes, reutilizar significa no sólo usar más de
una vez, sino usar en distintos contextos [Szyperski, 1998]).
Las tres primeras columnas de la Tabla 4 muestran los atributos de calidad para
componentes COTS mensurables en tiempo de ejecución. Similarmente, las tres primeras
columnas de la Tabla 5 muestran los atributos de calidad mensurables durante todo el ciclo
de vida. Una descripción detallada del modelo de calidad para componentes y de los
atributos de calidad se puede encontrar en [Bertoa y Vallecillo, 2002].
LENGUAJE Z
es un lenguaje formal utilizado en ingeniería del software para la especificación
formal de un sistema de cómputo, como una fase previa al desarrollo del código de
programa para el mismo en un lenguaje de programación.
Fue desarrollado por Jean-Raymond Abrial mientras formaba parte del Grupo de
investigación en Programación del Laboratorio de computación de la Universidad de Oxford.
El lenguaje Z se basa en la teoría de conjuntos, el cálculo lambda y la lógica de primer
orden en Z se definen construcciones denominadas esquemas para describir el espacio de
estados del sistema y las operaciones que sobre el mismo se efectúan en los esquemas se
declaran variables y predicados que afectan los valores de las variables declaradas.
ESTRUCTURA DEL LENGUAJE Z
En la primera línea podemos observar la declaración de dos conjuntos, el conjunto de
todos los nombres: NOMBRE y el conjunto de todas las fechas: FECHA, en la
especificación se los declara como tipos básicos.
El primer esquema que vemos: AgendaCumple es el esquema principal de la
especificación y define el espacio de estados del sistema. En el mismo se definen las
variables: contactos (como el conjunto de nombres cuyos cumpleaños están agendados –
subconjunto de todos los nombres - ) y cumple como una función parcial con dominio en el
conjunto NOMBRE e imagen en el conjunto FECHA; en la siguiente parte del esquema se
define una condición o invariante del sistema, que en este caso indica que el
conjunto contactos es igual al dominio de la función cumple.
 El esquema IniciarAgendaCumple representa el estado inicial del sistema.
Los siguientes esquemas definen las operaciones que se realizan sobre el sistema:
El esquema AgregarCumple especifica la
operación de agregar un nuevo cumpleaños, la letra
griega delta delante del nombre del esquema
principal, indica que luego de esta operación se
producirá un cambio de estado, luego se declaran
dos variables: nombre? y fecha?, la decoración (?),
indica que son variables de entrada; las condiciones
que se declaran son que los valores de la
variable nombre? NO deben pertenecer al
conjunto contactos y que el estado inmediato
posterior del conjunto cumple (cumple') es igual al
estado anterior unión la upla conformada por el
nombre y la fecha ingresadas.
El esquema BuscarCumple especifica la
operación de búsqueda de un cumpleaños dado un
nombre, se puede apreciar que las variables
de salida poseen la decoración (!), en este caso la
letra griega theta delante del nombre del esquema
principal, denota que esta operación no producirá un
cambio de estados.
Aquí las condiciones son que los valores de la variable de entrada nombre? deben
pertenecer al conjunto contactos y que el valor de la variable de salida fecha! será igual al
valor devuelto por la función cumple aplicada al valor de la variable nombre?
Finalmente el esquema Recordatorio especifica la operación que dada una fecha, el
sistema nos devuelve el conjunto de los cumpleaños que ocurren en la misma, como puede
verse tampoco modifica el estado del sistema y la condición indica que la variable de
salida tarjetas! deberá ser igual al conjunto de nombres tal que al aplicar la
función cumple sobre cualquiera de ellos el resultado es igual al valor de la variable de
entrada hoy?.
 NOTACIÓN QUE EMPLEA EN EL LENGUAJE Z
El resultado del trabajo de varias décadas sobre lenguajes de especificación formal y
métodos rigurosos para el desarrollo de sistemas de computación. La esencia de tales
lenguajes y métodos la constituye un soporte matemático que busca asegurar precisión y
trazabilidad.
Las descripciones convencionales, generalmente se dan en lenguaje natural o en
diagramas, pero es complicado hacer que estas no sean ambiguas y por tanto difíciles de
analizar. Los errores y las omisiones en los sistemas de computación son costosos de
rectificar y pueden poner en peligro su vida útil y apropiado funcionamiento.
Las técnicas formales se justifican particularmente, para sistemas con los siguientes
atributos:
Complejos: muchos sistemas, de por sí son complejos y la tendencia es producir
sistemas cada vez con mayor complejidad.
Concurrentes: son sistemas que exhiben patrones complejos de comportamiento y
potencialmente interferentes que deben ser entrelazados.
La concurrencia surge en sistemas distribuidos, sistemas en tiempo real, diseño de
hardware y procesamiento en paralelo.
Calidad crítica: son sistemas cuyas fallas no son peligrosas, pero cuya confiabilidad
es altamente importante; ejemplos de esto son las aplicaciones financieras, las de
telecomunicaciones y los sistemas operativos.
Protección crítica: son sistemas que controlan actividades vitales tales como la
defensa, la medicina, la industria nuclear, las telecomunicaciones y la gestión del tráfico
aéreo.
Seguridad crítica: con el uso extendido de las tecnologías computacionales puede ser
esencial impedir el uso no autorizado de información o facilidades de computación, por
motivos de seguridad y confidencia comercial o privacidad personal.
Estandarizados: los estándares, en particular los internacionales, suelen ser
ampliamente utilizados y deben ser interpretados uniformemente, si se quiere que tengan
algún valor.
 VENTAJAS Y DESVENTAJAS POSEE EL LENGUAJE Z
Ventajas: Se convirtió en una norma internacional bajo ISO denominada: ISO/IEC
13568, existen distintas herramientas de apoyo para el testeo como: Z Word Tools
y Community Z Tools Project (CZT)

Desventajas: Poca documentación que guíe a fondo el aprendizaje e implementación

de método formal, carencia de ejemplos prácticos de aplicación, pocos casos de éxito
documentados.
LA PROGRAMACIÓN ORIENTADA A ASPECTOS
Es un paradigma de programación que permite una adecuada modularización de las
aplicaciones y posibilita una mejor separación de responsabilidades (Obligación o
correspondencia de hacer algo).
Gracias a la POA se pueden encapsular los diferentes conceptos que componen una
aplicación en entidades bien definidas, eliminando las dependencias entre cada uno de los
módulos. De esta forma se consigue razonar mejor sobre los conceptos, se elimina la
dispersión del código y las implementaciones resultan más comprensibles, adaptables y
reusables. Varias tecnologías con nombres diferentes se encaminan a la consecución de los
mismos objetivos y así, el término POA es usado para referirse a varias tecnologías
relacionadas como los métodos adaptativos, los filtros de composición, la programación
orientada a sujetos o la separación multidimensional de competencias.
DIFERENCIA DE LOS OTROS PARADIGMAS DE PROGRAMACIÓN
AspectC ++: Es un conjunto de extensiones del lenguaje C ++ para facilitar la programación
orientada a aspectos con C / C ++.
AspectJ: La Programación Orientada a Aspectos (AOP) es un paradigma de programación
cuyo objetivo es aumentar la modularidad al permitir la separación de preocupaciones
"transversales".
Spring: Es un framework para el desarrollo de aplicaciones y contenedor de inversión
de control, de código abierto para la plataforma Java.La primera versión fue escrita por Rod
Johnson, quien lo lanzó junto a la publicación de su libro Expert One-on-One J2EE Design
and Development.
 BIBLIOGRAFÍA
Arturo Rangel Castillo
Manuel F. Bertoa, José M, Atributos de Calidad para Componentes COTS: Una
valoración de la información ofrecida por los vendedores. ´´, Universidad de Málaga, 02-
XI-2020, México, http://www.lcc.uma.es/~av/Publicaciones/03/TICS03.pdf
Jonathan Bowen, ´´Lenguaje Z´´, Wikipedia, 02-XI-2020, México,
https://es.wikipedia.org/wiki/Lenguaje_Z#Est%C3%A1ndar
José Nelson Pérez Castillo, ´´Métodos Formales y Tecnologías Orientadas a
Objetos´´, Revistas Udistrital, 02-XI-2020, México,
https://revistas.udistrital.edu.co/index.php/reving/article/view/2282/3084

Jesús Lobato Baez, ´´ Lenguaje de Especificación Formal Z "en breve"´´, blogspot, 02-XI-
2020, México, http://jesuslobatobaez.blogspot.com/2013/12/lenguaje-de-especificacion-
formal-z-en.html
Arturo Federico, ´´Programación orientada a aspectos´´, Wikipedia, 02-XI-2020,
México,
https://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_aspectos#:~:text=La%20
Programaci%C3%B3n%20Orientada%20a%20Aspectos,o%20correspondencia%20de%20
hacer%20algo).
.
Uriel Ruelas, ´´ Modelo evolutivo´´, codingornot, 02-XI-2020, España,
https://codingornot.com/que-es-la-programacion-orientada-a-aspectos-aop